なぜ「実装型」を名乗るのか ─ 技術を手放さなかった理由

Week3 の始まり

昨日の Day14 では、少し個人的な話をしました。
森博嗣さんの「自由をつくる 自在に生きる」との出会い、経営理念に入れた「自在」という言葉の原点。

今日からWeek3、「実装型コンサルタント」を名乗るバックグラウンドを書いていきます。

「実装型」の3つの意味

「実装型コンサルタント」とは何か。私は3つの意味で使っています。

1. 作れる

自分で手を動かせる。

プロトタイプを作る。検証する。小さな改善をすぐに実装する。

Day10 で書いた MVP（Minimum Viable Product）の考え方と繋がります。「動くもの」を見せると、経営者の理解が圧倒的に早い。

「こういうイメージですか？」と画面を見せながら話せる。言葉だけの説明より、認識のズレが早く見つかります。

今なら生成AIの力を借りて、1日でプロトタイプを作ることもできます。

2. 分かる

技術的な実現可能性を判断できる。

Day8 の世界線2で、こんな判断をしました。

すべての技術を深く知っている必要はありません。
「技術的なコンテキストが概ね理解できる」「調べ方を知っている」「判断できる」ことが重要です。

これができると、Day8 の世界線1のような失敗を防げます。「そんなこと最初に確認してよ」と言われる前に、確認できる。

3. 伝えられる

開発会社に明確に指示できる。

Day8 の世界線2で、こんな指示を出しました。

例えば「データベースにデータを集めてダッシュボード化してください」だと、開発会社は困ります。
データベースに何を使えばいいのか、ダッシュボードはスクラッチ開発するのか何かサービスを使うのか。

見積もりも曖昧になり、手戻りが発生しやすい。

製品名レベルで明確な指示ができると、見積もり精度が上がり、話も早くなり、手戻りが減ります。

開発会社との信頼関係も築きやすくなります。
「あの人は大体わかってるから話が早い」となります。

もちろん全ての技術を理解しているわけではないので、必要に応じて技術者と相談したり提案してもらったりもします。
その提案の妥当性を判断できるのも強みになります。

経営者と技術者、両方の言葉を話す

私はプログラミングからキャリアをスタートして、プロジェクトマネジメント職へ進みました。
プロジェクトマネージャーには進捗管理や品質状況など、顧客への説明等が求められます。

一方で、技術が分からなくなることへの恐れから技術も少しずつキャッチアップしてました。
英語で言えばスピーキングやライティングは苦手だけで、リーディングなら辞書を引きながらできる、という感覚で開発スキルをキャッチアップしてきました。

その結果として「作れる」「分かる」「伝えられる」がというスキルになったと思います。これらが揃うと何が起きるか。

経営者の言葉も、技術者の言葉も話せる。

という状況になります。

経営者に対しては：

• 「在庫配分を最適化する流れを整理しましょう」

• 「新しいツールを覚えなくていいです。既存の環境で実現できます」

技術者に対しては：

• 「Cloud FunctionsでAPIを叩いて、BigQueryに集約してください」

• 「IAMで権限設定してください」

この「翻訳」ができることが、「実装型コンサルタント」の価値だと考えています。

Week3 で答える「経営者の悩み」

さて、Week3 ではもう少し具体的な話をしていきます。

経営者の皆さん、こんな悩みはありませんか？

• 人材がいない ─ 「ひとり情シス」で回らない

• RPAが止まる ─ 「ロボットが自動で仕事してくれる」はずだったのに

• ノーコードツールに期待したけど ─ いわゆる野良アプリ、誰が何のために作ったアプリか分からず収拾がつかない

• CRM/SFAが定着しない ─ 毎月の利用料だけがコストになっている

これらの悩みに、「実装型」の視点から回答していきます。

「銀の弾丸」は私が知る限りですが、ありません。
でも、「ちょうどいい」解決策はあります。

明日から、一つずつ深掘りしていきます。