アジャイル宣言

すでにアジャイルに興味のある方は「アジャイル宣言」の存在はご存知かと思いますが、内容をもう一度振り返ってみましょう。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウエアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
(「アジャイルソフトウェア開発宣言」より)

この内容すべてに自分は共感しています。本当に素晴らしいと感じます。ただ最近「アジャイルを適用する」ことを「プロセスを導入する」としているプロジェクトも多いように思います。言い換えれば「スクラムやりたいんだけど」というプロジェクトが多いと感じているということです。

アジャイル宣言は「この通りに進めなさい」ということではなく「こういう方針や考え方で進めましょう」というものです。1つ1つの出来事や事象に対して、どう考えどう対応していくのかの指針を与えてくれているだけです。しかしそれがいつしか「アジャイルやりたいんだけれど、スクラムが評判いいよね。スクラムやりたいね」となり、スクラムのプロセスを導入し期待通りにいかないと「アジャイルでは成功できない」と結論づけてしまう場合があるということです。

しかしそうはいっても、アジャイルの考えに賛成できれば、アジャイルを適用してプロジェクトを進めてみたいと思うはずです。まずは形からとアジャイルプロセスを適用するのもプロセスによっては良いと思いますが、一般的な学習やスポーツのように「習うより慣れろ」でそのうちにできるようになるものではありません。例えば、朝会を実施するとしても、全員が「問題ありません」とだけ報告するような報告会ではやはりアジャイルの効果はなかなか出ないでしょう。変化へ対応しようとしても、どこかで仕様はFixしないと赤字になってしまう、と考えるのも自然な流れです。そして少しずつアジャイルの考えや方針から大きくずれてしまい、「アジャイルはスキルが必要」とか「アジャイルでは成功できない」となってしまうのです。

早く動かす

アジャイルで進める場合、いろいろ意識したい内容はあります。アジャイル宣言からも読み取れますし、宣言の背後にある原則も理解できればそれほど悩まずに進められるような気もします。しかしやはり現実にトラブルに直面するとなかなか想定どおりの解決はできないものです。そんなとき最も意識すること、それを自分は「早く動かす」だと信じ、悩んだらその方針にそってすすめるようにしています。

要件の変更があった場合

いくつか例を挙げます。せっかく作っているものに対して、それが無駄になってしまうので結構なダメージがあります。要件変更を受けたときには、「要件定義や設計をもっとしっかりやっていれば、この要件変更は防げたのでは?」と思わせるような状況もたくさんあるでしょう。

実は、作ったものを無駄にするぐらいならもっと入念に要件定義を行うべきだった、としてしまうのが最悪のシナリオだったりします。要検定義や設計時に入念に検討していればその要件変更は防げたはず、というのはある程度時間がたったその時だから思うことであり、実際の要件定義や設計中に気づいたかどうかはその時点では誰にもわからないはずです。「こんな簡単なことになんで気づかなかったのだろう」ということは多々あります。しかし悲しいかな、人間は思い込むとなかなか「そんな単純なこと」にも気付かないものなのです。

「早く動かす」を意識していれば、要件変更への対応は他の方法になるはずです。そもそも「早く作った」からこの要件変更の必要性に気づいたのかもしれません。要件変更の重大度や影響度はその都度異なります。そのため毎回1つずつ確認しなければならないのですが、「早く動かす」ことを最優先すれば方針が立てやすくなります。

たとえば、影響範囲が小さければ一旦対応を無視するというのもありです。影響度が大きくコストもかかる場合は、何かを捨てる努力が必要になるでしょう。ただ何を捨てるべきか、何を拾うべきかは要件定義時と同じレベルの話でありプロジェクトに大きなインパクトがあります。その際に正確に重大度や影響度を判断できなければプロジェクトの成功は危ぶまれます。

その時、動くシステムがあれば要件定義時よりは正確に判断ができるはずです。要件変更を受け入れる際、そして対策をする場合に、開発当初のような曖昧な状況で判断するとまた判断を誤る可能性が高くなるのです。そして、その要件変更がプロジェクト期間の後半で判明するのがまた最悪なのです。開発期間の前半ならば要件調整などもやりやすく時間にも余裕がありますので、致命的な問題にはなりにくいのです。

「早く動かす」ためには時には一度立ち止まってアーキテクチャを再検討したほうが良い場合もあるでしょう。ただ意識は「早く動かす」です。多少間違えていても動かしてしまってから修正する、と考えるほうが良いのです。気をつけなければいけないのは、「満足のいくアーキテクチャを決定する」とか「問題のないドキュメントを作成する」ではありません。それらを重視しないようにするために、「早く動かす」を目標にするのです。

