未完リスト8件のうち、実際に作ったのは3件だった

はじめに：この記事の前提

Koinobori 代表取締役の杉﨑です。 社員数名の会社を経営しながら、このコーポレートサイトも自分の手で作り、AI を相棒に毎日更新しています。

自社ツール集サイトの開発では、「あとで対応する」と決めて棚上げにしたタスクの一覧を持っています。今回はこの一覧に溜まっていた8件を、まとめて1件ずつ片づけたときの記録です。結論から言うと、8件のうち、実際に新しく作ったのは3件だけでした。残りは、調べたら既にできていたか、そもそもの作り方を見直すことで決着しました。

1. 課題：未完が8件、動けば動くほど溜まっていく

日々の開発を進めていると、「これは今すぐでなくていい」「これは判断が要るから後で」という項目が自然に積み上がります。この一覧が8件まで溜まっていました。中身は、用語の追加のような軽いものから、サイト全体の作り方に関わる大きな判断まで幅がありました。

厄介なのは、件数が増えるほど「何が軽くて、何が重いか」の見分けがつきにくくなることです。着手する前に、まず1件ずつ、今の状態を確認するところから始めました。

2. 取り組み：作る前に、まず「本当に無いか」を確認する

2-1. 実際に作った3件

調べた結果、次の3件は本当に手を動かして作る必要がありました。

• 用語の追加：セキュリティ関連の用語を13件、用語集に追加しようとして調べたところ、実際に不足していたのは12件（1件はすでに別の言い回しで登録されていました）。追加した結果、用語集は88件から100件になりました。ついでに、リンク切れになっていた参照を1件見つけて直しました。
• 詐欺見抜きクイズ：全7問のクイズを新設。5問は詐欺、2問はあえて「本物の業務連絡」にしました。詐欺の特徴だけを覚えさせると、普通の業務連絡まで疑って仕事が止まってしまいます。「送金先の変更を求めていないか」「認証情報の入力を求めていないか」「その場での即対応を求めていないか」という判断の軸を身につけてもらう構成にしました。
• 図解2本：不正アクセスの手口を2種類、図で説明するページを新設しました。どちらも一見すると別の手口ですが、実は**「パスワードを破る」のではなく「認証そのものを迂回する」**という共通点があります。文章で説明するより、図にしたほうが伝わると判断しました。

2-2. 調べたら、もう出来ていた

8件のうち、大きめの2件は、着手前に確認したところすでに実装済みでした。

• 逆算で価格を決めるための計算ツール（原価から目標の利益率で売価を割り戻す、心理的な価格設定の提案なども含む）
• 未上場の自社株の評価額を試算するシミュレーター（簿価・増資・低額譲渡・ストックオプションの4パターンに対応）

どちらも、本番環境で実際にアクセスして正常に動作することまで確認しました。タスクの一覧に残っていたのは、実装済みという事実が記録に反映されていなかっただけでした。ほかにも、検索のヒット率や難易度別の絞り込み表示など、細かい確認まで含めると、同じように「すでに対応済みだった」項目がさらに2件見つかりました。

つまり8件のうち、半分の4件は、調べただけで閉じられたことになります。

2-3. 最大の1件は、定義を変えて決着させた

残る1件が一番大きな判断でした。もともとの構想は、サイト内の167ページすべてが使う共通の部品を1つ作り、作りを統一するというものでした。

調べてみると、前提が崩れました。計算のロジック部分は、すでに以前の整理でほぼ共通化が済んでいたのです。残っていたのは、画面の要素を1つずつ拾ってくる細かい処理が1,300か所以上、という状態でした。これは「ロジックの重複」ではなく「配線の細かさ」であり、共通化しても行数は減らず、抽象化の層が増えるだけと判断しました。

しかも社内には前例がありました。過去に「使うはずだった」共通部品をいくつか作ったものの、実際には1つのページからも使われず、形だけ残っていたことがあったのです。大きな共通部品は、作っても使われないことがある——それが実績として残っていました。

そこで、「167ページを全部作り替える」という目標そのものを取り下げました。 代わりに、①作り方の決まりごとをまとめた文書、②本当に必要な最小限の共通処理、③作り替えの前後で表示結果が変わっていないかを機械的に検証する仕組み、の3つに置き換えました。検索エンジンからの流入が生命線のサイトで、表示内容そのものを大きく動かすリスクを取るには、得られるものが釣り合わないと判断したためです。

2-4. 一度、選び方を間違えた話

この作業の途中で、小さな失敗もありました。最初に「共通化の試しに使う3ページ」を選んだのですが、選んだページはどれも画面要素を直接1つずつ拾ってくるだけの作りで、独自の処理をほとんど持っていませんでした。 結果、共通化してみても減る行数はほぼゼロで、新しい部品を読み込む分だけ複雑さが増えました。

選び直して分かったのは、**「まとめる価値があるのは、そのページ独自の処理を持っているページだけ」**という基準でした。この基準を、以後の判断ルールとして文書に残しています。

3. 結果：8件が0件に。増えたのは実装よりも「確認する仕組み」

最終的に、8件の未完はすべて閉じました。内訳は、新規実装3件、確認だけで終了4件、方針転換1件です。件数だけ見ると地味ですが、今回の作業でいちばん値打ちがあったのは、実は新しく作った機能そのものではありません。「作り替えの前後で表示結果が本当に変わっていないか」を機械的に検証する仕組みと、サイトの安全面を機械的に確かめる仕組みの2つです。壊してから気づく検証ではなく、壊す前に止められる検証を手に入れました。

4. 学び：未完リストは「作るリスト」ではなく「判断するリスト」

8件のうち半分が「調べたら要らなかった」というのは、正直なところ良い成績ではありません。着手する前の確認が甘いまま積み上がっていたということでもあります。

一方で、その甘さに気づけたこと自体が収穫でした。私たちの会社は、放っておくと「作りすぎる」方向に転びやすいという癖があります。便利そうな共通部品、あると良さそうな機能——思いついたら形にしてしまう。過去に作って誰にも使われなかった部品が実例として残っているのは、その癖の証拠です。

だからこそ、企画の段階で**「これを作らない理由はないか」を先に確認する**ようにしています。今回の8件のうち4件は、まさにその確認だけで片づきました。着手前の10分の調査が、丸1日分の実装をまるごと消してくれることがあります。 未完リストは、作業を並べる場所ではなく、1件ずつ「これは本当に必要か」を判断する場所として扱うべきだと、改めて思いました。

おわりに

8件の未完を閉じて、リストは空になりました。派手な達成感はありません。新しく作ったのは3件だけで、残りは「確認して終わり」か「方針を変えて終わり」だったからです。

それでも、空になったリストよりも、「作る前に確認する」という手順が社内に定着したことのほうが、長い目で見れば効いてくると思っています。同じように未完のタスクが溜まっている方は、着手する前に一度、「これは本当にまだ無いのか」を確認してみることをお勧めします。