アジャイルが語る。価値あるソフトウエアを届けるために必要な12の価値観

アジャイル

私は日頃から「価値あるソフトウェアを提供したい」「開発スピードを向上したい」「顧客も開発者も幸せな環境を作りたい」、そう思いながら開発を行なっています。それらを達成するために必要だと感じているのが、”顧客とプロジェクトメンバー全員”で「価値観（大切だと思うこと）を共有して納得すること」だと思っています。極端な話ですが、もし顧客が「予算も仕様も開発期間も開発メンバーも固定だ。遅れたら土日祝日を使って取り戻せ。残業代はもちろん支払わないぞ。そしてソフトウェアが役に立たなかったら買い取ってもらうからな。フハハハハ！」という価値観をもった顧客と契約（約束）できるでしょうか？価値観というのはとても大切なのです。

私はアジャイルについて、以前から興味を持っています。例えば下記のエントリーがその現れです。

今日は、書籍「アジャイルサムライ --達人開発者への道」を読みました。そして、私の過去の経験も踏まえて、価値あるソフトウェアをを届けるために必要な12個の価値観を抽出してみました。

1. 価値ある成果を届ける

「この機能は本当に必要なのか？」・・・プロジェクトの中で考えていますか？。顧客が提示してきた機能の一覧を、何も考えずに実装しようとしていないでしょうか。顧客によっては「とりあえずこの機能もつけておくか」と考えている場合もあります。「本当にこの機能は必要なのか？」そう感じたら、顧客とコミュニケーションを取りましょう。「今回のプロジェクトの目的はこうなのですが、この機能はなぜ必要なのでしょうか」ということについて議論しましょう。それは、開発が面倒だとか、そういう気持ちではなく、顧客に「本当に価値のあるものを届けたい」という気持ちで議論しましょう。「機能が多ければ良いというわけではない」というのは皆さんご存知だと思います。そのソフトウェアを使いやすくデザインするために、使われない機能を省くことはとても大切なことなのです。開発の保守性も高まり、今後の開発もしやすくなり、ソフトウェアが長生きすると思います。

2. 必要とあれば進路を変える

世の中は混沌としています。そして、変化の連続です。そんな混沌とした世の中に、プロジェクトの計画には秩序があり、それを乱すことは許されない。こんなことが可能でしょうか。だいたいのプロジェクトは混沌から生まれる変化を無視できません。秩序を乱すような現実が多々現れます。「見積より時間がかかる」「競合他社がこの機能をリリースした。だから、この機能のリリースを早めたい」「この機能は必要なくなった」「やっぱりこの機能が必要だと気づいた」「この機能を作るためには、この機能に影響があり、再検討が必要だと気づいた」・・・日々変化の連続です。世の中が混沌と動いている限り、曖昧な人間がソフトウェアを作っている限り、このような変化は必ず起こります。強いチームは、変化が起こったら、本当に顧客が必要としている価値を再検討し、必要とあれば計画を変更します。この機能を後に回せないのかなどを検討します（ちなみに価値というのは期日も含まれます）。チャールズ・ダーウィンも言っています「強い者が生き残ったわけではない。賢い者が生き残ったわけでもない。変化に対応した者が生き残ったのだ」。プロジェクトも同じです。変化や課題、リスクをキャッチする仕組みをチームに導入し（例えば、朝会で「今の課題は？」を発表する場を設けてもよいですね）、顧客と積極的にコミュニケーションを取り、変化に対応しましょう。

３つの真実
1. プロジェクトの開始時点にすべての要求を集めることはできない
2. 集めたところで、要求はどれも必ずといっていいほど変わる
3. やるべきことはいつだって、与えられた時間と資金よりも多い

（アジャイルサムライ P13）

3. 顧客の期待をマネジメントする

顧客が提示する機能の一覧を見て、開発者であるあなたは何を思うだろうか。「ふーん、これ作ればいいのね。じゃ、さくっと作るか」と思うだろうか。もしくは、「これは本当に顧客にとって価値があるものだろうか」と考えるだろうか。先程も書いたが、「価値ある成果を届ける」ことが重要であって、「顧客が提示したものをただ作る」ことは重要ではないのです。つまり顧客を疑う必要があると思います。顧客は神ではないし、完璧に仕様を作れる存在ではありません。実はソフトウェアの利用者のことをわかっていないかも知れません。技術について良く分かっていないかも知れません。開発者側も「なぜこのソフトウェアが必要なのか」ということを、しっかりと理解した上で、顧客の期待をマネジメントする必要があります。プロジェクトやチームへの期待は一方的に「設定」して終わりじゃないのです。顧客と継続的にコミュニケーションをとり、本当に必要な価値を知り、日々の変化に対応しながら、期待をマネジメントする必要があるのです。顧客とコミュニケーションを取る中で「やっぱこの機能いらないよね」「この機能の方が皆が喜びそうだね」といったことはよくあることなのです。

