こんにちは。アイレット デザイン事業部でディレクターをしている ivanov です。
倉貫義人氏著「人が増えても速くならない〜変化を抱擁せよ〜」を読みました。大変考えさせられる良い内容でしたので、紹介させてください。
お客様とのやりとりの中で、プログラミングやソフトウェア開発のご経験があまりないために、プロジェクトの進行において戸惑われる場面に何度か遭遇したことがあります。これは、ソフトウェア開発特有の注意点や、一般的な製造プロセスとの違いに起因します。本書に挙げられている例としては、以下のようなものがあります。
- 人を増やしたからといって、速く作れるとは限らない
- 正確な見積もりを求めたら、見積もりが膨らんでしまう
- 一度に大きく作ろうとするほど、結局は損をしてしまう
「このようなギャップを埋めていくことで、ビジネスもソフトウェアももっと良くなる」という著者の倉貫氏の考えにとても共感しながら読み進めました。本書には以下のような内容が書かれています。
- 完成しても、終わりではない
- 人を増やしても速く作れるわけではない
- たくさん作っても生産性が高いとは言えない
- 人に依存せず同じ品質で作ることはできない
- プレッシャーをかけても生産性は上がらない
- 見積もりを求めるほどに絶望感は増す
- 一度に大きく作れば得に見えて損をする
- 工程を分業しても、効率化につながらない
1. 完成しても終わりでない
システムを開発してリリースすることはゴールではなく、スタートです。ビジネスの改良・改善にともなってシステムにも改修が必要となるため、これまでのプロジェクト型の開発から、システムを事業のコアとなるプロダクトとして捉え、発展させていく考え方に変えていく必要があります。
2. 人を増やしても速く作れるわけではない
エンジニアの仕事は「設計者」でありプログラムを書くだけの「作業者」ではないことから、人を増やしても必ずしも速くなりません。また、後から入った人への情報や知識のキャッチアップとその人たちへの教育にコストがかかること、コミュニケーションにかかるコストが増えること、タスクを分解して分業するにしても限界があります。
ただし、高い生産性を出せる環境は用意できるし、速く作れるチームに育てていくことは可能です。
3. たくさん作っても生産性が高いとは言えない
システム開発において、プログラムを書く仕事で求められるのは「抽象化能力」で、手を動かしてプログラムを多く書くことではありません。抽象化されたプログラムはシンプルになるので、プログラムを量で測って評価してしまうと、よくないプログラムが量産されてしまうリスクが発生してしまいます。
4. 人に依存せず同じ品質で作ることはできない
ソフトウェアには「見やすい」「操作が簡単」「動きが軽い」などの外形的な品質の他に、「（エンジニアの）誰にでも理解しやすく作られているか」「あとから修正を加えることを考慮されているか」といった、見た目からはわからない品質があります。そして、内部的な品質の違いは、作った後の生産性に影響を与えます。
5. プレッシャーをかけても生産性は上がらない
プレッシャーをかけることで開発速度は上がる可能性はありますが、プログラムの品質が下がるリスクも発生します。プログラムはリリースしてしまうと、影響範囲があるので、影響範囲の大きさによっては品質を上げるためであっても、後から書き換えることに大きなリスクがある場合も出てきます（システムの稼働を止めなければならないなど）。そして、そのような状況で書かれたプログラムはシステムにとって永遠の負債となります。
6. 見積もりを求めるほどに絶望感は増す
「実際に開発を進めた時にはじめの想定と異なっていた」などのケースもよくあることから、事前に正確な見積もりを作ることは非常に難しい作業です。そのため、想定されるリスクに対してバッファを積むのですが、その分、見積もりの工数はどんどん増えていきます。また、見積もりの精度を上げようとすると、見積もりする作業そのものに時間がかかるようになってしまいます。
7. 一度に大きく作れば得に見えて損をする
ソフトウェアを作る際は「あれがあったらユーザーは喜ぶ」「これがあったら便利」など、大きな夢を詰め込んでしまいがちです。それ自体は悪いことではなく、夢は大いに語るほうが良いのですが、いざ、その実現のためのソフトウェアを作ろうとする際に要件をたくさん詰め込んでしまうと、それだけ開発にお金と時間を要してしまいます。
大規模なソフトウェアを作る場合は、一度に作るのではなく、小さく分けて作っていくことで失敗のリスクを下げることができます。プロジェクトが不確実な時に大きく作るのはギャンブルと同じで大きく賭けると大きく失敗するのです。「近い未来は解像度を高く、遠い未来は曖昧なまま」という方針でロードマップを作成し、常に見直していくようにソフトウェア開発もマネジメントしたほうが、損をしない開発になります。
8. 工程を分業しても、効率化につながらない
プログラミングは「製造」と誤解されがちですが、実際はコンピュータを動かすための「指示書」です。ソフトウェア開発には「製造」という工程がなく、すべてが「設計」なのです。だから、単純に分業したりアウトソースしたりしただけでは上手くいかないことが多いのです。
これからは事業に対して変化を受け入れ柔軟に対応していくことが必要となってきます。事業の根幹をなすシステムもまた同様の対応が求められます。ゆえに、事業者側の人間と開発側の人間もワンチームになっていく流れになっていくでしょう。
本書読了後に思ったこと
本書はシステム開発における考え方の本で、主にエンジニアとプログラミングに関して書かれています。しかし、システム開発におけるデザインにも、ほぼ同様のことが言えると思いました。
特に、新規ビジネスを開発するに当たってはリリースするまでの速さが最も重要なことの一つになるので、そのためにスモールスタート・スケールアウトの考え方が大事で、まずは、想定ユーザーにとってサービスの価値を体験するための最低限の機能を実装することが必要です。このことも本書の内容と合っていると思いました。
弊社においてはデザインチームと開発チームが仲良くコミュニケーションをとりながら開発を進めていますが、そういう環境もシステムを速く作るためには必要なことだということがわかって、ちょっと嬉しくなりました。
簡単30秒