プログラマーとお仕事をするということ

最近、この本を読みました。

プログラマーとお仕事をするということ
Working with Coders
https://www.shoeisha.co.jp/book/detail/9784798155029

今回は、この本を、強く！オススメしたく、ご紹介します。
※本の対象はソフトウェア開発ですが、ほぼ、インフラの設計構築にも読み替えられます

ちなみに、私は一応エンジニアですが、ちょっと変わってるので、ビジネス系の人の考えもそこそこ理解している方かな、と思ってはいます。
(違ったらすいません)

この本について

タイトルは「プログラマーとお仕事をするということ」ですが、この本が説明していることは、ソフトウェア開発が、不確実性を含み失敗しやすく困難なことである (ビジネス系の人、プログラマ、双方にとって)、ということです。
※「ビジネス系の人」は、主に、営業職の人など、技術系ではない職種の人、を意図しています

ソフトウェア開発とは何なのか、一体何が難しいのか、それを作っているプログラマとは何なのか、理想や思想と現実の乖離など、ビジネス系の人の思考、プログラマの思考、お互いのコミュニケーション、人間の能力、それぞれの立場、特徴や課題が複雑に影響しあうことが、それぞれの視点や思考から、素晴らしいバランスで記載されています。

目次は、↓ の「目次」に記載されています。
https://www.shoeisha.co.jp/book/detail/9784798155029

この中で、特に読んで欲しいものは、

第 1 章　イントロダクション
第 2 章　なぜソフトウェア開発は建築と似ていないのか
第 5 章　緑の大きなチェックマーク
第 9 章　プログラマーを上機嫌に保つ

です！

引用しつつコメント

引用したいところが多すぎて困ってしまいました。。。

第 1 章 イントロダクション

この本に書かれているのは、ソフトウェアはどう作られるのか、どういう人が作っているのかということ、特にソフトウェアを作るプロセスがいかに奇妙で特異性のあるものか、いかに気まぐれで失敗しやすいものかということです。信じてほしいのですが、ソフトウェアプロジェクトというのは失敗しやすいものなのです。大規模組織における IT プロジェクトについての調査で、ソフトウェア作成を含むプロジェクトでは、ソフトウェアを含まないものより予算超過額の割合が平均で 5 割高く、スケジュール遅延期間の割合が平均で 10 倍になることがわかっています。ソフトウェアの作成は誰の予想よりも長くかかり、高くつくだけではありません。その予測が外れ失望させる度合いが驚くほどなのです。

日経コンピュータによる調査結果もあります。
システム開発プロジェクトの5割が失敗、1700件を独自分析
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00177/022100001/

「10年前に比べ大きな進歩だ」。ITプロジェクトの動向に詳しいアドバンスト・ビジネス創造（ABC）協会の細川泰秀副会長は「成功率が52.8％」という調査結果をこう「評価」する。
　一見すると厳しい結果にもかかわらず、それを評価する声があること自体がITプロジェクトの難しさを示している。「システム開発の成功率は3割程度と言われていた。失敗の原因を追究して未然に防ぐ、地道な努力が結実した成果だとみなせる」（細川氏）。

2.3 想像力の問題

「提案されたソフトウェアについて記述しようというとき、ソフトウェアが自明でなくまだ存在しない場合、ソフトウェアの仕様を明確で完全な形で伝えるために、そのソフトウェアがどう振る舞うかを十分な詳細さと精度をもって想像することはほとんど不可能である」。あるいは、プログラマーがよく言うように端的に表すなら「顧客は何がほしいのかわかっていない」ということです。

スティーブ・ジョブズも同じことを言っていたそうです。
https://iso-labo.com/labo/words_of_StevenPaulJobs.html

A lot of times, people don’t know what they want until you show it to them.
多くの場合、人は形にして見せてもらうまで、自分は何が欲しいのかわからないものだ。

いや、わかってるよ！という人もいるかもしれませんが、本当に、細かいことも含めてすべて示せるとしたら、それは凄まじい能力だと思います。

