新しいフロントプロセスとドキュメントフォーマットを考えてみた

Kanazawa.rb meetup #168 2026-08-22 ( Sat ) at ITBP武蔵 での発表内容です。

AIエージェントの活用によって後工程の一部はコストが下がって、逆に前工程の意味が大きくなってきているんじゃないか、DX / AI活用などさまざまな文脈で要件や要望、設計や見積もり**というほどでもない**なにかが求められてきているんじゃないか、そういう問題意識で、抽象的で幅広く使えて、目的をあまり限定しない部分だけ取り出して、整理して名前を付けてみました。

Transcript

1. 新しいフロントプロセスと ドキュメントフォーマットを 考えてみた @wtnabe Kanazawa.rb meetup #168 2026-08-22 (Sat) at ITBP 武蔵
2. 問題意識 かつてない DX / AI活用の圧 開発しないソリューション 開発工程の（一定の）コストダウン フロントプロセスの意味の変化 この変化に対応した何かを考えたい ソフトウェアエンジニアのタスクは従来の定義の外に広がっている
3. Problem vs Us は構図、取り組み方、姿勢
4. 実際にはその手前がある
5. 何を当たり前のことを？
6. でも2026年の今って、 この部分のアクセントが 変わってきていませんか？
7. 2026 年の地平 の普及からもうすぐ4年 Claude Code ショックから 1 年半 世界を巻き込む戦争とインフレと人材、資材の不足 LLM
8. そして何が起きているか コーディングタスクのコストダウン（一部） かつてない DX / AI 活用の圧
9. つまり 人々のマインドが変わってきている もしかしたらこういうことできないか？を検討する機会爆増
10. しかし 何が何やらよく分かっていないことも多々
11. これです
12. 従来からこの工程はある でもソフトウェアのライフサイクルなどの教科書にはない ソフトウェアの形になっていない ソフトウェアを開発するかどうかも決まっていない
13. これまであったもの 何らかの開発というゴール、ソフトウェア成果物という前提 開発が十分重いので手前は「前工程」として吸収できた
14. これが見積もりゼロ円の正体の一つ
15. これから 後工程が一部軽くなり、相対的に前工程の比重が大きくなる 前工程は（コストベースで言うと）おまけではなく、ここで何を成 すかが重要になる
16. この「なにか」を掘り下げたい
17. 要求分析？ 設計？ 見積もり？
18. とも限らない
19. もっと雑多 問題をどう捉えるかの確認 どんな仕組みがあり得るのかの検討
20. こんな感じ
21. なんか話を聞いて
22. 考える。必要なら話を聞いたりなんだり
23. 何らかの成果物を渡す どういう話だったのか 何が問題だったのか / 何を欲しかったのか どうすればよさそうか
24. ※ くり返しになりますが これは受託開発がどうとか、 そういう文脈に限りません
25. 抽象化して名前を付けてみる
27. 概要を聞いて以降のターンを Explore
28. 成果物を Brief
29. 中身が確定していないので要求分析とも 設計、見積もりとも呼ばないために 別な名前を作って当てています
30. これを用いて理解を深める Sensemaking と次手の位置付け
31. このちょっと曖昧な話に対して 従来型の要求分析、設計、見積もりが重すぎる
32. これを変えたい 注：営業を除きます
33. 改めて 従来のプロセスとドキュメントから除外してよい（すべき）もの 「後工程」を判断、決断するためのもの 事業価値 見積もり ↑ 依頼側は不確実性が高い状態なのに、 エンジニア側は不確実なりに確実性を 担保しようと頑張っている
34. お互いに分からないんだから 分かっていること分かっていないことの整理が進めば それでいいという割り切りが大事
35. Brief 関係者 Situation 状況 Concern 関心事 の内容 Actor Insight / Findings ( optional ) One Solution Example ( optional ) 「この間の話は整理するとこういうこと」 「解決案の一つはこうなると予想される」
36. One Solution Example システム / ツール概要 ( Assumptions 仮説 ) Outcome 達成できるもの ( Unresolved Issues 解決しないもの ) Size 概算見積もり リスク評価も詰めない。「やる」前提の策にしない。 Overview
37. 位置付けの再確認
38. Brief は なんかよく分からない題材を扱っている可能性が高い 初手で正解はまず出ない ラフに近い 脳内ダンプの推測に近い Next を導出できればなんでもよい
39. 精緻な設計 精緻な見積もり 事業価値判断 省きたいもの 分かりたいもの 誰の何を課題とするか 誰の何を解決するか（解決しないか） あくまで案の一つである
40. ポイント （成果物指向ではなく）Concernの解明が主 解決案は具体的な話をして考えやすくするため 普通の相手はワークフロー整理やツールの組み合わせでソリュー ションの導出とかやりたくない ← Exploreはここを代行している ツールの問題なのかワークフローの問題なのかも見えるとよい 見積もりを入れるなら相互に通用する概算の規模感程度 松竹梅でも2週間、2ヶ月、半年（たぶん）みたいなものでよい 相手の知りたいことは「上期に収まるか？」みたいな感じかも
41. 改めて front process Explore: 調べたり聞いたり概要設計 artifact Brief: Brief 問題の輪郭が分かる文書 のゴールはNext Moveを決められるもの
43. 恐らくかなりミニマムな内容に絞れている 立場的なすり合わせや価値判断は追加事項で 頑張りましょう
44. 残るは この Brief や Sensemaking の価値をどう定義するか？ 開発自体はしていないけど調査能力、設計能力、ある程度言葉を転 換するコミュニケーション力、抽象度、詳細度をコントロールする 言語化力が必要。ちゃんとむずい。 受託の場合は値付け、内製の場合は評価、このための言葉が欲しい 積極的な取り組みでありポジティブに評価したいが言葉がない
45. consulting に近い。あえて言うと Consultative Engineering ?
46. 参考にしたもの Shape Up ( 37 signals ) Boundary Object Business Analysis 原典
47. Shape Up ( 37 signals ) Shaping Fixed time Variable scope Breadboarding Fat markers sketches Rabbit holes → Pitch → Betting
48. Pitch Shaping Problem Appetite Solution Rabbit holes No Gos して作り上げる成果物
49. Betting 事前に Pitch を読み込み、プロセスとして掛ける時間は1〜2時間ほど Bet されなかった Pitch はバックログに積まない（リトライは可） 全体ではかなりライトウェイトなプロセス。ただし Pitch はしっか り作り込まれていて、これが Appetite という事業価値判断を持つ いま何を Ship すべきか？がテーマと言ってよい ↑ ここら辺が 37 Signals 固有なので今回は除外したい
50. 参考 Business analysis - Wikipedia Boundary object - Wikipedia Shape Up: Stop Running in Circles and Ship Work that Matters