4. 顧客も積極的に参加する

「何を作りたいのか」は、基本的には顧客が要求してくるものです。しかし、先程書いたように、開発側も「顧客の期待をマネジメント」する必要があります。「顧客の期待をマネジメント」するためには、顧客が積極的に開発チームとコミュニケーションを取る必要があります。例えば、「（開発チーム）この要求について質問したいのですが・・」「（顧客）あー、まぁ適当にやっといて」このやりとりを見てどう思うだろうか、良いソフトウェアが出来ると思うだろうか。価値あるソフトウェアを作るためには、当然ながら顧客の協力も必要となります。顧客が開発チームの質問に答え、開発チームにフィードバックしなければ、価値あるソフトウェアなど作れるはずもない。顧客は「真実の源」です。

5. チーム一丸となって成果責任を果たす

こんな会話を聞いたりしないだろうか。「これは顧客が欲しい機能ではなかったよ」「私はテスターですから、実装された機能をテストしただけです。私に責任はありません」このやりとりを聞いてどう思うだろうか。同じチームで仕事をしながら、自分の作っているものに自信や責任感を感じられるだろうか。アジャイルが持つ価値観はそうではない、「チームに参加している以上、成果に対して責任を持つ」これがアジャイルの価値観なのです。また、アジャイルのチームは、要求分析担当、設計担当、実装担当、テスト担当などと言う、旧来の「テストしかしない」「実装しかしない」というように、あらかじめ細かく定義された役割というものは基本的には用意しません。要求分析、設計、実装、テストを機能ごとに短いサイクルで回すので、すべてを１人で行うこともあります。もちろん人の強みを活かすというのもありますが、こだわり過ぎて、本来の目的である「価値あるソフトウエアを顧客に届ける」ことを忘れてはいけません。品質保証部門というものも存在しません、あなたが品質保証部なのです。「仕様が悪いから、こんな使われない機能ができたんだ」「テストをちゃんとしてないから、こんなバグが出たんだ」こういった声はアジャイルチームではありません。仕様に疑問を感じたら質問する、テストに不安があったら質問する、チーム内のすべての人が「本当に顧客にとって価値があるのか？」を問い続け、コミュニケーションを頻繁にとり、開発工程のそれぞれを密接に連携させながら、日々作業進めていくのです。縦割り組織ではなく、一丸となったチームなのです。

6. 継続した学習

アジャイルは従来のチームとは全然違う。先ほども書いたが、典型的なアジャイルチームには、あらかじめ決まった役割分担が存在しない。誰もがどんな役割もこなしている。何もかもが混沌と混乱のうちにあって、チームには階層も序列も欠けているとしか思えないのに、なぜか彼らは高い遂行能力を持ち、どうやっているのかはわからないが、質の高いソフトウェアを届け続けている。「私はプログラマだから要求分析については専門外だからやりません」「私は要求分析専門だから、プログラミングは知りません」こういった声は普通に聞こえてきそうだが、アジャイルなチームはそうではない。チーム全員が、要求分析〜開発〜テストを行う場合があるのだから、必要な学習はする必要があります。アジャイルなチームは、学習意欲が高く、責任感が強く、顧客に価値を届ける情熱を失わない・・・こういった人が最適なのです。こうしたチームは信頼され、権限を移譲され、煩わしい決済などはすっ飛ばし、開発スピードが上がります。こうした職能横断型チームの真骨頂は物事をこなしていくスピードにあります。プロジェクト期間中は同じメンバーで協力しあい、一丸となって仕事をこなしていく。アジャイルチームには、役割分担が曖昧であっても冷静に対処できるゼネラリストが居たほうがいいのです。スペシャリストが必要になるのは、発生した事態に対処するスキルが開発チームに備わっていない場合です（たとえばデータベースチューニング）。

7. プロジェクトのゴールやビジョン、チームメンバーについて全員が理解して合意する

