ITエンジニアが中小企業診断士を勉強する理由

数年前、私は「なぜこのシステムを作っているのか」という問いに答えられないエンジニアだった。要件は理解していた。実装もできた。でも、そのシステムが会社の利益にどう貢献するのか、なぜその機能が競合より先に必要なのか、という問いは、いつも「ビジネス側の話」として自分の外に置かれていた。

その感覚が変わったのは、中小企業診断士の勉強をはじめてからだ。

中小企業診断士とは何か

中小企業診断士は、経営コンサルタントの国家資格だ。1次試験は7科目──経済学・財務会計・企業経営理論・運営管理・経営法務・経営情報システム・中小企業経営政策──を問うマークシート、2次試験は実際の企業事例をもとにした記述式の経営診断だ。合格率は1次20%前後、2次20%前後、ストレート合格は4〜5%という難関だ。

ポイントは「経営情報システム」という科目が存在することではない。財務・戦略・組織・オペレーションという経営のあらゆる断面を、系統的に学べることだ。

なぜエンジニアが診断士を学ぶのか

1. 「なぜ作るか」がわかるようになる

エンジニアリングの本質はトレードオフの解消だ。速度 vs メモリ、一貫性 vs 可用性、実装速度 vs 保守性──。

経営もまったく同じ構造をしている。利益率 vs 市場シェア、短期キャッシュ vs 長期投資、専門化 vs 多角化。デュポン分析（ROE = 利益率 × 回転率 × レバレッジ）を学んだとき、「これはパフォーマンスチューニングのフレームワークだ」と思った。ボトルネックを特定して、そこにリソースを集中させる──という発想は完全に一致している。

財務諸表は、企業というシステムのログだ。BSは状態（State）、PLは処理結果（Result）、CFは実際のI/O（Input/Output）。エンジニアの目で読むと、突然クリアになる。

2. 経営者と対等に話せる

エンジニアが経営判断に関与できない最大の理由は、言語が違うことだ。

「技術的負債の解消に3ヶ月かかります」と言っても、経営者には「利益にどう影響するか」が見えない。しかし「現状の開発速度低下はリードタイムを30%延ばしており、機会損失に換算すると四半期で推定X百万円です」と言えれば、話が変わる。

診断士の学習は、この「翻訳能力」を体系的に鍛えるプロセスだ。2次試験の事例問題では、「この会社の強みを活かした新規事業を提案せよ」という問いに対して、財務指標・組織・マーケティング・オペレーションの4軸で根拠を示す必要がある。エンジニアで言えば、アーキテクチャ設計書を書く能力に近い。

3. 「希少な掛け合わせ」という市場価値

日本のITエンジニアは約120万人いるとされる。中小企業診断士の登録者は約3万人。その両方に足をかけている人間は、おそらくその10分の1もいない。

DXが叫ばれる現代、企業が本当に困っているのは「システムを作れる人」ではなく「経営課題とシステムをつなげる人」だ。それを証明できるのが、診断士という資格だと思っている。

勉強をして変わったこと

診断士の学習がエンジニアリングにも直接フィードバックする場面が増えた。

要件定義の場面では、バリューチェーン分析の視点で「この機能は付加価値を生むか、コスト削減につながるか」を問うようになった。プロダクトバックログの優先順位付けに、PPM（プロダクト・ポートフォリオ・マネジメント）の考え方を借りた。財務会計を学んで、投資対効果の試算をエクセルで出せるようになり、インフラ刷新の稟議が通りやすくなった。

逆方向の影響もある。私がプログラマー的に「正規化された問題構造」を好むため、診断士の2次試験でも答案をフレームワークに当てはめて書く癖がついた。採点者には「型通りで読みやすい」と好評だったが、「独自の切り口が薄い」という弱点にもなった──構造化思考の光と影だ。

まとめ：遠回りではなく、近道だ

「診断士の勉強をしているというと、本業に集中しなくていいのか」と言われることがある。私の答えは逆だ。

本業に最も集中するために学んでいる。コードを書く意味を理解し、経営者と同じ解像度で課題を語り、技術と事業の橋渡しをできるエンジニアになるために──それは診断士という資格の先にある姿だと、今は信じている。

試験はまだ合格していない。でも、学習を始める前より、エンジニアとして明らかに視野が広がった。それだけでも、この勉強を始めた価値は十分にあったと思っている。