受託アジャイルを始めたい人から受けた相談とその回答

はじめに

• 社内で相談を受けた話をベースにしてます。（事例ベースの記事）
• 当時の回答を記載しています。
• どれもこれも相談を受けて回答したものばかりで、その対処結果まで教えてもらえてないです。なので、「こう回答したよ」という一覧です。上手くいったかどうかは不明です。すみません。
• 相談を全部は書き切れてません。思い出したら追記するかも。（多分しない）

対上司

アジャイルって胡散臭くて好きじゃないんだよね

概要

• 相談内容：自分はアジャイルを現場に導入したいが、上司が「アジャイルって胡散臭くて好きじゃないんだよね」というスタンスで、アジャイル導入を反対される。
• 回答：「アジャイル」という言葉なしに、「個別の課題に対して個別のアジャイルプラクティスを適用するような提案」をしてはどうか？
  • チームの進捗状況が非常に見えづらいので１週間ごとに進捗をチームが整理する場を作りたい　→ スプリントプランニング/レビュー/振り返り
  • テストが書かれていないため、テストを描き始めるアプローチを取りたい　→ TDD
  • 若手が多くレビュー時の手戻りが非常に大きいので、複数人で一緒に実装する作業を行いたい　→ ペアプロ/モブプロ

「アジャイル」ってキーワードは、その人の理解度によって意味合いや背景が異なったりするので、そういう抽象的なレイヤーで会話するのではなく、なるべく具体的なレイヤーで会話するようにする。
そして「結果としてアジャイルになる」くらいのアプローチをしていくのが良さそうだね、という話をした。
相談者は割と納得してた。

フェーズ分けと何が違うの？

概要

• 相談内容：上司にアジャイルを勧めたものの「フェーズ分けと何が違うの？フェーズ分けでよくない？」と言われて、答えに詰まっている。助けてほしい。
• 回答：別に上司の言い分は間違ってない。
  • そもそもPJ目標を達成できるならフェーズ分けでもアジャイルでもどちらでもいいはず。アジャイルに拘る理由は何か？を整理して伝える必要がある。（例えば以下）
    • 「フェーズ分けするにしてもリスクポイントすら現時点では不透明であり尚且つかなりのリスクポイントがありそうなので、高頻度で仮説検証を行う必要がある。」
    • 「フェーズという言葉からイメージされるような数ヶ月スパンでの評価タイミングでは、その分手戻り幅も大きくなりやすい。要件が不明確で方向性が現時点で定められないからこそ、細かく仮説検証を繰り返していくべき。」

フェーズ分けで行けるなら、フェーズ分けで良いと思ってる派。

一週間で要件定義〜リリースまでできるの？

概要

• 相談内容：アジャイルを導入したいと上司に伝えたが「スクラムってのは１週間で要件定義〜リリースまでするらしいよ。この現場でできると思ってるの？」と言われてしまい、グゥの音もでない。
• 回答：間違ってないけど間違ってる。
  • 理想的には1週間で要件定義〜リリースまでこなせるのが良い。が、現実には難しい。
    • その現実をどう落とし込んでいるか、いろんな事例があるのでもうちょっと調べてみると良い。
    • スプリント期間の考え方は別途記事化予定。（ちょっと書ききれなかった）
  • アジャイルもそうだけど、スクラムと呼ばれる開発プロセスのフレームワークも、「凝り固まった一つのパッケージ」ではなく「現場に応じて形を変えるもの」だと思った方が良い。
    • あなたの現場に適したアジャイルの形は、あなた自身が考え抜くしかない。

結構、「スクラム」がガチガチに固まったプロセスで、それさえ守れば良いと思っている人が多かった印象。

対顧客関係

アジャイルを導入したいが顧客側に説明する際のポイントを知りたい

概要

