💡

『Musubi AI 在庫管理開発チームの品質向上ハンドブック』を読んで考えた、ourlyの開発プロセス改善のヒント

ourly tech blog 運営

2025/10/20に公開

先日、株式会社カケハシ様のテックブログにて『Musubi AI 在庫管理開発チームの品質向上ハンドブック』が公開されました。
https://kakehashi-dev.hatenablog.com/entry/2025/10/18/110000
弊社ourlyのプロダクトチームでも本PDFを拝読し、多くの学びや気づきを得ることができました。

この場をお借りして、素晴らしい知見を公開くださったカケハシ様に心より感謝申し上げます！

 個人の感想/学びのまとめ以下では弊社プロダクトチームの各メンバーから章をピックアップし、感想や学びを共有させていただきます！

 相澤がピックアップした章

 ピックアップした章ユーザーストーリーの記載で高い価値を維持する

 感想、学び曖昧で抽象的な会話になりがちなユーザーストーリー(提供価値)をどう分解し、具体的にチケットに何を記載しているかのイメージが湧きました
単に、提供価値 = 機能開発ではない分割基準を示していただいたことで、自分の中に新しい基準の参考になる情報が得られました（ちょうどourlyでも1Qからユーザーストーリーベースでの開発に移行したところだったので）
狩野モデルを取り入れたスコープ判断軸の一例も示してくださったので、今後取り入れる際に参考になりそうだと感じました。

 ourlyで活かせそうな内容分割基準は現状、提供価値 = 機能開発という認識が強かったので改めてハンドブック内で分類していただいたものをまずあてはめてみようと思います
また、狩野モデルをベースにした品質分類も取り入れてみようと思います

 玉田がピックアップした章

 ピックアップした章心理的安全性の理解を深め、コミュニケーションの質を高める

 感想、学び心理的安全性の定義として、単純な安心ではなく対人間関係のリスクを負っても大丈夫だと感じられる状態、というのがとても腑に落ちました。
単なる優しさだけではなく、挑戦を称賛し、ときには衝突を恐れず問題に率直に向き合うことができるという状態をイメージすると、心理的安全性の高さがチームとしてパワーを発揮できる状態とリンクすると感じますし、これは新たな視点でした。

 ourlyで活かせそうな内容ourlyには「気前のよさ」を尊ぶ文化があります。他者への手助けを厭わない、他者の成長のためのフィードバックを恐れない、といった行動は心理的安全性が高いからこそだと感じ、この点に関しての方向性は間違っていないと思いました。
心理的安全性の確認基準や自己点検の節は、チームにおけるガイドラインや行動規範として取り入れられる内容だと感じました。

 神本がピックアップした章

 ピックアップした章要求を分解して要件を明確にする

 感想、学び「見積もり」は単に工数を算出するためのものではなく、「得られる価値」に対して設定した予算と、実際にかかるコストの釣り合いを確認する手段であるという考え方が印象的でした。また、先にリターンから予算（バゲット）を決め、その中で実現可能性を検証していく順序によって、コストを抑えながらも選択肢を広く保てる柔軟な意思決定が可能になるという話も印象に残りました。
さらに、開発の各フェーズごとに要件定義としてどの中間成果物に何を必須で記載すべきかが定義され、逆に「記載しなくてよい項目」とその根拠まで整理されている点も興味深かったです。抽象的になりがちな要件定義を、具体的なガイドラインとして明文化している点に感心しました。

 ourlyで活かせそうな内容ourlyでも、「PMF済みの価値を向上・改善するための機能開発」と「PMF前でまずはPoCやR&D的に進める探索的な開発」が混在しています。今回のようにフェーズや目的毎に要件定義の基準や適用範囲を明確化するガイドラインを設けることで、議論の透明性や開発判断の一貫性を高められると感じました。
価値から逆算して予算やスコープを考えるアプローチは、ourlyのプロダクト価値最大化にも直結する考え方として取り入れていきたいです。

 土橋がピックアップした章

 ピックアップした章完了条件のある開発プロセスとフローを共通化する

 感想、学び開発プロセスのうち検証段階の中でも、”可逆なもの”と”不可逆なもの”が明記されていることが印象的でした。心理的にも意思決定がしやすくなる効果が期待できそうです。
またここまでプロセスが体系化されていると、振り返りの際にどこの意思決定に問題があったのかを振り返りしやすく、複利的にこの開発プロセスの構造を磨き上げることもできるのかと感じます。
プロセスの細部においては、要件定義の段階で「効果判定条件策定」の項目があることに驚きました。いわゆるリリースしたものの効果測定とその撤退条件を明示するプロセスになりますが、常にプロダクトの価値密度を最大化することを念頭に日々プロダクト開発に携わっているカケハシさんの姿勢が感じ取られ、ぜひ自分も見習うべき姿勢だと感じました。

 ourlyで活かせそうな内容プロダクトのダイエット（価値提供があまりできていない機能の改善・削除）はぜひ取り組みたいです。
ourlyにおいては、これからより機能拡充・価値検証をしていくフェーズになるので、「リリースしたものがどういった価値提供を狙ったものなのか？」そして「それはどういった指標から検証するのか？」を事前に言語化し、チーム内で合意をとった上で開発をしていくようなプロセスにしたいです。

改めて開発プロセスの全体像を整理する動きも必要だと感じました。
現時点でPO・デザイナー・エンジニアがそれぞれどういう領域や役割を担っているのかを明記することで、エンジニアがもっと介在すべきポイントを明確化でき、越境できるポイントをより見つけやすくすることにつながると考えました。


 永山がピックアップした章

 ピックアップした章開発用語を定義して認識を合わせる

 感想、学び用語集を作って思考の軸を共有することで、メンバー全員が共通の前提・解釈をもって会話でき、設計や仕様の議論がよりスムーズになると感じました。
解釈が揺れやすい言葉を明示的に定義しておくことで、レビューや議論の際に本質的な論点に集中できるのではないかと思いました。
過去の経緯や背景を知らないメンバーでも文脈を理解しやすくなるため、新規参入メンバーのオンボーディング効率化にもつながりそうです。

 ourlyで活かせそうな内容ourlyはカルチャーが強く、ビジネスや開発における思考の構造化や仕組み化が日常的に実践されている環境だと感じています。普段の会話や議論の中でも学びが多いので、こういった考え方を用語集にも落とし込めると、カルチャーを形として積み上げることができそうだなと思いました。
こういった用語集を作る「過程」自体にも価値があり、認識のすり合わせを通じてお互いの理解も深まりそうです。

 最後に最後までお読みいただきありがとうございました！

『品質向上ハンドブック』では、現状の方法をベストとせず、常に改善を重ねていく姿勢が印象的でした。

カケハシ様のこうした取り組みを参考に、ourlyでも顧客への価値提供を最大化すべく、継続的なプロセス改善に取り組んでまいります！