「[価値と構造 勉強会]「使われるシステム」を開発する」に参加してきました
2023年11月24日（金）19:30~21:00に開催された「価値と構造 勉強会 - 「使われるシステム」を開発する」に参加してきたのでその内容を共有します。
おことわり
今回のレポートは非公式的なものであり、自分なりに整理したものです。
「こんなこと言っているんだな～」と思ってみていただければと<(_ _)>
サマリ
使われない機能を開発してしまう要因について、分析結果を共有し、それをベースにディスカッションする会
「価値」という点から分析すると、機能面にフォーカスしすぎており、As IsとTo Beに注力できていないことや情報がちゃんと伝達されないということが要因ではないかという結果になった
ディスカッションでは、なぜ機能面にフォーカスしてしまうのか、何が壁となっているのか、それをどう打破してくとよいかといった議論が行われた
本勉強会について
株式会社レヴィ主催の勉強会で、今回は使われない機能を開発してしまう問題について、主催者の安達さんが価値という側面から分析した結果を共有し、その内容をもとにBalus PdMの安西さんや参加者とディスカッションする会でした。
たくさんの人数で頑張って導入or開発した機能がほとんど使われない。
そんな経験があるプロダクトオーナー、システム導入者、プロジェクトマネージャー、エンジニアなどの方々は沢山いらっしゃるのではないでしょうか。
誰も望んでいないこんなことがなぜ起こるのか？？ この疑問の解消は一筋縄ではいきません。そこには複数の構造や要因が隠れているのです。
そこで今回は、コトづくりを指向する安達が開発現場で起こっている悲しい出来事を「価値」の側面で分析してみた結果やそこから得られた仮説を持ち込み、さまざまなアジャイル開発プロダクトに携わっている安西にレビューしてもらう／レビューの過程で”現場で何が起きているのか？”をディスカッションしてみることにしました。
実施するわれわれもどういう結論になるのか？、いや結論がでるのか？もわからない台本なしの一発勝負。 現場で起こっている悲しい事象の背景や要因とはいったい何なのか？ 一緒に探ってみましょう！
私もシステム開発の要件を整理する立場におり、少しでも多く方に使ってもらいたいと思っているため、本勉強会に参加しました。
安達さんの分析結果共有
使われるシステムの要因
David Aakerの価値3分類（ベネフィット3分類）を基に分析
使われるかどうかの境目は、現状の価値・課題（As Is）と実現したい価値・目的（To Be）部分
システムで提供することだけを増やしても、現状価値・課題と実現したい価値・目的に紐づいていなければ、使われなくなる
なぜ、現状価値・課題と実現したい価値・目的部分がおろそかになるのか
開発者からの距離が遠い
工程ごとに役割を分けている場合、開発者に届くときには重要な情報が抜けている可能性がある
開発する時にはいろいろな構成要素（インフラ、DB等）を考慮する必要があり、その大元が見えにくい
いろんな人が関わる場合、人によって関心事が異なるため、認識齟齬が発生しやすくなる
期待していたものと違うモノができあがってしまう
開発者も含め、プロダクト開発に携わる人は現状価値・目的と実現したい価値・目的部分から一緒に考えるべき
ディスカッション
安達さんの分析結果を基に、Balusを活用しながら、いろいろな議論が行われました。
その内容の一部を共有します。
①：なぜ、開発者は機能的価値にフォーカスしてしまうのか
一次情報から遠くなっている現象が起きているから
エンジニアにわたるのは二次、三次情報
利用者がどのような行動を起こしているか等の現場情報が薄い
ペルソナが出てこない時や利用者情報が少ない≒実際にどんなことをしているのか知らない時はこういうケースも多い
人数が多い時によくあるらしい
開発とビジネスをつないで考慮できていない
何のため、誰のため、課題、ソリューションを考慮できていない
開発者は設計にフォーカスしがち
解決の手段が決めやすく、直ぐに実装できるからかも
すでに目の前の作業（機能的価値）の実現に手一杯であり、それ以外のことを考慮する時間が少ないのでは？
②：ソリューション実現方法にフォーカスする時間はどうとるべきなのか/なぜ取れないのか
壁（制約）がたくさんあるということが判明
制約
時間
メンバー数
スキルセット
契約（スコープ）
判断権限（自ら意思決定できるかどうか）
ビジネス構造も要因っぽい
下請け構造
開発メンバー全員で課題の共通認識を作ることは投資で、後に回収できるのでは
上記のような人がいるかどうかも制約事項
③：いろいろな壁がある中で打破していくにはどうすべきか
プロダクトを網羅的に検討するための4階層（※1）の情報を関係者全員の共通認識にするべき
ビジネスから開発へ伝わるフレームワークがあるとうれしい
インセプションデッキ（※2）はその1つだが、もっと使いやすくしたい。。（パッケージデザイン作成など手間がかかるものもある）
時間はかかるが、ボトムアップ（How⇒Why）のアプローチもありそう
プロダクトの階層ごとに役割を分けたくないが、リソースや時間が有限である
混成チームで担うようにするとうまくいった
うまくすすめるために、ファシリテーション能力は重要
開発時には誰も正解を持っていないため、全員で考えていく必要がある
役割ごとに分けると「誰か答えがあるんじゃないか」と思って進めがち
実際作ると答えじゃないこともある
PdMやPOは「答えを出さなきゃならない」と思っているかもしれない
ユーザーのことを知らない、分からないことを共有することが大事かも
「教えて」といえる
不安定な状態（不確実性が高い状態）を保つことで、全員が周りが考えるようになる
（※1）2020年にしたプロダクト系図解まとめ、もしくはプロダクトマネジメントのすべて-Chapter3を参照のこと
（※2）AGILE STUDIO - インセプションデッキ、アジャイルサムライを参照のこと
学びになった/気づいたこと
「価値」を3分類に分けて、説明していただいたことで、
システムの外側でどんなことを考えるべきかは少し鮮明になった気がします。
自分の経験ですが、目の前が手一杯になっている時は、
あまり「価値」まで考えられずに与えられた情報だけで進めてしまうな～と感じました。
（それで手戻りが発生したな～と思い出しました。）
ユーザーの手に触れるまで正解がわからないという点からみると、
与えられた情報を信じすぎず、「本当に必要なものか」「なぜ必要なのか」をちゃんと考えるべきだなと思いました。
また、わからないことは明確に表明するという点ですが、
以前開発を始める前に「わからないから教えてほしい」と言ったときは、
お互いに協力して進めることができた経験があるため、とても重要なことなのかなと思いました。
また、一緒に考えるためには蜜にコミュニケーションを取って認識合わせをすることも重要かなと感じました。
感想
結局、壁は一杯あって乗り越えるのが大変だなという感じで終わってしまったので、続きも聞きたいなと思いました。
いろんな人の意見を聞けて楽しかったです。
補足
Connpassグループについて
この記事が気に入ったらサポートをしてみませんか？