プロジェクトの意義や目的をはっきりさせておけば、誰のために何をしたらいいのかよく分からない、といった混乱とは無縁になれます。また、ゴールやビジョン、プロジェクトの状況や背景、期日、必要な技術、予算等についてチームでよく話しあっておくこと。そうすれば、チームは状況に応じて適切な判断をくだせます。これは、プロジェクトの最初の段階で積極的に行う必要があります。プロジェクトの後半になり、取り返しが付かないところで、重要なことが発覚して途中でプロジェクト中断・・・このようなことを防ぐために、プロジェクトの最初の段階で「手ごわい質問」をどんどんしましょう。また、ステークホルダーに開発の状況や課題などの情報を積極的に提供しましょう。彼らにはプロジェクトを続けるかどうかを決断するための材料が必要です。

8. 関係者との信頼関係を築け

プロジェクトのご近所さんと会って、あらかじめ知り合いになっておきましょう。きっと、後になってから「挨拶しておいてよかった」と感謝することになります。たとえば、顧客と開発チームでソフトウェアを作っていたとする。その機能はとても膨大なアクセスログを生むため、顧客と開発チームで「データは半年以上前のものは消しましょう」ということになった。ソフトウェア開発も終盤、そろそろリリースかなぁと思っていた頃、会社の管理部にその話をしてみると「弊社はプライバシーマークを取得しているので、アクセスデータは１年間は保持することが必要なのですよ」と言われ、データの保存や機能について再検討することに・・・。こうしたことは、管理部とコミュニケーションが取れていれば、起こらないことなのです。プロジェクトコミュニティは考えているよりも常に大きいことを認識し、関係者を探して、信頼関係を構築しておくことはとても大切な事なのです。もし、管理部と信頼関係がなければ、この話を管理部が聞いても、無視して、後の祭りになるかも知れません。

9. 小さく考える

プロジェクトの期間が長くなればなるほど、失敗のリスクが増える。これは、私の少ない経験からでも分かりますが、ランディという経験豊富な方も同じ事を言っています。下記は書籍から引用したものです。

　ランディ・モットは世界的にも有名なウォルマートのデータウェアハウスと在庫管理システムの開発を手がけた。店舗マネージャが全米の店舗でポップターツのどの味が今一番売れているかをリアルタイムに把握できるようにした。彼は同じことをデルでもやった。在庫のだぶつきをすぐにわかるようにして、過剰在庫を値引きできるようにしたんだ。現在、ランディはヒューレット・パッカードのCIOとして、コストを10億ドル削減する社内業務改革プロジェクトを担当している。
ウォルマートやデル、ヒューレット・パッカードといった企業を助けるために、これまでにランディは適切にあの手この手を講じてきたわけだが、彼自身が打ち明けたところによると、そこには共通するひとつの秘訣があるそうだ。それは、開発サイクルが6ヶ月を超えないことへのこだわりだという。
ゴールのはっきり定まっていない大規模プロジェクトの問題は、果たされることのない約束が交わされてしまうことと、届けられる成果が不十分になりがちなことにある。「これも追加してよ！」と「この機能も必要なので・・・」がいつまでも続く。やがてコストはかさみ、見積は誰も気にしなくなる。ついには肥大化し過ぎた自らの重みに耐え切れなくなって、プロジェクトは崩壊する。
　ランディのITプロジェクトの守備範囲は6ヶ月以内だ。彼の見立てでは、これ以上の期間を要するプロジェクトは危険過ぎるというわけだ。もちろん、彼の手がけたITによる業務改革のすべてが6ヶ月で完了したというわけじゃない。彼はただ、長年の経験から身にしみてわかっているだけなのだろう。本当に大きな仕事を成し遂げようと思ったら、それをもっと小さな、制御できる単位へと分割しなければならないのだということを。
　ITプロジェクトの期間の見極め方について、ランディのプロジェクトマネジメントの秘訣とアジャイル手法は同じことを言っている。つまり、小さいほうがいい。そして、期間は6ヶ月以内であることが望ましい。

私の経験からすると、３ヶ月でも長い。しかし、それは私の技術、経験不足が大きく影響していると思います。１日も制御できない人が、数ヶ月も制御できるだろうか？それと同じで、私は１ヶ月でも制御するのは難しい。まだまだ、私は修行が足りないということです。長いプロジェクトでも、その人なりに、制御できる小さな範囲に分割して収めることが、とても大切なのです。

10. 文書に頼りすぎてはいけない

