「人が増えても速くならない ～変化を抱擁せよ～」を読みました。

どんな本？

ユーザー数が伸びるにつれて多くの要望が出てきても，新しい機能をスピーディーに追加できなくなってきた。ちょっとした修正のはずなのに，ものすごく時間がかかる。

――そのようなことが起こる原因は，ソフトウェアが変化に適応できないから。

プログラミングを学んでも理解できないソフトウェアの本質を，プログラマーとして12年，経営者として12年の経験を持つ著者が集大成。

・完成しても終わりではない
・人が増えても速くならない
・たくさん作っても生産性が高いとは言えない
・人に依存せず同じ品質にはできない
・プレッシャーをかけても生産性は上がらない
・見積もりを求めるほど絶望感は増す
・一度に大きく作ると得に見えて損をする
・工程で分担しても効率化につながらない

これからの事業の成長に欠かせない思考法がわかる。

人が増えても速くならない ～変化を抱擁せよ～：書籍案内｜技術評論社

https://gihyo.jp/book/2023/978-4-297-13565-2

ビジネスサイド・マネジメント層向け

「人を増やしても速くなんないの？」

「見積もりって大事だよ…」

そう言いたくなるほど刺激的な言葉が並んでいます。

どちらかといえば、この本はプレイヤーで稼動するエンジニアよりも、ビジネスサイドやマネジメント層向けの本です。

技術者とコミュニケーションを取りながらプロダクトを開発する中で起こりがちなシチュエーションを例に、ビジネスサイドと技術サイドの認識の違いから生まれるギャップと、どんな体制・方針でプロダクト開発に臨めばいいかのヒントが書かれています。

画面の一部を変えてもらうだけなのに…

「ここの画面をちょっと変えるだけなのに、何でこんなに時間がかかるのだろう」

技術者から、プロダクトの内容を変えてもらいたいときに返ってきた回答にこう思ったビジネスサイドの人は多いでしょう。

しかし、技術者から見ると、少し画面を変えるだけのことにもさまざまなことを検討していたりします。

行き当たりばったりで改修をしては、複雑さを増したプロダクトは機能追加もままならない状態になってしまうし、見た目より影響の多い箇所を改修しなければならない場合は影響する範囲も考えなければなりません。

そういった、お互いの視点から見た認識のギャップが、この本には平易な言葉でまとまっています。

見積もりと約束が「受発注」の関係を作ってしまう

自分が最も印象に残ったのが、第6章の「見積もりと約束が"受発注"の関係を作ってしまう」という言葉でした。

事業側から、「ざっくりと」どのくらいで開発が行えるか「見積もり」をお願いすることは非常に多いと思います。

しかし技術者からすると、これは「約束」に近い感覚があり、簡単には出したくない。

どうしても開発中には不確定な要素が現れてしまうことが多く、開発前に全てを見越すのは難しいのが実情です。

そのため、「約束」を守るために「バッファ」を積んで見積もりが膨らんでしまう。バッファを積めば計画は守られるが、開発期間は長くなり、生産性が落ちる。

また、事業会社の中で内製している場合でも、ビジネスサイドからすればわからないことが多いから技術サイドに「依頼」する形となることが多く、「頼む側」「頼まれる側」の関係→受発注のような関係ができてしまう…

本を読みながら「あるわー…」と唸ってしまいました。

プレイヤーとして、エンジニアとしてこの本を読むと、あるある集として首がもげるほど、うなずきながら読むことになるはず。

ビジネスサイド・技術サイドの相互理解を深めるために

ビジネスサイド・技術サイドが同じ問題に向き合う時、お互いがどんな認識でいるのか。

この本ではこれをシンプルにわかりやすく言語化し、解きほぐしてくれていると思います。

本自体のページ数も少なく、1日で読み切れる分量です。

自分はエンジニア歴が20年を超えていますが、前職・フリーランス時代・現場常駐時代・SAKURUGでの開発業務のほぼ全てで（程度の差はあれ）こんな問題があったなと、この本を読んで思い返しました。

つまり、これはどこにでもある問題を解きほぐしてくれる本になるんじゃないかと。

SAKURUGの中の人にも読んでほしい

いきなりですが、このエントリを書いている人は今月でSAKURUGを退職し、本日が最終出社日です。

しかし、次の職場でもこの本のことは「よかったよー」と布教するつもりです。

そして、SAKURUGの中のいろいろな方々にもこの本を読んでもらい、お互いの理解を深めていって欲しいなという思いをこのエントリに込めたいと思います。

ありがとうございました！