突然ドキュメントがほしいと言われた場合

アジャイルを適用していても顧客からはドキュメントの納品やレビューを要求される場合は少なくありません。アジャイルであってもドキュメントは重要ですが、従来のウォーターフォールに比べればですがそこまで期間やコストを裂きません。(詳細は、「ドキュメントを最新に保つ効率的な管理方法とは?」を参考)顧客に要求されたら開発を止めてでもドキュメントを用意しようとするのが一般的なのではないでしょうか。ただもし「早く動かす」を最優先している場合はどうなるでしょうか。開発の手を止めてドキュメントを作るのではなく、言葉は悪いですがドキュメントを片手間に書き、簡易で不十分だと明らかにわかる文書でも提示することができるのではないでしょうか。包括的なドキュメントより動くソフトウエア、というわけです。

例として、同じ規模感の2つのサブプロジェクトがあり、開発状況を比較する機会があったので紹介します。Aチームは設計レビュー時にドキュメントは30ページ、Bチームのドキュメントはわずか2ページでした。Bチームのドキュメントには詳細には記載がないのですが、レビュー時には方針はだいたい固まっており、指摘事項にも口頭ではきちんと回答できていました。ただドキュメントへの記載がいくつも漏れていたので、追記を約束しレビューは終了。後日確認するとBチームのドキュメントは4ページぐらいになっていました。

そして時間が過ぎ、受け入れ判定のときにドキュメントを確認したところ、Bチームのドキュメントは30ページぐらいになっておりAチームのドキュメントと同じぐらいの分量になっていました。Bチームは対応漏れもなくドキュメントも修正は必要ないということでしたが、Aチーム側は対応漏れがあり、かつドキュメントの修正は受け入れテスト中に行う、ということでした。開発中もBチームは超過作業もすくなく、受け入れテスト後の障害はゼロでしたが、Aチームは開発中から障害も多く、超過作業も多く、受け入れテストでも障害がいくつか出ていました。

お気づきのように、Bチームではアジャイルで進めており、レビュー時にはその時点の途中の文書を出してきただけだったのです。レビューは通らない、というのは認識していたらしいのですが早く動かすことを優先していたため、ドキュメントは簡易な状態だったというわけです。

要するに顧客に何かを求められても、まずは「早く動かす」を優先していたということです。そしてその手法が最終的には顧客にもメリットがあったということです。

アジャイルを適用するということ

アジャイルを適用したい理由は「プロジェクトを成功させたい」ということのはずです。その最も近道が「早く動かす」ことです。プロセスの適用ではありません。もちろん、本当はそんなに単純ではなく、チームの目的意識の統一や効率的なコミュニケーションのとり方、捨てる技術やドキュメンテーションなども重要です。重大度や優先度の判断基準も「早く動かす」だけの単純な考えですべてが解決するわけでもありません。

しかし、アジャイルを適用しているつもりだけれど期待通りの成果がでない、という場合に「早く動かす」だけを目標にすれば大きなブレはなく、プロジェクトの成功に近づけることができるということです。慣れてきたらアジャイル宣言や原則を考えながら、本当に自分たちのプロジェクトに必要な方法はなにか、を考え続け適用を継続していけば良いのですが、慣れるまでは「早く動かす」を最優先に進めれば期待する効果はある程度得られるはずです。

アジャイルの方針を適用していこう

本連載は今回が、最終回となります。「現場から届けるアジャイル」というタイトルでしたが、おもったより現場のトラブル事例をお伝えできませんでした。というのもあまり自分の担当するプロジェクトでは問題となるトラブルは起きていないからです。もちろん要件変更は日常茶飯事ですし、その他想定外の問題は常にたくさん発生していました。しかし、どの問題もアジャイルの方針を適用するだけで乗り切れてしまい致命的なトラブルとならなくなってしまったということなんです。つまり、"うまくいっている"のです。皆さんのプロジェクトやチームはいかがですか? もし、うまくいっていない、としたら是非今回のシリーズを参考にしていただければ幸いです。またどこかでお会いしましょう。

執筆者紹介

川上文夫

パッケージベンダーのグループマネージャーとして複数プロジェクトのPM、PLを兼務。要件定義からプログラミング、テスト、運用を担当している。数多くのプロジェクトのリーダーとして20年のキャリアがあり、オフショア開発の経験も豊富。独自プラクティスに軽量議事録、朝会Wiki、設計実装並列手法などがある。アジャイル系コミュニティにも所属し、記事の執筆やワークショップ登壇など精力的に活動を続けている。