「あの話どうなった？」が消える開発の進め方 — 全工程を1ヶ所に記録する仕組み

この記事のターゲット読者: 外部にソフトウェア開発・DX を依頼する側の経営者・事業責任者・現場マネージャー。技術用語は出てくるたびに噛み砕いて説明します。

なぜ「あの話どうなった？」が永遠に繰り返されるのか

外部に開発を依頼したことがある方なら、こんな経験はないでしょうか。

• 月1回の定例で「先週話した X、結局どうなりましたか？」と毎回聞いている
• 担当者が変わった瞬間、ゼロから業務説明をやり直すことになった
• 議事録は Word、タスクは Excel、やり取りは Slack で どこに何があるか分からない
• 「進捗報告書」が届くまで、現場が何をやっているのか分からない

これは担当者が悪いわけではありません。情報が複数の場所に分散している という構造的な問題です。

結果として、誰かが「あの話どうなりましたか？」を聞き直し、誰かが資料を探しに行き、誰かが説明し直す——毎週同じ摩擦が発生 します。

Appspect は何が違うのか — ひと言で

私たち Appspect は、ヒアリングから納品まで全部 1 ヶ所に記録する だけです。それだけ。

その「1 ヶ所」として GitHub というサービスを使っています。

GitHub（ギットハブ）とは？ ─ 元々はエンジニアがプログラムを保管するためのサービスですが、最近は「議事録」「やることリスト」「日々の決定事項」「実物のコード」をまとめて時系列で記録できる総合プロジェクト管理ツールとして使われるようになりました。私たちは GitHub を プロジェクトの履歴書 として使っています。

つまり、議事録もタスクもやり取りもコードも、全部 GitHub に集約します。

そして、これを 非エンジニアのお客様にも見やすく するために、弊社オリジナルのワークフロー補助ツール（GitHub プラグイン）を内製しています。実装の詳細は伏せますが、要するに「整理整頓を自動化する仕組み」です。

以下、これによって何が変わるのかを 3 つの視点 で説明します。

視点1: 議事録から実装まで、1 本の線でつながる

ミーティングをすると、必ず「次にやること」が出てきます。普通はこう流れます。

ミーティング
  ↓ 議事録を Word に書く
  ↓ やることを Excel に転記
  ↓ エンジニアにメールで依頼
  ↓ エンジニアが Backlog にチケットを切る
  ↓ コードを書く

この転記の段階で、毎回 30% くらい情報が失われます。「ニュアンス」「言った人の温度感」「なぜそれが必要か」が、転記されるたびに削ぎ落とされていきます。

Appspect では、こうします。

ミーティング
  ↓ 議事録を1個の「議事録票」として GitHub に登録
  ↓ その議事録票の中に「やることリスト」を直接書く
  ↓ やること1個ごとに「子チケット」が自動でぶら下がる
  ↓ エンジニアが子チケットを開いて、その場で実装
  ↓ 実装が終わったら子チケットが自動で閉じる
  ↓ 議事録票のリストにチェックが自動でつく

ここで何が嬉しいか: 「3ヶ月前の打ち合わせで話した、あの予約フローの改善はどうなった？」と聞いた瞬間、その議事録票を開けば「やった／やってない／やってる最中」が一覧で見えます。探す時間がゼロになります。

そして何より、新しく参加するメンバーに対する効果が絶大 です。後から入った担当者は、議事録票を時系列で見ていくだけで「何が話され、何が決まり、何が形になったか」が再構築不要で把握できます。

視点2: 進捗は「聞く」ものではなく「見る」もの

ふつうの開発現場で進捗を確認する方法は、こうです。

1. 週1回の定例ミーティングで報告を聞く
2. 月1回のレポートを読む
3. たまにエンジニアに「いまどうなってる？」と聞く

これだと、気になった瞬間に進捗を見ることができません。「あれどうなったかな」と思っても、次の定例まで待つしかない。

