以下の内容はhttps://nealle-dev.hatenablog.com/entry/2025/12/02/112000より取得しました。


合意形成を念頭にドキュメントを書くと仕事が捗る

ニーリーアドベントカレンダー2025、2番手を務めますプロダクトエンジニアの大友凜です。
最近、今更になってグランメゾン東京を見て「ボナペティ(召し上がれ)」と言うことにハマっています。
ただ、完全に時期を逃してしまっているため、あまりネタが人に伝わることがなくスベりまくっています。

さて本題に戻りまして、直近「ニーリーには今、エンジニアとしてのキャリアを賭ける価値がある」という強気なタイトルの記事を書くにあたり、自分の経験の棚卸しやふりかえりをしました。
その中で僕がニーリーに勤めてから「あ〜、これは上手になったな〜」「ここはエンジニアとして強くなったな〜」と感じたことが「合意形成の推進、意思決定や判断の推進」だと思っています。

そこで今回は個人的な持論やふりかえりを基に「実はエンジニアはドキュメントを合意形成の推進を念頭に書くと仕事が捗るのでは?(≒ 開発スピードが早くなるのでは?)」というお話を書いていきます。

抽象的なお話ですが、読んでくださった方がいい感じに仕事を進められる様になるヒントが見つかったりしたら幸いです。ボナペティ。

エンジニアの仕事で最も重要なことのひとつがステークホルダーとの合意形成

まず個人的に、エンジニアの仕事は「ドキュメントを基にステークホルダー(関係者)と合意形成して課題解決をすること」だと考えています。
ここでいうステークホルダーは手近なところでは自分のチームのリードだったり、もしくは社内のエグゼクティブなポジションの方々や社外の出資者など広い意味での利害関係者全てを指します。

企業に勤めている以上、個人開発ではないので関係者との「何故作るか・何を作るか・どう作るか」の合意形成からは逃れられません。
また、合意形成には常に合意する相手・他者が存在するため、エンジニア個人内で完結しない要因です。

なので、得てして合意形成は価値提供・開発を進める上でのボトルネックとなりやすく、この合意形成をスムーズに進めることがエンジニアとしてバリューを出すために重要なスキルであると考えています。また、特に僕が普段開発しているパークダイレクトというサービスは BtoBtoC 且つ BPO 的な側面もあるサービスで、更に事業規模も大きくなってきているため、よりステークホルダーとなる部署との協力・調整は不可欠です。

その上で合意形成する場合には必ず合意形成する相手との情報の同期、あるいは意思決定の証跡を残す必要があります。合意形成がスムーズに進まない例として、ミーティングを設定してもスムーズに議論ができなかったり、終わった後に言った・言わないになってしまうことがあると思います。 そうした状況を防ぐ為、僕は合意形成とセットでドキュメントをゴリゴリ書き進めることが超重要であると考えています。

ドキュメントを書く目的は読み手に変化を促すこと

そもそもドキュメントとは文字情報をまとめたものであり、その目的は「読んだ人に対して変化を促すこと」だと思っています。
もしもあるドキュメントを読んで何も変化がなければ、それは全く意味のない文字情報となります。意味のないことはあまりやりたくないですよね。

なので、僕はドキュメントにまつわる日々の活動を以下の2つに分類して考えています。

  1. 合意形成 … 関係者に読んでもらい、レビューを通して「これで開発するよ」などの合意を取ること、など。
  2. 情報共有 … 開発を継続的に円滑に進めるために必要な情報を書き記し、共有できる状態にすること、あるいは議論の証跡を残すこと。

例えば、設計ドキュメントに対するレビューとは「この内容で開発して OK だよね」「OK だよ」という合意形成です。また、ポストモーテムなどでふりかえりをした内容を書き記すことは後から読んだ人に対する情報の共有と言えます。

また、目的によって書くべき内容は変わります。合意形成が目的の場合はそれさえ達成できればよく、必ずしもすべてを詳細に書き残すことは必要ありません。逆に情報共有であれば、なるべく読み手に親切で詳細な完全性のある情報を残すことが好ましいです。
このようにドキュメントを書く目的を意識することで、書くべき内容や取るべき行動が変わっていき、効率的になっていきます。

PRD / DesignDoc は実は情報共有ではなく合意形成の為に書いている

プロダクト開発を進める為の設計ドキュメントとは、実はすべて合意形成の為に書いているのでは?と思っています。

具体的なプロダクト開発を進める為のドキュメントとして PRD(プロダクト要求仕様書) や DesignDoc などのプラクティスがあります。弊社ニーリーでもドキュメント文化が盛んで、開発時には DesignDoc や PRD(プロダクト要求仕様書)、あるいは SRS(ソフトウェア要求仕様書)などを書くことが推奨され、これらを書くことが当たり前化しています。

