まとめ
- プロジェクトの組み込みソフトウェア部門の設計リーダーをやることになった
- 勉強のために『人月の神話』を読んだ
- プログラマは基本的に工数見積もりが甘い
- 少数精鋭チーム最高
- コミュニケーションはめっちゃ大事
- 1日1日のじわじわとした遅れが破滅へとつながる（緩慢な死）
- 今後のプロジェクトではさらに活かしていくことができそうだ
導入
今のプロジェクトでソフトウェア部門の設計リーダーを任されることになったとき、とても気合が入りました。
コロナ禍によってわが社の業績は一気に悪化し、それを立て直すためにコケる訳にはいかない製品だったからです。
また、なにより僕にとって初めての設計リーダーの経験となるので、気合を入れていく必要がありました。
そこで、設計プロセスの勉強がてら前から読みたかった本『人月の神話』を購入して読むことにしました。
1970年代に出版された本ですが、非常に読む価値のある本です。
実際にプロジェクトが進んでいく中でこの本から得た知見が役に立つことが多々ありました。
内容をざっくりと紹介します。
プログラマは純粋な思考からなるもので組み立てるため、実現の困難さをほとんど予想していない。
だが、アイデア事態に間違いはつきものであるから、バグが発生することになる。
僕の実感の中でも、たいていの組み込みソフトウェア屋さんは工数の見積もりがヘタです。
僕がよく「どのくらいでできると思う？」と聞くと、
- 全然できないひよっこちゃんは、「・・・」と答えに窮します。
- ちょっとできる子は見積もりが甘く、実際よりも少ない見積もりを言ってしまい、結果として納期に遅れます。
- できる子ほど正確な見積もりを出してきます。そして大抵は見積もりよりもすこし早く終わります。（これが一番うれしい）
論理的な思考の中で、「ああ、たぶんこうすればできるな」とか「おそらくこれが原因だろう」という自分の中で予想を立ててどのくらい工数がかかるか見積もると思います。
たしかに今解決すべき課題にフルコミットできれば、見積もり通りに終わるのかもしれません。
しかし現実には、著者がいうように着想に間違いがあるかもしれない、また、ほかの業務の割り込みがあったり、体調がよくなくて頭が回らなかったり、デバッグのための装置が使えなかったりという障害が高確率で発生します。
それも考慮したうえで見積もりを出すべきでしょう。
コストをもとにして組み立てられた見積もり技術は、労力と進捗を混同している。人月は、間違った危険な神話である。というのも、人月とは「人」と「月」が相互に交換可能だということを意味しているからだ。
筆者は人月は間違った思想だと断言しています。
人を増やせば工数の問題が解決するかというと、プログラミングの開発現場ではそうではない、ということです。
人を増やせば増やすほどコミュニケーションのために必要な時間が増える。
再配分作業とそのための中断、新しい要因の訓練、それから新たに必要となる相互コミュニケーション。
これらの時間的コストを甘く見てはいけない。
少数精鋭チームが最高である。人数はできるだけ少ないほうが良い。
筆者はこう言い切っています。
上記のコミュニケーションのコストもばかにならないし、それ以外にも大人数がよいというのは間違いだということを理由付けで言及しています。
これも実感としてわかることです。
設計にかかる時間は個人の能力に大きくかかわると思います。
また、設計の質に関してはさらに大きく変化します。
能力の低いプログラマは、能力の高いプログラマが考え出す設計を一生かかっても思いつきすらしないかもしれません。
しかもバグを埋め込むリスクもあります。
能力の高いプログラマは本当に、ぜんぜん、バグを埋め込みません。
それに対して能力の低いプログラマは、バグ埋め込み職人です。
ソフトウェアという論理によって作動するシステムに、論理的な思考ができない能力の低いプログラマのコーディングが混ざることで、全体が損なわれてしまう例は枚挙にいとまがありません。
経営者は、能力の高いプログラマを確保するために高い給料を払うべきですね。
この本は有名なブルックスの法則についても言及しており、その法則の確からしさを高めています。
「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」
- 人数を増やすことによりコミュニケーションコストが増大すること
- 能力の低いプログラマによってバグを埋め込まれるリスクが増大すること
これらのリスクを排除するには、少数精鋭チームが理想的だ、と言っています。
バベルの塔はコミュニケーションとそこから生まれる組織がなかったために失敗した
コミュニケーションはまじで大切だよ！と筆者は言っています。
チームごとでやっていることがばらばらであるため、スケジュールの悲惨な状態だとか機能がうまく合っていないとか、システムのバグなどが一度に発生する。
これはわが社で言えば、組み込みソフトウェア部門だけの問題ではなく、メカ屋さん、電気屋さん、さらにほかの部門も含めてチームワークを形成しなければいけません。
各部門の同期がとれていないことによりスケジュールの遅延は、わが社のようなスピード感がすごいプロジェクトではよく起こる問題です。
そしてこの問題による時間的ロスはとても深刻です。
筆者はコミュケーション不足に陥らないためにこうするべきだと言っています。
チームは可能な限り多くの方法で互いにコミュニケーションを図るべきだ。つまり非公式の会話や技術的な概要報告を行う定期的なプロジェクトミーティング、教養の正式なプロジェクト手引書などを通してだ。（電子メールも使って）。
今ではTeamsによるチャット機能もあります。
これによって他部門とのやりとりが円滑に進むこともあります。
（ケンカみたいになるときもありますが・・・）
とにかくそれでもコミュニケーション不足になるよりはましでしょう。
より正確な工数見積もりを出す
プログラム開発プロジェクト全体の労力やスケジュールは、単にコーディング時間を見積もってそれに作業のほかの部分の比率を掛け合わせただけでは、正確に見積もることはできない。
プログラム全体の規模が大きくなるほど、実際に設計やコーディングにかかれる時間は減少する、ということです。
筆者は基準となる規模から1.2の指数をかけた工数であるべき、と言っています。
確かにわが社でも、これから1年以上続くプロジェクトが始まるというときに、まず工数の概算を見積もります。
その際に搭載する機能をリストアップして、単純にそれらによってかかる工数を足し算していました。
これではダメ、ということですね。
そこにさらに、規模が大きくなるほど余分な工数がかかるよ、ということを上の人に説明して見積もりを上乗せする必要があります。
（上の人が耳を貸してくれるかわからないけど）
プロジェクトはどうして大幅に遅れるのか
これが一番身に染みた内容でした。
プロジェクトは度重なるアクシデントによって、不運にも大幅に遅れるのではない。
破滅的な状況は竜巻のような突発的なものではなく、シロアリのようにじわじわ忍び寄ってくるものが原因である。
プロジェクトがどうして遅延してしまうのか、今までは僕は設計リーダーではないので他人事のように考えていましたが、設計リーダーになったのを機に真剣に考える必要がありました。
プロジェクトは1日1日の遅れが、取り返しのつかない遅れにつながる、このことに最初に気づけたのは幸運でした。
しかしやっかいなことに日ごとのじわじわとした遅れは、気づいた時にはどうしようもない、ということです。
遅れないように予防するしかない。
現代のアジャイル開発やイテレーション開発はそのために存在するのだと実感できました。
スキのないスケジュール表を作り、進捗管理を徹底すること、これがプロジェクト遅延のための最大の対策ということになります。
予定外の事態には反復的なスケジュール管理とフィードバック（イテレーション開発）によって対応する必要があります。
決まり切ったウォーターフォール開発では絶対に対応できません。
そして筆者はこうも言っています。
とめどなく遅れていくスケジュールはやる気殺しというべきものだ。
おわり
いかがだったでしょうか。
いまこうして振り返ると、僕がプロジェクトで実施することによっていい影響のあったものも多々あります。
しかし本の内容を実践しきれていない部分もあります。
特に最後のプロジェクトの遅れというところは、今まさに直面しつつある問題です。
（遅れが発生し始めている）
あと、プロジェクト全体の工数見積もりも甘かったなと感じています。
今回振り返ったことで、今後また新たにプロジェクトに取り組む際に活かせそうです。
今回のプロジェクトの遅れは、もう残りは足がもつれながらでも、這ってでもゴールするしかありません（笑）
いい勉強になりました。