Appspect では、お客様専用の 進捗ダッシュボード（プロジェクトボード）をお渡しします。これも GitHub の機能を使っていますが、見た目はカンバン形式のシンプルなボードです。

┌─────────────┬──────────────┬─────────────┐
│   未着手    │   進行中     │   完了      │
├─────────────┼──────────────┼─────────────┤
│ #62 通知設定 │ #58 ログイン │ #54 DB設計  │
│ #65 一覧改善 │ #60 デザイン │ #56 雛形    │
│             │              │ #57 認可    │
└─────────────┴──────────────┴─────────────┘

ご自身のスマホやパソコンから、いつでも見られます。「いま何が進行中で、誰がやっていて、何が完了したか」が一目で分かります。

ここで何が嬉しいか: お客様は「進捗を聞く」必要がなくなります。気になったら 見れば分かる。週次レポートを作る時間も、報告会で進捗を確認する時間も、ほぼ不要になります。「進捗確認会議」が「次に何を作るかの議論」に置き換わります。

視点3: すべての判断が、永久に残る

開発中には、いろんな判断が発生します。

• 「なぜこの設計を選んだのか」
• 「なぜこのライブラリ（部品）を使ったのか」
• 「なぜこの仕様にしたのか」
• 「なぜこの不具合をこの方法で直したのか」

これらは普通、Slack の流れの中や口頭の打ち合わせで決まり、3 ヶ月後には誰も覚えていません。担当者が交代したり、お客様側の窓口が変わったりすると、知識はゼロから再構築されます。

GitHub では、議事録・チケット・コードの修正履歴・PR（修正提案）に対する議論——全部が時系列で永久に残ります。

04/05  📝 議事録 #42 起票（キックオフMTG）
04/06  ✅ アクション #43-46 起票
04/08  💻 ログイン機能を実装（修正 abc123）
04/10  🔀 修正提案 #62 オープン（議論 6 件）
04/12  ✅ 修正提案 #62 マージ → やること #58 自動完了
04/15  💬 振り返り議事録 #47 起票

PR（プルリクエスト）とは？ ─ エンジニアが書いた修正内容を「これでいいですか？」と確認・議論する仕組みです。普通の業界で言うと「修正案を回覧して承認を取る」のと同じ。違うのは、議論の経過がそのまま永久保存されることです。

ここで何が嬉しいか: 「半年前にこの機能を作った時、なぜ A 案ではなく B 案を選んだんだっけ？」という疑問が出ても、議論の経過を辿れば当時の判断理由がそのまま分かります。社内引き継ぎ資料を別途作る必要がなくなります。GitHub のリポジトリ（プロジェクト保管庫）そのものが完全な履歴書として機能するからです。

お客様にとってのメリットを 1 枚にまとめると

「全部 GitHub に集約」と聞くと、技術者向けの仕組みに思えるかもしれません。最終的にメリットを受けるのは、ほとんどの場合、非技術者であるお客様の側です。

まとめと、次のステップ

Appspect では以下のサイクルで開発を回しています。

1. 打ち合わせをする → 議事録票を 1 つ起票
2. やることを書く → 議事録票の中にチェックリストを書く
3. 開発する → やること 1 個ごとの子チケットを進める
4. 完成する → 自動でチェックがつき、議事録票も自動更新
5. 振り返る → 振り返り議事録票を新しく起票

これらすべてを、弊社オリジナルのワークフロープラグインが裏側で支えています。プラグインの実装詳細は今回は割愛しますが、興味のある方は別途お問い合わせください。

ヒント: この仕組みは、受託開発でもマージンシェアプランでも同様に適用 されます。プラン体系の詳細は 料金ページ をご覧ください。

「進捗が見えないコンサル」の時代は、もう終わっていいはずです。透明な開発プロセスで、一緒に事業を作りませんか。

ご相談・お見積もりは無料です。 お気軽にお問い合わせください 。