『ソフトウェア開発プロフェッショナル』を読んだ

ソフトウエア開発プロフェッショナル

ソフトウエア開発プロフェッショナル

『コードコンプリート』を書いたスティーブ・マコネルが著者。『コードコンプリート』より薄いのでサクッと読んだ。

ピラミッドの岩を運ぶ

 古代のピラミッドの巨岩を動かす作業を、ソフトウェア開発にたとえて、仕様を入念に確認し設計しないことのリスクとコストについて書かれている。たとえば川にある巨大な岩石の塊を1万メートル離れた建設現場に、20人で100日以内でやらなければならないとして、力任せに岩を押してもせいぜい1日に10mしか進まない。 賢いチームならいきなり力任せに動かそうとはせず、岩石の塊をどう動かすのか十分検討し、木を切って丸太をローラーとして使ったり、砂の道路を舗装するなどの方法を考えたりする。 たとえ木を切り取ってくるのに数日かかって、数日間1ミリも岩が動かなかったとしても、その後の効率を考えると妥当な投資といえるだろう。プログラム開発でも、賢いチームはプロジェクトの最初でいろいろ計画を立て、最も効率よく仕事が進むようにする。しかし、ソフトウェアプロジェクトの75%は、巨大な岩を力任せに動かそうとするように、いきなりコーディングから始めてしまう。

参考:ピラミッドの石を運ぶ方法がついに解明 | ギズモード・ジャパン

作ってから直す開発方式

作ってから直す開発方式=事前に計画や設計をすることなくいきなりコーディングに走る形式。
賢いチームは、木を切りローラーを作って岩を動かすように、適切なフレームワークを築き、生産性・効率を高くする。
典型的なソフトウェア開発プロジェクトでは、開発の初期段階で作り込んだバグの修正のため、全開発予算の40~80%を食い潰す。
生産性が時間の経過とともに落ちていき、効率を上げるメカニズムがないのでプロジェクトが進むに従いバグの修正に費やす時間が飛躍的に大きくなる。

作ってから直す開発方式にも実は利点がある!そしてまさにその利点のせいで作ってから直す開発方式をに走ってしまう。

  1. プロジェクト進捗の証拠をすぐに見せられる。
    せっかちなマネージャや顧客は目に見える成果を要求する。岩が10mでも動いていると進捗しているように見える。
    しかし、木を切ったり道路を舗装するのに最初に時間を費やすほうが効率がいいように、優れたプロジェクトは、開発の初期段階で仕様分析に時間をかけ、後段階の不必要な作業をごっそり切り落とす。

  2. 訓練が不要なこと
    ソフトウェア開発関連の教育レベルが低い組織では、作ってから直す方式で開発するのが当たり前となっている。
    経験豊かなソフトウェア開発者は、作っから直す方式は、一見魅力的だが、なんの価値もないことを見破る。

ソフトウェアはソフトにあらず

「ハードウェア」は変更が難しいため「ハード」と呼ぶ。一方、「ソフトウェア」は簡単に変えられたので「ソフト」と呼んでいた。
しかし、仕様の変更(ソフトウェアの表面的な変更しやすさを悪用する行為!)はコストやスケジュールが超過する最大の要因である。
仕様がフラフラしてないなかなか決まらないと、いつまで経ってもプログラム開発が終わらないこともある。

例: 5種類のレポートを印刷するシステムを設計していたところ、途中で10種類に変わったとする。
その場合以下のことを考えないといけない。

  • 10種類より増えないか?
  • 新しい5種類のレポートは最初の5種類と似ているのか?
  • 10種類のレポートは毎回印刷するのか?
  • 10種類のレポートは決まった順序で印刷するのか?

柔軟性が最大になるように設計すべしというのは最もだが、費用がかかる。
ソフトウェア開発の早い段階で柔軟性を限定できるが、後工程で作ろうとすると桁違いの費用がかかることを認識しないといけない。
決定を下す上で難しいのは、現在明らかになっているユーザの要求と将来必要になる要求を天秤にかけ、ソフト(柔軟性)とハード(難しい)でうまくウェアを作る方法を決定すること。


プロのソフトウェアエンジニアの免許制度によって質を担保しようということについての話が多いが、個人的にはソフトウェア開発の泥沼についての話が興味深かった。
特に「作ってから直す開発方式」はまさにいま自分が経験していることなので、体感的に本に書かれていることが納得できた。ちなみに自分は「作ってから直す開発方式」のことを「思いつき駆動開発」とか「なんちゃってアジャイル」と呼んでいる。 『ソフトウェア開発関連の教育レベルが低い組織では、作ってから直す方式で開発するのが当たり前となっている。 』と書いているように、悲しいことにソフトウェア開発プロセスのレベルが低いということなのだろう。

「効率よく設計する方法がわかれば、ソフトウェア開発を制覇したも同然だ。」そこで、きれいな構造で完璧に設計したところ、仕様が頻繁に変わったので、プログラムは何ヶ所も変更しなければならなくなった。このとき、私は「仕様を定義するよう方法がわかれば、今度こそ、ソフトウェア開発を制覇したも同然だ」と考えた。仕様の定義方法をいろいろ模索するうちに、ソフトウェア開発を制覇するのは不可能ではないかとの思いが芽生えた。この思いにより、私は、真の意味でのソフトウェア・エンジニアリングの第一歩を踏み出したと言える。プログラマは、知識を積み重ね自分なりに悟りを開く過程で、回り道を何度も繰り返す。

自分も真の意味でのソフトウェア・エンジニアリングの第一歩を早く踏み出せるようになりたい。