この記事は6/4にBit Valley -inside-さんのご協力の下で開催された、『「正しいものを正しくつくれているか？」〜経産省プロジェクトでのアジャイル開発〜』のレポート記事です。
このイベントは5月14日に開催された「経産省と本気でアジャイル開発をやってみた！制度ナビPJで見えたGovTechのリアルと未来」の講演についての掘り下げを行ったイベントでした。
越境ジャーニーでもすでに、記事にしてありますのであわせてご覧ください！
イベントのメインは大きく2つで、
前半はギルドワークス株式会社の市谷 聡啓さんによる経産省プロジェクトについての講演、
後半はプロジェクトチームのメンバであるKOUSEI NISHIさん、沼田佳介さんを交えて参加者からの質問に答える形で進行されました。
正しいものを正しくつくれているか？
自分たちだけで越境できないのなら，ユーザを巻き込んで残せるものを残そう
市谷さん
この講演は、5月14日のイベントの再演ということなので、掘り下げがあった部分や、追加でお話があった部分を中心にまとめてあります
プロジェクトの背景
市谷さん「2018年の下半期にかけて中小企業庁が主催のプロジェクトを手がけていました。そのお話になります。
今回のプロジェクトで私は制度ナビチーム全体のマネジメントをしていました。規模は省庁内のデジタルトランスフォーメーションを推進している方々含めて約10人、開発チームは5～6人くらいになります」
プロジェクトの目的
市谷さん「このプロジェクトでは、中小企業への支援策や補助金の情報提供をするサイト ”ミラサポ” をリニューアルすることが目的でした。それが ”制度ナビ” です。
アジャイル開発でやりたい！ということだったので、私は制度ナビチーム全体のマネジメントとプロジェクトオーナー支援をしていました。分かる人には分かると思いますが、これちょっと危ない感じしますよね笑
それなりに苦労するところがあったけど、やってこれたのは開発メンバがともにつくるで関わってくれたからです。SlideShareに上がっているので、そちらも見てくださいね！」
“アジャイル開発”だけで 「何をつくるべきか」が⾒えるわけではない
市谷さん「アジャイル開発へのいろんな解釈があるけど僕は
早く（少しだけ）形にできる
と思っています。
言葉の通り、『アジャイル開発ならいい感じのプロダクトができるんやろ！』というのは乱暴な話で、
アジャイル開発をやっていれば何を作るべきかが見えるのではありません。
フィードバックベースで作っているものの認識があっているかはわかるけど、そもそもあわせる先が大丈夫なのか(そんなもの存在するのか？)は分かりません。
そういう状態にこのプロジェクトもあったわけです。
想定しているユーザーがどのような状況に置かれていて、何が課題となっていて何が必要なのか、仮説を立てて検証して何を作るべきか見立てる仮説検証が必要だったわけです。
この『仮説検証が必要』というのを関係者の方に理解してもらうには結構ハードルが高いものです。」
アジャイル開発はフィードバックを反映させながらプロジェクトを進める手法であって、 それがビジネスを成功させる直接的な方法ではないということなんですね！
”アジャイル開発”が思考停止ワードになってしまって、ビジネス視点が欠けてしまっていることも結構ありそうですね
プロダクト作りでの問題
市谷さん「仮説検証が何なのかを説明し、まともに合意形成するのは難しいので、プロジェクトとしてプロダクトバックログをつくるために必要な活動の一つであるという位置づけで実施しました。活動を踏まえて、プロダクトづくりに入りました。
ここで非常に厄介な2つの問題にぶつかりました。
①プロダクトの「全体感欠如」問題
そもそもプロダクトとして、制度ナビは部分であり、ミラサポ本体と事例ナビと制度ナビの3つのアプリで構成したいという方向性が出てきました。
ある部分はギルドワークス、ある部分は他の会社さんで企画・開発を進めていたのを、プロジェクトが始まってしばらく経ってから知りました。後からでは、スケジュール全体の整合性を合わせようがなく、利用ユーザにとっての統一的な体験設計が難しい状況になってしまう問題に直面しました。
②データの境界は「組織の境界」問題
こちらの方がもっと厄介な問題でした。
支援策（助成金、補助金）の表現の仕方がいかにわかりにくくても、それを変えるのが難しい。支援策を企画している自治体、省庁と膨大な調整、合意形成が必要になるためです。
いかにサービスの検索機能を改善しても文章自体が難しければ、ユーザーは情報を活用することできません。
①の問題について、プロジェクトが進行してしまっている途上で大きく変更していくのは困難です。何とか3チームで集まったり、整合性を整えようとするけども、理想的な滑らかな体験にはならないんです。
②の問題については、アジャイル開発以前の問題です。そもそも支援制度をつくるためのガイドラインが無いので、記述にばらつきがあって当然です。ガイドラインの整備から必要になります」
現状維持の大モーメンタム
市谷さん「データについて、誰も明確には管理していなくて、そのメンテについても誰も判断できないし、では勝手にやってしまっていいのかというとそうでもない。
あるのは、これまでこうしてきたからという現状維持のモーメンタムです。これに立ち臨むには、関係者含めて全員でどこまで出来るのか手探りで進めるやり方、探索的になるしかありません」
「行動でしめす」のが唯一できること
市谷さん「状況に対して、正論をぶつけることは誰でもできます。ですが、正論が通じないからやめてしまう、諦めてしまうのでは何も変わりません。必要なのは「行動で示す」ことです。
正論をぶつけに行って変わることがなく、途中でやめてしまったら、何も残りません。次にも繋がりません。
でも、作ったものは形が結果として残ります。
その結果は「次にやるべきこと」を突きつける、宿題となります」
自分たちだけで越境できないなら、ユーザを巻き込んで残せるものを残そう
市谷さん「最後に、3アプリ（ミラサポ本体、制度ナビ、事例ナビ）合同のユーザテストを実施しました。
3アプリのメンバで集まって、ユーザのリアルな反応を全員で受け止めようとしました。
自分たちのできていなさ加減をここで体験するんです。
なんとなく、『 問題があるんだよね 』ではなく、お互いを理解して、きちんとそれを言語化して、プロダクトバックログにして次に残します。
うみだされたプロダクトは宿題であり、希望でもあります。
問題提起をしてくれる存在となり、宿題を突き付けてくれる。それが今後より良いプロダクトになる可能性を残すことになります」
Q&A ディスカッション
ここからは会場参加とzoom参加のみなさんから、sli.doに寄せられた質問をディスカッション形式で回答するコーナーです。実際に開発に参加されていた沼田さんと西さんも交えてのコーナーでした。ここでは一部の質問をご紹介します。
Q．合宿の中身を知りたいです。できればどう参加してもらうところまでこぎつけたのかも知りたいです！
沼田さん「この合宿は3つのプロジェクト合同でやりました。内容としては、みんなでプロダクトに向き合って、触っている時間が長かったです」
西さん「自分は都合で少し稼働を少なくしたタイミングで、ちょうど合宿になりました。ですが、デザイン等はみんなで決めた方が良いと思っていた所だったので、参加しました。
実際の合宿では、作ったものをみんなで見ながら、デバッグレベルでデザインを検討したり、落としどころを探ったりしました」
市谷さん「この合宿は3つのプロジェクト合同でやったので、他のプロジェクトの知見も巻き込む形でできたのは面白かったです」
Q. メンバが副業だったり、リモートで働く場所がバラバラだったりする中でどうやってチームで開発を進めていくのでしょうか？
市谷さん「副業・リモートだと時間、作業量とかの分断が起きるので、同じオフィスで開発するよりもやりにくいんです。
実際にシン・ミラサポでも『メンバと同期しにくい』、『プロダクトバックログアイテムごとのオーバーヘッドが発生する』といった問題が顕著に現れました。
これらの問題はコミュニケーションコストを上昇させる事に繋がります。
結果として、ステークホルダ間での認識のすり合わせがうまくいかずに、プロジェクトや制約の認識齟齬が生まれてしまう事がありました。
そういったことがある為、最近ではリモートで気を付けている事を言語化し、雁行陣開発（がんこうじんかいはつ：後述有）をしています。
この開発手法はサッカーのフォーメーションに近いような考え方で、フォーメーションで時間を切って適応しています。
あとは、合宿をしました。
1日だけではありますが、ステークホルダが一同に会して強力な同期をするんです。
このプロジェクトにおける合宿では『設計的な問題は何？』とか『このバグは？』といった話をしました。
スマートではないけれど、強力な方法をとりました」
Q．プロダクトの認識齟齬というのはクライアントによるものだったのでしょうか？
沼田さん「クライアント側だけでなく、開発チーム側にもありました。受け入れ条件においても、テキストを見て想像する場面がありました」
市谷さん「そうなんですよ。背景としてコミュニケーションが難しいんです。途中、『みんなプロダクト触ってないんじゃないの？ここタップしたら落ちるじゃん！』ということがありました。何かの迷いがあって触ってないのではないかと思い、合宿をしました」
Q. 雁行陣開発（がんこうじんかいはつ）とは何ですか？
市谷さん「副業・複業、リモートでバラバラな時間で働いているチームだとどうしても様々な分断があって、やりにくいんです。
これらの分断は同期しにくいとかオーバーヘッドが発生するとかの問題が発生します。
そこで、リーダーではなく、プロダクトリード、チームリードというそれぞれのミッションを先導する役割を置いて、分断された状況に適応する形をとる作戦でる。」
Q．二人にとってこのプロジェクトでの学びは何ですか？（市谷さん）
沼田さん「『自分で作るものを決める』詳しく言うと、一覧機能に対して、これをどうすればユーザが使いやすくなるのかを自分で考えていいので、学びというか気づきです」
西さん「ほとんどゼロからアジャイルを勉強しながらやりました。
開発では『前提条件として間違っているのに、そのまま進めていくのが正しい解決策なのか？』『それは必要なのか？』という部分を考えることがよくありました。
これだけ世の中にサービスがある中で、より多くの人に共感されるようなプロダクトを作る。その為には何をカイゼンして、今から何を作っていくのか考えながら、スプリントで週一でプロダクトを覆しながら作っていく。
プロダクトを作る自分の意識が変わっていく感覚が得られたのが学びです」
Q. 現在のソフトウエア開発の課題とはなんですか？
市谷さん「 何を作っていくのか決めていいのはこれまでのソフトウエア開発の問題というか課題だなと思うんです。
作って良いんですよ。必要だと感じた意見を述べて、意思決定はある場面でやらなきゃいけないんです。
その意思決定の場がスクラムイベントでそこではPO、ステークホルダー同士が会って決めていく。
そもそも仮説検証をやっているのかというのが、
だれかの勘と経験と立ち位置に頼ってやるのを散らす為
なのです。
プロダクトの上限とプロダクトの”正しさ”がその人に依存してしまうし、その人の勘と経験に頼ったからといって必ずうまくいくわけではありません。
なので、仮説検証はある意味では、PO（プロダクトオーナー）みたいな人に意思決定が集中しているところを引きはがし、意思決定の民主化をすることになります。
基準を人に頼るのではなく、自分たちで追い出し、仮説キャンバスみたいなもので仮説を立てるんです。とはいっても、今後間違っていく可能性はあるので、みんなで修正もする。さらに、それを意思決定と照らし合わせてどうなのか考えていく、というのが次のプロダクト開発の進め方ではないかと思ってやっています」
おわりに
いかがでしたか？今回のイベントでは、経産省プロジェクトの進め方と、開発チームから見た経産省プロジェクトのお話しがされていました。
お話の中にはメンバがプロダクトに全力で向き合っている様子やチームで働くためのエッセンスがちりばめられていました。何故チームで開発するのか、チームの力を最大限に生かす為には何をするのか、考え、向き合うきっかけになった方もいらっしゃるのではないでしょうか。
おまけ
今回のお話にあった仮説検証とアジャイル開発についての市谷さんの本が、6月14日に出版されました！
Amazonリンクはこちらです。ご購入希望の方はこちらからどうぞ！
同日開催された出版イベントのまとめレポートも後日アップするので、読んでいただけると嬉しいです。
