業務の8割は、
10個のアルゴリズムでできている

「アルゴリズムを勉強しなきゃ」と思って教科書を開くと、赤黒木やダイクストラ法が出てくる。読めば面白い。でも翌日の業務で使うかというと、使わない。

一方で現場のコードを見ると、毎日同じ顔ぶれが登場する。IDをキーにした参照、一覧の並び替えと絞り込み、カテゴリ階層の探索、非同期処理の待ち行列。教科書の網羅性と、現場の出現頻度は、まったく別の分布をしている。

受託開発で7年やってきて、福祉・医療・EC・建設・物流と業界が変わっても、書いているコードの「型」はほとんど変わらないことに気づいた。業界知識は毎回入れ替わるのに、実装の道具箱の中身は同じなのだ。

だったら、その道具箱を一度ちゃんと棚卸ししてみよう。そう思って作り始めたのが、今回の話の起点になる1枚のリファレンスガイドだった。

最初のルールはシンプルにした。「自分の業務で実際に登場した頻度」だけを基準に選ぶ。競技プログラミングで重要かどうかは問わない。面接で聞かれるかどうかも問わない。現場で書いたか、書かなかったか。それだけ。

棚卸しの結果、残ったのは10個だった。それぞれに「業務のどの場面で出てくるか」を添えると、こうなる。

この一覧を眺めて気づくのは、どれも「アルゴリズム」というより「業務の場面」から逆引きできることだ。「商品一覧を出して」と言われたら②と⑦。「注文ステータスを管理して」と言われたら⑩。「2つのCSVを突き合わせて」と言われたら⑨。

最初の成果物は、この10個にPHPとVue.jsのコード例を付けた1枚もののHTMLガイドにした。普段の業務スタックそのままの言語構成で、タブ切替でコードを見比べられる形。要するに「未来の自分が現場で開く」ためのリファレンスだ（現在のv2は公開している）。

ガイドを使い込むうちに、物足りなさが出てきた。10個のアルゴリズムは「処理の型」としては十分だが、実際の業務システムにはもう1段上のレイヤーがある。処理をどう配置するかという「設計の型」だ。

そこでv2では、TypeScriptのコード例を全アルゴリズムに追加するのと同時に、業務システムで頻出する設計パターンを7つ新設した。

さらに後日、この7パターンにPHPとJavaScriptのタブも追加した。ここで面白かったのは、同じパターンでも言語が変わると「設計思想」が変わることだ。

たとえばRetry + Backoff。PHP（バックエンド）ならusleepでジッターを入れて同期的にリトライすればいい。だがVue 3のフロントエンドでは、リトライ中にユーザーが画面を離れるかもしれない。だからonUnmountedでのクリーンアップが必須になる。楽観的ロックも同じで、サーバー側は409を返すだけだが、フロント側は「楽観的UI更新を巻き戻す」処理まで設計に入る。

パターンは言語非依存の「概念」だが、実装は言語の生存環境に適応した「生き物」になる。4言語（PHP / JS / TS / Vue）を並べたことで、この違いが初めて1画面で見えるようになった。

この時点で、ガイドは「10アルゴリズム + 7設計パターン = 17個の語彙」を持つ辞書になった。そしてこの辞書が、思わぬ方向に化ける。

きっかけは、ガイドを眺めていたときにふと浮かんだ一言だった。「これって、見積もりにも使えたりするのかな？」

受託開発の見積もりは、正直に言えば「画面数 × 単価」のどんぶり勘定になりがちだ。経験者の勘で補正はかかるが、その勘は言語化されていないので、人にも渡せないし、外れたときに原因も分析できない。

ここに17個の語彙を当てはめると、何が起きるか。考えてみると3つのレベルがあった。

学習用に作ったリファレンスが、見積もりの語彙になる。この瞬間に、ただの知識整理が「仕事の道具」に変わった。

考え方が固まったら、次は道具にする。作ったのがパターンベースの見積もりツールだ。動きはシンプルで、こうなっている。

• 1.機能を追加する（例：「商品管理画面」「CSV取込」）
• 2.各機能に、10アルゴリズム + 7設計パターンをワンクリックで割り当てる
• 3.数量と工数をインライン編集すると、自動で積み上げ集計される
• 4.最後にバッファをスライダーで上乗せして完成

工夫したのはバッファの扱いだ。経験上、見積もりが外れる原因は実装速度ではなく、実装の外側にある。だからバッファを1本の「安全率」ではなく、要件の曖昧さ・技術リスク・コミュニケーションコスト・テストの4項目に分けて、それぞれスライダーで調整できるようにした。

「なぜ1.5倍なのか」と聞かれたとき、「要件がまだ固まっていない分が+20%、初めて使う外部APIの分が+15%……」と内訳で答えられる。バッファそのものを説明可能にする、という発想だ。

出力はテキストコピー、JSON保存・読込、印刷に対応させた。見積もりは作って終わりではなく、案件が終わったあとに実績と突き合わせる対象なので、データとして残ることが大事になる。

仕上げに作ったのが、10アルゴリズムすべてをインタラクティブに動かせるビジュアライザーだ。コードを読むのと、動きを見るのとでは、理解の速度がまるで違う。

たとえばHashMapは、キーがバケットに配置されるアニメーションとHIT / MISSの表示で「なぜ速いのか」が見える。Sortはバブルソートとクイックソートの棒グラフを並走させて、計算量の差を体感できる。LRUキャッシュは追い出しの瞬間とHIT率のリアルタイム計算。ページネーションはOffset方式とCursor方式で、発行されるSQLと表示範囲がどう違うかを並べて見せる。

ステートマシンは注文ステータスをクリックで遷移させる作りにした。「キャンセル済みからは発送に進めない」という制約が、文章ではなく押せないボタンとして伝わる。

「理解している」ことの最終テストは、人に説明できるかどうか。そして説明の最強の形は、目の前で動かして見せることだ。

作ってみて分かったのは、ビジュアライザーの第一の受益者は自分だということ。アニメーションとして実装するには、アルゴリズムの1ステップ1ステップを完全に分解する必要がある。「分かったつもり」では絵が描けない。教えるための教材作りが、いちばん深い学習になっていた。