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