株式会社オーム社様のご厚意により,
書籍 "Ship It! ソフトウェアプロジェクト成功のための達人式ガイドブック"
をブックレビューコーナー にご献本いただきました.
この本のレビューをして頂くべく,
Linux Users ML
や本サイトにおいて公募を行い,
これにご希望頂いた方々より感想などをレビュー記事にまとめていただきました.
ここに, レビューアの方々から寄せられたレビュー記事を公開します. (原稿到着順)
オーム社様およびレビューアの皆様のご厚意に感謝いたします.
なお, 以下のレビューは初版を対象としています.
開発プロジェクト管理者の立場になった時, 様々な管理手法の適用を試みるものの, 直面した現場での開発体系や管理, 問題に適用可能かと言えば躊躇う場面も多々ある. 本書は, 従来の管理手法に関する概念的説明ではなく, 開発現場サイドに主眼を置く実践的内容を解説したものであり, 共感し, 理解の下, 間違い無く実践に役立つ一冊である.
本書は, 読者への理解を深めさせるために,
を冒頭に置き, さらに (c) に対して
といった, 現場で活用し易い順立てした内容となっている. 特に, (f)〜(h) においては他の書籍にない観点であり, 非常に読みやすく, 受け入れやすい内容である.
今まで手にした書籍には無い観点, 即ち本書の特徴を挙げる.
本書は, 大規模から小規模まで適用可能とあるが, 実際に効果があるのは大規模プロジェクトであろう. 特に数週間で開発が終了するような小規模プロジェクトであれば, 逆に煩雑になる可能性もあると感じる. また, 本書の目的を考えれば納得行く全体内容ではあるが, 一般的ツールの解説等はほぼない (極小簡潔に概要を記載しツールの存在だけ説明する程度) ため, 本書だけでプロジェクトが即改善されるとは考えにくい. したがって, その他解説書を併用することで, 現実的な時間範囲内で効果的が上がると考えられる.
プロジェクト管理に関する多少の前提知識が必要ではあるが, 駆け出しのプロジェクト管理者であっても, 難しい技術書ではないため取り入れ易いと感じた (実際に私が当てはまる). また, 数々の経験を積んだ管理者であっても, 本書によって再認識, 発見する内容は多々あるように感じた. 本書は非常に実践的な内容であり, 敷居も高くなく, プロジェクト管理者として常に側に置いておきたい実践書であると思う.
レビューの前に, 簡単に自己紹介をしておきたいと思います. 私は, 工学部の情報系学科を卒業後, すぐに教職につき現在に至っています. Linux 上 で C, Java, Perl などで教育に必要とするような小さなプログラムは作っていますが, チームを組んでの大規模なソフトウェア開発経験はありません. 以下は, そのような私が本書を読んで感じたことをまとめたものです.
本書は, 筆者らがソフトウェア開発の実際の現場や複数のプロジェクトで効果が立証された 基本的かつ現実的なアドバイスをまとめた本です.
第 2 章「ツールとインフラストラクチャ」では,
を例に挙げ, ソースコード管理 (SCM) システムの有効性や IDE のビルドボタンではなく, ビルドをスクリプト化することなどについて, 具体的なツール名を挙げて詳細に述べてあります.
第 3 章「実践的なプロジェクト管理技法」では, プロジェクトを円滑かつ生産的に進めるために使っている共同作業の技法が 5 つ程紹介されています. その中で印象的だったのが, 「毎日のミーティングを行う」です. ソフトウェア開発というと, 一人ひとりのプログラマが黙々とプログラミングをしているような印象を持ってしまいがちですが, 毎日のミーティングを行うことの重要さを 10 ページ以上を割いて, その必要性や毎日のミーティングの進行例なども書かれており, ソフトウェア開発も特殊な社会ではなく, 人間のコミュニケーションを大切にする普通の仕事なんだと感じました.
第 4 章では, 一般に広く使われているプロセスの問題点を挙げたあと, 筆者らが実践している「曳光弾開発」について述べられており, 第 5 章では, 「一般的によく見られる問題とその解決方法」について述べられています.
本書を読んでみて良かった点をまとめてみたいと思います.
まず, 各節で詳しく説明してあることが, Hint という形式で, 以下のように端的に分かりやすく表現してあることがあげられます.
また, 42 個ある Hint が付録 A にまとめられており, 本書をあとから見直すときは付録 A の Hint 集を読み返すことによって本書を簡単に振り返ることができると思います.
次に, 各節の構成が良いと思います. 各節の最後には,
があります. 読者が実践する際, どのようにスタートすればよいかという不安を取り除いてくれるのではないかと思います.
本書を読んで, 一番印象に残ったのは, 「1.1 習慣の美徳」です. 本節ではアリストテレスの「われわれが何であるかは, われわれが繰り返し何を行ったかによって決まるのである. それゆえ, 美徳は行いではなく, 習慣なのである」を引用し, ソフトウェア開発において「良い習慣を身に付けること」の重要性を説いていますが, これは私たちの日常生活, 人生にもおいても重要なことだと感じます.
また, 本書を通して, ソフトウェア開発の現場の様子を知ることができ, 今後の教育活動に生かしていきたいと思います.
まず, 本書が対象としている読者は開発者や顧客など特定の読者ではありません. 立場によって本書で取り上げるアイデアへの取り組み方は異なるものの, ソフトウェアプロジェクトに関わる人全てを対象としています.
本書の構成は, インフラストラクチャ, テクニック, プロセス, Q&A の四つに大きく分かれており, それぞれ 2〜5 章に相当しています. また, 各章とほぼ同量のページを用いた付録がついています.
2〜4 章でのアイデアや習慣についての記述は一貫しています. まず, アイデアを具体例とともに紹介し, アイデアへの取り掛かり方, アイデアを正しく使えているかの判断基準を述べています.
読み方については, 一節読み終えたらアイデアを仕事に応用する方法を 5 分ほど考えてほしいと述べていますが, 全部で 60 節程度なので毎日二節ずつ読み続けて一ヶ月で楽に読み終えることができるでしょう.
バージョン管理, ビルドスクリプト, 継続的なビルド, 問題の追跡, 機能の追跡, テストの自動実行について述べています. また, ツールを選ぶときの注意やアイデアを取り込んではいけない局面についても述べています. 個々のツールについては知っていましたが, プロジェクトへの応用の仕方には参考になる部分が多かったです.
リスト, 技術主任, ミーティング, コードレビュー, コード変更通知の送信について述べています. 主にチーム作業について述べられていますが, 作業時間の見積り方や優先度の割り当て方なども解説していて参考になります.
開発プロセスの中でも曳光弾開発を取り上げて, システムオブジェクトの提案, インターフェースの提案, インターフェースの接続, 機能の追加, リファクタリングについて述べています. 3 章同様にチーム作業について述べられていますが, 回り道をしないでプログラミングするプロセスというのは興味深いものでした.
5 章では Q&A のような形式で 2〜4 章を振り返り, ソフトウェアプロジェクトでの役割ごとにより細かく解説しています. 付録では, 取り上げたヒントのリスト, ツールなどの紹介やそのキーコンセプト, 選び方などが述べられていて, 簡単なカタログとしても使えそうです.
本書では専門用語の解説や解説へのポインタが細かく入れられています. 一部を取り上げてみると, アジリティ, バグのリグレッション, Wiki, RSS, コードフリーズ, ステークホルダ, バーンレート, ペアプログラミング, リファクタリング, 情報発信物, モックオブジェクト, 割れ窓理論などがあり, 読者に求められる前知識が少なくなっています.
同様に, 前述のアイデアへのポインタも細かく入れられており, たとえ忘れてしまってもすぐ読み返すことができるでしょう.
本書はソフトウェアプロジェクトに関わる人に向けてかかれていますが, プロジェクトに参加していない趣味プログラマーでも参考になる部分は多いでしょう. 2, 4 章で取り上げている内容は個人でも実践できることも多くて, 興味をそそられるし, 3 章はチーム作業が主で個人では応用できない部分がありますが, 実際の開発現場を想像して楽しめました.
本書を読んで, まず, こんな環境でソフトウェア開発をしたい, こんな風にマネジメントしたいと思いました. インフラストラクチャ, テクニック, プロセスの三つに大きく分け, それぞれの章で今すぐ使える方法が書かれています. 具体的な事例を挿話としてはさみ, 今すぐ始めるためのポイント, うまく機能しているかどうかチェックするポイントなどが丁寧に記述されていました. 何かの方法論を押し付けようとしているのではないかという懐疑的な目で見ながら読み始めましたが, 読み終わる頃には, どこの部分からでもいいから実践してみようと思いました. 書かれていることは難しいことではありませんが, 理想論ではないのかと思うような部分もあります. しかし, 実際にあったという例示や, 「どこから着手するか」という具体的なアドバイスで, 今すぐできそうな気がしてきます. もちろん, 開発の現場で実践できていることもありますが, そういう部分についても「警告サイン」の指摘部分をチェックしてみようという気が起きました.
全体を通して各部分が提案と説明, 着手方法, チェックポイント, 警告サインという 4 つの項目で構成され, まだ取り組んでいなければ取り組む方法を提示し, 取り組んでいれば機能しているかどうかを確認する方法を提示しています. そのため, 気に入ったあるいは共感できた部分から, 手をつけることができ, 本書の頭から全部やらなくても小さなところややりやすいところから始めることができます. 場合によっては環境を整備するためにリソースを確保しなければ実現できないような部分もありますが, そのために必要な経営者への説得方法まで提示されているところもありました.
「曳光弾開発」手法がプロセスとして一章割かれています. この手法はオブジェクト指向のプログラミングあるいはソフトウェア開発では使われて当然と感じました. 敢えて名前をつけてまで紹介しているのは, 当然と思われる方法が開発の現場では使われていないということを示しているのでしょう. このプロセスは今すぐにでも実践したいクールな手法ですし, 実践しているなら, 改めて本書で挙げているポイントをチェックするとよいでしょう.
最後の章ではソフトウェア開発を進める上で遭遇する様々な問題に対する解決方法が提示されています. 本書で紹介した手法が絶対的なものではないことを踏まえ, いろいろな点からのアドバイスが具体的に記述されています. 実際に出会ったことのある問題も記述されていましたし, まだ見たことのない問題も書かれていました. ソフトウェア開発を進める上で既に障壁に当たっている場合や, 当たる可能性がある場合でも, この章で何かしらのヒントを得られると思います.
随所にちりばめられた 42 個の "Hint" は付録として一覧することが出来ます. そのため, それぞれのヒントを読後に再確認することもできますし, 実際に本書を活用してから見直すためにも便利に構成されています. 一連のツールや方法論なども付録でまとめられているため, 本文での本質的な説明とツールの説明が明確に分けられており, 特定のオープンソースの押し売りのような, 押し付けがましい部分がありません. 惜しむらくは索引が内容に対して少なく, これをもう少し充実させると読後の実践手引書としてもより充実したことでしょう.
脚注が多いため読んでいる途中で思考が中断されることがありました. ほとんどの脚注では気にせずに読み飛ばして後に見直すことでより理解が深まりますが, 略語が本文で使用される前に脚注で説明されているところがあり, 先に脚注を読んでいないと本文の意味がわからないことがありました. 日本語訳のせいではなく, 原書がそのようになっているためでしょう. また, 挿話に出てくる人物の英語の名前がたくさんあり, 日本人には逆に混乱すると思われる部分が多々ありました. 例えば, Jeff と Jen などの人物名が同じ挿話に出てくると, 混乱してしまいます. 原著者に許可をもらう必要がありますが, この部分は日本人向けに焼き直しした方が思考も中断せず, 読みやすかったと思います.
原書が英文のため日本人には多少読みにくい部分や, 文化の違いからなじみにくい挿話などもありますが, 全体的にすぐに始められる方法を具体的に示しており, 良書であると思います. 経営者に読んでほしいところではありますが, 残念ながら純粋な経営者に対する書き方ではないため, 開発現場のマネージャなどが咀嚼して経営者に説明する必要があります. 逆にソフトウェア開発に携わっているすべての人は一読すると良いでしょう. 今すぐ始めるためのアドバイスが丁寧に書かれていますので, できるところからはじめてはどうでしょうか. 書かれていることのすべてを一度に実施することは様々な要因から難しいかもしれませんが, 紹介された一つ一つは, 本書でも書かれている通りすぐに実践できる, あるいは現状を見直すためのヒントになるはずです. こんな環境で技術主任を目指して一日をすごしてみたいと思う一冊です.