本連載では、ある日本の製造業の会社がリーンとアジャイルで変わる過程で直面する様々な課題と解決策を物語仕立てで提供する。第3回は、アジャイル開発推進役の吹田が開発委託先の2社と打ち合わせを持ち、 アジャイル開発の実績や要求の取扱い等に関して質問する。なお、本連載の物語はフィクションであり、実在の企業や人物を記したものではありません。
前回までのあらすじ
A 社は、ある製品を製造、販売しているが、近年製品の売り上げの減少が続いている。売り上げの減少の原因が、製品の周辺サービス機能が消費者のニーズに合っていないとの分析に基づき、その対策としてCEOの椎名は開発本部長の貝原にアジャイル開発を早急に適用するように命じた。 貝原は、開発本部内でアジャイル開発に詳しい吹田をアジャイル開発の推進役に指名し、プロジェクトの立ち上げを依頼した。
吹田は、 A 社のこれまでの開発委託先であるロングパートナー社がアジャイル開発を実践できるかを疑い、上司の宮本にアジャイル開発の実践経験が豊富なバリアジャイル社とロングパートナー社の2社でパイロットプロジェクトを行うことを提案し、認めてもらった。吹田は、宮本に掛け合ってプロダクトオーナーとして織田の協力を取り付けた。
アジャイル開発実績に対する5つの確認点
織田との打ち合わせ後に、吹田はロングパートナー社とバリアジャイル社にアジャイル開発に関する支援を依頼しようと考えているので可能な限り早く打ち合わせを持ちたいと連絡をした。
翌日、ロングパートナー社の営業担当者が来たので、吹田は「当社の新製品の開発にアジャイル開発を使いたいと考えているのですが、御社は対応できますか」とまず質問を切り出した。ロングパートナー社の営業担当者は、「アジャイル開発には問題なく対応できます」と答えた。
そこで、吹田は「とりあえず 2 か月、5 名で弊社に来て頂いて試験的に開発をしたいと考えていますが、発注するかどうかを判断するために教えて頂きたい点をリストアップしたのがこの紙です」と紙を差し出した。この紙には、今回の開発で用いる予定の開発言語やフレームワークの開発経験の有無に加えて以下のような質問が列挙されていた。
- 今回アジャイル開発を適用する場合、どのような手法、フレームワーク、技術的なプラクティスを用いるか？
- 今回アジャイル開発を実践するチームはどのようなシステム、サービスの開発実績があるのか？
- これまでのアジャイル開発実績において、要求はどのような形式で誰が定義したのか？
- 今回の開発を進めるうえで事前に確認したいことはあるか？
- 現段階で開発をどのように進めるつもりか？
ロングパートナー社の営業担当者は、「開発言語やフレームワークは問題ありません。A はおそらく一般的なアジャイル開発だと思いますが、社内に持ち帰ってすぐに調べて回答を差し上げます」と言った。
アジャイル開発未経験者のチーム
吹田は、「メンバー5名程度のアジャイル開発の経験者のチーム以外に、アジャイル開発の未経験者を5人ほど集めたチームが編成できるのであればそのチームの見積もりもお願いします。アジャイル開発の未経験者としては、開発言語やフレームワークの経験があり、新しいことに意欲的に取り組む人が望ましいと考えています」との依頼を付け加えた。吹田は、この依頼の理由を「未経験者チームにより、今後アジャイル開発の適用が広がる際にアジャイル開発チームをどのように育成するかについて検討したいのです」と説明した。
吹田は、『世の中にアジャイル開発を実践できますと言っていても、スクラム等を学びもせずに従来手法を自分たちのイメージするアジャイル開発風にアレンジして実践していることも多い』ことを知っていた。吹田の追加の依頼には、ロングパートナー社の経験者チームがこのようなアジャイル風のアレンジに基づいている場合に備えてスクラム等を学び、実践できるチームをロングパートナー社に育成するという狙いもあった。
バリアジャイル社の回答
ロングパートナー社の営業担当者が去った後、バリアジャイル社の営業担当者が訪ねてきた。吹田はロングパートナー社の営業担当者にしたのと同様の説明及び質問をした。すると、バリアジャイル社の営業担当者は吹田の質問に対して「開発言語やフレームワークは問題ありません」と答え、さらに残りの質問にも以下のようにその場で回答した。
- スクラムをベースに、継続的なインテグレーション、テスト駆動開発、受け入れテスト駆動開発等を基本として用います
- おそらくチームメンバーの半数程度は経験者が長い人間を割り当てられますが、残り半分は比較的経験が浅いメンバーになると思われます。後で経験が長い人間が関与したプロジェクトの概要をお知らせします
- 要求の表現形式としてはユーザーストーリーを用い、ユーザーストーリー自身はお客様に書いて頂きます。ユーザーストーリーだけではお客様の業務知識や着想の理解に不十分なことが多いので、DtoD (Discover to Deliver)[1]というフレームワークを併用することをお勧めしています
- 特に気になるのが、現状プロダクトオーナー(PO)の役割を果たされる方がある程度プロダクトの構想を固めていらっしゃるかという点と、その方がPOの役割を果たされた経験があるどうかどうかという点です
- D の回答次第で開発の進め方等が変わりますので、現段階では回答できないと思います
吹田が「やはりユーザーストーリーを使われているのですね」と言うと、バリアジャイル社の営業担当者が「価値あるプロダクトを作ろうとする場合、開発委託者と開発者がユーザーストーリーを介して話し合うことが重要になります」と答えた。さらに吹田が「ユーザーストーリーマッピング [2] は知っていたのですが、DtoDは初めて聞きました。DtoD ってなんですか」と質問すると、バリアジャイル社の営業担当者は「発注者と開発者との知識のギャップを埋めて、系統的にユーザーストーリーを組み立てるためのフレームワークだと聞いております」と答えた。
ユーザーストーリーの準備とリリース計画
さらに、吹田は「今回 PO の役割を果たす人間は、プロダクトの構想をある程度固めていますが、これまでPOの役割を果たしたことがありません」と説明を補った。 バリアジャイル社の営業担当者は、「そうであれば、2週間の4回のスプリントサイクルに入る前に以下のような3日間前後の準備ステップを持つことをお勧めします」と答えた。
スプリント前の準備ステップ
- POへのスクラムの教育：1-2時間
- POのプロダクト構想のヒアリングと価値観点、成果の議論：半日
- POを交えたリリースレベルのDtoDセッション：1-2日
- POを交えたスプリントレベルのDtoDセッション：1日
バリアジャイル社の営業担当者は、「ここで3 ステップ目でリリース計画案が策定されます。従来の手法のように丁寧な説明資料はないことが許されるのであれば、PO以外の利害関係者にもこのリリース計画を数時間で説明し、ご意見を頂いた方がよいと思います」と付け加えた。
ロングパートナー社の回答
実は、吹田とバリアジャイル社の営業担当者の話はまだ続くのだが、その話の続きは次回に回し、時間を先に少し進め、先に出た吹田の質問に対して得られたロングパートナー社の回答を紹介する。以下がその回答である。
- 今回アジャイル開発を適用する場合、どのような手法、フレームワーク、技術的なプラクティスを用いるか？
- スクラムが基本で、お客様の要望する技術プラクティスを実践します
- 今回アジャイル開発を実践するチームはどのようなシステム、サービスの開発実績があるのか？
- 自社の社内システムを開発した実績があります
- これまでのアジャイル開発実績において、要求はどのような形式で誰が定義したのか？
- お客様の要望をヒアリングし、その要望に基づいて分析者が要件定義書を作成し、その要件定義書からプロダクトバックログを切り出しました
- 今回の開発を進めるうえで事前に確認したいことはあるか？
- どのような技術プラクティスの適用を希望されるかという点です
- 現段階で開発をどのように進めるつもりか？
- お客様の要望をヒアリングし、その要望に基づいて２週間程度で要件定義書を作成し、そこからプロダクトバックログを作成し、２週間のスプリント２回で開発を行い、最後の２週間でテストとデモを行います
この回答を聞いた吹田が「開発途上での要求の変化には対応しないのですか」と尋ねると、ロングパートナー社の営業担当者は「基本的には要件定義書のレビューでコメントは頂きますが、それ以降要件は確定します」と答えた。さらに、吹田が「開発途中で開発したもののデモはないのでしょうか」と尋ねると、ロングパートナー社の営業担当者は「デモはテストを通って最後に行います」と回答した。
さらに、吹田が「技術プラクティスとして継続的なインテグレーションとテスト駆動開発を適用することは可能でしょうか」と問うと、ロングパートナー社の営業担当者は「継続的なインテグレーションは大丈夫だと思いますが、最後にテストをまとめて行うのでテスト駆動開発はあまりお勧めしません」とのことだった。
吹田が「スクラムを適用されているということですが、スクラムマスターやプロダクトオーナーの役割はどうされているのでしょうか」と問うと、ロングパートナー社の営業担当者は「うちは PM がスクラムマスターとプロダクトオーナー代理の役割を担います」と答えた。
第 3 回の終わりに
吹田は、開発の委託先候補のアジャイル開発の経験を確かめるために以下のような質問をしました。
アジャイル開発の経験を確かめる質問
- 今回アジャイル開発を適用する場合、どのような手法、フレームワーク、技術的なプラクティスを用いるか？
- 今回アジャイル開発を実践するチームはどのようなシステム、サービスの開発実績があるのか？
- これまでのアジャイル開発実績において、要求はどのような形式で誰が定義したのか？
- 今回の開発を進めるうえで事前に確認したいことはあるか？
- 現段階で開発をどのように進めるつもりか？
また、これらの質問への回答に基づいてこれまでのアジャイル開発の進め方についてさらに質疑を行ないました。これらの質問を通じて、吹田はロングパートナー社のアジャイル開発の実績と自分の期待するアジャイル開発との間にずれがありそうなことを確認しました。
読者の皆さんは、2 社の回答についてどう思われましたでしょうか？
次回のお話では、吹田がバリアジャイル社にアジャイル開発の導入支援が可能かを問います。
参考文献
[1] 藤井 拓, DtoDに基づくアジャイル要求入門, https://www.ogis-ri.co.jp/otc/hiroba/technical/IntroDtoD/
[2] Jeff Patton, ユーザーストーリーマッピング, オライリージャパン, 2015