大手システム開発会社の社員が本気で考える、小学生の夏休みの宿題を最速で終わらせる方法。

はじめに

夏休み。

それは、小学生にとって一年で最も自由な期間です。

朝からゲームをしてもいい。友達と遊びに行ってもいい。

しかし、そんな自由を脅かす巨大プロジェクトがあります。

夏休みの宿題です。

計算ドリル。漢字ドリル。読書感想文。自由研究。絵日記。

そして最終日に発覚する、謎のプリント。

普通の小学生であれば、毎日コツコツ進めるでしょう。

しかし私は、システム開発会社で働く会社員です。

システム開発の世界では、納期までに大量のタスクを完遂するために、あらゆる手段を使います。
コンプライアンスに反してなければ何でもやります。

人を増やす。作業を外に出す。並行して進める。スコープを減らす。場合によっては納期そのものを交渉する。

「頑張ったけど間に合いませんでした」は、なかなか通用しません。

そこで今回は本気で考えてみます。

もし小学生の自分が、システム開発の知識を持っていたら、夏休みの宿題をどう攻略するのか。

目標は一つ。

品質はさておき、最速で納品まで持っていくことです。

まずは要件定義をする

※要件定義：システム開発を始める前に「何を作るのか・何が必要なのか」を整理して決めること。

いきなり宿題を始めてはいけません。

まずは先生から配布された「夏休みのしおり」を確認します。

これはシステム開発でいうところのRFP（提案依頼書）に近い存在です。

ここで重要なのは、

「何をやったほうがいいのか」

ではありません。

「何をやらなければ怒られるのか」

です。

たとえば、

• 漢字ドリル：全ページ必須

• 計算ドリル：全ページ必須

• 読書感想文：1作品

• 自由研究：任意

• 絵日記：3日分

だったとします。

この時点で自由研究はスコープアウトします。

※スコープアウト：当初予定していた作業や機能を、対象範囲から外すこと。

「やったら偉い」は要件ではありません。

必須要件だけを満たして、最小構成でリリースします。

作業範囲（宿題）を減らせないか交渉する

次にやることは宿題ではありません。

スコープ調整です。

委託元である先生と協議します。

「漢字ドリル、本当に全部必要でしょうか」

「20ページまででも学習目標は達成できるのではないでしょうか」

「読書感想文は原稿用紙3枚ではなく、2枚でも成果物として成立する認識ですが、いかがでしょうか」

システム開発でも、要望をすべて受け入れていたらプロジェクトは終わりません。

納期と工数を考慮し、スコープを調整します。

ただし、小学生がこれをやると普通に怒られる可能性があります。

リスクとして管理しておきます。

自分でやる必要のない作業は外注する

スコープを削減しても、まだ作業は残っています。

そこで外部リソースを活用します。

工作は父親。

自由研究の模造紙は母親。

朝顔の写真撮影は弟。

家族という限られたリソースを最大限活用します。

ただし、丸投げはいけません。

成果物の責任は元請けである自分にあります。

父親が本気を出しすぎて、

小学4年生では到底作れないレベルの木製貯金箱

を納品してきた場合は手戻りです。

ベンダーコントロールは非常に重要です。

WBSを作り、リスクも洗い出す

※WBS：プロジェクトで必要な作業を細かく分解し、「誰が・何を・いつまでにやるか」を整理したもの。

宿題を全部順番にやる必要はありません。

父親が工作を作っている間に、自分は漢字ドリル。

母親が模造紙を作っている間に、計算ドリル。

弟が朝顔を観察している間に、自分はゲームをします。

複数のタスクを並行させれば、工期を短縮できます。

ただし、計画通りに進むとは限りません。

夏休みには、さまざまなリスクがあります。

「お盆に親戚が遊びに来て、一日潰れる」

「友達から突然プールに誘われる」

そして最大のリスク。

「工作担当の父親がゴルフに行ってしまう」

土曜日に工作を進める計画だったのに、

「ごめん、明日ゴルフだから」

主要ベンダーのリソースが突然消失しました。

※ベンダー：システム開発などで、製品やサービス、作業を提供する会社・事業者のこと。

しかも朝から夕方まで帰ってきません。

工作工程、即日遅延です。

母親への代替要員依頼、工作の簡素化、父親への納期再交渉。

すぐにリカバリープランを策定します。

口約束のリソースを100％信用してWBSを引いてはいけません。

小学生にして、大切なことを学びます。

最大のリスク「8月31日に全部やる」を回避する

そして夏休みプロジェクト最大のリスク。

8月31日まで何もしないことです。

これはシステム開発でいうと、

「本番リリース前日に結合試験を始める」

くらい危険です。

そこで毎週日曜日、進捗会議を開催します。

参加者は、自分、父、母。

議題は、

「宿題、どこまで終わった？」

おそらく母親がPMOとして非常に強い権限を持つことになります。

遅延が発生した場合は、即座にリカバリープランを策定します。

生成AIも投入する

そして2026年。

我々には強力なリソースがあります。

生成AIです。

読書感想文の構成案。自由研究のテーマ出し。算数の解説。工作のアイデア。

使えるところはいくらでもあります。

ただし、AIに全部やらせると、

本人が何も理解していない成果物が完成します。

これは仕事でも最近よく見る光景です。

先生から、

「この部分、どういう意味？」

と聞かれた瞬間、プロジェクトは炎上します。

AIを使っても、最終的な成果物について説明できる状態にはしておく。

これは小学生でも会社員でも同じなのかもしれません。

最後は受入試験

すべての宿題が完成しても、まだ提出してはいけません。

名前を書いたか。

抜けているページはないか。

文字数は足りているか。

そして最も重要なのが、

「これ、本当に小学4年生が作ったように見えるか」

です。

父親の工作、AIの読書感想文、母親の自由研究。

すべてを統合した結果、異常に完成度が高くなっていたら危険です。

品質を上げすぎることがリスクになる。

システム開発では、なかなか経験できないタイプの案件です。

そして9月1日、本番リリース

ランドセルに成果物を格納。

登校。

先生へ納品。

そして検収。

問題がなければ、

夏休み宿題プロジェクト、完了です。

こうして考えると、夏休みの宿題もシステム開発も意外と似ています。

要件を確認する。スコープを決める。外部リソースを使う。リスクを管理する。そして納期までに納品する。

小学生のころからこれをやっていれば、私はもっと優秀なプロジェクトマネージャーになっていたかもしれません。

ただ、一つだけ問題があります。

ここまで偉そうに書いてきましたが、小学生時代の私は、

8月31日に泣きながら宿題をやる側でした。

結局、プロジェクト管理で一番難しいのは、

計画を作ることではなく、計画通りにやることなのかもしれません。

どれだけ完璧に計画しても、予定外のことは起きます。

お盆に親戚が来るかもしれない。

父親がゴルフに行ってしまうかもしれない。

そして、なぜか8月31日まで手をつけない宿題が残っているかもしれない。

課題が何も起きないプロジェクトなんて、たぶんありません。

それでも、なんとか考えて、調整して、最後は納品まで持っていく。

だからこそ、システム開発という仕事は面白いと私は思うのです。