[Book] 「ソフトウェア開発 201の鉄則」を読んで学べた事

ソフトウェア開発に関わる人は絶対に読んでおいたほうが良い一冊を読んでしまいました。 「鉄則」とかって書かれると逆に引いてしまうんですが、書いてある内容が受け入れられると非常に良質なPMだったり、開発マネージャーになりえるという確信を持てた本で、コーディング規約をピンポイントで指摘するのではなく、エンジニア全般の格言のような事が大量に書かれています。

評価

★★★★★

洋書を翻訳したモノを読んだのですが、翻訳前の原文を非常に重要視していて、読み手が解釈を間違えないように重要な箇所は原文をそのまま残しているという親切な書かれ方がしています。 書いてある内容が上から目線なので、読んでみて気に入らないという人もいるかもしれませんが、ソフトウェア開発を経験した時に味わうであろう苦い経験をしてきた筆者が、「こうあるべき」という格言を「鉄則」としてページ毎に書き記しています。 僕の経験から見てもどれもうなずけるモノで、非常に腹落ちする内容でした。 これからソフトウェア開発を始めるエンジニアの人は是非一読しておくことをオススメします。 ただし、経験値がないと、何を書いてあるか分からないという鉄則が多いので、将来予測として気になるページだけを読んでいくだけでもいいかもしれませんね。 また、ソフトウェア開発マネジメントに関する鉄則も書かれており、開発部門を束ねるCTOや、チームマネジメントを行う人にとっても非常にいい内容になっています。

内容紹介

【目次】 1. 序章 2. 一般原理 3. 要求分析の原理 4. 設計の原理 5. コーディングの原理 6. テスティングの原理 7. 管理の原理 8. 製品保証の原理 9. 進化の原理

目次を見て、開発に関する全般的な内容で有ることが非常によく分かると思います。 多くの開発啓発本は、コーディングとテスティングぐらいの内容のものが多い中、要求分析と設計を分けている点でSEの人は必読ですし、 管理に関しては、マネジメント担当者、 保証などは、WEBサービスなどの運用フェイズに入った段階の事を想像しながら読むととても参考になるし、 何より「進化の原理」という点は、ソフトウェアは陳腐化するものだし、どのような設計を行うべきか、どういう思想が適しているかを書いてくれていて、これまでこうした事に答えを見出すことができなく、開発チームごとに特色が違うと考えていた自分としては、一つの答えをいただいた内容でした。

特に気に入った鉄則

原理11. 適切な型のプロトタイプを開発せよ

「使い捨て型」と「進化形」のプロトタイプを使い分ける事が説明されており、プロトタイプに対するこうした分類はこれまで考えたことも無かったので、開発作業の効率化に繋がるいい指標でした。

原理19. どんな複雑な問題にも解決策はある、と思うのは誤り

根性論ではなく、「まずは疑ってかかれ」との事ですが、この鉄則の奥深さを経験から身にしみてわかりました。

原理30. レミング（一時の流行）には心して従え

次から次へと出てくる新技術やツールなど、古いやり方にこだわっているばかりでなく、新しい技術は無視することはできないという鉄則です。 年配者が古いやり方を離れれられないのではなく、新しいやり方を知らないという人事的な問題も大いに関連していますね。

原理37. 責任をとれ

ギャグにも捉えられるこの鉄則ですが、多くのプログラマーは、言われたことをやっているだけで、コーディングミス以外は責任は自分には責任が無いと本気で考えているエンジニアが多いというレベルではなく、大多数であるという事実をソフトウェア開発部門は、評価として反映すべきであることがわかります。 会話コミュニケーションが苦手であるがゆえに、稚拙な言い訳をよく口にするエンジニアは、責任を取らないどころか、重要なスキル不足と考えるという思考はマネジメント観点から見ても納得が行く。

原理39. 要求仕様を書く前に問題を特定せよ

誰が本当の問題を抱えているのか？本当の問題とは何なのかを追求する事で、システム開発における手戻りが減り、大きなコスト削減になるといういい鉄則です。

原理51.簡明に書け

要求仕様に関して、分かりやすく簡単に明記せよとの内容ですが、本書では言葉のチョイスの事を行っているが、そもそも契約書のような文章の書き方をする設計者がいたり、説明を聞かなければ理解できない要求書を書く人に対する啓蒙と考えられる。

原理53. 曖昧な要求記述を減らせ

「いい感じに」とか「多め、少なめに」とかを目にすると実際にプログラミングをする際に適当なプログラムになりがちだが、仕様設計において、こういう事を少なくすることがクオリティを高める非常に重要な要素であることは、開発員のコミュニケーションスキルと合わせて必要だと改めて理解できる。

原理64. 文書の無い設計は設計と言わない

今どきのソフトウェアエンジニアには耳の痛い話ですが、設計書を必ず書かないと行けないという事実と、ちゃんとした設計書を書かないとそもそも設計したと言えないという事実に、改めて設計図を事前に書くという文化を構築する必要があると感じます。 家を建てる時に、設計士が設計図を作らずに家を作り始めるワケが無いというレベルと同じ考えという点は非常に納得感があった。

