内製を始めると決めたら、最初の30日をどう使うかが肝心です。漠然と始めると、また情報収集だけで終わってしまいます。そこでこの1か月を週単位で設計します。第1週で環境を整え、第2週で最初の1機能を作り、第3週で社内に公開し、第4週で振り返る。ゴールは完璧なシステムではなく、動くものが社内に1つ出ることです。
最初の30日を「週単位」で設計する
内製の最初の1か月は、何となく始めると何となく終わってしまいます。締め切りもゴールもないまま走り出せば、エンジニアは外したくない一心で調査を続け、経営者は様子を見守るうちに、気づけば月末になっています。これを避けるには、1か月をひとかたまりで捉えず、週ごとに区切ることです。期限とゴールが目の前にあると、人は手を動かしやすくなります。
区切り方は単純で構いません。第1週で環境を整え、第2週で最初の1機能を作り、第3週で社内に公開し、第4週で振り返る。この4つを順に置くだけで、1か月の地図ができます。各週のゴールは欲張らず、その週のうちに達成できる範囲にとどめます。
大切なのは、完璧を目指さないことです。30日のゴールは「立派なシステムが完成すること」ではありません。「試せる状態のものが、社内に1つ存在すること」です。この基準をあらかじめ経営者と現場で共有しておくと、各週の判断が驚くほど軽くなります。
4週間の進め方
では、各週で具体的に何をするのか。順に見ていきます。
第1週：環境を整える
最初の1週間は、コードを書く前の土台づくりに使います。GitHubにコードの置き場を用意し、コンテナで動かす準備を整えます。ここを飛ばして手元のパソコンだけで進めると、後で「あの人の環境でしか動かない」という壁にぶつかります。最初に土台を作っておけば、その後の数か月がずっと滑らかになります。
同時に、最初に取り組むテーマをこの週のうちに確定します。テーマは、本シリーズ第2回で示した4条件——狭い・毎日起きる・失敗しても安全・効果が見える——で選ぶと外しません。環境とテーマ、この2つが第1週末にそろっていれば十分です。
第2週：最初の1機能を作る
第2週は、いよいよ手を動かして最初の1機能を作ります。ここでの合言葉は「粗くても動くものを」です。きれいなコードや細かな例外処理は後回しにして、まずは決めたテーマが一通り動く状態を目指します。完成度を上げるのは、動くものができてからでも遅くありません。
この週に陥りやすいのが、作り込みすぎて週内に動かないことです。動くものが出ないまま次週に持ち越すと、勢いが削がれます。完成度より「動くこと」を優先し、たとえ70点でも、週末に動くものが手元にある状態を作ります。
第3週：社内で使ってみる
第3週は、作ったものを実際に使ってみる週です。Fargateのような環境に載せて社内に公開し、自分やチームのメンバーが日常の業務の中で触れるようにします。手元で動かすだけでは見えなかった使いにくさや勘違いが、人が使った瞬間に表に出てきます。
ここで集めるべきはフィードバックです。「ここが分かりにくい」「この出力は使えない」という声こそ、次の改善の材料になります。完璧を待たずに公開し、早く使ってもらい、早く声を集める。この回転の速さが、内製の伸びを決めます。
第4週：振り返りと次のテーマ
最後の1週間は、振り返りに充てます。何が効いたのか、どこで詰まったのかを、現場と経営者で一緒に整理します。うまくいった点は次も続け、詰まった点は原因を言葉にしておきます。原因が「テーマが大きすぎた」なのか「環境が足りなかった」なのかで、次の打ち手は変わります。
そのうえで、次の30日に取り組むテーマを決めます。最初の1か月で得た手応えと反省を踏まえれば、2か月目のテーマ選びは1か月目よりずっと的確になります。こうして30日のサイクルを回し続けることが、内製を軌道に乗せる近道です。
経営者が各週で見るべきこと
この1か月、経営者は何を見ればよいのでしょうか。見るべきは進捗の細部ではありません。コードの中身や技術の良し悪しを評価する必要はなく、各週末に「先週決めたゴールに届いたか」を現場と一緒に確認するだけで十分です。届いていれば次へ、届いていなければ何が足りなかったかを話し合います。
そして、詰まりが見つかったときこそ経営の出番です。多くの場合、現場が止まる原因は技術ではなく、決裁が下りない、他部門との調整がつかない、優先順位がはっきりしないといった、現場の手では動かせない障害です。これらを取り除くのが経営の役割です。週次の確認は、進捗を監視するためではなく、障害を早く見つけて外すために行います。
成功の基準をどこに置くか
最初の月の成功を、何で測るか。ここを間違えると、せっかくの芽を摘んでしまいます。売上やROIといった数字を最初の月に求めるのは、早すぎます。1か月で経営成果が出るほど、内製は甘くありません。
では何を基準に置くか。「動くものが社内に公開され、1人でも使った」こと。最初の月は、これで十分です。たった1機能、たった1人でも、動くものが現場で使われたなら、その会社は「作って、出して、使われる」という回路を一度通したことになります。この回路をくぐったかどうかが、その後の数か月を分けます。
最初の30日のゴールは、完璧なシステムではありません。「動くものが、社内に1つ出ること」です。
早すぎる成果要求は、芽を摘みます。「で、いくら儲かったのか」と最初の月に問われれば、現場は萎縮し、次の挑戦に踏み出しにくくなります。最初の月は数字ではなく、動くものが出たことそのものを成果として認める。その姿勢が、内製を続けられる組織と止まる組織を分けます。
まとめ
最初の30日は、漠然と始めず週単位で設計します。第1週で環境を整え、第2週で最初の1機能を作り、第3週で社内に公開し、第4週で振り返る。経営者は各週末に「ゴールに届いたか」を確認し、詰まりがあれば障害を取り除きます。そして1か月の成功は、売上ではなく「動くものが社内に公開され、1人でも使った」ことで測ります。次回は本シリーズの最終回として、内製が軌道に乗る会社と止まる会社の分岐点を扱います。
自社が内製のどの段階にあるかを、3分で診断できます。
無料で組織のAI成熟度を診断する →よくある質問
- 30日で本当に動くものができますか？
- テーマを十分に小さく絞れば可能です。完璧な完成ではなく、社内で試せる状態を30日のゴールに置くことが前提です。
- 成功の基準は何にすべきですか？
- 最初の月は、売上やROIではなく「動くものが社内に公開され、1人でも使った」ことを基準にします。早い段階で大きな成果を求めると、芽を摘んでしまいます。
- 経営者は毎週何を見ればよいですか？
- 進捗の細部ではなく、各週末に「先週決めたゴールに届いたか」を一緒に確認します。詰まりがあれば、決裁や調整といった障害を取り除くのが経営の役割です。
- 30日でうまくいかなかったらどうすればよいですか？
- どこで詰まったかを振り返り、テーマの大きさや環境の不足を調整して次の30日に活かします。一度で完成させる前提は置かないことが大切です。