なかなかの難問である。オレなら「情報の粒度」って言うけど今回は元ポストの通り「情報のロットサイズ」で通す。
エンジニアリングの「情報のロットサイズ問題」とは、上流から次工程に、どんなかたまりで設計情報を流すかの問題だ。大きすぎると全体リードタイムが長くなる。だが設計データは互いに関係し合っている。だから小さすぎると、下流側は全体が見えないまま設計することになり、あとで手戻りが生じる。
— 佐藤知一 (@tomoichi_sato) 2024年2月5日
基本的には「そこは合議」だと思う。
オレの場合例外を除くと、基本設計のたたき台を全部まるっと一人で書く。例外の例はこちら。
ソフトウェア開発という少し範囲を広く表現しているからプログラミングだけじゃないと思う。なのでシステム開発の昔話を書く。
オレが獲得した大規模案件で最初から大人数投入という暴挙に出た。オレが獲得した案件は通常オレが基本設計全部やる。あくまでまずはたたき台としてだが。全部一通り基本設計を書いてそこで人を入れてレビューする。そのレビュー結果を修正し、そこで初めて担当者に分割する。プロジェクト管理の基本で、段階的に詳細化する手法である。
最初から大人数で基本設計をする弱点は複数ある。
担当者の能力差で設計内容に差がでる。担当者間の力関係が設計に反映されてしまう。担当者間の境界でダブりや抜けが出る。設計の粒度、詳細化度が設計者によって差が出る などである。上に書いたようにコミュニケーションコストも付加されるので、10人で設計したからといっても1人で設計した10倍の成果にはならない。2倍になればいいほう、ヘタすりゃ0.8倍くらいということはよくある。
このケースでは親会社のエラい人の意向なので一応抗議した後に受け入れたけど、時間は掛かるわ上に書いたような問題は頻出するわで多分2倍の成果も出てない。コストを無視してもオレに全部任せた方が良かった。
親会社の若手のエースがバカな子で、「バッチサーバー」なるものを作り出してしまった。当人は自分の担当範囲のバッチ処理をするサーバーのつもりだったようだが、他の担当がこぞって自分の担当範囲のバッチ処理を投げていいか聞くことに。オレも聞いた。今回の本題とは異なるが、システム内のネーミングは「名は体(たい)を表す」でいかなければこのような混同を招く。
この不毛なバッチサーバー問題ミーティングは合計6時間は使ったと思う。1人で6時間じゃなく10人以上で各6時間だよ。だからダメなんだよ最初から大人数の設計は。
レビューに参加する人たちの中には、純粋にレビュアーというより次工程の各パートのまとめ者も参加している。なので基本設計書としてそれぞれのパートをどのようなロットにするかは「情報のロットサイズ問題」でもある。ここでレビューを受けながら合議する。
ただし、パートごとにはロットサイズは変えない。そこをパートごとに変えてしまうと、基本設計と詳細設計でデコボコになる。基本設計で踏み込んで書いているパートと詳細設計に投げているパートがバラバラだと、後年設計書を見て混乱することになる。
記述レベルを基本設計側で揃えることで、次工程以降に同じロットサイズで設計を引き渡すことができる。
簡単そうに書いたけど、普通の人がやると自分の得意なパートはやけに詳しく、そうでもないパートはそっけない書き方だったりする。それはあまりよろしくない。幸いかどうか、オレには専門分野が無いので特に思い入れもなく平準化を優先する。細かい実装レベルのことを思いついても書かない。次工程の担当者がもっといい手を考えるかもしれないじゃん。
ロットサイズの平準化も上流から仕込む話をまず書いたけど、これは確かに難しい問題である。
大きすぎると全体リードタイムが長くなる。だが設計データは互いに関係し合っている。だから小さすぎると、下流側は全体が見えないまま設計することになり、あとで手戻りが生じる。
だから、そこそこの規模のシステムを構築するのであれば、常に全体をコントロールするアーキテクトが常時必要である。プロジェクトマネージャとは別に。
へえ、こんな本があるんだ～。本読んでできるならラクなもんだ。
このタイトルは笑うって。用紙サイズは関係ないだろ。A3用紙1枚に全部書けるレベルのシステムばかりじゃないし、逆にA4でも全部描き切れるシステムもある。表記ゆれはわざと。培った技ねえ……
つまり、上流から次工程に情報を流すこと作業の進捗に応じては次々に起こるし、最上流から実装レベルまで同じ思想で、段階的に詳細化されていかなければならない。そこのコントロールの要素の一つは情報のロットサイズの段階的な分解でもある。きれいに1/n倍化されていくと気持ちいいし、設計ミスも内包しにくい。ロットサイズばらばらだとどこかに抜け漏れが入り込む。
中学生でもサクッとわかるらしい。
中学生にもわかるのはいいけど、これができるかできないかは経験じゃないと思うんだよね、個人の感想としては。
経験「は」必要だけど、じゃあ経験年数が長いとかならできるようになるかといえば、それは違うなと。俯瞰で見るとかメタ化するとか、そういう実質的な手法を言語化しにくいスキルが必要じゃないかと。俯瞰で見ましょうって言われて「見ました、なにも感じません」って人には難しい。俯瞰で見た時、逆に部分的に変なところがあるって見えてくるんだけど、それってすごく個々の事象によるから普遍的な言語化が難しい。
