初めてのアジャイル開発

初めてのアジャイル開発　?スクラム、XP、UP、Evoで学ぶ反復型開発の進め方?

ここ読んでもらえればわかるかと思いますが、現在スクラムの勉強会に顔出したりしているのは 半ば追いつめられた自分がいるからです。そもそもその直前まで開発しかやっていなかった人間がマネジメントをやってうまくいくわけはないのですが（私は開発とマネジメントは互いに関連の薄い別のスキルだと思っています）、後工程での手戻りの問題やマネジメントの面で、単純にウォーターフォールプロセスで取り組んでいくのには限界があるのではないかと感じました。そういう経緯があって、アジャイルが一つの答えを与えてくれるのではないかという思いで取り組んでいます。
本書は、原題が「Agile and Iterative Development A Manager's Guide」なので、別に邦題として「初めての」を強く意識しなくてもいいような気はします。プロマネの人がアジャイルを自分のプロジェクトに取り入れるためのガイドとして、開いてみるという使い方もできるかとおもいます。

構成

章立ては以下のようになっています。

1. はじめに
2. 反復型と進化型
3. アジャイル
4. 物語
5. 導入理由
6. 根拠
7. スクラム
8. エクストリーム・プログラミング
9. 統一プロセス
10. Evo
11. プラクティスのヒント
12. FAQ

「アジャイル」を全く理解していないのならば、1〜6章は一度は目を通しておいた方が良いです。アジャイルの利点やウォーターフォールの問題点などをデータとともに示しているので、動機付けや説得の材料として使えるはずです。
7〜10章はそれぞれの手法の紹介です。内容はコンパクトにまとめてあります。全体像を掴むには良いかと思いますが、もっと深く知りたいという欲求には応えてくれませんので、それぞれをテーマにした個別の書籍を読むべきでしょう。
しかし、他の手法との組み合わせの観点はこういう横断的な書籍ならではの視点だと思います。
ウォーターフォールの誤解や問題点に関しても触れています。興味深い話題です。個人的には「２度工程を回せ」と主張していることに驚きました。ウォーターフォールも提唱者の主張通りに適用すれば反復型であり進化型であるプロセスだったわけです。

アジャイル宣言

アジャイル開発を語る上では、まずこれは外せないでしょう。アジャイル開発プロセスは以下を重視します。

• プロセスやツールよりも、個人と相互作用を
• 完全なドキュメントよりも、動くソフトウェアを
• 契約交渉よりも、顧客との協調を
• 計画に従う事よりも、変化に対応する事を

この他にも提唱している原則があります。こちらをご覧ください。

ソフトウェア開発の目的

我々エンジニアがシステム開発を行う目的はなんでしょうか？我々が仕事としてシステム開発を行っている以上、顧客に何かを提供することで対価をもらっています。クライアントが我々に対価を払っても良いと思わせるような価値を提供する事が目的なのです。
ですから、プロジェクトが計画通り・予算通りに進むことも一つの価値であるわけですが、顧客が思い描いたシステムになっているかどうかも重要な価値なのです。ですが、顧客は最初から自分たちのやりたい事を明確にイメージしている訳ではありません。
だとすると、今までのように設計段階でユーザのやりたいことを制限してしまうようなやり方が果たして妥当なのかどうかということは考えて見る価値があると思います。（スケジュール通りに進めたいから顧客にやりたいことを我慢してもらう、って比較的思い浮かぶ光景ですよね？）
その辺りを許容しながらどうやってプロジェクトを円滑に進めて行こうか、という方法論がアジャイル開発だと考えています。

アジャイル関連に触れて思う事

今年になってから、勉強会とかイベントとか本とか、様々な場面でアジャイル関連の情報に触れるようになりました。
実際の取組みは思うように進んでないんですけどね……。まだ、実践をともなった知識になっていないです。
一番感じる事は「人を中心にしている」ということです。同様にチームを重視します。アジャイル界隈の方とお話ししていると、プロセスは「人を中心に進めるためのツール」であると感じます。
正直な話、かなり意外でした。エンジニアリングは、もっと数値的なものを重要視すると思っていたからです。ただ、よく考えてみると、結局は人が仕事をしてシステムを作っていくわけですから、そこを無視して話は進まないんですよね。
私見ですが、アジャイルに取り組もうとしているプロジェクトマネージャがすべき事は、プロジェクトチームを作り上げる事であり、プロジェクト中の仕事はチームのパフォーマンスを阻害する要素を取り除いてあげる事になるのではないか、と思います。
ということは、本書を聖書にしてはいけないという事ですかね？目的を達成するためなら、積極的にプロセスも成果物も変えていく心構えが必要なのではないかと思います。

実際問題……

私の経験の場合、一番の障壁は自分の部署のマネージャだったりします(苦笑)。「変化」を受け入れることは今までのプロジェクトマネジメントの定石からは外 れるとおもいますので（リスクとして捉えられていますし）、リスクだらけのプロジェクト運営をしようとしているように見えているのだと思います。今の所、 それを論理的に説得できるだけの材料も力量も自分に身についていないのです。
また、アジャイルで提唱されているプロセスを実際に取り組むためには、技術力が大前提となります。私の所属する会社の場合ここが一番の問題点で、残念ながらアジャイルに取り組む技術レベルにまで達していないのが現実です。

最後に

本書から一つの言葉を引用させてもらいます。

プロセスは副次的な効果しか持たない。一人一人の個性、感情、素質、コミュニケーションの方が影響が大きい。

良いチームを作れるようになりたいものです。精進します。