原理67. 単純に作れ

プログラミングのアルゴリズムに思われがちだが、設計段階における単純化は、プログラムコーディングの効率化にも繋がる。 設計思想の基本であり、この単純化スキルが、製品の品質にも繋がる重要な要素であることが理解できると、より高品位なエンジニアになり得るという事もよく分かります。

原理74. 変更が容易なよう設計せよ

以下のような設計方式があるとのこと。

・モジュラー設計 ・移植可能な設計 ・順応性のある設計 ・最小の知的距離での設計 ・知的コントロールの下での設計 ・概念的完全性を示すような設計

それぞれ調べてみると新たな発見があるかもね・・・

原理88. グローバル変数を使うな

もはや無名関数でしかJavascriptの記述をしなくなった僕としては非常に納得感のある内容であり、グローバルとローカル変数や関数を意識することで、仕事としてソフトウェアプログラミングができるかどうかの差であると考えてもいいかもしれない。

原理92. 人のことを第一に考えてプログラムを書け

ペアプログラミングなどが流行っている事が想像できますが、自分の書いたプログラムを人が理解できるかどうかが、ソフトウェア開発の運用フェイズにおいて重要ポイントであることは、経験者なら誰もが容易に想像できます。 ここでも、他人の目を重要視するべきスキルが必要なんですね。

原理96. コーディングを始める前に文書化せよ

設計という点でも同じだが、細かなコーディング作業においても、事前に文章化するという事もどうやら重要なスキルと考えられるようです。 この作業を行うだけで、周囲の人の作業が円滑になる事が理解できれば重要性がわかるはずです。

原理104. 言語についての知識はそれほど重要ではない

確かに言語にこだわるプログラマーは大したことが無い場合がほとんどだし、言語知識が無いが故に、自分の知識内でしか物事を考えられないエンジニアは多数見たことがある。 知識が重要ではないが、勉強する姿勢を無くしたらアウトとも考えられる。

原理108. テストを行う時期よりもずっと前にテストを計画せよ

よく言われていることとして「プログラム設計をすると同時に、テスト設計もせよ」という事なのだが、後付けで行うテストはかならずボロが出るという点においても納得感がある。

原理117. 無効な入力テストをせよ

イレギュラーテストとして検討されるべき内容ですが、利用者がリテラシがある無いに関わらず、そもそもソフトウェアの品質としての例外テストが重要という内容ですね。

原理125. エラーの原因を分析せよ

エラーは直せば終わりではなく、きちんと分析して品質向上に活かすという思考が、ソフトウェア全体の向上にも繋がる。 敷いては、関わるエンジニアのスキルレベルの向上も図れるため、分析をしているチームとしていないチームの差は歴然とも言える。

原理132. 少数精鋭はスキルの低い人々による人海戦術よりずっといい

人が多いと効率が増すというまやかしは、誰もが陥る過ちですが、どんなに忙しいエンジニアでも、忙しさがピークを超すと、人を増やしたい衝動にかられます。 マネジメントにおいて、人を増やす前に、高スキルの人ならどのように対応するかを考えてみるだけで、チーム戦略は良好になる可能性が高いですね。

原理136. うまく話し合う技術は必須である

コミュニケーションの事を言っているのですが、当たり前のようでいて、プログラマーというジャンルの人達の最も苦手な技術とも言える。

原理141. ソフトウェア技術者の能力差は大きい

最高のソフトウェア技術者と最低の技術者では25倍もの生産性の開きがあるそうです。 ちなみに、品質は最大10倍もの差があるそうですよ。

原理159. 計画を常に更新せよ

状況の変化を嫌わずに、日々の変更を常に更新して、計画を確実に推進するということこそが、もっとも確実に成果が得られる方法で有ることを認識しなければいけないようです。 無駄な作業をしていることの発見や、変化を嫌う傾向を排除するためにも重要な気付きになりますね。

原理189. 最初に要求仕様を変更せよ

すでに完成したソフトウェアに変更をする場合には、必ず要求仕様の変更から入らなければならない。 当たり前のように新しく作る時よりも、変更における見直しの時間が取られる分、そちらのほうが工数が増すことを理解しなければならない。 もちろん、そういう事態を想定した仕様を作れているかどうかも、重要な要素であることも忘れてはいけない。

原理193. 時にははじめから治すほうがいい場合がある

思い切って作り直したほうが効率的な場合は、まあまあある。 今あるものを変更し続けることで負債が多い場合は、作り直しも選択肢に入れるべきである。

読み終えた感想

WEBエンジニアとして会社を起こした僕としては、バイブルと言えるレベルでの気づきを与えられました。 これまでモヤモヤしていた点も、ザックリ言い切っていたり、他人も同じ箇所でトラブっている事を知ることがいかに重要かという事も合わせて勉強になりましたね。 特にサービス設計、チームマネジメント、などを行っている人にオススメの書籍だと断言できます。 コーディングに関する事は他の書籍と同じ内容なので、流し読み程度でいいと思いますが、テストや管理に関しては秀逸ですね。