DXプロジェクト成功へのチャレンジ(2)

アジャイルの行動原理

行動原理というと少し大仰なイメージをもたれるかもしれませんが、アジャイル手法における最も重要なことがここであると言わせて頂ければと思います。各プロジェクトに参加する中で、「アジャイル」そのものの勘違いがプロジェクトの失敗に結びついていることが考えられます。まず、アジャイルは「アジャイル宣言による４つの価値」と「アジャイル宣言の背後にある１２の原則」によって成り立っています。以下、引用です。

アジャイルソフトウェア開発宣言による４つの価値

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。

• プロセスやツールよりも個人と対話を、
• 包括的なドキュメントよりも動くソフトウェアを、
• 契約交渉よりも顧客との協調を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

アジャイルソフトウェア開発宣言による４つの価値

私たちは以下の原則に従う:

1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません
5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
7. 動くソフトウェアこそが進捗の最も重要な尺度です。
8. アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

上記の行動原理、マインドセットは、提唱された2001年から20年経つ、今でも変わらず重要視されています。これらの考え方を理解せず、ただ迅速さだけがクローズアップされたり、プロジェクトの都合で解釈を曲げたり、断念することが、アジャイル手法を導入したプロジェクトの根本原因になると思います。

アジャイル手法の位置付け

また、アジャイルといっても様々なフレームワークと手法を対象とする包括的な用語になります。アジャイルの位置付けは、多数のアプローチを総称する用語であるものの、リーンの思考である「価値に焦点」「小さいバッチ・サイズ」「ムダの排除」などを用いた実例であるとされています。以下、代表的な手法についての概要です。

カンバン方式　

カンバン方式はリーン思考の原則に由来しており、在庫管理と補充のスケジューリングに用いるシステムです。「ジャストインタイム」となるこの手法は、トヨタの生産工場方式に適用されたことでも有名です。大きなカンバン（＝カード、情報ラジエーター等）を使い、作業ごとの状況を表す列（実行前、実行中、完了）を表示し、ワークフローの見える化をはかると主に、仕掛かり中（実行中）作業の制限をし、ムダを排除（効率的）する仕組みになります。非常に多く環境に提供が可能であり、すぐに取り入れることができるのが特徴的です。

スクラム

スクラムは、プロダクト開発をマネジメントするために使用される単一チームのプロセスフレームワークになります。スプリントと呼ばれる短い期間単位で、リスクを最小化し、主にソフトウェア開発で利用される手法です。反復型のアプローチを通して、１つずつ機能を追加的に開発し、各反復が終了するごとに機能追加された動くプロダクトをリリースします。

また、スクラムは、特殊なチームを組みます。プロダクト・オーナー、開発チーム、スクラム・マスターから構成されます。一般的にはプロダクト・オーナー＝プロジェクトマネージャーとされます。アジャイルプロジェクトはこの手法を取ることが比較的多く、以降の記載で、アジャイル手法に関する記述はスクラムでの手法の紹介になります。

XP（エクストリーム・プログラミング）

XPは、頻繁なサイクルに基づく、ソフトウェア開発手法の１つです。柔軟性に優れており、よりスピード感と変化に対応することを重要とした開発手法です。スクラムでのアジャイル開発よりさらに細分化したサイクルで行います。
　また、素早いリリースを要求されるため、開発規模は小さく10人程度のチームを組む場合に最適な手法といわれています。

アジャイル手法を採用したプロジェクトの失敗例

アジャイル手法（スクラム）で、プロジェクトが失敗となる原因について、例を用いてご紹介させていただきます。

価値重視の考え方がプロジェクトが進むにつれ薄まる

アジャイルは、価値重視のプロジェクトに適用される手法です。プロジェクトにおける効果測定が、従来のようなデリバリーや社内標準の品質基準に照らし合わせるやり方に戻ってしまうと、「顧客に取っての価値」が低下し、結果的にプロジェクトそのもののコストが勝ってしまうケースです。ここでの課題は、プロジェクト管理が、従来の手法にまだ囚われているプロジェクトマネージャーによって運営されてしまっていることです。

アジャイルの考え方を曲解し、計画やドキュメントを軽視する

アジャイルの宣言では、「プロセスやツールより個人と対話」「計画よりも変化に対応」と唱っております。この内容を曲解し、プロジェクトにおける計画、設計書などのドキュメント類を作成せず、プロジェクト・チーム内におけるコミュニケーションに支障を来すケースです。宣言においては、あくまで重視する要素を示してるのであって、軽視してよいとは言っていません。アジャイル＝迅速さ＝計画は２の次、３の次になってしまうこの思考は、表面的なアジャイルの手法にこだわってしまうことで起き得ます。
　

反復（イテレーション）期間が変わる

当初計画時に反復におけるサイクルの長さを定め、その中で決められたサイクルを繰り返し、機能をアップデートしていく手法がアジャイルでは一般的です。これらをプロジェクトマネジメントや一部のマネジメントの都合により、当初2ヶ月サイクルを早めたり、開発がうまく進んでないからと長くしたりすると、振り返りができず問題点の改善に至らない、計画の精度が下がる等の悪影響が出ます。

これは、経営レベルの都合をプロジェクトマネージャーが押し返せないことに原因があります。もちろん、ビジネス上の課題は最も優先すべき事項ではあるものの、サイクルを崩すことによるアジャイル計画への影響は甚大です。特にちチームのモチベーションが下がることは避けられないかと思います。

柔軟な発想を受け入れない

とはいえ、計画の変更はアジャイルではつきものです。作っている機能の改善、中止等は顧客価値最大化を考えるDXプロジェクトの状況下では受け入れるべきです。しかしながら、開発者にとって変更は自身の作業が無駄になったり、作業が増えたりといいことのように受け取れず、柔軟さを無くしてしまうことがあります。結果的に自身が作ったものが、顧客とって良いものではなければ意味をなさないことを念頭に入れなければなりません。

「反復（イテレーション）期間が変わる」はマネジメントレベルの都合で起きる事象ですが、こちらは作業担当者がこだわりを捨てきれずに起きてしまうケースかなと思います。価値重視で動きつつ、反省はテンポよくサイクルで区切って行うことが望ましいです。

作ったものをデモ（実際に動くところ）で見せない

　
「動くソフトウェア」をプロジェクトで共有することはアジャイルにおける重要ポイントです。つまるところ、百聞は一見に如かずであり、イメージの共有をデモですると、関係者のレビューの質は高まり、顧客価値の創出イメージも大きく前進します。これをせず、ドキュメントや静止画像で見せても、実際に使ったらイメージと違った、がどこまでも付きまといます。開発サイドの見せなくても伝わるだろうという思い込みと、見る側の深く聞きづらいが、大体こういうことだろうという思い込みのスレ違いが防げるので、実際に動くもので確認することは非常に重要です。

開発チームの声が弱い（＝開発に携わらない一部メンバーの意見が強い）

アジャイルはアジャイル手法での実現意識の高いメンバー・チームで構成されていることが非常に重要視されます。従来型のプロジェクトのような階層型の組織構造ではなく、１つの目的を各チームがそれぞれ自己管理しつつ、進めていくからです。そのためには、阿吽の呼吸とはまではいかないまでも、アジャイルの呼吸は必要になってきます。

一方、プロジェクトは様々なステークホルダーが関与しており、急でかつ強い意見がプロジェクトに舞い降りることも多々あります。それらをブロックする役目がいないと計画の破綻は目の前です。今までの失敗例でもある通り、アジャイルプロジェクトを回すことの難しさは、「アジャイルの原則」を守りきることにあると思います。

まとめ

アジャイル開発が世に広まって久しいですが、日本のプロジェクトにおいては、アジャイル開発の原則を意識して取り組んでいる企業・組織は少ない印象です。すぐに価値（アウトプット）が出ると思われがちですが、その期待値と現状がすり合っておらず、その穴埋めに苦労されているプロジェクトマネージャーの方や開発担当者がいらっしゃいます。

プロジェクトにアサインした際には、アジャイルの方法論のみに固執せず、アジャイルの行動原理・マインドセットを理解し、なぜこのプロジェクトはアジャイル手法を採用しているのかを、プロジェクトの中で時々思い出しながら進めてはいかがでしょうか。

次回以降、アジャイルプロジェクトのマネジメントにおける課題と対策について、ご紹介させていただければと思います。