読者です 読者をやめる 読者になる 読者になる

give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

体系的な開発プロセスや開発方法論を身につけるための参考書籍

はじめに

システム開発って、免許がなくてもできちゃうので誰もが「自称プロ」です。
だから豊富な経験と専門知識を持った人が担当することもあれば、勘と度胸と限られた経験しかない人が担当することもあるわけです。


規模の小さいシステムであれば後者のような人でもなんとか形になるかもしれません。
しかし、規模的に数十人月を超えるような大きなプロジェクトだったり、かなりシビアな可用性やパフォーマンスを求められるミッションクリティカルなシステムだったりすると、後者のような人が担当するのはちょっと不安です。
奇跡的に大成功する可能性がゼロとは言いませんが、やっぱり見積りやスケジュールを大幅にオーバーしてしまったり、品質的に目も当てられないシステムができあがったりするリスクの方がはるかに高いと思います。


豊富な経験は簡単に手に入れられるものではありませんが、知識だけであれば書籍などからある程度吸収することができます。
少なくとも「勘と度胸と限られた経験」しかない場合に比べれば、専門的な知識を頭に入れておくだけでもずいぶんマシだと思います。
そこで、今回は体系的な開発プロセスや開発方法論を学習できる書籍をいくつか紹介したいと思います。

アジャイル

おいらはあまりアジャイル開発の経験はありませんが、アジャイル開発への憧れから本だけなら色々と読んでいます。
アジャイル銀の弾丸ではないにしても、大半のプロジェクトではかなり大きな効果を上げられる合理性を持っているんじゃないかと感じています。


アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)


今まで読んできたアジャイル関連の本の中で最も内容が濃かった一冊です。
本気でアジャイルを導入したいなら、この本は外せないと思います。


アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~


見積りとスケジュール作りに特化した本です。
従来のトラディショナルな技法とは全く方法論が異なるので最初はなかなか馴染めませんでしたが、実際に試してみるとトラディショナルな技法よりもずっと合理的な方法論じゃないかと思いました。

トラディショナル系

厳格なウォーターフォールとまではいかないにしても、システムのスコープ(機能)やスケジュールをできるだけ事前に固めようとしたり、開発スケジュールがいくつかのフェーズに分かれていたりするタイプの方法論を、ここでは「トラディショナル系」と呼ぶことにします。
アジャイル派からは嫌われがちなトラディショナル系ですが、今でも参考になる部分はそれなりにあると思っています。
そして何より、勘と度胸だけで立ち向かう人に比べれば、こうした体系的な方法論を理解している人の方がプロジェクトを成功させられる確率は高くなるはずです。


ラピッドデベロップメント―効率的な開発を目指して (MicrosoftPRESS)

ラピッドデベロップメント―効率的な開発を目指して (MicrosoftPRESS)


新訳 ソフトウェアプロジェクトサバイバルガイド

新訳 ソフトウェアプロジェクトサバイバルガイド


ソフトウェア見積り―人月の暗黙知を解き明かす

ソフトウェア見積り―人月の暗黙知を解き明かす


トラディショナル派の方におすすめなのは、CODE COMPLETEで有名なスティーブ・マコネル氏の本です。
決して厳格なウォーターフォールを推奨しているわけではないのですが、かといってアジャイル寄りでもありません。
個人的な感覚からすると、どちらかといえばトラディショナルな方法論に該当すると思います。
マコネル氏はまさに豊富な経験と専門知識の塊のような方なので、どの本も非常に実践的で役に立つ情報が満載です。


クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?


いくらバッファ工数を用意しても、なぜかプロジェクトはずるずると遅れていってしまうという、よくありがちな問題の原因と解決策を述べたビジネス小説です。
クリティカルチェーンの考え方はフェーズや担当者が分かれているようなトラディショナル系の開発方法論と特に相性がいいように思います。

合わせて読みたい

ちょっと昔に書いたおいらのエントリを挙げておきます。
犬小屋と高層ビルの違い - give IT a try


今回のエントリでは開発プロセスや開発方法論にフォーカスしましたが、テクニカルな話に関しても同様です。
小さなシステムを開発する場合に必要な技術や知識と、大規模でミッションクリティカルなシステムを開発する場合に必要な技術や知識は大きく異なります。
勘と度胸と限られた経験だけで大規模案件に立ち向かう「自称プロフェッショナル」ではなく、「本物のプロフェッショナル」を目指すなら、常に自己の研鑽を怠らないようにしたいものですね。