- 技術業務を工場のように標準化し、再現可能な成果物にしようとする経営側・ベンダー側の期待は大きいが、多くの現場ではまだその方法で安定的に商品化できていない
- McDonald's的な運用は、品質そのものよりも、異なる場所や人員が同じ結果物を出せるようにする規律に近く、多くの経営書もIT運用をこのような生産フローとして捉えている
- エンタープライズソフトウェアの販売は、SQL・データ・開発業務をドラッグアンドドロップと一貫したインターフェースで置き換え、人材を代替可能にするという約束に近い
- 実際の組織では、質の悪いソフトウェアライセンスや誤った抽象化では技術的な問題を解決できず、結局は優れたエンジニアが悪いデータモデルや技術的判断を自ら修正しなければならないことが多い
- 創造性、センス、専門性、人と人とのつながりを必要とする仕事は、JiraボードやAgileのスコアに完全には還元できず、大規模な生産インフラの中でも個々の人がシステムを動かしている
McDonald'sが示す標準化の難しさ
- 優秀なデータエンジニアだった最初のマネージャーは料理に深く没頭していた人で、McDonald's運営の複雑さを何度も高く評価していた
- McDonald'sの価値は成果物の品質そのものより、教育水準や地域の異なる従業員たちが同じバーガーを作れるようにする最適化と規律にある
- 異なる場所の未熟練労働力が一定の結果を出せるようにするのは単純なことではなく、この事例が技術業務の商品化の議論へとつながる
経営書はITを工場のように扱う
- The Phoenix Project はIT運用を製造工場の業務に近い問題として描き、組織内の作業フローとコミュニケーション管理を中心に据えている
- 似た空気感を持つ本として The Unicorn Project, Investments Unlimited, The Goal が続く
- The Goalは実際の工場運営を変える物語であり、ほかの本に影響を与えた作品として扱われる
- High Output Management もレストランで仕事が流れる仕組みを例に取り上げ、間違ったタイミングで卵をゆでると顧客のもとに届くころにはトーストが冷めている、といった形で作業フローを説明している
- この系統の考え方では、規模の経済、スループット、作業フローといったテーマが繰り返し現れる
ベンダーピッチの核心は技術より代替可能性
- あるベンダーカンファレンスでの複数の製品ピッチは、技術的な詳細よりも、十分に良い業務成果物を再現可能な形で届けるという約束に焦点を当てていた
- ある製品はSQLを直接書かずにドラッグアンドドロップのエディタで依存関係を設定できると宣伝していた
- 実際にはアプリケーションがPostgresに接続するため、SQLが消えるのではなく、ライセンス付きの抽象化レイヤーがSQLの代わりに記述する構造になっている
- こうしたピッチは経営陣にとって、「遅く問題の多いSQL」を一貫したインターフェースと市場のツール専門家に置き換えることで、組織内のデータ提供を滑らかにできるというメッセージに聞こえうる
- Agileが平均的な機能不全組織で実装されるやり方も、似た問題を露呈している
- エンジニアを機械、成果物を部品、story pointを生産単位のように数え、翌週の目標達成率を確認するようなやり方である
多くの技術業務がまだ商品化されていない理由
- McDonald'sはおおむね5分以内に一定品質のフライドポテトを提供できるが、多くの技術組織は価値のあるものをデプロイできないまま、質の悪いソフトウェアライセンスを購入している
- 技術的問題や悪いデータモデルを金で解決する道は、問題解決だけに集中する優れたエンジニアを確保することに近い
- 商品化できそうに見える領域も多いが、実際には動かない製品を売る会社と、それを買う無知な意思決定者の組み合わせであることが多い
- 一部の意思決定者は、法令順守を満たすという名目で低賃金地域の電話サポートを活用し、解約しようとする顧客を気にしないやり方を選ぶこともある
- サポート担当に連絡しなければならないとき、まず販売窓口に電話して、権限のある現地担当者へ素早くつないでもらえないか試す、という経験も紹介されている
創造的な技術業務には人の要素が残る
- Rich Hickeyの Hammock Driven Development は、調査内容を無意識に入れ、瞑想し、眠ることで設計上の答えを得るような作業フローを扱っている
- プログラマーは問題から離れているときに答えがひらめく現象を経験することがあり、これは単にウィジェットをより速く量産する仕事とは異なる
- 社会にはより速く量産する種類の仕事も多いが、価値のある多くの成果物は、定義しにくい創造性と生産の現実が交わる地点から生まれる
- 本、料理、レストラン運営のような事例でも、大量生産や提供の仕組みを洗練させることはできるが、美しい成果物にはセンスと配慮が必要だ
- 機能開発をJiraボードとAgileのストーリーに還元しようとしても、人とのつながりがなければ価値ある結果を得るのは難しい
- iPhoneに入るチップを設計している知人の例のように、テストや大量生産のインフラがあっても、特定の個人が病気になると次のリリースが遅れるほど個々の人が重要な役割を担っている
- 社会が商品化の上に成り立っている現実はあるが、特定のクラフトへの理解や、人間の複雑さ・必要・脆弱性を無視した純粋な商品化だけでは技術業務を運営できない
1件のコメント
Hacker Newsのコメント
筆者は、かつて技術業務と呼ばれていたもののかなりの部分が、いまや汎用品化された点を見落としているように思う
かつて差し込み印刷とは、本当に大量の宛名ラベルを印刷して手で手紙や封筒に貼る作業だった。Word 2.0あたりが1990年代にその問題を解決し、MailChimpが21世紀にそれを商品化した
複式簿記も高度な訓練を受けた人が行う技術業務だったが、いまでは店主がバーコードを読み取り、顧客がタップ決済すればよい
Scratchより複雑なものに使えるドラッグ＆ドロップインターフェースはまだ存在しないが、難しい部分はライブラリをつなぎ合わせる技術作業ではなく、要件収集である
高品質な暗号化ライブラリを組み込んだり、Webサイトにインタラクティブな地図を取り込んだり、WebサイトをWYSIWYGで編集したりすることは、かつてないほど簡単になった
退屈している18歳をIDEの前に座らせてERPを作らせることはできない、という点では筆者は正しい。しかしITの多くの雑務は、いまや確実に商品になっている
技術産業の雑務は減るどころか増えていると思う。現在、雑務がXだけあり、新技術Zが登場してXを0.1Xに減らす一方で、Zが新しい作業方法を可能にし、その副産物としてまた別の雑務が生まれる。すると現在の雑務はYになり、YはおおよそXに近くなる
2000年代に技術の進歩が止まっていたなら、90年代に由来する雑務は今日ほぼ0になっていただろうが、新技術は自動化と雑務を一緒にもたらす
最近の例はAIツールだ。音声、画像、映像、テキストを生成するツールはあるが、差別化された製品や体験を作るには、ChatGPTやStable Diffusionのようなツールを組み合わせる雑務が必要になる
さらに商品化するほど問題はより高次元へ上がり、雇う専門エンジニアもスタックのより上位へ移動する
最近SaaS化されたスタートアップ製品の中には、まだ望むことを実際にはやってくれない製品の割合が高いように見える。料金を取ってサービスを使わせたうえで、顧客のユースケースを実装対象として収集し、他の顧客向けに商品化しようとする形なので、リードタイムは長くなり、知的財産も漏れていく
SQLのテンプレート化は、経営陣が常に誤解する対象だ。SQLは業界で驚くほど長く生き残っており、実際かなりよくできている。その上に載せるラッパーやDSLの99%ははるかに悪いものにしてしまい、少しでも平凡でない作業は結局SQLまで降りる必要がある。SQL専門家を採用する代わりに、存在もしないSaaS式DSL SQLラッパーXの専門家を育てなければならない状況になる
根本的な問題は、こうした製品が、その分野で働いていない購入者に対して「買って差し込めば問題が解決する家電製品」のように見えるよう設計されていることにあるのかもしれない
多くの製品は実際には問題を解決しておらず、他社が買っているという理由で解決しているように見えるだけだ。そして実装が成功したと嘘をつかなければ昇進できない。差し込み印刷のようなものは本当にやかんのように、すでに解決済みの問題であり、そうした問題は自分で試しながら解決すればよい
より大きな問題は、私の雇用主がWorkdayをやかんのようなものだと信じて買ったものの、我々の組織構造があまりにひどく、そもそもモデリングできないという事実は直せなかったことだ
今年初めて、大企業における十分に悪い組織構造は一種の技術的負債なのだと気づいた。誰が誰の下で働いているのか、このユーザーがこのデータベースで何を見られるのかを突き止めるために、ありとあらゆる奇妙なことをする羽目になる
1994年や2004年に比べて、いま事業を運営し、Webサイトを作り、旅行を計画し、請求書を支払うことはどれほど単純になったのだろうか？
以前の世代は生活のペースがもっとゆったりしていて、その分より充実した暮らしをしていたように感じることがある。いまは時間があまりにも速く過ぎ、ストレスも高い
少し前、銀行で60歳以上の人が少なくとも3人、簡単な用事を処理できずに困り、職員に助けを求めているのを見た。オンラインバンキングで簡単にできるはずのことなのに、例外的な状況のためシステムが対応しておらず、結局予約を取る必要があり、最短の日程は3〜4か月後だった
そのうちの1人は、薪を買って家を暖めるために凍結された口座からお金を引き出す必要があったが、銀行員は3か月待つように言うだけだった
2年前、父はシチリアから自宅へ簡単な電話をかける方法を見つけられなかった。1970年代なら、近くのバーに入って硬貨を数枚入れれば済んだことだ
昔は普通の人でも電灯、車、暖房、自動ドアではないドアくらいは自分で直せたが、いまは専門家を呼ばなければならない
技術業務を完全にコモディティ化しようとする試みは悪い考えであり、今後も失敗し続けてほしいと思う。
ただし、私は The Phoenix Project を2回読み、Scrum の大半は嫌いだが、その本がそういうことを主張しているとは思わない。
私が得た要点は、反復可能な業務を実行・管理するための明確なシステムを持ち、可能なところは自動化すること、進行中の仕事を減らして人々が大量のタスクに縛られないようにすること、情報を広く共有して複数のチームメンバーが同じ作業をできるようにすること、実際にビジネスに必要な仕事をしているか確認すること、ノイズや予定外の仕事を減らして、従業員が無秩序な沼をさまよう代わりに、楽しんで取り組める高付加価値の仕事をできるようにすることだった。
The Phoenix Project の主旨は、人を交換可能なオートマタにすることではなく、自動化や体系化が不可能な、本当に価値ある仕事をするための余裕と時間を与えるシステムを作ることにある。
工場を運営したこともあり、開発者でもあったので両方の側面を見るが、開発者を生産工場の労働者にするのは筋が通らない一方で、既知の作業や反復可能な手順のように工場仕事に見える業務は、同じように扱うべきだ。
s/manufacturing/IT/gし、現代的な参照で更新したものに近い。その本が嫌いだという意味ではない。半分ほどは読んだし、チームごとにシステム中心の考え方へ切り替えさせるために読ませようともした。ただ、The Goal よりはるかに深い、あるいは洞察に富むとまでは言えない。
文体をからかりはしたが、実際には読む価値があった。既知の作業や反復可能な手順で人々が犯す多くの間違いを、Phoenix Project 的な思考のせいにすることはできない。
ただしプログラミングでは、既知の作業を反復手順として行うことはまれだ。そういうことが起きるなら、ステークホルダー管理で戦術的な失敗をして、自動化する時間がなくなっている場合が多い。
注意深く読めば最後の段落のような結論に至るが、私が出会う管理者の大半は、ウィジェット生産とシステム設計の違いを理解していないことは確かに分かっている。
継続的学習、自動化、計測は、上記の1〜5を可能にするための道具だ。
The Phoenix Project から「もっと一生懸命働いて、より多くの仕事をより速くこなせ」というメッセージを受け取ったことはない。
https://scrumguides.org/scrum-guide.html
たいていひどいのは、人々が Scrum と呼びながらその上に載せる雑多なものだ。でたらめな Scrum に対抗する最善の方法は、戦うことではなく、本来の教義に純粋主義的に忠実なふりをすることだった。反抗的に見えにくく、影響も与えやすい。
タイトルに戸惑った。「commodify」は「販売可能にする」、つまり商業化するという意味ではないのか？ 技術はすでに数十億ドルを稼いできたのでは？
筆者が言っているのは commoditization、つまり技術業務を、誰でも代替可能な従業員ができる一般的な業務にすることのように思える。
https://en.wikipedia.org/wiki/Commoditization によれば、commoditization は独占的なものが一般財になることで、commodification は販売不可能だったものが販売可能になること、と整理できる。
私は細かいことを言いすぎだろうか？ 両者は別の意味だと思っていた。
追記: Wiktionary を見ると、https://en.wiktionary.org/wiki/commodification では相互に使われることもあると出ている。単によくある混同のようだ。
https://www.merriam-webster.com/dictionary/commodify
「内在的価値を持つものや芸術作品のようなものを商品に変える」という意味なので、commodify は commoditization に関する言葉に近い。
石油がコモディティである理由は、生産者が多く、全員が同じものを作っているため、どこから買っても構わないからだ。
McDonald’s の比喩で、開発者は機械の前で働く10代の若者ではなく、機械を設計したエンジニアです。その比喩では、コンピュータが10代の若者です。
プログラミングは作業ではなくメタ作業です。一度命令のリストを作れば、コンピュータがその作業を24時間続けて実行し、私は別の作業のための新しい命令リストを書きに行きます。
同じ命令リストを2回書いているなら、基本的にやり方を間違えています。だから常に新しいことをすることになり、同じことを2回しないので、どれくらい時間がかかるか分かりにくいのです。
ITは工場ではなく、工場を作る仕事です。
多くの開発者と管理者の対立は、「管理者」という言葉があまりにも大ざっぱすぎることから来ていると思います。McDonald’s の管理者は、従業員が製品を作り出すプロセスに従っているかを監督します。プロセスに従っていないかどうかは明確で、プロセスは有効だと前提され、成果物が出ていないかどうかも明確です。
一方、プログラマーは機械が従うプロセスを開発するために雇われます。この従業員を管理する人にも、プログラマーが従うべきプロセスがあるかもしれず、それに従っているかどうかは明確かもしれません。しかし、そのプロセスが有効かどうか、特定の行動が定められた結果につながるかどうか、結果そのものが明確かどうかは不確実です。
それでも、どちらの役割も「管理者」と呼ばれます。
この機械の比喩では、プログラマーは人を管理しているのではなく、機械を指揮する別種の管理者です。ただし、その機械は世の中に放たれ、プログラマーがずっと監視するわけではありません。
もちろん、ほかのコメントのように、この概念が完全な戯言である可能性もあります。ただ、数年後にこれが愚かな考えだったと気づくとしても、一人で恥ずかしい思いをするより、一緒に恥ずかしくなってくれる誰かがいるほうがまだましです。
約10年前、機械工学者の友人たち数人が、私がソフトウェア開発を学んでいるのを見て驚いていました。
「まだやることがたくさん残っているのか？ 必要なことは既存のシステムで全部できるんじゃないのか？」といったことを言っていました。
誤解は、新しい問題を解決するシステムを作ることは簡単で、すでにコモディティ化されているので、もはやコードを書く必要はない、という考えです。
現実には、ソフトウェア構築がUIの設定ほど簡単なことはまれです。論理ルールとフローを表現するテキストが必要で、システム変更を追跡しロールバックするためのバージョン管理が必要で、結局プログラマーが必要になります。
コーディングはなくならず、抽象化レベルが上がるだけです。
テック業界は長い間、開発者をコモディティ化しようとしてきましたし、COBOLやJavaもその流れの中にあったと思います。
しかし、何を抽象化しても再び現れてくる本質的な性質があります。要件が単純に見え、高水準フレームワークがあっても、私たちのソフトウェアの多くはいまだにきちんと動きません。
書き手の言う通り、本当の解決策は、能力があり、気を配る開発者です。それでキャリアを築くことができます。
同じ分野で長く働いてみると、パターンは似たように繰り返されますが、それぞれのビジネス要件は少しずつ異なります。スタックの各階層ごとにこの違いは大きくなり、全体としては非コモディティ的でカスタムな仕事がものすごく多くなります。
だから2つの製品が正確に同じになることはなく、すべてを生産する単一の巨大なグローバル企業だけが存在するわけでもないのです。
自分自身をテイラー主義的に細分化する形の自己コモディティ化の機会が来ると、開発者たちが浮き立つ姿を数え切れないほど見てきました。
医療業界は、自動コモディティ化の議論が出たときに私が挙げる反例です。感情面で2つの訴求力があります。患者は医師をあちこち移されるのを嫌がります。コモディティ化にはある程度の専門化の増加が伴い、引き継ぎが1つ増えるたびに失敗点も1つ増えることを理解しています。
2つ目は、地位と働き方をより高い地位のように見せられる点です。1つ目を前面に出し、2つ目はサブテキストとして読ませるようにすると、たいていうまくいきます。労働者はより一般化された能力を維持し、引き継ぎよりも互いに相談するやり方に頼るようになります。
組立ラインは順序が決まった専門化であり、医療研修医の勤務時間に関する引き継ぎミスを見ればよいのです。
運用、イノベーション、保守。この3つのうち、好きな3つを選べばよいのです。
同じチームが担当するか、互いに非常に近いチームが担当するほうが望ましいです。
理想的には、チームの各メンバーが3つの機能すべてを程度の差はあれ担うべきです。改善の着想はそこから生まれるからです。
この3つの機能を3つのグループと3つの管理階層に分けることもできますが、結果はたいてい平凡で、人々は不幸になります。特に保守チームに閉じ込められた人たちは、感謝されないものの中核的な仕事をしています。
チームに3つの機能すべての責任を持たせることもできますが、特定の1つに過剰適合した管理者を選ぶことがよくあります。偶然にも、その1つは次の四半期により良い報酬につながる機能です。
1つの文化の中で、運用の卓越性、誠実な保守、そして深く考える時間を同時に支持するのは難しいことです。難しくて当然です。
ビジネスインテリジェンス／アナリストの役割を見ると、業界は SQL を使う人を Tableau のようなツールを使う人で置き換えようとしている
「どんなデータストアにでも接続すれば、非技術系の人材がドラッグ＆ドロップでできる」という具合だ
問題はいくつかある。第一に、出力が線形にしか増えないため、より多くの低賃金人材を雇わなければならない点を忘れている。すべて UI ベースの作業なので、人が手でクランクを回さなければならない
第二に、非常に複雑で整理されていないビジネスロジックの変換コードが依然として生まれるが、今度はそれが UI の中に埋もれる。そのロジックが何なのかを知っているのは PM やビジネスチームだけだ
エンジニアリング組織は、ビジネス上の問いに答えるための、かなりプリミティブで高品質にテストされたデータセットを提供している。難しい部分は、ソースデータから妙な方法でビジネス上の成果物を得る問題を解くことだった
いまやその解法は Tableau ワークブックに保存され、別の入力として使うことはできない。新しい Tableau ワークブックに UI 上でコピー＆ペーストしなければならない
Tableau のクラウドサービスを買ったのだから、BI チームが SQL 抽出をより厳格に作り、保守することはできる。Tableau は Databricks の事業の一部を取りにいこうとしているように見えるが、今ではその仕事を非エンジニアリングチームがやっている。うまくいくかどうかは分からない
たとえば「われわれのユーザーはどの国の出身か？」という典型的な質問がある。登録フォームに書いた国のことなのか、現在サービスにアクセスしている国なのか、決済手段の国なのか、生まれた国なのか、市民権の国なのか、現在の居住国なのか、配送先なのか、請求先なのかはすべて違う
データセットが十分に大きければ、それぞれ異なる答えになる。「グローバルフィンテック」の領域では、こうした奇妙なケースが普通になるだろう
典型的な低賃金の Tableau ユーザーは、見えている国コードを見つけて count を回し、それを真実だと宣言する可能性が高い
もう少し賢い Tableau ユーザーなら、エンジニアに SQL を書いてほしいと頼むだろう
データセットとソースシステムを知る人がいてこそ、ビジネス側に問い返し、適切な質問と文脈を強制できる
Tableau 系のツールは、毎日同じ SQL クエリを pgAdmin に貼り付けて CSV をメールで送るような「技術作業」を置き換えるにはよいが、UI 中心の低スキル作業者によりよく考えさせることはできない
コストに対するアウトプットの線形スケールはスプレッドシートでモデル化でき、顧客に転嫁したり請求したりできる。ビジネス層の誰もがこうした力学に安心感を覚える
一方で、専任の専門家が少ない労力で 1000 倍のアウトプットを生み出せるものの、それが 1 日で済むのか 1 週間かかるのか確信できない状況は、全員を不確実にし、リーダーを不安にさせる。誰もが心地よい凡庸さを望むなら、売り込むのは難しい
2 番は皮肉にも、より多くの専門家、ただし別種の専門家を必要とする。そのすべてのロジックを維持しなければならないからだ
結局は雇用創出プログラムのように機能し、より高くつくだろうが、政治的に影響力のある領地に比例して価値を配分するので、成功するだろう
まずバックエンドの人たちはビジネスを知らないとして全員解雇し、Tableau を新しいバックエンドにする。バックエンドの人たちがビジネス要件を吸収し、磨き込んできた事実は無視される
その後、ビジネス側の人たちが自分たちの作っためちゃくちゃなクモの巣に絡め取られると、Tableau コンサルタントを呼ぶ。彼らは金を吸い上げながら、価値あるものは何も作らない
構造工学の出身だが、ソフトウェアは他の工学分野というより都市計画に近いように見える
あまりにも広大だ。時間がたつにつれ、バックエンド、フロントエンド、ファームウェア、機械学習エンジニア、データサイエンティスト、セキュリティアナリスト、カーネル開発者のように、特定の作業タイプを表すさまざまな職種が増えていくのは驚くことではない
標準が発展すれば、ある時点でこうした職に就くには非常に具体的な認証が必要になるかもしれないと思う。別の形に変わる可能性もあるが、結晶化の効果ははっきり見える
ソフトウェアを工場と考えることも可能だし、有用な場合もある。だが、すべてがその比喩に当てはまるわけではない。たとえば製品統合を考える場合や、アプリではなくサービスである場合がそうだ
工場という言葉には何かが作られるという含意があるが、多くの場合、ソフトウェアは最終成果物ではなく、それ自体が可能にする手段である
ソフトウェアでは、ほとんどの仕事が漸近的に自動化されてきた。だから、その仕事がかつて労働だったという事実を忘れてしまう
素朴なファイルコピーを考えればよい。いわば「自動写字生」だ
コピーは、われわれのシステムが実行する膨大な量のコピーが見えなくなるほど自動化され、経済的な差別化ポイントとしても消えた
しかもメタ的にも有用だ。コピープログラム自体も同じアルゴリズムで簡単にコピーされる
要点は、ソフトウェアを書くことは数学と同じように、常に既知のものと未知のものの境界で時間を過ごすことになる、ということだ。完全に知られ、特性づけられた領域は、皆のために問題を解決すると同時に、その活動の経済的な土壌を焼き尽くす形で自動化されるからだ
ソフトウェア業務には、どの領域であれ未知の領域へ入って富を探す探検、つまり研究の要素が常に含まれる。その新しい領域が輝かしいものであれ、悲劇的なほど平凡なものであれ同じだ
ソフトウェアの専門性を持たない管理者が自動化できる領域は、簡単に果実を採れるよう飼いならされた果樹のようなものだ。だが、そうした木にはもはや果実はない
その管理者の問題定義が、面倒な創造性と専門性を再び必要とする、自動化しにくい領域へと上がっていかないなら、もはや差別化された価値ある仕事をしているとは言えない