あるビジネススクールで受講した「テクノベート・シンキング」の学びを全12回の記事にまとめていく。その1本目。
初回の今回は、そもそもなぜIT畑にいる私がわざわざこの科目を取ったのか、という受講動機と、第1回の事前学習を通じて考えた「ICTの進化と自分の仕事」について書く。
なぜIT畑にいる私が「テクノベート・シンキング」を学んだのか
私はIT業界の中でも、長くインフラ側を専門にしてきた。サーバーやネットワーク、認証基盤やクラウド環境の設計・運用が日々の仕事の中心だ。
「IT業界にいるのに、なんでわざわざビジネススクールでITの科目を取るの？」と聞かれそうだが、理由は割とシンプルだった。
インフラ畑にいると、開発やDXの文脈から少し取り残されている感覚があったからだ。
インフラ周りの話なら日常的に扱っている。ただ、アプリケーション開発の現場でどんなアルゴリズムが組まれ、データがどう流れ、どうユーザー価値に変わっているのか──そこは正直、自分の手触りでは語れなかった。AIやデータ活用の話題を振られても、インフラ側の答え方しかできない自分がいた。
もうひとつは、「ビジネスリーダーとして押さえておくべきITの考え方」を体系的に取り込んでおきたかったこと。実務でなんとなく知っていることと、言語化して語れることはまったく違う。プログラミングそのものを職業にする予定はないが、その世界の論理の組み立て方を一度は自分の手で経験しておきたかった。
この「なんとなく分かっている」と「自分の言葉で説明できる」の間にある溝は、IT畑が長くなるほど深くなる。経験年数が増えれば自然にその溝が埋まるかといえば、むしろ逆だ。日々のオペレーションに追われて、自分が何を知っていて何を知らないのか、その境界線すら曖昧になっていく。そういう危機感が、ビジネススクールの教室に足を運ばせた大きな理由だったと思う。
「テクノベート・シンキング」ってどんな科目？
この科目のねらいをひとことで言えば、大量データや繰返し処理はコンピューターに、論理設計は人間が担う──その役割分担によるテクノベート時代の問題解決手法を身につけることだ。実際にプログラミングを体験しながら、自分のビジネスの問題に適用できるようになることを目指す。
キーワードは「役割分担」だ。コンピューターに任せる部分と、人間が考え抜く部分を分けて考える。エンジニアに丸投げするのでも、自分で全部書くのでもなく、論理設計は自分でできるビジネスリーダーになるための科目、と言える。
全6回の構成は、前半でプログラミング基礎やアルゴリズムの考え方を実際にScratchで体験し、後半でAI・IoT・ノーコードなどの応用技術に触れたあと、最終回で自分のビジネスの問題を実際にツールを使って解決する──という流れになっている。座学で終わらず、自分の手を動かし、最後は自分の現場に持ち帰る設計だ。
教科書は前半の回で『Scratchで学ぶプログラミングとアルゴリズムの基本 改訂第2版』、全回を通して『ビジネススクールで教えている武器としてのITスキル』の2冊。前者で実際にScratchを動かし、後者で経営目線のITリテラシーを補う、という二段構えだ。
第1回の学び：ICTの進化が自分の仕事にもたらす変化を考える
第1回の事前学習では、ICTの進化が自分の仕事にどんな影響を与えるかを考える課題があった。日々の現場を思い浮かべながら自分なりに考えた結果、大きく4つの変化に整理できた。
① 業務プロセスの変化──「ITに業務を合わせる」方向へ
従来は、ユーザー業務にシステムを合わせてカスタマイズするのが一般的だった。複雑な業務要件に対応するために、現行の仕組みを熟知した一部の人が職人技のように設計を引き受ける、という構図はどの現場にもあったと思う。
しかし今は、その逆方向に動き始めている。正確性・迅速さ・セキュリティリスク低減のために、業務側を標準化・構造化してITに合わせていくという流れだ。AIや自動化で処理しやすい形に業務側を整える、と言ってもいい。一部の領域に閉じた話ではなく、業務要件全体に同じ波が広がっていくと感じている。
これは現場にいると「なんとなくそうだよね」と思っていることだ。でも、改めて文章にしてみると、自分がどの程度この変化を理解していて、どの部分は感覚でしかなかったのかが浮き彫りになる。「分かっているつもり」の中身を棚卸しする感覚が、ここにはあった。
② 人材と組織の変化──「導入支援」から「共に設計する」役割へ
ここ数年で、ビジネス側のITリテラシーが格段に上がっている。AI・データ活用のキーワードを交えた高度な相談が普通に飛んでくる。
これに応えるには、IT側の担当者も単なる「導入支援」から脱却しなければならない。技術を理解した上で、業務と結びつけて提案・設計する役割を担う必要がある。実際、AIによる業務最適化や既存運用変更の提案を求められる場面が増えていて、「要件が降ってくるのを待つ受け身型」では立ち行かなくなってきた。
インフラ畑の人間として特に感じるのは、この変化が「自分の領域の外」ではなくなりつつあるということだ。クラウドの自動化、IaCの浸透、ゼロトラストの設計──いずれも、ただ「導入する」のではなく「なぜその設計にするのか」を業務側に説明し、一緒に意思決定する力が問われる。技術だけでも、コミュニケーションだけでもダメ。その両方を自分の言葉で橋渡しする能力が要る。
③ ガバナンス・リスク管理の再設計
AIの導入は新しいリスクも連れてくる。自動化によって人が手を動かさなくなる分、判断の根拠や説明責任をどう担保するかという統制課題が増えていく。「自動化したから安心」ではなく、「自動化したからこそガバナンスを再設計する」フェーズに入っている。
これはインフラ運用の文脈では以前から意識されてきたテーマでもある。障害対応フローの自動化や監視閾値のチューニングは、「人が判断しなくなった部分」に対する品質保証をどう設計するかという問いそのものだ。その経験があるからこそ、ガバナンスの再設計という話は腹落ちしやすかった。同時に、自分の経験がこの新しい課題にどう接続できるかを言語化できていなかったことにも気づいた。
④ 顧客との関係性の変化──「納品」から「共創」へ
ビジネス側のDXが進む中、IT側に求められる役割も変わってきた。「構築して納品する」から「変革を共にデザインする」へ、というシフトだ。
業務部門と一緒にあるべき姿を描き、ツール導入から運用設計まで一気通貫で支援するようなプロジェクトが増えてきた。共創型のチーム体制と、新しいケイパビリティの構築が同時に求められている。インフラだけ、運用だけ、という縦割りでは戦えない時代になりつつある。
4つの変化を整理して見えてきたこと
4つを並べてみて改めて思ったのは、「会社の仕組みを支える・守るIT」よりも「変化に対応するIT」の重要性が増しているということだった。守りのITを軽視するわけではない。むしろ、守りを自動化・標準化したうえで、その分の時間と頭を「変化に対応する側」に振り向ける──そういう構造変化が来ている。
インフラ畑の人間にとって、これは結構キツい問いかけだ。守りの領域を長くやってきた人ほど、自分の存在価値を「安定稼働を守ること」に置いてきたからだ。その価値が消えるわけではないが、それだけでは足りない時代になった。そこに正面から向き合わなければならない。
そしてその「変化に対応するIT」を担うには、技術に対する一定以上の理解と、構想・設計して伝える力が不可欠になる。インフラを長くやってきた私が「テクノベート・シンキング」を取ろうと思ったのは、まさにここを補強したかったからだと、この4つを書き終えてから改めて自覚した。
ビジネススクールでITを学ぶ意味──現場の感覚を言語化する
現場でなんとなく感じていたことを、改めて書き出すと、自分の中で4つに整理された。これがすごく大きかった。実務をどれだけ続けていても、書き出さないと言語化できないものは山ほどある。
ビジネススクールでITを学ぶ意味は、新しい知識を仕入れることそれ自体ではなく、現場の感覚を構造化された言葉に翻訳する練習にあるのかもしれない。少なくとも初回を終えた段階での私の実感はそうだった。
IT畑で長く働いていると、日々の仕事の中に「気づき」はたくさん転がっている。ただ、それは「なんとなくそう思う」という形で脳のどこかに蓄積されていくだけで、他人に伝えられる形にはなっていない。会議で「DXってこういうことだと思うんですよ」と話しても、相手に届く言葉になっているかは怪しい。
「思っている」と「語れる」の間にあるギャップを埋めるのが、言語化の力だ。そしてその力は、現場にいるだけでは身につかない。一度立ち止まって、自分の経験を別のフレームで整理し直す機会が要る。ビジネススクールの事前学習は、まさにその機会だった。
今後この科目を進める中で、プログラミングやアルゴリズムのスキルも当然学んでいく。だが、もしかするとそれ以上に大きいのは、「自分が現場で何を見てきたのかを、自分の言葉で再定義していく」プロセスなのかもしれない。初回でそう感じられたのは、いい滑り出しだったと思う。
次回：Scratchで「本のレコメンドプログラム」を作ってみた話
初回にはもうひとつ、骨のある事前課題がある。Scratchでプログラムを作り、そのアルゴリズムをフローチャートに表すという課題だ。
開発未経験の私がこれにどう取り組み、どこで「やりすぎた」と感じ、どこで「自分のベーススキルがちゃんと活きた」と実感したか──次回はその話を書く。
今回参考にした書籍
初回で使った教科書はこの2冊。
「Scratchで学ぶプログラミングとアルゴリズムの基本」は、開発未経験の私でもつまずかずに最後まで進められた。次回紹介する事前課題のScratchプログラムも、この本を通読してから取り組んだ結果、ある意味「やりすぎ」な実装になってしまった……という話につながる。
