エンジニアが標準モデルを考えるということの意味

組織の中で多分偉い人が「うちでもやろう♡」と言ったのか、誰かが「コミュニケーションを活性化したいんです！」なんて言ったのか知らないけれど、インハウスのsnsがあるのよ。ご多分に漏れず、コテハンばっかりでDAU、Daily Active Userなんて高が知れるくらいなんだけど。

とは言っても別にdisっているわけではないのよ。だって、ネタを見つけてネタがある日は書くもの。「バカだなー、オレ。」って思うくらいの頻度で書くているよ。古いタイプのsnsなので足跡が残るので見ていてくれる人が居るなら書いておこうって思うもんね。

で、先日もネタ振りしたら偉い人にレス付けられた上で召喚されたような書きっぷりだったので、トボトボと席までお伺いしたのね。

「snsのアレの件、レス付けたんだけどさ、アレの絡みで○○さんのところで悩んでいるみたいなんだよ。」
「ふーん。それで？」
「でさ、○○さんにインタビューして欲しいんだけど。」
「あのポストした記事は、hogehogeな主旨で書いたんでちょっと違いますねぇ。」
「いやさ、もうアレを使うときにアレをいちいちローカライズさせるところで悩ませたくなくないんだよ。」
「で、もう、これでやれって言いたいわけ。標準モデル作って♡」
「○○さんに話を聞けばいいんですね。わかりましたー。」

全然わかってないフリしていますが、何か？いやー、どうしようーって感じです。だって、on goingなプロジェクト“も”抱えているのに！その上標準化ですかー。それ美味しいんですかー。それ、何故私に振るのー。って感じです。

選択肢はいくつあるかな―。

スルーする

他の人に振る

諦める

何か詰んだような気がしてきた。ダメだ。負けゲームだ。いやいやそうじゃなくて、標準化の話だ。大丈夫。大丈夫。

標準化と品質
エンジニアが関わる標準化っていうとプロジェクト内のドキュメントの様式を決めたり、作業標準つまり、工程ごとの作業の段取りを決めたりする、所謂、そうしたプロジェクトに関わる標準化を思い出すんですね。これは、自分の経験の中でそうしたプロジェクト内の標準化に関わったことがあるからなのです。

プロジェクトでの標準化をなぜコストを掛けて取り組むのかその理由、狙いがわかっていないエンジニアが多いこと多いこと。だって、「エンジニアなんだから自由に作りたいんだよ。」とか「縛られるの嫌だ。」とか言うくせに、ドキュメントを書かせれば「〜である。」とか「…します。」とか挙句の果てには体言止めをそれこそ自由に使い倒して作成しちゃうわけです。そのプロジェクトに参画するエンジニア誰もが“暗黙で”である調にするとか出ます調にしてくれるならそうしたまるで“てのをは”なんて規定する標準化は要らないわけです。それをできないから標準化するわけです。

現状のプロジェクトの工程を媒介するデータが設計書になっている以上、次工程は“自分ではない”神様の可能性があるのですから受け取るエンジニアに伝わる書きっぷりが必要だし、そもそも次工程を自分が担当するにしても、受っとった時期より前に執筆している設計書なんて“何でそんな設計になっているか”なんて受け取った張本人の自分だって経緯を含めて覚えているわけないんですよ。例え受け取るのが自分であっても他人なのだと思って書いておかなければ工程を跨るごとにバグが混入する危険度合いが高まるんです。

顧客の品質は要求であるからその要求を確保するためにバグの混入を防止したり、欠落をいかに拾うかと言う話になるわけで、それをインシデントが起きてから対処するにはその収束時期と完了見込みのコストが見積もれないからバカがやることでしかないんですよ。そんな見積もれないリスクを抱えるより見積もれるコストで品質をいかに維持するかを考えてプロセスの中に織り込んだほうが何倍もマシなんだと思っています。

エンジニアと標準化
エンジニアが標準化を考える機会を貰えるのはとてもありがたいことです。なぜなら、プロジェクトに関わるメンバがふるまい成果物を作るための標準化されたプロセスを作れるということは、自分の経験の棚卸と書籍やフレームワークなどの形式知を学び直す機会なのですから。

標準化は、その標準化を担当する人の経験値だけでは成り立ちませんし、書籍の形式知では運用が回りません。

自分の経験知だけではなぜだめなのか。それは、これまで自分が経験してきたことがこれから適用するプロジェクトにフィット、つまり適用しきれるか分からないからです。多分、そのままでは適用できないず、何等か手を入れることになるものです。

他方、フレームワークだって概念でしかないんです。つまり“うつわ”でしかないんです。そこには、プロジェクトにフィットしたhow toがない。

だから、deliverableそのもの、プロジェクトの特性や扱う製品、アーキテクチャやメンバの習熟度を計って、どんなプロセスをどれだけ踏んでいけばdeliverableになるのかを最小の手間とコストでできるように組み合わせ調整しなくてはならないのです。

標準化に至るには、それぞれのプロジェクトを構成するインプット情報や中間に吐き出される生産物があって、それらの具体的なアウトプットをdeliverableに変換するための概念に変換する“抽象化”をしなければならないのです。

そこの標準化のプロセスを経ることが現実を抽象化する経験を積ませてくれるのです。これと同じような経験をするならば、要件定義で顧客から要件を聞き出してシステムのアーキテクチャに変換するところくらいです。あとはシステム要件を分解と再編の繰り返しの作業なので。

要件定義に関われるエンジニアの数は限られます。上流工程ではエンジニアを潤沢に投入できるほどコストを掛けられないからだし、経験の中途半端なエンジニアでは顧客要件を抽象化する作業をやり切れないからです。

その点、プロセスの標準化は取り組みやすいし、進行中の行程の中で次工程を準備するなど機会も多々あるものです。標準化は先に述べたようにプロジェクトに関わる関係者すべてが関わることから、共通の概念モデルを作るという機会であって、概念モデルを作るということは抽象化をすることでもあるのでそうした機会は進んで経験を積んでおくことが上流での顧客要件をシステム要件に抽象化するときの糧になるのでしょう。