世界一シンプルな誕生日カードのウェブサイトを作るものとしましょう。
〜 省略 〜
素晴らしい! これを開発者に渡して作ってもらうことにしましょう。
それから最初の問題が持ち上がります。長いメッセージに対してどうするか書いていませんでした。
〜 省略 〜
万事解決です。しかし、新しいバージョンができてきて、
〜 省略 〜
万事 OK です。ただ、実際にこのアプリを使おうとしたところ、
〜 省略 〜
そしてついには作り込んで、すべてが出来上がりました。ただ問題なのは……。

ほとんど省略してますが、ここの例えは、本当に良い例えです。

技術仕様書と人間のプロセス
〜 省略 〜
持論とはこうです。建築業界や多くの工学的分野は、何か物を作ることに関して存在していますが、ソフトウェアは通常プロセスを作るものです。
〜 省略 〜
対象が物質か人間のプロセスかというこの違いが、想像力の問題の裏にある原因を指しています。プロセスの全体を明確にイメージするというのは本当に難しいものです。私たちの脳はプロセスの可視化に向いていません。

やってみてはじめて、「あーっ！」ってなること、ありますよね。
だからこそ、「実際にやってみることが大事」とか言われているわけですし。。。

2.5 既知の問題

「ユーザーフィードバック」というのは、「あなたが私に頼んだことが、あなたの望んでいたことではなかった、ということに、あなたが気付く瞬間」を意味します。

これによって、「要件の明確化」が行われ、明確になった要件について、追加要件？考慮漏れ？誰の責任？などなど、の議論が行われます。明確になった要件に対応する場合、必ず、それに対応する時間と費用が必要ですが、当初の期日と予算が変わらないことが多いですね。。。

2.12 ブルックスの法則

「遅れたプロジェクトに人を追加するとさらに遅れる」。その主な理由は、ソフトウェアプロジェクトでは開発者がソフトウェアのコンポーネントを作ると同時に、そのソフトウェアがどう働くかの明確で一貫したメンタルモデルを作り上げます。複雑さが増すにつれ、開発者はこのメンタルモデルをコードベースへの案内役として使い、何かを直そうとして別のところを誤って壊したりしないようにします。プロジェクトに後から加わった開発者にはこのメンタルモデルがないため、軌道に乗るまでに長い時間がかかります。

モデルの認識は、本当に重要。

5.4 したと言ったことをするか?

QA の最後の部分は「回帰テスト」で、これは新しい機能が追加された後、元々動いていた機能が今もちゃんと動くことを確認するということです。これは重要で、新しく追加したものが古い部分を壊してしまうというのは絶えず起きることであり、怖いくらいの頻度で起きます。

こういったことが減るように (だけが目的ではないですが)、マイクロサービスなどのアプローチが試みられていますが、本質的には、基本、壊れます。

5.5 失敗と折り合う

そのような技術的負債は、概念モデルをアップデートするための十分な時間なしに機能が変更されることでよく起きます。新しい要求を満たすために古いモデルが応急処置を施されて厄介な形になります。しかし「まずいモデル」型の技術的負債は、要求に変更がない場合でも、プロジェクトのはじめに概念モデルをちゃんと計画する時間がなくて起きることがあります。
〜 省略 〜
開発者に時間を与え、彼らが愚かでなければ、その時間を有効に使ってコードを改善し、後々それは効いてくるでしょう。

愚かでなければ！

5.13 治療法

彼らは既存のコードがどれほど自分の作業の妨げになっているかよくわかっています。
〜 省略 〜
ああ、また我らが友、時間です! 時間というのは技術的な累積赤字に対する通貨であることがわかります。技術的負債の場合にも利子が積み上がります。取り除くには、最初から避けていた場合よりも長くかかります。本気で負債をなくそうとするなら、スケジュール付の返済プランを考え出す必要があります。

既に動いているものを改善したい、というリクエストを受け入れてもらうことはかなり難しいです。
動いている以上、ユーザに提供する価値は同じだから、とか、予算が、とか、色々な理由があることは理解できます。まぁ、しょうがない、といえばしょうがない、です。PDCA は、ソフトウェアには適用されません (！ちょっと言い過ぎ)
※余談ですが、私は、PDCA よりも OODA 志向です。状況は絶えず変わりますし、自分でも変えます。変化することを前提にしなければ、世の中についていけません。

9.1 静かな部屋と強力なコンピューター

