なぜ「エンジニアリング組織」は「エンジニアの組織」だけを考えてはいけないか
「エンジニアリング組織論への招待」という本がありますが、この「エンジニアリング組織」とは「技術を使って課題解決をする組織」のことです。
決して「エンジニア」と「エンジニア以外」で組織論を分けて語るべきではありません。
サービス開発技術の進化
10〜20年前は、30人とか50人とかのチームで一つのウェブサービスを開発していました。大規模開発という言葉がぴったり当てはまる時代でした。
そういう開発スタイルだと、課題解決のためにはまず課題を定義し、エンジニアチームに依頼して、開発されて完成品が出てくる、というやり方でやらざるを得ませんでした。
その反動が2001年のアジャイルソフトウェア開発宣言です。アジャイル開発では、チームで必ず毎週（毎イテレーション）仮説検証をすることを義務としています。
毎週仮説検証をするためには、チーム間のやりとりなどは無駄でしかありません。自分のチームで1日でできることでも、隣のチームに頼むだけで1週間待たされてしまいます。チームの人数をどんどん小さくして、1言えば10伝わるチームで最速で課題解決に向かうほうがよっぽど仮説検証サイクルが速く回ります。
今では3人のスタートアップが毎週仮説検証を繰り返すことができるぐらいにウェブサービス開発のフレームワークやツールが充実しています。
課題解決できるチーム
そんな現代のソフトウェア開発においては、「エンジニアを何人揃えるか」などよりも、「本質的な課題解決ができる組織作り」のほうがよっぽど大事なことです。
例えばCSとエンジニアを別々のチームにしてしまうと、CSの課題はエンジニアからは他人ごとになってしまい、なかなか解決されず、CSの手間がどんどん増えることになります。そうなるとCSを増やすことになり、より一層他人ごとになっていきます。
では少人数チームを作れば良いかというと、それだけではまだ不十分です。単に同じチームになっただけで、一緒に課題解決をするチームだと思っていなければ意味がありません。CSがエンジニアリングを覚えてエンジニアがCSの手伝いをしたほうが課題解決に繋がることもあります。
課題解決に向かうチームに「あちらさん」の関係を作ってはいけないのです。
組織全体で最も本質的な課題解決をする
そもそも今はGoogle Apps Scriptなど、（いままでの）エンジニアからすればオモチャみたいなツールが出てきていて、CSの課題解決はそういうものでも十分だったりするかもしれません。もっというなら、遅かれ早かれGUIでポチポチしながらウェブサービスを作る時代も来るはずです。
そんな時代にエンジニアだけがコードを書いて、エンジニア以外はコードを書かないなどという考え方は通用しません。全員でこのテクノロジー時代を進んでいるのです。
会社というのは、テクノロジーなどの社会基盤の上にサービスを作り、全員で市場の課題を解決するのがミッションの組織です。
この図のどこにどういうチームを作れば最速で課題が解決できるか、それこそが「エンジニアリング組織」の設計なのです。
「エンジニア」と「エンジニア以外」に分けて「エンジニア」だけの組織を設計することはもう時代遅れになっています。