実際のソフトウェアプロジェクトで、重厚な文書化が要求を捉える手段として本当にうまく機能したことなんて一度もない。顧客は自分たちの欲しいものを手に入れることはほとんどなく、開発チームは求められたものを構築しきれない。ものすごい時間とエネルギーが文書化のために費やされるが、それは何を成し遂げるべきかを話し合うためじゃない。何を文書に書くべきかを話し合うことに費やされるんだ。しかも、ソフトウェアへの要求を表現する手段として文書に頼りすぎることに弊害はそれだけに留まらない。いくつか例をあげてみよう。

  • 変化に対処できない（「確かに半年前はそう言ったわよ！」）
  • 顧客の欲しいものに合わせるのではなく、仕様に合わせて作ることになる（「顧客がこの機能が欲しいと言っていますよ」「さっき仕様を凍結したばかりだ。とりあえず聞いておいて」）
  • 下手な推測や誤った前提を招き入れる（「半年後はたぶんこうなってるよね・・・？」）
  • 多くの時間を無駄にする（「３ヶ月もかけて作った私の要件定義書が日の目の見ないとはどういうことですか？」）

顧客がソフトウェアで実現したいものを表現する手段としては、文書だけじゃぁ貧弱すぎて使いものにならないことの方が多い。「文書に頼りすぎてはいけない」という教訓から得られる最も重要なアジャイル開発の原則の一つがこれだ。

「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです」

11. 見積もりは未来の正確な予想図ではない

見積もりをどうしても間違えてしまうことが問題なんじゃない（まぁ実際、間違えてしまうわけだし）。問題は、見積もりから本来そこにありもしないものを読み取ってしまうこと--つまり、見積もりを未来の正確な予測だと思い込んでしまうことにあります。
こちらにも書いたのだが、極端に言えば、前もって正確に見積もるなんて無理。だから私たちはあたかも正確に見積もれるかのような素振りをやめるべきなのです。
前もって見積もるときに、私達が欲しい答えはただひとつ。つまり「このプロジェクトをやり遂げられそうなのか？」。プロジェクトの初期段階での概算見積もりを信用しない。とはいうものの、プロジェクトを始めるのには予算が必要だし、プロジェクトにどんな成果が期待できるのかを見通しも立てねばならない。そのため、見積もるのだが、顧客にも「初期段階の見積もりは当てずっぽうだという前提を理解」してもらい「ソフトウェア開発の複雑さを認めてもらう」、そして「期日と品質のバランスを考慮して柔軟に計画を変更していく必要がある」ということを話し合い、理解してもらうことが必要です。

12. 「やり方」はたった１つではない

これまで、アジャイル開発の価値観について書いてきましたが、「開発のやり方」というのは１つではりません。アジャイルの価値観を理解してれば、あなたの開発現場に適した「やり方」というのは数えきれないほどあるのです。チーム構成メンバー、要求を作る人、ソフトウェアを使う人というのは、皆違うのですから。さらに、あなたの開発チーム独特の価値観もミックスされるでしょう。

　万人の認める唯一無二なる究極のアイスクリームのフレーバーが存在しないように、万人が従う唯一無二なる究極のアジャイル手法のフレーバーも存在しない。


　・スクラムは、アジャイルプロジェクトを包んで、プロジェクトマネジメントの装いを与えてくれる運営手段だ。
　・エクストリーム・プログラミングは、どんなアジャイルプロジェクトにも欠かせないソフトウェア開発のプラクティスを規律正しく実践する手法だ。
　・リーンは、能率を挙げることをとことん追い求める。たゆまぬ改善を続ける企業のためのトヨタ生産方式だ。


　そしてこれに、君独自のアジャイル手法が加わる。家族旅行で予定していた遠くの遊園地に車で向かったら、改装中で休園だったらどうする？そのときの対処法だってここに含めたっていいだろう。
　アジャイル開発に関する書籍や記事はどれも、それぞれの著者たちが、自分たちのお客さんと実際に試してみた経験から学んだことを、ただ共有しているだけなんだ。本書もその例に漏れない。

（アジャイルサムライ P14）

まとめ

リッツカールトンにはクレドと言われる価値観をまとめたカードがあります。弊社にはLR HEARTという価値観をまとめたカードがあります。サウスウェスト航空には「従業員第一、顧客第二主義」という価値観があります。なぜ企業は独自の価値観を構築するのでしょうか。それは、価値観が合う人同士で仕事を行うと、問題も少なく、決断が早く、安定して高い価値を提供し続けることができ、顧客からも信頼されるからなのです。開発チームにも価値観を導入すべきです。カードを作って毎日読み合わせても良いくらいです。アジャイルの価値観は、あなたの開発現場独自の価値観を構築する上での大きな柱となるのではないでしょうか。価値観は開発チームごとに千差万別でしょう。開発のやり方も千差万別でしょう。これがベストの価値観・やり方であるという銀の弾丸は存在しません。あなたが、あなたの開発チームのために大切だと思うことを考えてください。

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−