述べられていたので、少し考えてみた。組織論は、組織をエンジニアリングする、と考えることができる。いうことが述べられていた。これについては確かにその通りであるなと思う。今回はその点について少し考えてみる。自分はWebエンジニアなので、作るモノとしてはWebサービスがほとんどだが、組織自体がこれに相当するかと思う。組織の構成員サーバー、つまりサービスを稼動するベースとなるのは組織の構成員だ。組織の構成員サービスのユーザーは組織の構成員になる。マニュアル、社内wiki、暗黙知、制度、ビジョン動作を規定するのがソースコードなので、対応するのはマニュアルや社内wikiなどになる。明文化されていないところでもこの場合は上司に相談するほうがいい、などの暗黙知や文化的なものもある。会社のミッションやビジョンもここにあたるかもしれない。上のように対応させて見ることで得られる発想として、例えば以下のようなものがあると思う。要件定義エンジニアリングで考えると、ソースコードに落とし込んでいく前に、まず「なぜ必要なのか?」「何が必要なのか?」を詰める、いわゆる要件定義のフェーズが入ると思う。その目的によってはソースコードを追加して解決するべきではない、という判断をするかもしれない。これを組織に適用すると、組織の構成員がなぜそれを必要としているのか?を考える必要があるということだ。新しい会議の導入が希望されている際、なぜその会議が必要なのか?会議以外の代替手段がないか?を考える必要がある、ということだ。インフラの冗長構成サーバーにあたる人(組織の構成員)は、サービス(組織)の可用性を担保するため、冗長構成をとるほうがよさそうに思える。人の冗長化とはつまりその組織におけるその人の提供価値を冗長化する、ということだ(人を分身させることではない)。あるXさんがA社の案件を一人で対応していると、そのXさんが倒れるとサービス(組織)自体がとまってしまう。実際は組織自体はとまらないものの、A社における組織の価値がなくなる、ということだ。対応としては、Xさんが対応していたA社の案件の対応に必要な知識、職能を明文化し、それに見合う人を採用するなり社内で異動するなりして冗長化する必要がある。同様にスケールアウトも必要かもしれない。A社からの発注が急激に増えたとき、1人だけではさばききれなくなる可能性がある。Descriptionを明記したほうがよい、ということを言っていた。これはとても同意で、例えば、上のXさんがA社に対応するために何をしていたか、XさんのA社対応スキルの内容がわかっていないと、どういう人が採用できれば冗長化が達成されたと言えるのかもわからない。本=外部ライブラリ本来「図書館」の意味をもつライブラリを本にたとえるのは変(むしろ当然?)なのだが、本など、外部から仕入れた知識は外部ライブラリのように扱うといいかもしれない。本に書いてある、いわゆるフレームワーク的な知識もエンジニアリング的に考えることができる。Webフレームワークを導入する際には、以下のようなメリット/デメリットがある。メリットフレームワークの対応できる範囲内においては、開発が簡単になる広く使われている、枯れている技術なら、成果が保証されているデメリットフレームワークの想定していない使い方をするのは大変これはWebフレームワークに限らず、本に書いてあるフレームワーク的な技法であればあてはまると思う。外部ライブラリ自体のアップデートをチェックしておかないと、古いライブラリを使っていて、実はそのバージョンは脆弱性が広く知られていた、ということになりかねない。エンジニアリングとして考えるメリット組織をエンジニアリングする、と捉えることにより、エンジニアとしては以下のメリットがある。仕事で使っている知識の延長線上で問題を捉えることができる単純に問題のスコープが狭くなるので考えやすい身近に感じられて、興味を持ちやすいエンジニアリングとして考えるデメリット当然、何かデメリットはあると思う。今、思いつくのは以下だ。ハンマーを持つ人にはすべてが釘に見える知ってることに置き換えることはやりやすいのでついつい過剰に置き換えてしまう人間は個々人違うことを見落としやすい(かもしれない)オブジェクト指向におけるクラスのインスタンスはいくつも同質のものを生成できるが、人間はそこまで同質ではないこともある。ある側面だけをうまく切り取れば同質にそろえられるかもしれないまとめ組織をエンジニアリングする、という考え方はとても興味深く、個人的にもあっているので、自社の組織設計などにも活かしていきたい。