コペル21少年から実装型コンサルタントへ
導入：Week1を終えて
今週（Day1-6）は、戦略実行設計者という肩書き、株式会社ラヴィの理念、DXが進まない理由、そして私のキャリアの変遷について書いてきました。
日曜日の今日は、少し立ち止まって「なぜ私は技術を手放さなかったのか」という原点を振り返りたいと思います。
子供の頃の憧れを忘れてマンション営業へ
中学生の進路選択で、私は商業高校の情報処理科を選びました。
そのまま就職するつもりでした。
選んだ理由は、子供の頃からパソコンに憧れていたからです。
公文式で買った「コペル21」という雑誌。
早見優さんが登場するパソコンのコーナーを、理由もわからず読んでいました。
図形を引くプログラムだった記憶でなんの役に立つのか分かりませんでしたが、何か惹かれるものがあった。
実際に情報処理科での授業は私にとって簡単なもので、第二種情報処理技術者試験に合格できました。模試のプログラミングは100点だったと記憶してます。
しかし、バイト先の先輩を見て「大学生活を送りたい」と思うようになりました。有り体に言うと「大学で遊びたい」です。
そして進路を切り替えて進学クラスに入り、大学に進学しました。
大学の4年間は、特に人生について考えることもなく過ごしました。
褒められることではありませんがたくさん遊んで、目的は果たせました。
サークル活動とバイトの記憶が99%です。
そして、バイト先のお客様の紹介で、マンション営業の職に就きました。
このときは「遊びも人生で大切なこと」と自己肯定して、マンションの営業で稼ごうと思ってました。
マンション営業からプログラマへ──「手に職をつけたい」
Day1 で書いたように私はマンション営業を半年で辞め、プログラマとしてキャリアをスタートしました。
営業では、なかなか契約が取れず全然稼げませんでした。チーム成績に迷惑をかけてしまうことと、自分には適正がないと判断して辞めました。
当時の動機はシンプルで、「手に職をつけたい、子供の頃に憧れてたパソコンの仕事に就こう」 でした。
これは転職時によくやる自己分析の結果です。
ちなみに第二種情報処理技術者という資格は、あまり役に立たなかった記憶があります。プログラマになるためのパスポートみたいなものかと思ってましたが、現実は違いました。
「手に職つけられた」の安心感から一転して危機感へ
無事プログラマとして転職できたわけですが、SIerプログラマとして働く中で、ある現実に気づきます。
これは「手に職」と言えるのか？
プログラマとして働き始めると、だんだん「上流」「下流」というシステム開発の流れが見えてきました。下流のプログラマは上流で決まったことを、言われた通りに実装するだけ。
「この場合はどう動くべきですか？」
「仕様にこのケースが書かれていません。」
質問して上流が間違ってたら「修正しました」と回答が来て、私たちの残業で設計やプログラミングの修正作業（結構な作業！）を行う。
こんなことが多く発生して、「手に職」と私が思っていたものとは違いました。自分で仕事を選べてない感覚。
もっと自在に、価値のある仕事がしたい。
そう考えて「上流に行きたい」と思ったのです。
上流に行って見えてきた根本的な課題
そして実際に上流（要件定義）に関わるようになりました。
これも Day1で書いたように、東京で半年間の要件定義プロジェクトに参加しました。しかし、そこで見たのはまた、期待していた光景ではありませんでした。
コミュニケーション能力に難あり。
主張が先行し、議論をまとめる力がない。
次のアクションを制定して確実に実行・確認する文化がない。
定時になると何も決まっていないのに帰ってしまう人も居る。
そして曖昧なまま、下流に資料を流す人も居る。
これは多くの企業で起きている「会議が多いのに何も決まらない」「決めたはずなのに現場が動かない」問題そのものでした。
「上流に行けば下流の問題が解決する」と思っていましたが、上流には私の手に余る課題 があったのです。
このときようやく理解しました。
流れが途切れてしまう課題はどこに行ってもつきまとうということを。
技術を手放したくなかった
上流にも理想はないという現実を知ったとはいえ、会社を辞めたりといった行動は起こさず私なりに頑張ってシステム開発の上流（要件定義等）やマネージャー（QCD管理）の仕事を続けました。
ここで私のこだわりのようなものがありました。
技術のわからないマネージャーにはなりたくない。
例えば「（分かってないけど）分かった」というマネージャーにはなりたくなったのです。漠然とですが、裸の王様になるような恐怖を抱いてました。
多すぎる見積もり工数に説明を求めたり、逆に少なすぎてリスクが高すぎるなど技術者と議論できるマネージャーで有りたかった。
さらにフリーランスになってから、コンサルタント会社の外注メンバーとして銀行へ出向したときに技術の必要性を感じました。
資料を作るために実装者にヒアリングしてて大変そうだな・・
技術が分かれば、技術選定や実装イメージまで考えて資料を作り、顧客へ説明して、そのまま実装担当へ渡せます。今なら生成 AI でプロトタイプ作成まで行うでしょう。
実際、生成 AI が進化したおかげで複数のシステムからデータを取得して企業のダッシュボードを構築したことがあります。Google Cloud Platform 上に構築して、pub/sub を使うなど、適切な設計を施しました。
これは技術を完全には手放すことなくマネージャーの役割を担ってきた私の特性だと思います。
Week1で伝えたかったこと
長くなってきたのでまとめます。
今日は私自身のバックグラウンドを紹介しました。
また、この一週間で会社の経営理念やMVVも紹介しています。
Day1 (12/1): 私の Pivot ─ 最下層PGから経営者・実装型コンサルタントへ
Day2 (12/2): 株式会社ラヴィ ─ 小さな実装型コンサル会社の紹介
Day3 (12/3): DXが進まない理由 ─ 実装のプロのほうが安く、速く、確実
Day4 (12/4): 戦略実行設計者 ─ 私が設定した肩書き
Day5 (12/5): Connecting the dots ─ 私の dots の話
Day6 (12/6): BlackFriday ─ 「ちょうどいい」設備投資の実践
少しでも「戦略実行設計者」「実装型コンサル」のイメージ、私自身のこと（技術を手放してない）が伝わると嬉しいです。
Week2への予告：翻訳力と実装力を深掘りする
来週からは、もう少し具体的に書いていく予定です。
経営の抽象語を「動ける設計」に変える翻訳技術
業務とデータを同時に設計する方法
アジャイル・DevOpsを「文化」として実装する理由
ユーザーストーリーマッピング（USM）の実践
経営者の方には「こうすれば自社のDXが動き出す」具体策として、
技術者の方には「上流への関わり方」のヒントとして、お読みいただければ幸いです。
最下層PGとしてスタートした私が辿り着いた「実装型コンサルタント」「戦略実装設計者」という在り方。その中身を、順を追って言語化していきます。
引き続き、よろしくお願いします。
関連記事:
