はじめに
現在の開発チームでは、アジャイル開発を採用しています。しかし、私を含めて、きちんとアジャイル開発を理解している人は少ないと思います。
プロダクト開発が問題なく進んでいるのであれば、大きな問題はないのかもしれませんが、いくつかの課題を感じるようになったので今一度アジャイル開発について学び直してみることにしました。
現在のチームで感じている課題や、一般的に想像できる仮想課題について検討し、その解決策としてアジャイル、およびスクラムの仕組みがどのように役立つのかを考えてみたいと思います。
チームの課題
個人的に感じる課題は以下の通りです。
- プロダクトの進捗が見えにくい
- ビジネスサイドとエンジニア間での作業の進捗が見えにくい
- 進捗が見えにくいため、ビジネスサイドの要望が変わりやすかったり、エンジニアが作業を進める際に経緯を知らないため、最適解かどうか不安を感じることがある
ありがちなチームの課題
- 上流工程での要件定義に時間を使い、開発工程はほぼウォーターフォールで進める
これらの課題のほとんどは、開発チームとビジネスサイドの認識のずれが原因だと考えています。
解消のために、要件定義の段階からエンジニアが積極的に関わり、かつ予算等の情報を共有することが重要だと考えています。
また、ビジネスサイドからはその要望を実現することで得られるメリットを説明してもらう必要があり、お互いに理解度を高めることが重要です。
これらの課題の解消法として、アジャイルの考え方に則り、文化を浸透させていくことが第一歩だと思うようになりました。
なぜアジャイル開発を採用するのか
上記IPAの資料からいくつか引用します。
なぜ、いまアジャイルなアプローチが求められるのでしょうか？プロダクトを速くリリースできるからでしょうか？もちろんスピードは大事ですが、それだけではありません。アジャイルによる仮説検証型の問題解決方法が、新しい価値を創出するうえで必要不可欠だからです。
また、下記のようにソフトウェアエンジニア以外の分野にもアジャイル開発が適用できることへの言及もあります。
当初アジャイル開発はソフトウェアエンジニア主体の開発手法でしたが、近年は不確実さに対応するビジネス戦略としても採用され始めました。さらに現在は組織変 革の手法としても利用され始めています。本資料は、アジャイルの必要性について説いたものですが、ソフトウェア開発に閉じたものではなく、ビジネス一般における価値創造の局面にもあてはめることができます。
また、「価値」についてのスライドがあります。
従来の社会では、プロダクトを顧客に提供することで、個人のニーズを満たしたり、組織課題の一部を解決してきました。プロダクトのもつ「機能」に注目していたといえます。「機能」が成熟してくるにつれて、そのプロダクトを「使用」して目的が実現できればよいという視点に移ってきました。そして、現在の社会では、使う時に味わう体験そのものを対象とみなす、「ユーザー体験」という価値を提供するサービスが登場しました。
さらに、人とつながりたい、場を共有したい、みんなで経験を積み上げたい、等々の個人個人が「良い」とするモノ・コトの実現支援を提供するサービスがビジネスになる時代がやってきました。これは価値共創のコミュニティづくりが求められるようになってきたということです。価値とは、個人や組織やコミュニティが「良い」と意味づけているモノ・コトの総体であり、それらは、個人やコミュニティの幸福につながっていくものです。
アジャイル開発の誤解
アジャイル開発 = 早い、安い ではない
確かにリリーススパン自体は短くなることが多いです。ただ、重要な要件から順に開発を進めるので、すべての要件を実装するまでの工数が必ずしも少ないとは限りません。
プロダクトの規模が大きくなればなるほど、ウォーターフォールよりもアジャイル開発の方が工数がかかることもあります。
もっと根本的に、先述した価値創造の観点から仮説と検証を繰り返して不確実な状況への適応を行うための手法であると考えるべきです。
アジャイル開発の品質
アジャイル開発は、品質を犠牲にしてスピードを上げるものではありません。
アジャイル開発では、自動テストを組んで一定の品質を保つ仕組みはありますが、ウォーターフォールと比較して品質が高いとは言い切れません。
個人的には、あくまで自動テストは開発者にとっての安全ネットであり、プロダクトという単位での品質を保つためには、テストエンジニアやQAエンジニアが行うテスト工程が必要だと考えています。
仕様の変化
アジャイル開発 = 仕様変更がしやすい という誤解もありますが、これも正確ではありません。
アジャイル開発は、仕様変更がしやすいというよりも、仕様変更があっても対応しやすいというのが正しく、かといって無制限に仕様変更を受け入れるわけではありません。
リリース日や予算、他の機能の実装を遅らせるなど、他の要素とのトレードオフが選択しやすいだけで、当然仕様変更による不都合はあります。
予算
アジャイルにすると予算が少なくて済むという誤解もありますが、これも正確ではありません。
正確には、定められた予算、スケジュールでどの機能を優先的に開発したいかをあらかじめ決めておく、というだけです。
最低限どの機能がないとリリースできないのか、その機能はどういうテストをクリアする必要があるのかといった内容を事前に決めておくことで、予算を使い切る前にリリースできる機能を最大限に開発することができます。
そのため、全ての機能をリリースするまでの予算だけを比べると、ウォーターフォールよりもアジャイルの方が予算がかかることもあります。
丸投げ体質の改善
よくあるアジャイル開発の失敗例、私個人の経験則でも実感してるのは、「開発チームだけアジャイル」という状態です。
ビジネスサイドからの要求を受けてはいますが、その要求がどのような背景で出されたのか、その要求を実現することでどのような価値が生まれるのか、といった情報が不足していることが多く、開発チームが要求を受けて実装するだけの状態になってしまいます。実際に実装が終わった後にビジネスサイドの想定からずれていた。そもそもユーザーが望んでいる機能とビジネスサイドから依頼のあった機能が一致していなかったというケースが発生します。
このような状況を改善するためには、ビジネスサイドとエンジニアが共通の認識を持つことが重要です。
「~という機能を作って欲しい」という要望を受けるまえに、ユーザーストーリーという形で、誰が何をしたいのか、なぜそれをしたいのか、どのような価値があるのか、といった情報を共有することが重要です。
ユーザーストーリーについては以前記事を書いたので、参考にしてください。
エンジニアだけでなく、ビジネスサイドにもアジャイルに振る舞うことを求めることが重要です。アジャイルとは、開発手法であると同時に、価値観や考え方といった文化的な要素を含んでいます。
アジャイルとは、ビジネス価値の実現にむけて、 ITとビジネスにおける複雑・不確実な問題を探索と適 応を繰り返して解決するアプローチです。
引用元: なぜ、いまアジャイルが必要か？
ユーザーに提供する価値を求めて探索、仮説検証を行う姿勢はエンジニアもビジネスサイドも関係なく、全員が持つべき姿勢で、ただ役割が異なるだけだという認識をチーム全体で持つ必要があります。
アジャイル開発を導入、継続するために
現代のWEB企業において、アジャイル開発は当たり前のように行われています。その一方で必ずしもアジャイル開発の認識がチーム内で統一されているわけではありません。
エンジニアの雇用の流動性、プロダクトの規模、ビジネスサイドの理解度など、開発における価値観や認識を一致させることに時間と労力をかけることが重要だと考えます。
特にプロジェクトの開始時点で、アジャイル、スクラムの考え方やプロジェクトに関する価値観を揃えておく必要があり、そのためのワークショップとしてインセプションデッキを行うことがあります。
インセプションデッキ
プロジェクトの開始時点では、メンバーそれぞれが想像しているプロダクトの姿が異なることがあります。
認識が異なっていること自体が問題ではなく、その認識を揃えるための時間を取らずに開発を進めることが問題です。
ゴールやビジョン、プロジェクトの背景についてチームで話し合うことでチームは状況に応じて適切な判断を下すことができるようになります。
これらの目的のために、インセプションデッキというワークショップを行うことがあります。
インセプションデッキには、プロジェクトの目的、ゴール、リスク、スコープ、ステークホルダー、メンバーの期待、プロジェクトの成功基準について等の質問が含まれており、これらに対してチームで話し合うことでプロジェクトの方向性を共有することができます。
インセプションデッキの作成にあたって、開発チームだけでなく、ステークホルダー全員を巻き込むことが重要です。
このあたりの話は書籍「アジャイルサムライ」に詳しく書かれています。 形にこだわる必要はありませんが、この内容に関する認識をチーム全体で共有することが重要だと考えています。
課題例
-
我々はなぜここにいるのか?
なんのために自分たちはチームを組むのか。自分たちの顧客はだれなのか。そもそもこのプロジェクトが始まった理由はなんなのか。こうしたことを再確認する。 -
エレベーターピッチを作る 30秒以内に2センテンス(エレベーターに乗っている程度の時間)でプロジェクトをアピールするとしたら、何を伝えるべきだろうか?
-
パッケージデザインを作る 何気なくめくった雑誌のページに、自分たちのプロダクトやサービスの広告が乗っているとしたら、それはどんな内容がいいだろうか? その広告を見た人はプロダクトを利用したくなるだろうか?
-
やらないことリストを作る プロジェクトで実現したいことは明確になっている。それと同じかそれ以上にやらないことをはっきりさせる。そしてそれを一覧にする。
-
「ご近所さん」を探せ 「プロジェクトの関係者」に含まれる範囲というのは、自分たちが思っているよりもずっと広い。
-
解決案を描く チーム全員の認識が揃っていることを確認するために、概要レベルのアーキテクチャ設計図を描こう。
-
夜も眠れない問題 プロジェクトで起きる問題の中には、夜も眠れなくなるような大きな問題もある。あえてそうした心配事について話し合おう。どうすれば最悪の事態を避けられるだろうか。
-
期間を見極める どれくらいの期間が必要だろうか
-
何を諦めるか プロジェクトの開始前に、重要な要素はどれで、どれくらいのレベルで重要かをあらかじめ決めておく。
特にソフトウェア開発で挙げられる要素は以下の4つ
- スコープ(必要な機能をすべて含める)
- 予算(プロジェクトにかけられる金額)
- スケジュール(プロジェクトの期間)
- 品質(プロジェクトの成果物がどれくらいの品質であるべきか)
- 何がどれだけ必要か プロジェクトに必要なスキル、コスト、期間をまとめる。どんなチームならプロジェクトをやり遂げられるだろうか?
実際に再確認したこと
チームの運営においてアジャイルを改めて周知する際に、インセプションデッキの内容を参考に、以下の項目について再確認を行いました。
- プロジェクトのターゲットは誰か
- プロジェクトの目的は何か
- 目的に対する現在地はどこか
プロジェクトの発足から数年が経過し、立ち上げ時のメンバーとは異なるメンバーが多くなっていました。
私自身もプロジェクトに途中から参画した身なので、プロジェクトの目的やターゲットについてはあいまいな部分がありました。
これらの部分を改めて明確にすることで、チーム全体がプロジェクトの目的を共有し、それに向かって進めることができるようになりました。
タスク(ユーザーストーリー)の優先度を決定する上でも、目的やターゲットを明確にしておかないと基準がなくなってしまうため、これらの情報は非常に重要だと感じました。
まとめ
- アジャイル開発は開発手法だけでなく、ビジネス価値の実現にむけて、 ITとビジネスにおける複雑・不確実な問題を探索と適応を繰り返して解決するアプローチです。
- プロジェクトの開始時点で、アジャイル、スクラムの考え方やプロジェクトに関する価値観を一致させておくことが重要です。
- インセプションデッキを行うことで、プロジェクトの目的、ゴール、リスク、スコープ、ステークホルダー、メンバーの期待、プロジェクトの成功基準について等の質問が含まれており、これらに対してチームで話し合うことでプロジェクトの方向性を共有することができます。
- 重要なのは手法や特定のツールではなく、アジャイルな振る舞いを各メンバーが行い、メンバー間のコミュニケーションを重視することです。
所感
アジャイル開発については、多くの書籍や記事があり、どれを参考にするか迷うことがあります。
他社ブログや書籍を参考にすることも大切ですが、自分たちのチームに合ったアプローチを見つけるためには、自分たちで考え、試行錯誤することが重要だと感じました。
今回は私自身の例とアジャイル関連で自分が誤解していたこと、また改めて確認したことについて書いてみました。
実際にアジャイル開発を行なっている効果はすでに感じていますが、数字として確認できるにはまだまだ時間がかかると思いますので、引き続きアジャイル開発を継続していきたいと思います。
