会社組織の構成を読み解く - アーキテクチャ
北海道の蘭越（らんこし）町で見つけたダンゴムシです（虫嫌いの方すいません） 。いままでワラジムシしか見たことがなかったので、北海道にダンゴムシはいないものだと思い込んでいました。遠い昔、まん丸いところが憧れの虫でした。あのころに会いたかった……。もう触りたくもないですもんね……手の上に乗せているけど。
前回、企業理念の「設計方針を理解しているか」と「正しく実装されているか」を分けて質問していたのには、理由があります。
企業理念というインターフェイスを設計したのは「経営者」、そのインターフェイスを実装しているのは「各社員」という認識をまず持って欲しかったのです。
ですので、バグがある場合は以下の3パターンが考えられます。
※企業理念レベルのバグ＝組織体として各社員がポリモーフィズムを満たしていない状態です。
- 設計がされていない
- 設計に誤りがある・適当ではない
- 設計方針を理解せず間違った実装を行っている・実装していない
企業理念というインターフェイスは、ほとんど実装すべき内容はない（会社を一言で説明するメソッドくらい）ので、1か3の可能性が濃厚です。
1の場合（もしくは2の場合）は、周りを巻き込みながら、仕事内容からインターフェイスを抽出しましょう。
3の場合は……まずヒアリングを行って実装してみてください（笑）。ほかのインターフェイスに隠れていて、オーバーライドが漏れている場合もあります。
Javaなどの開発においても、「目の前に便利なコレクションフレームワークがあるから使う……」というだけではなく、設計意図を読み解く習慣をつけた方が、より「正しい実装」ができるようになると思います。
今回以降は、もう少しブレークダウンして、アーキテクチャやフレームワークといった「基本設計フェイズ」について触れていきます。
●会社のアーキテクチャ
前回、会社を「社会のニーズを満たすアプリケーション群」と見なしましたが、会社にとって1つひとつのアプリケーションは「何」にあたるでしょう。
生産部門や非生産部門がありますが、「部」や「課」といった「部署」じゃないでしょうか。
組織図って、機能概要図と意味合いが似ていませんか？
組織においても、階層ごとにインターフェイスが定義・実装されていなければなりません。各部署の存在理由や果たさなければならない使命など、企業理念を実装もしくは継承している場合もあります。
設計者は「部署長」、実装者は「各社員」です。
※ワンマン社長の場合は、部署長がいても設計者をやっていることが多いです。
今回は部署の話がメイン（……というか前回の続きがメイン）でしたが、チームといった階層までインターフェイスは定義・実装されるのが理想です。
次回は、インターフェイスの明文化や職務権限関連で、最も問題が多そうな「フレームワーク」を予定しています。