5年ぶりに開発プロジェクトを回してみて得られた実感

はじめに

こんにちは。IVRyでエンジニアリングマネージャーとして働いている海老原です。ちょうど去年の12/1に入社して怒涛のように一年が過ぎました。入社エントリーに個人的な嗜好をつっこんだお陰で、今でも初めてお話しする社内外の方から「GRAPEVINE好きなんですね！」と触れてくださることも時々あります。

改めて、本記事は、IVRy Advent Calendar 2025「みんなが知らないIVRy！」一日目の記事になります。

さて、私は前の職場の特に後半ではどちらかというと全体のビジョンやコンセプト、方針を定める局面が多かったり、IVRyでも組織の運営面の側面が多く実際の実装や開発プロジェクトの実務からはもう五年ぐらい離れていました。

しかし、AIを価値の中心に据えたサービスの開発手法については既存の知見からのアップデートが必要になります。私自身、過去の一般論の視点だけでなく最新のスタイルを模索・キャッチアップするためにプロジェクトに実装やプロジェクトマネジメントの立場として参加しています。この数年間、開発の進め方などについてマネージャーとしてレビューすることが大半になっていましたが、久しぶりに自分自身でプロジェクトを回してみて懐かしいような新鮮なような感覚がありました。

そして、改めて考えてみるとIVRyとして開発の進め方についてはこれまであまり発信してきていないように思います。一方で、特にソフトウェアエンジニアを中心に開発関連の方の大きな関心事の一つとしてまさに「その会社が日常どのように開発を行っているのか」ということがあると思います。今後より体系的な発信ができるといいですが、まずは直近自分が実際にどのような進め方をしたのか、そこからどんなことを感じたのかを記してみたいと思います。

プロジェクトの前提

IVRyでは、先日11月6日に新しいデータプラットフォームIVRy Data Hubについてリリースしました。

今回私が参加している開発プロジェクトは、このIVRy Data Hubの一部のもので、簡単に言えば「自分たち自身が営業行動の中でユーザーとして使っているアイブリーから得られるデータや、関連する他のビジネスコミュニケーションデータを活用してインサイドセールスやフィールドセールス、カスタマーサクセスの人たちの業務支援を行う社内エージェント」を開発するものです。

これによって、

• IVRy Data Hubの開発を進めるために必要な顧客インサイトを最も近く手触り感がありリアルに手に入れることで仮説検証を高速に回す手段

• 「最高の技術をすべての人と企業に届ける」の対象としてIVRy自身を捉え、AIやデータ基盤を業務改善に使い尽くす試み

の両者を推進する狙いがあります。AIとデータ基盤を用いて業務改善を行う取り組みはまだまだ実際にどのようなことができるのか皆が手探りしている状況のため、明らかに成果が上がるであろう施策を粛々とこなすというよりは、「探索的に実験してみて、どんなことが実際に改善につながるのかを学習する」「そのために何を実現するのか自体完全に自分たちに委ねられている」という出発点の自由さも前提になってきます。

一方で、社内向け開発の常として大工数を割くことは難しいため

• 人数はプロダクトオーナーとデータエンジニア、私の三人

• 三人とも他に大きな業務を兼務している

• 四半期を一旦の区切りとするため期間は短い

という制約が前提としてありました。

重要視した価値観

プロジェクトの性質とはまた別に、今回改めて重要視した考え方は、つきなみなものではありますが以下のようになります。基本的には、常に思考のベースにしている事柄ではあります。

• 社内ツールであろうと、むしろだからこそ思考の起点を常に「顧客価値」に置く

  • 事例づくりや「試しに作ってみた」で終わらせず、セールスの方たちにとっての改善はなんなのかを設計する行為としてプロジェクトを進める

• 巨人の肩に乗る

  • オリジナルの何かをゼロから設計するのではなく明確な方法論に従い、その基礎を徹底してプロジェクトを進める

• プラクティスの本質を問う

  • 一方で、単に形式を遵守するのみでなく、プロジェクトの性格や状況に応じて、手法がもたらす価値は何なのかを実現する形でプロジェクトを進める

やったこと: 立ち上げ時の言語化

プロジェクト立ち上げ時の各種の言語化・ドキュメンテーションは、プロジェクトの前提にある通り少人数短期プロジェクトであることを踏まえるとどの程度議論や工数を割くか悩ましいところではあります。

一方で、AI時代のソフトウェア開発に関する議論において、ほぼ共通した見解として「言語化・テキストによる情報整理」の重要性の向上が言われています。今回は、小規模だからといってここを手抜きせず、しかしコンパクトにすることを意識して「とにかく言語化する」「一次資料をグラフィカルでなくテキストで起こす」ことをプロジェクトの前提に対しては手厚くなるのを認識の上進めました。

プロジェクト憲章

IVRyではドキュメンテーションについて基本的にNotionを使っています。プロジェクト全体の起点になるNotionページに、いわゆるプロジェクト憲章として背景・スコープ・役割定義・スケジュールなど一通りの項目をまとめました。全てを書き下すと言うよりも、そこに行けば必ずプロジェクトのことが分かるポータルとしての性質のものとして作成したため、スケジュールはタスク管理ツールLinearのプロジェクトマイルストーンへのリンクにする、その他別のプラクティスで行う言語化へのリンクにするようにして、作って終わりの文書というよりは期間を通して育てる性格のものにしました。