これらは開発する内容をビジネス上、あるいは実装上などのそれぞれのレイヤーごとにまとめる為のドキュメントです。そして原則としてその内容を正として開発を進めていきます。

実際に開発を進めるということはユーザやビジネスに対する影響が発生することを意味します。なので、必然的にその影響の結果責任、あるいは説明責任を持つ人に対する合意形成が必要となります。 極論、ボタン1つの場所を変えるだけでも大きなユーザ影響がある場合、それはエンジニア個人が勝手にできる変更ではなく必ず承認が必要です。

なので、これらの設計ドキュメントを書くということは関係者間での合意がつきまとうことであり、合意形成を念頭に置いて書き進めると仕事が円滑に進み始めると思います。(個人的には、この辺りを意識し始めてから開発や仕事のスピード感が変わったな、と実感しています)

合意形成に必要な意思決定・判断を IPO モデルとして分解し、必要な Input を書き記しておくと仕事が捗る

ある行動は「当人が自分の持っている情報を自分の判断基準に照らし合わせて自分の行動を決めている」と考えた場合、以下のように IPO モデルになぞらえて考えることができます。

INPUT(情報) -> Process(判断基準)-> Output(行動) 

そして合意形成とは関係者間の意思決定・判断を揃えることです。
なので、関係者それぞれが持っている判断基準(Process)を把握し、それらに対して必要な情報(Input)を揃えていくと、自然と合意形成が推進されていきます。

この意思決定の IPO モデル(仮称)を行動指針にする様にしてから、ところどころで仕事が円滑に進む様になりました。

つらつらと思い当たる出来事を書き並べていくのですが

  • ドキュメント上で、見てもらいたいことと決めてもらいたいことを明確にコメントをつける
    • Pull Request を出す時に似ていますが、開発案件の重要なロジック部分や UX を決める部分など論点になりそうな部分は事前にコメントをつけるようにしています
  • 仕様を決定するプロダクトオーナー相当の人が仕様を決めるために、必要な情報をすべてドキュメントにまとめておく
    • 例えば、システム上の各種処理の AS IS / TO BE と想定論点をドキュメントに表形式でまとめる様にしています。
  • 常に A 案 / B 案など複数の選択肢と検討した結果を記述しておく
    • 例えば、あるデータモデル設計など「後から変更しづらいこと」に関しては常に複数案の Pros / Cons をまとめた上で、選択を行う様にしています。
    • こうすることで「なんであの時、これやらなかったの?」「あの時、これは考えられていなかったね」と過去のジャッジに対して説明できるようになります。

といったことをしています。

基本的に意思決定・判断をする人は忙しいことが多いと思います。
なので「判断する上で十分な量の情報があるか」「論点・取りうる選択肢が整理できているか」「もしも判断基準が揃っている場合だったらどれを選ぶか」というところまで、まとめられると好ましいはずです。

これらを意識してドキュメントを書き、必要情報の共有、できれば提案というレベルでコミュニケーションを取るように心がけると合意形成のスピード自体が早まります。決定する側として選ぶだけで良い、という状態が理想ですよね。

まとめと宣伝

つらつらと自論混じりに書いてしまいましたが、いかがだったでしょうか。

先述した通り、プロダクト開発をする上で合意形成は常に付き纏い、そのスピードが遅いと明確に開発ボトルネックになります。なので、その合意形成がスムーズに進むように最初からドキュメントを書くように意識すると仕事が捗り、開発もスムーズに進むようになると感じています。

以上がここ数年で僕が伸びたな〜と感じることであり、皆さんに共有したい学びや気づきでした。
何か参考になったり、面白いと思っていただけていたら何よりだなと思います。

で!ここからは宣伝なのですが、今、弊社ニーリーはとても事業が伸びており、更にマルチプロダクト化が進むというめちゃめちゃアツいフェーズにいます。
(具体的には是非、こちらの記事こちらの連載記事達をお読みください。)

そのめちゃめちゃアツいフェーズのニーリーでは、プロダクトエンジニアの業務範囲を以下の様に定義しています。

ニーリーにおけるプロダクトエンジニア - Speaker Deck

一般のエンジニアの業務範囲にとどまることなく開発案件を推進するということは、他部署交えた合意形成をする必要があります。ある意味、正しく裁量を持って開発を進められる役割定義なのではないか?と考えています。
個人的には自分が主となって合意形成を進め、ゴリゴリと開発、事業成長に対してコントリビュートすることはめちゃくちゃ楽しいことだと感じています。

そんな環境にご興味のある方、一緒に働いている方々をどしどしじゃんじゃん募集していますので、興味ある方は是非カジュ面を!よろしくお願いします!!

www.notion.so




以上の内容はhttps://nealle-dev.hatenablog.com/entry/2025/12/02/112000より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14