• 相談内容：アジャイルを導入したいが顧客側を説得できる自信がない。何かポイント・コツみたいなものはあるか？
• 回答：何かがおかしい。
  • 顧客の抱えている課題ではなく、アジャイルを導入することが目的になっていないか？
    • 課題を解消するのにアジャイルが適している場合にアジャイルを導入するはず。なので、課題が解消できることを端的に伝えれば良い。
    • そのソリューション（今回でいえば「アジャイル」）が解決する課題が明示できないのであれば、それは提案しない方が良い。
  • そもそもアジャイルってパッケージみたいなものじゃなくて、プラクティスや概念を総称してる表現になってきてる印象。「アジャイル導入」って言われても具体的に何？って感覚。
    • 受託開発という文脈において、アジャイル界隈で言われているプラクティスを全部をいきなり導入するのはめちゃくちゃ難しい認識。（顧客側の承認プロセスだったり、自社の権限範囲とかにも関わってくるので）
    • 基本スタンスは具体的かつ部分的な導入から始めるのが良いと思っていて、例えば「スクラム」を始めませんか、とか「定期的な振り返り」から始めませんか、とかだと思ってる。
  • 基本的には「仮説検証のサイクルを回しましょう」というのがアジャイル（だと私は思っている）ので、「スコープや市場ニーズや実現方法が不透明な領域」に使いましょう。くらいのスタンスで良いと思ってます。
    • 前提としては「わからないものはわからない」という前提に顧客と一緒に立てるかどうかがポイントな気もしてる。

アジャイルだと生産性が上がるって聞いたけどほんと？

概要

• 相談内容：アジャイルだと生産性が上がるという話を聞いたみたいで、その説明をしないといけない。何か材料はあるか？
• 回答：「生産性」という言葉の定義がずれている可能性があるので、そこからすり合わせた方が良い。
  • 受託開発で言われる生産性は「step生産性（単位時間あたりにどれくらいコードを書けるか）」を指すことが多いが、この場合は期待には応えられない。
    • この基準で照らすなら、ウォーターフォールからスクラムに転向してしばらく（少なくとも数年、長ければ永劫）は、スクラムのが低いことが多い（観測範囲内に限る）
    • ウォーターフォールでも良い案件（要件が固まっており、技術的懸念もない）の場合で、プロセスだけスクラムにしたら、おそらくウォーターフォールのが早く安く作れます。
    • スクラムはイベントが多く、作業以外に意外と時間取られます。（１週間スプリントで回すのであれば、毎週１日くらいはイベントで潰れる。）
  • スクラムをはじめとしたアジャイルの強みは「手戻り幅を小さく抑えられること」で、結果として寄り道が少なくて済む。
    • 要件が曖昧なケースをウォーターフォールで作った場合、大きな手戻りにつながる可能性が高いです。
      • リリースしてから要件がずれていたとか、リリースまで行かなくても、最終のテストフェーズで検知して手戻りになる可能性があります。
      • その手戻りも含めると、それなりのコストが発生することになります。
    • 一方で、スクラムをはじめとしたアジャイルでは、少し作ってそれが妥当なのか検証してというサイクルを繰り返す。
      • 小さく検証を繰り返すため、軌道修正を都度行うことができるため、手戻りを小さくすることができる。
      • その分、早く・安く出来上がることが多い。
  • 手戻りリスクが小さい案件（要件が明確・実装方法も容易）な場合は、ウォーターフォールのが生産性は高い。
    • 手戻りリスクがゼロになることはないので、そこの対策はちゃんと考えておく必要がある。

補足：ウォーターフォールが向いている案件は・・・？

「ウォーターフォールが向くのは手戻りリスクの小さい大規模案件」という話を昔よく聞いたんですけど、「大規模案件」の時点で手戻りリスクは割と看過できないレベルになっているはずなので、ウォーターフォールが向いている案件って滅多にないんじゃないか？と最近は思っています。（そう思ってそれを補強する根拠を集めちゃったところはあるので、情報の集め方がやや偏ってます。すんません。）

JUAS調査：ウォーターフォールな受託開発って基本的に大規模になりやすいんですけど、大規模なほどやっぱり工期や予算って見通せてなくて、手戻りしてる。（以下）

JUASの調査によると500人月以上のプロジェクトの半数近くは工期を守れていないってことで、そもそも見積りは難しいのだ(予算超過も40%)。そして規模が大きいほど難しい。たぶんバッファ積んでてもこうなんだぜ。
出典: 日本情報システム・ユーザー協会(JUAS) 企業IT動向調査報告書2021 図8-2-1 pic.twitter.com/B0bYvkgdSc

— Ryutaro YOSHIBA (@ryuzee) November 25, 2022

あと、実感として近いものを増田さんが呟いてくれていたので、参考にあげておく。
調達コストを無視できたものとしてすごい技術者だけを集めたとしても、コミュニケーション不良は発生しうる以上、定期的なフィードバックが必要だよねという話。結果としてイテレーティブな開発のが良いんじゃないか？ってのは本当にそう思う。
なお、現実問題では調達コストは無視できないので、このコミュニケーション不良はより多くかつより大きな問題として生じる印象。

人がやることなので、上流だろうが下流だろうが、どんなに熟達した技術者がやっても見落としや勘違いが紛れ込むので、うまくフィードバックと改善のサイクルを回すことは必要。結局、イテレーティブでインクリメンタルな開発になりそう。

— 増田 亨． (@masuda220) November 29, 2022

チーム内活動

アジャイル始めてみたんですけど上手くいかないんですよね

概要

• 相談内容：アジャイル研修を受けて講師のいう通りにカンバンから導入してみたけど、いまいち今までとどう変わったのかよくわからない。
  • 1日アジャイル研修の質疑応答の中で、講師から「最初の導入はカンバンをお勧めします」と言われたのでカンバンを導入した。
  • とりあえずカンバン形式でタスク管理するようにはしたが、見た目がカンバンになっただけで、あまり何かが変わったようには感じない。
  • 1ヶ月くらい試してみたが、状況変わらないので相談に来た。
• 回答：「カンバン」を導入した狙いを明確にしよう。
  • アジャイルに限らず、狙いが不明確なアクションは、効果も不明確になりやすい。
  • 形から入るのも悪くないが、その場合はアジャイルコーチやスクラムに詳しい人に随時相談しながらできる状況とセットのが良い。
  • 基本的にはカンバンはプロセスボトルネックを炙り出して組織を最適化するのに適した手法。

どんなプラクティスも、なんとなく使ったところで効果は出ない。
「カンバン」がどのような課題を解消するプラクティスなのかは別記事で説明予定。

アジャイルって聞いてこの現場に来たのに全然楽しく開発できない！

概要

• 相談内容：アジャイルと言われる現場に入ってみたんだが全然楽しく開発できない！これがアジャイルなの！？
  • 相談者は「アジャイル＝開発者体験の向上」と捉えている様子だった。
• 回答：「アジャイル」という言葉抜きにして、その現場で目指していることを会話しよう。
  • 相談者が不満をぶつけている相手からすると「勝手に期待して勝手に裏切られて勝手に怒ってきた」と見えてしまう可能性があり、まずは何を不満に思っているのか正しく伝える必要がある。
  • 伝える側は何が不満なのかをちゃんと言語化しよう。
    • 具体的に話す：不満に感じた実際の事例を伝える
      • 誰がいつ何をした時か？それを受けてどう感じたのか？（客観的事実と、主観的認識を分ける）
      • 1回だけなら特殊なケースだったのかもしれないし、頻繁に起こっているなら特殊じゃないかもしれない。（頻度を会話する）
  • 聴く側はなるべく否定しない
    • 主観的認識は否定しようがないので尊重する。（相手がどう思うかは相手の匙加減であってこちらが干渉できることではない）
    • 客観的事実をベースに会話をするが、なぜそのような事実に至ったかの背景を含めて説明する。
  • 当事者同士で解決できないのであれば、第三者を入れるしかない。
    • 最終的にはPJの成功が目的であって、アジャイルは手段でしか無い認識。アジャイルに拘る必要性はない。

これはアジャイルというよりは単なるコミュニケーション不具合といった印象だった。

次回予告

カンバンの話でもしようかな。
その次くらいにスプリント期間の考え方を書きます。