インセプションデッキ

インセプションデッキは初期の言語化として定番のプラクティスだと思いますが、本格的に行うとするとしっかりしたワークショップや情報整理が必要な比較的重いプロセスになります。ここはプロジェクトの前提を意識して、実際の開発の推進のために気になる部分のみを三人で集中的にディスカッションしました。実際にフォーカスしたのは以下の3つです。

• やらないことリスト

  • 少人数短期間兼務プロジェクトとして、本当に必要があるものだけに真に集中する必要があるため「ここはこだわらなくてよい」は明確に言語化した

• 夜も眠れなくなる問題は何か

  • 全てが手探り・学習主体のプロジェクトとして、実現性などの観点で既に見えている頭の痛い問題はあるか、それは向き合う必要があるものか一旦忘れていいものか

• トレードオフスライダー

  • 何かに迷った時に一番優先すべきことは何かの基準を事前に全員で握る

本来「我々は何故ここにいるのか」が常に最重要と考えていますが、これはプロジェクト憲章によって言語化されているので問題ないとしています。

ワーキングアグリーメント

プロジェクトの前提を踏まえると、価値観や約束事について認識を合わせるワーキングアグリーメントを明確に言語化するのかはやや意見の分かれるところです。

実は背景として、三人という少人数である程度ツーカーでやれるとはいえ、全員の入社歴が1年弱～1ヶ月と短く、会社そのものとしての暗黙の価値観や思考の基盤が全員で共有しきれておらず、何か議論が発生するたびにゼロベースで前提の食い違いを修正し直す工数がかかることを懸念しました。そういう意味では、表現としてのテイストは異なりますがインセプションデッキのフォーカスした項目と同じような課題意識で言語化を行ったと言えると思います。

実際の項目としては、よくある「オンラインミーティングでは顔出しで」「Slackの一次反応はできる時の最速で」のようなよくあるものもいくつか挙げはしましたが、あまり認識の齟齬が無いようなことが多かったため最小限にとどめ、どちらかというとここまで書いてきたような「思考のベース」「判断基準」として以下のような抽象的なこと・価値観を中心に整理しました。

• プロジェクトの目的を「(顧客価値に対する)学習・ディスカバリー」に置き、何かを選ぶ必要がある時は「学習の最大化」を基準とする

• 全ての事柄に対して言語化・形式知化を行う

• 「重要視した価値観」に記載のような事柄

やったこと: Scrum Dayの設計

いわゆるスクラム開発の各種イベント（プランニング、リファインメント、デイリー、レビュー、レトロスペクティブなど）は基本的に三本柱と言われる「透明性・検査・適応」を主眼として行うことですが、しばしば「会議が多い」という形で難色を示されるところでもあります。

私は、基本的に「本来必要な合意形成や認識同期をスキップして出す実装進捗は見せかけのものであって本質的なスピードではない」という立場で考えることが多いですが、プロジェクトの前提を踏まえると最小に圧縮したいのも事実です。今回は、会議の時間の絶対量というよりも曜日ごとの時間の使い方のメリハリをはっきりしよう、ということを目的に以下のような設計にしました。

• スプリントの開始日を水曜日とする(月曜は振替休日になりがちなため)

• 開始日にプランニング、最終日にレビュー・レトロスペクティブという風に2日に分けず水曜午前をスプリント終了のイベント(レビュー・レトロスペクティブ)に使い、午後をスプリント開始のイベント(プランニング)に使うことで「水曜はプロジェクトとしてのコミュニケーションを集中的に行い、それ以外の日は各自のタスクに集中する」というリズムを設定する

• デイリースタンドアップは通常通り行う

その上で、それぞれの会議の設計で以下のような取り組みを行いました。

レトロスペクティブをデータベース化する

やや細かい話ですが、レトロスペクティブでありがちなこととして「なんとなくKPTっぽいことをやるがその場で挙げて終わり」ということがあると思います。

これでは透明性・検査・適応につながらないので、やりっ放しではなくNotion上のデータベースに永続化してレトロスペクティブの前半は既存のKPTの棚卸しに時間を使うようにしました。Problemはそのスプリントで分かった困難に対する発見・学習でもあるので、「この問題は大丈夫なんでしたっけ?」という話を毎週しつこく追跡するようにしました。

スプリントにおける「インクリメント」「学習」にフォーカスする

特にレビューとプランニングにおいて、「そのスプリントのインクリメントはなんだったか?」「定義したインクリメントを満たせたと言えるのか?」「次のスプリントのインクリメントは何か?」「それをブレイクダウンするとどのようなタスクの優先順位を上げるべきなのか?」「進捗の中で得られた顧客価値に関する学習はなんだったか?」といった議論を中心とし、それ以外の個別の詳細なデモであったり個々人のタスクのピック、バックログメンテナンスに関するやり取りはかなり大胆に省略しました。

