1000engineering

技術コミュニティについて、一度立ち止まって考える

私は、ある時期から技術コミュニティに少し引っ掛かりを感じるようになった。最初から否定的だったわけではない。会社の外で知識を交換できることにも、技術者同士がつながれることにも、大きな価値があると思っている。今でも、その考えは変わらない。ただ、長く眺めているうちに、一つ気付いたことがある。技術コミュニティで語られることは、思っている以上に「ある範囲だけ」を見ている。もちろん、そこで語られる内容は重要だ。新しいフレームワーク。クラウド。生成AI。アーキテクチャ。設計手法。どれも技術者にとって必要な知識であることは間違いない。しかし、それらの多くは「どう実装するか」という話だ。つまり、技術の実装レイヤーである。私は以前、「技術者とは、技術を知っている人ではなく、技術の概念を理解している人ではないか」と考えるようになった。その頃から、少しずつ違和感が生まれた。技術そのものを考える話が、意外なほど少ないのである。技術は、なぜ生まれるのか。なぜ企業はその技術を選ぶのか。その技術によって、組織はどう変わるのか。責任はど

1000engineering

「どうすればできるの？」は建設的な発言とは限らない

「どうすればできるの？」一見すると、とても建設的な言葉に聞こえる。実際、現場でもよく使われる。しかし、この言葉は建設的な発言とは限らない。むしろ、責任を他者へ移すための言葉として機能してしまうことがある。問題は「問い」ではなく、「誰が考えるか」例えば実装担当がこう言う。「この通信経路では成立しません。」「この権限では動きません。」「この運用では回りません。」ここで、PMなりリーダーなりが、「どうすればできるの？」と返す。これは、一見すると前向きだ。しかし、その一言だけで終わるなら、実装担当は * 制約を分析し * 代替案を考え * リスクを整理し * 工数を見積もり最後に判断材料まで用意することになる。つまり、制約を理解する責任そのものが実装側へ移っている。本当に建設的な人は何を聞くのか本当に現実を見ようとしている人は、こう聞く。 * なぜ成立しないのか。 * 制約はどこにあるのか。 * 要件を変えれば成立するのか。 * 納期を変えるべきなのか。 * リスクを受け入れるべきなのか。

1000engineering

技術と近づきすぎてはいけない

技術企業だからといって、技術ばかりを見ていてはいけない。一見すると矛盾しているようだが、私はむしろそう思っている。技術は重要だ。だからこそ、真剣に見なければならない。しかし、技術とべったりになった瞬間に、企業の視点は驚くほど短絡的になる。「次は何を導入するか。」「どのモデルが勝つのか。」「どのフレームワークへ移行するべきか。」もちろん、それらは重要な問いである。しかし、それだけを追いかけ始めると、本来考えるべきことが見えなくなる。顧客にどんな価値を届けたいのか。組織として、どんな能力を蓄積したいのか。五年後、十年後も変化に適応できる状態とは何か。技術は、その問いに答えるための手段であって、問いそのものではない。これは企業だけの話ではない。個人の技術者も、特定の技術そのものに関心が止まっていると、やがて成長が停滞する。新しい製品を覚える。新しい構文を学ぶ。新しいフレームワークを使えるようになる。それ自体は必要なことだ。しかし、そこで学びが止まれば、技術が入れ替わるたびに、また最初から追いかけ直すことになる。本来、技術

1000engineering

「まず進める組織」と、「成立条件を整理する仕事」のズレ

ここ数ヶ月、ITシステム構築のPMとして担当していた案件で、かなり強く感じたことがある。最初、この案件は「AIオーケストレーションOSSをAWS上に安全に導入する」という文脈で始まっていた。だから当初は、閉域構成、アウトバウンド制御、Proxy、認証、ログ、運用更新方針といった、いわゆる「AI導入基盤」としての論点整理を進めていた。ただ、整理を進めるほど、違和感が大きくなっていった。自分が確認していたのは、データがどこを流れるのか、AIオーケストレーションOSSのDBには何が保存されるのか、Python実行を許可するのか、外部SaaS連携をどう扱うのか、AI出力責任は誰が持つのか、AIが業務判断に関与するのか、マスキングは本当に成立しているのか、閉域環境で更新運用をどうするのか、といったことだった。進めると見えてきたのは、これが単なる「AI導入案件」ではない、ということだった。 AIが業務データを横断し、ワークフローを実行し、Pythonコードを動かし、ファイルを生成し、他システムと連携し、業務判断の一部に関与する。構造としては、かなり「AI業務システム」に近い。