アンチパターン「考慮不足により山積みになる改善タスク」
向井毅男氏（以下、向井）：MoT側もこういった運用チームというか、そういったSyncの場を設けていってユーザー体験の悪化を防いでいく、構築していくような事例があった、アンチパターンがあったと聞いていますが、そのあたりを紹介してもらってもよいでしょうか？
脇水誠氏（以下、脇水）：そうですね。先ほどのMVPの考慮漏れというところにつながってきますが、考慮不足に対応しなきゃいけないところが途中でどんどんできてきて。狙っているターゲットのスケジュールから、だんだん乖離しちゃうようなアンチパターンを書いています。
それが2点目の「改善タスクが山積み」という話なんですけれども。クリティカルな要求とか不具合以外が見送られてしまう。ターゲットのスケジュールがあって、そこからだんだん乖離していくところがあって。
スケジュール的にどうしても守らなきゃいけない時期がくるので、優先的に低いものは見送られてしまって、タスクが積まれて、どんどん溜まってしまうといった2番目のアンチパターンがあります。
アンチパターン「スケジュールを守るための手運用カバー」
脇水：3番目も言っちゃいますね。3番目ですが、スケジュールに遅延を与えてしまうところがあって。それを運用でカバーするのは本来するべきじゃないと思っているんですけれども。そういった運用でのカバーを許容してサービスを見てしまうところも、3つ目の「手運用でカバー！」が増えてしまうアンチパターンとして書いています。
手運用でのカバーって、最初だけ（のこと）だと当初は考えているはずですが、なかなか改善されないところもあって。そのあたりが今の課題としてあります。
エンドユーザー側で起きていた負のサイクル
脇水：ここは事例をあげたいです。GOで「空港定額」というサービスを2020年7月にローンチしています。タクシーって、距離やその時間とかによって運賃がどんどん上がっていきますが、「空港定額」を使うと、いわゆる東京から羽田とか成田などの区間の間、一定の金額で乗れるということをあらかじめユーザーに提示した上で、安心して乗れる。そういった機能を提供しています。
特に旅行とかで使えるサービスかなと思って、7月からサービスインしています。
先ほどのアンチパターンの事例をまとめたものがその次のスライドです。これは、エンドユーザー側で起きていた負のサイクルとして書いています。
まず1点目のMVP定義です。これは、空港定額の場合、新しい案件の必要最低限な機能をまず定義します。2番目で、開発・QAに進んでいきます。その途中で、先ほどお伝えした考慮漏れが発覚して。既存の機能に対しての定義が漏れていたことが見つかってきます。
そのために4番目です。定義を追加していきますが、それをやっていくと、狙っているリリース日からどんどん乖離してしまうのが5番目です。
そのために、また開発をして2番に戻って、2、3、4、5をグルグル回してしまったというサイクルがあって。
とはいえ、リリース日はこれ以上延ばせないという期限がどうしても事業的にもあるので。そこを達成するために、6番、7番につながってきてしまうと。タスクの見送りが発生してしまったり、先ほどの手運用を許可して進めてしまうところがあって。
このアンチパターンが起きてしまっていたのは、空港定額の事例としてありました。
事業者向け側の事例
脇水：その次は山田さんからですかね。事業者向けのアンチパターンを紹介いただければと思います。
山田慶氏（以下、山田）：そうですね。先ほどの空港定額の案件だと、事業者向けのプロダクトでもアンチパターンがあって。先ほどMVPの定義のところでもお話ししたと思いうますが、例えば空港定額を必要としている、機能を必要としているすべての事業者さんに機能を提供しなくちゃいけない中で、当初、「既存で事業者さんが運用している仕組みを踏襲して対応すれば、最小工数でほぼ開発なしでいけるんじゃないの？」みたいな議論が社内でされて、（そのように）考えられていました。
実際、MVPをちゃんと定義しようとして蓋を開けてみると、その体制でいけるのは（スライドの）右の構成Aと書いてある一部の事業者さんだけで、その他の構成の車載器や構成の事業者さんだと、その空港定額の機能でのサービスを提供できないことがわかりました。
その結果、きちんと定義したら想定していた最初のスケジュールの倍以上工期がかかるとわかったみたいなことがあって。最初にきちんとスコープを把握できて、MVPを定義できていれば、こういった見積り誤りは起きなかったのかなというのを事例の1つとしてあげました。
3つの項目の対策
脇水：そうですね。それに対する知見を紹介したいなと思っています。3つですね。
まず1番目の、「要求がMinimumすぎてしまう」というところに対して、考慮漏れという話がありました。そこに対して、トレーサビリティチェックを導入しています。
もう1個、認識ズレですね。MVPの認識がズレてしまったところに対しては、課題とその解決後の姿を明確にして、最低限守るべき質を定義することをやっています。これは後で紹介したいと思っています。
「改善タスク山積み」については、改善案件を専門とする開発チームを作っていて、そこで改善タスクの対応をしています。
優先順位付けのところですが、こちらはRICE（Reach、Impact、Confidence、Effort）スコアというのを定義して使っていて、ペインを可視化しています。それによって何から優先的にやるべきかを明確にして、ペインを可視化して対応しているところを今行っています。
「『手運用でカバー！』がどんどん増えてしまう」に対する対策です。いわゆる手運用する人もちゃんと1人のユーザーとして認識した上で、サービス設計を行うところをやっていて。
案件を進める時に要求仕様書のレビュー会を関係者で行っていきますが、そこに運用する人もきちんと入ってもらって、指摘してもらって、トータル的にサービスとして問題なかった（かという）ところも含めて見てもらうことをやっています。
手運用解消の改善タスクについて、先ほどの2番目のところにもつながっていきますが、実施期間を明確にして、いつまでにやるかも明確にして対応しています。
先ほどの考慮漏れを改善するための対応で、トレーサビリティチェックを導入しています。ただこれは、本来は品質管理の一環で、定義した要件と対応する機能の突き合わせをして抜け漏れを防ぐ仕組みです。これを導入して、各プロジェクトごとに適用する。影響する範囲をあらかじめ把握して、考慮漏れを見つけることを目的として導入しています。
これは本当に一例ですが、これまでのGOが作ってきた機能をガッと並べていて。まずそれを最初に作っています。
例えば、新しい案件をやる時に「その案件がここの機能のここに影響する」というところを、PdMとかエンジニアとかQA、あとデザイナーと、ロールごとの観点から影響があるかどうかを判断してもらって、影響あると思う部分については丸を付けるみたいな感じで、ざっと影響範囲を見ています。
PdMは中身の実装まで全部把握していなかったりするので、やはりそれぞれ気づきが違うんですよね。既存の仕様に一番詳しかったりするのは、けっこうQA部隊だったりするんですけれど。ロールごとの観点でチェックをしてもらって、それをすり合わせる場を作っています。これによって影響漏れをだいぶ潰せているというのを今の実感として思っています。
もう1個ですが次です。ここはMVPの認識をきちんと合わせましょうというところですが、その案件をやることによって解きたい課題と解決後の姿を明確にして、最低限守るべき質をちゃんと定義します。それを関係者と認識を合わせることによって、案件のゴールを明確にして、スコープもズレないようにしています。
この表ではフェーズ3までを例としてあげていますが、フェーズごとに誰をどんな姿にしたいかをまず明確にして、その時に提供する機能を記入して、それに対して想定する効果を書いています。
これを関係者できちんと案件をやる前にやることによって、認識ズレを防いで、この案件で達成したいMVPの認識を明確に合わせた上で、予期せぬことが起きてもきちんと対応することができているかなと思っています。以上です。
向井：ありがとうございます。非常にロジカルな打ち手ですね。ステークホルダーとの認識ズレだったり、考慮漏れを防ぐ取り組みは非常に勉強になるなと思いました。
（次回に続く）