結果としてそれぞれの会議はきっちりした進捗確認や計画の場というよりは「向かっているところに近づけているのか」「自分たちが向かっている方向にずれ・要修正点は無いか」「新しい発見は何か」などに関する不定形の議論が中心になりました。

OKRとの接続

ここまで全く触れていませんでしたが、IVRyでは元々プロジェクトごとにOKRを目標として定め四半期を通してそのOKRの達成を主眼として進めていく仕事の仕方を取っています。

OKRにおける「トラッキング」の概念は非常に重要な要素のため、スクラムイベントの中の一要素として明確に組み込みました。今回は「xxxが完了している・できている」系のKRが多く進捗度の議論が感覚的になるため、プランニングにおけるOKRチェックインのセクションの中で以下の議論を毎回行うようにしました。

• 現時点でのKRごとの確信度を全員から1-10(確実に無理～確実に達成可能)のスケールとその根拠を表明する

• プロジェクトの最終見解としてどのスコアにするかを議論

• プロジェクト立ち上げ時からの推移を確認、どうして今このスコアになっているのかを議論

• このスコアを向上させ、四半期末頃に10に到達しているために直近で何をすべきかを議論

この議論を受け、そのスプリントのインクリメントとして何を定義するかという論点に移行する流れを作りました。

所感

まず、冒頭にも述べた通り、この数年は自身のレポートラインのスクラムマスター・エンジニアリングマネージャーなどから報告を受けて「そういう場合はこうしたらいいんじゃない?」というフィードバックを行うのが中心で、過去の経験や理論の上である程度自信を持って言ってはいるもののそれが芯を食っているかどうかは間接的にしか認識できない状況でした。

今回具体のプロジェクトで状況を観察しながら施策の実践を行うことで現実的な問題にチューニングを合わせていく感覚を少し取り戻してきていること、また周囲の事例に対してフィードバックしていたことを実際にやってみることでそんなに外したことは言ってなさそうな自信も少し持てました。その他、特に印象的だったのは以下の三点です。

ワーキングアグリーメントによる思考・スタンスの拠り所の醸成

これはプラクティスの定石としてはワーキングアグリーメントに限ることでもないかもしれませんが、今回はこれを中心に「自分たちの最優先事項は『顧客価値に対する学習』である」ということを共通理解として宣言して常にそこに立ち戻るようにしたことは、「なんでもやっていい自由なプロジェクト」に起きがちな議論の迷走に対する楔として有効に作用させられたと感じています。

実は自分自身でワーキングアグリーメントを制定したのは今回が初めてで、「よく言われるけどなんぼのもんなんだろう?」と思いながら進めたのが本音だったのですが、これもプラクティスになんの意味があるかというよりもそれによって解決したいことは何かを見つめ続けて落とし所を作ることが重要なのかなと改めて認識しました。

インセプションデッキの議論によってOKRの確信度が明確に上がった

これも本当のところを白状すると、プロジェクトの初期段階では目指すところを明確にしきれておらず三人の確信度がかなり低い状態でした。

インセプションデッキの、特にどちらかというと不安やフォーカスを言語化するセクションに的を絞って議論することで、一旦皆がなんとなく抱えている不安を外部化・共有でき「不安ではあるがここまでならやれるだろう」「これはどう考えてもスコープ外なのでこの四半期では諦めると決めよう」という認識を明確にしたことが確信度の向上に繋がったと思います。

インクリメント -> 学習 -> 確信度 -> インクリメントの議論の型が自然に形成できた

スプリントにおけるインクリメントにしろOKRにおける確信度にしろプラクティスとしては基本的な事柄ですが、機械的に定義したり確認したりしていてもそれをすることによって本当に何を認識したいのかを意識していなければ形骸化するでしょう。

私たちも、最初から全てを目的意識を持って運用できていたわけではないですがスプリントを重ねる中で「これを定義することで何をどうしたいんだっけ?」を意識しながら形式をチューニングすることで、自然に前スプリントのインクリメントを通じた学習から現在の確信度の更新、そしてその確信度を向上させるための次スプリントのインクリメントを検討するという思考の型を形成できたのは良かったのではないかと思っています。

おわりに

本記事では、私が携わっているプロジェクトがどのように開発を進めているかについてプラクティスを中心に簡単に書き起こしてみました。

IVRyでは様々な性質・前提の開発プロジェクトが動いており、今回のあくまでその一つ、そして多分かなり特殊な性格のものだと思います。実際、それぞれのプロジェクトの話を聞いていても背景が異なりそれを踏まえたプロジェクト推進の仕方を模索し続けていると感じます。今回の内容によらず、IVRyでどのように開発を進めているのか・どんなプロジェクトが動いているのかなどご興味持っていただけたら、是非以下のURLからご登録ください。

herp.careers O03.カジュアル面談

株式会社IVRy

募集要項をみる

そして、IVRyでは、Advent Calendarをもう1レーン走らせています。本日は、Moriyaさんの「もしAI素人が『明日からAIエージェント作ってくれ』と言われたら」が公開されました！ぜひご覧ください。