こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
プロダクトの開発を始めた当初はすばやく機能をリリースできていたのに、プロダクトが成長するにつれてだんだん何をするにも時間がかかるようになってしまった、という経験をしたことのある人は多いと思います。
こうなる大きな理由はコードやプロセス、コミュニケーションの複雑化です。本セッションでは、これらの問題を解決して、価値をすばやく届けられるようにするために、何を考えてどのような改善をしていけばいいのかについてお話します。
会の様子
アウトプット/アウトカム/インパクト
最初に前提の話として、アウトプットとアウトカムとインパクトの説明がありました。*1
アウトプット...コードの量など
アウトカム...顧客が抱える問題の解決、行動変容
インパクト...組織に与えた金銭的な影響
価値交換システム
顧客やユーザーにとっての価値は問題を解決したりニーズを叶えることであり、それを継続することが企業活動につながるという話がありました。
今回の発表では、この価値交換を継続できるようにどうすればいいか？という話をしてくれました。
アウトカムを決める要素
アウトカム=問題設定力×開発力×チーム力だという話がありました。
掛け算で表されるのがポイントで、どれかの要素が0であればアウトカムは出せないということです。
アウトカムを持続可能なペースで提供し続けるには、改善をするために強制的に立ち止まるのが一つの手だということで、これは例えばスクラムのレトロスペクティブなどが挙げられるというお話でした。
プロダクト開発の流れ
アウトカムの説明があったところで、次にプロダクト開発の流れの説明がありました。
プロダクト開発は、
- 解決したい課題を見つける
- 課題とソリューションの仮説を評価する
- ソリューションを作る
- ソリューションを評価する
- スケール
という流れで進みますが、上記の3と5にフォーカスしがちな点には注意しないといけない点や、機能が一定以上増えるとユーザー満足度はどんどん下がるという話がありました。(2019年には80%の機能が使わないことが分かっている)
生産性の落とし穴
アウトカムがそもそも出ていない状態で改善をしてもどうしようもないよねという話があり、そこから生産性の話につながっていきました。
何かを改善するとなると、生産性を改善させようという話になりがちですが、そもそもアウトカムが出ていない状態で生産性を上げようとしても、ゴミが大量生産されるだけなので、改善すべきなのはまずアウトカムであるというお話でした。
開発力の改善
アウトカムを最大化するように改善していくという話から、開発力の改善の話がありました。
ryuzeeさんが支援しているチームでは、開発力に課題があるチームが意外と多いということで、具体的には以下のような点が改善するためのポイントになってくるという話がありました。
- 短い期間で機能を作れるようにする
- 変更に強い構造を作れるようにする
- テストの負担を一定に保つための工夫をする(テスト自動化)
- 品質や速度低下の兆候を継続的に潰していく
- 「フロントエンド担当」「バックエンド担当」みたいに専門性が分かれており、分業が発生しないようにする
また、その他にも、LeanとDevOpsの科学にあるような24個のケイパビリティなども意識したほうがいいということでした。
こうした改善をするためには作る量を減らしてでもトレーニングを積んだり学習を進めたりすることが重要だということです。
文化の改善
前述した開発力の改善なども、良い文化が根付いているのが前提条件であり、
- 非難文化がないか？
- 安全が必須条件になっているか？
- コミュニケーションの複雑性が低いか？
- The API Mandate
といった点を考慮する必要があるという話がありました。
チーム構成の改善
まず、ryuzeeさんの個人的な考えとして、組織構造やチーム構造をいじるのは問題領域の設定や開発力の改善よりは優先度が低いという話がありました。
チーム構成や組織構成を改善するのは高コストであり、なかなかいじる障壁も高いので、他の要素が揃ってから最後にいじるのがよいのではないか？ということです。
また、機能しているチームができているときは解散させずに保つことと、兼務をなるべくしないことが重要だというお話がありました。
Q&A
最後にQ&Aがありました。以下、内容を常体で記載していきます。
開発力を上げるために組織全体で開発力を上げるためには？
道場を作って、安全に失敗できるような場を作る。
また、ベテランの人がやったほうが早いという誘惑に耐えて、スキルトランスファーを積極的に行うようにペアプロをすることも大事。
非難文化を改善した具体的な事例は？
お客さんの話なので答えづらいが、組織レベルなら経営者が変わるのが一番早い。
チームレベルなら、Googleが公開しているようなチームに関するふりかえりを率直に行うとかも効果はある。
組織が「できる人」をプロダクトに兼務させたがるのだがどうしたらいいのか？
Noということ。リクエストする人に対してNoということが大事。
デザイン思考から開発にたどり着くのに苦労しているのだがどうしたらいいのか？
今持っている材料を一回全部書きだしてみるのが重要だと思うので、今までどんなことがあったのか？や課題はなんだと思うか？を一度書きだしてみるのをおすすめする。
メンバーレベルの人が組織改善する場合、経営者にそのことを効果的に伝えるにはどうしたらいいのか？
4 keysは説得力がある。定性的なデータも併せてぶつけてみるのが重要だと思っている。
会全体を通した感想
ryuzeeさんらしく、要素がコンパクトにまとまって話のつながりもめちゃくちゃしっかりしている素晴らしいお話でした。
個人的な経験では、チーム構成をまずいじろうとして失敗する場面をこれまで多く見てきたので、まずは開発力向上と問題設定に注力しようという考え方はすごく共感しました。
