要約「人が増えても速くならない〜変化を抱擁せよ〜」
こんにちは
本日は最近読んだ書籍の中から、みなさまにおすすめしたい一冊
「人が増えても速くならない 〜変化を抱擁せよ〜/倉貫義人」
について一部要約しご紹介したいと思い
ます。
この書籍で語られている内容は、私がこの業界に従事した当初、いえそれ以前から何度となく言及されつづけていた課題について、非常にわかりやすく言語化されています
ビジネス・テックいずれの職種を問わず、プロダクト開発のプランニングに関わる方には是非おすすめしたい内容です
もし、この記事で興味を持たれたら是非手にとってみてください。
そしてできるならば、感想戦をできれば幸いです
本書の要点
人を増やしたり、プレッシャーをかけても速く作ることはできない。むしろそれは、コミュニケーションコストや技術的負債を蓄積し生産性を低下させてしまう
正確な見積もりと約束をとりつけようとしてはいけない。事業側と開発側が”受発注”関係ではなく、協働の関係を築くこと。「何を作るのか」ではなく、「何を実現したいのか」を伝えることで価値を生みだすことができる。
変化をないものとして、管理やコントロールをしない。変化を前提として柔軟に動けるように、扱える範囲を小さくし、なるべくシンプルな状態を保つ
要約
ソフトウェア開発は人数に比例して生産性が上がるものではない
何か物を作るような製造現場では、一般的に人数を増やせば、生産性は上がる。
一方でソフトウェア開発はそうではない。
エンジニアの仕事の本質は単純なコーディングではなく「求められている機能を、どう実現するのか考えること」である。
例えるならば、家を建てる時の設計士のようなものだ。
施主と議論を重ね、理想の家はなにかを見極めて、設計を行う。
もし、一つの家を建てるのに５人の設計士がいても、生産性は5倍にならない。
むしろ意見の調整や、情報共有で生産性は落ちてしまう。
エンジニアを設計士ではなく、大工であったりとか、開発チームを一般的な物作りの製造ラインのように捉えていると、「人を増やせば生産性は上がる」という誤解をしてしまうことになる。
人を追加するのではなく、時間をかけて生産性の高いチームをつくる
「遅れているプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけ」
これは、1975年出版の「人月の神話」の文章であるが、いまもなお通じる内容である。
あとから参加した人と既存のメンバーでは、前提となる情報・知識・認識が揃っていない。情報や知識のキャッチアップや教育にはコストがかかり、さらに人数が増えるほどにコニュニケーションに時間が必要になる。
また、タスクを分解するのにも限度はある。もし誰かに細かく指示を出さなければいけないのであれば、自分でコーディングをして、直接コンピューターに指示をしたほうが速いのだ。
生産性の高い「速く作るチーム」には、チームワークとコミュニケーションが欠かせない。率直に意見を言い合える心理的安全性を備え、信頼関係があり、仕事をする上での哲学や文化が揃っている。
そうしたチームを作るには、共通体験が必要で時間がかかる。
ソフトウェアを育てていくように、チームも育てていくことでスピード感をもって変化に適応できるようになる。
プレッシャーをかけ急がせると、生産性はより低下する
ビジネスには締め切りがある。
だからといって、プレッシャーをかけて急がせてしまうことは、エンジニアに対して、「作り方」に妥協を強いることになる。
エンジニアリングは手を動かす仕事ではなく、頭を使うクリエイティブな仕事である。
急がせたからといって速く成果は生まれない。
妥協は技術的負債となって残り続けそれ以降の改修や機能追加を困難にして生産性を低下させてしまう。
負債は放置するほどに、利子が嵩むように膨らみ返済にかかるコストは大きくなる。
目先の完成を急がせるために、一時的な妥協で乱雑・複雑に作ってしまった土台をシンプルな状態に戻すのは不可能に近い。
最初からずっとシンプルな状態を維持できるように手を加えることが必要であり、そのためのコストと期間を計画に常に織り込んでおくことが必要になる。
「正確」な見積もりを求めることとバッファの功罪
ビジネスにおいては、「いつできるかわかりません」というわけにはいかないので、どうしても「正しい見積もり」を求めてしまう。そして、厳密に知りたいわけではないので「ざっくりで」という言葉で気軽に見積もりを依頼されることが多い。
ただ、これはソフトウェア開発においては簡単なことではない。
明示されていない詳細仕様の把握、例外的な処理、新技術利用時の制約、担当者の技量、メンバーの数など見積もりを変動させる要素が多岐にわたる。
例えるならば、東京から富士山山頂までの登頂を見積もるようなものだ。地図、直線距離がわかっても
高低差、ルート、移動手段、パーティの人数、体力、年齢などによって変わってくる。
一方で精度を高めるために、詳細まで検討をしようとするならばその時間は実際にかかる時間と変わらなくなる。つまり、正確な見積もりは実際にやってみることでしか出せない。
このような状況で、見積もりと、その計画の厳守を強く求めるとどうなるのか。
最大限にリスクを盛り込んだ「守れる」見積もり。つまり大きなバッファを含む見積もりになってしまう。
受発注の関係ではなく、協働の関係であること
事業側と開発側が、頼む側と頼まれる側というような受発注関係の構造になってしまと、見積もりや計画が「約束」となってしまう。こうなるとその「約束」を守らせること、守ることが重要視され、見積もりにはバッファが膨らむようになり「依頼されたものを期限内に作る」ということが最優先となってしまう。
システム開発においては、事業側、開発側が相互に理解を深めて協働し、システムを作ることだけを目的とした体制やマネジメントをしないことが重要である。
そのためには、一度に機能・期間について大きな約束をして、出来上がるのを待つというスタンスではなく１〜２週間で少しずつ確認をしながら作り上げていくほうがよい。
ポイントは機能ありきで期間を見積もるのではなく、期間ありきで機能を見積もることだ。
エンジニアには「何を作るのか」ではなく「何を実現したいのか」から相談をしてチームとなることが、受発注関係となることを避けて、協働関係を構築するのに重要である。
変化を管理・コントロールするのではなく柔軟につきあう
物理的に形のないものは変化をし続ける。
変化を前提とし、それに柔軟に対応できるようにするために必要なことはなにか。
不完全さを受け入れ、すべてを予見しようとせず、扱う範囲をシンプルに小さなものに保つことがポイントである。
作りたいものを一度に作ろうとしないこと。
ソフトウェアは一度作って終わりではなく、継続的に手をいれていくものである。
ソフトウェアが生きている限り不確実性はゼロにはならない。
だからこそ一度に大雑把に進めるのではなく優先順位を決め、スコープを絞り不確実性を下げた状態で作り出して進めていくことが重要である。
おわりに
本書は、私自身これまでのキャリアの中で何度となく目にしてきた事業側と開発側のコンテキストのギャップから生まれるジレンマ、すれ違いとその解決のヒントについてとても分かりやすく表現されています。
（このくらいの言語化能力があれば、もっとプロジェクトをうまく回せたのだろうか）
納期が迫り、プレッシャーに負け、将来に技術的負債を残してしまっていないか。チームを守るために、受発注関係でみられるようなバッファをいたずらに積んでしまっていないか。
自分自身を省みるきっかけにもなるなる一冊でした。
事業側、開発側いずれの方にもこれから協働関係を維持していく上で参考になるところがあれば幸いです。
この記事が気に入ったらサポートをしてみませんか？