何年か前に彼は良いソフトウェアチームのための一連の条件をあげてそれを「ジョエルテスト」と名付けました。チームの実践やプロセスや作業環境に焦点を当てた 12 の問いからなっていて、それぞれイエスかノーで答えることができます。
〜 省略 〜
ソフトウェア開発には集中を要します。強度の、すべてを傾けた集中です。それは前に見たように、ソフトウェア開発者というのは書いているコード行の構文的な詳細と、ソフトウェアの根底にある概念モデルの全体構造を同時に考える必要があるからです。彼らはコード片の視覚的なエレガントさと、それが他のさまざまな部分とどう関わり合うかを考えています。プログラムのどの行を書くときにも、5 つか 6 つの異なる考えを意識の中に置いて検討し、相互参照する必要があります。そのため、注意を逸らされることがことのほか有害になります。プログラマーの頭の中に注意深く配置されたそういった考えは、容易に追い出されてしまうものだからです。

ほんと、一瞬で吹っ飛びます。で、再構築するのに時間がかかります。。。
複数の仕事を同時にやるなんて当たり前でしょ、というのもわかります。でも、頭の中では、既にやっているんですよ。一つのことを考えているわけではなくて、これをこうしたらあっちがこうなるし、こうするとこっちがあれだし、あぁ、これを汎用化するにはこれとこれとこれとこれとこれの相互作用を踏まえて。。。とか、膨大なパターンを考えているんです。

人間が同時に考えられることは、3 つ？ 4 つ？ 6 つ？とかいう話はたくさんあります。数は色々あるようですが、確実に言えることは、限界はある、ということです。

プログラマって、キーをタイプしている時間はあまり多くないんですよ。
ほとんどの時間は、調べたり、概念モデルを考えたり、ということが占めています。

9.2 妙な時間

ソフトウェアプロジェクトには納期があります。
〜 省略 〜
危機的な状況でチームに残業して働く用意がないのはマネージャーにとって苛立たしいことで、険しい会話をすることになるかもしれませんが、納期が迫っているというだけで甚だ長時間働くことがチームの当然の義務だと決めつけるのは、世間知らずで短慮というものです。

こんな考え方もあります。

納期ありきでプロジェクトのスケジュールや体制を計画してはいけない
https://tech.nikkeibp.co.jp/it/atclact/active/17/041200270/042000001/

逆算してスケジュールすること自体は普通のことなんですけどね。
IT に関しては、まぁうまくいきません。

引用はここまで。

どうでしょうか。

プログラマにとっては、プロジェクトが予定どおりに進まないことは、ほぼほぼ共通認識だと思いますが、ほとんどの原因が自分でなかったとしても、1% でも自分が努力すればクリアできたかもしれない、と思うところがあると、あまりそのことを口にしない傾向があると感じます。
例えば、納期について、不確定要素はあるにせよ、見積もっているのは自分、ということも含めて、何とか納期に間に合わせようと努力します。

それには、自分が知っていることは、広い IT の世界の中のほんの一部 (言い方を変えると、ほとんど知らない)、という認識が「自分のスキル不足」と考えさせやすいことも作用していると思います。でも、広範な技術が複雑に連携し合い、且つとんでもないスピードで進化する IT 業界で、あらゆることをキャッチアップすることは不可能です。関連する業界の知識も必要ですしね。
(プロフェッショナルなんでしょ？言い訳するな！と言いたい人もいるだろうなとは思いますが。。。)

他に、ビジネス系の人には理解してもらえないだろう、という意識もあります。(理解してもらえないことが悪いと思っているわけではなく、そういうもの、という認識。同じように、自分たちに営業活動のことはわからないので。その上で、お互いの歩み寄りは必要ですけどね)

まとめ

この本は、

プログラマにとっては、普段あまり表に出さない、言いづらいことを代弁してくれる (主張したいことや、自分たちの弱みも含めて) と同時に、自分たちがビジネス系の人からどう見られているか、を教えてくれる存在でもあります。

ビジネス系の人にとっては、ソフトウェア開発や、それを扱うプログラマがどういうもの (人) かということを説明して、関わり方を教えてくれる存在だと思います。

お互いの理解を深めるきっかけになると思いますので、ぜひ！
読んでみてください！