はじめに
巷では「メテオフォール型開発」という小粋なワードが流行っているそうですね。
幸いなことに、私が担当している現案件では役員各位の配慮により円満な開発体制を維持できているわけですが、かつては「神よッ…何故そのようなお戯れをなさるのですか…？！」と血涙が零れた案件もあったとかなかったとか。（辛いことがあると人は記憶が曖昧になるといいます…）
今回は、そんな当時の私が状況改善の為に意識していた方法論をまとめてみました。
題して「エンジニアらしく組織を変える為のプログラミング・マネジメント」です！
例えばこんな問題があるじゃろ
ひとまず適当にメテオフォール型開発で起こりがちな問題を列挙してみましょう。
- 現場で判断すべき問題に偉い人が口を出してマネジメントが壊れる
- 自己中な現場社員が自己都合に基づいた情報を偉い人に流して騒動が巻き起こる
- 偉い人の風化した知識が現場に混入して開発品質が劣化する 等々...
まー、日本企業ではよく観察されるパターンすね。
この手の状況が発生した場合、責任感強めな人々は「こんなやりかｔでは案ｋんが回んないっすお！！１1」と発狂して訴えるパターンが少なくありませんが、残念ながら悲しくなるほど効果ないです。大抵の場合、触るもの皆傷つけるナイフみたいな扱いを受けて孤立します。 ウッ 頭が…（錯乱）
話を元に戻しましょう。要は「構造」ですよ「構造」。
物事の帳尻が狂ってる時は、必ずどこかで「組織の構造」が歪んでいます。
問題は「どうやって歪んだ構造を見つけ出せばよいのか」ですが…
数多のスパゲティ・コードと戦ってきたエンジニアの皆さんなら、既に方法をご存じのはず。
構造上の問題と戦いたいなら、「プログラミング原則」を使えばいいじゃない！
「プログラミング原則」で組織の問題を炙り出す
考え方はとてもシンプルです。「似てる」レベルでオッケーなので、状況に対してそれっぽいプログラミング原則を当て嵌めてみましょう。今回の事例の場合、次のような概念が「ぽい」感じですね。（あくまで「似てる」だけなのでマサカらないでね）
- 各役職が自身の「役割」から逸脱した行動を取っている → 「単一責任の原則」
- 各役職の意思決定が他層の情報に強く依存している → 「依存性逆転の法則」や「モジュール結合度」
- 経営層がマネージャーの頭を跨いでしまっている → 「デメテルの法則」etc...
どうやら「役職の責務」がボヤけてしまっている点、「結合度が強すぎる」点に根本的な原因がありそうです。このあたりに焦点を絞り、「プログラミング的手法」を通じて組織構造をリファクタリングしていきましょう。
「役職の責務」をはっきりさせる
ピラミッド型組織を「プロジェクト」という概念を中心に据えて整理してみましょう。非常に単純化したモデルですが、組織を「経営層」「プロジェクトマネージャー層」「プレイヤー層」の三層に分けると、おおよそ次のような役割が見えてきます。
■経営層
- 企業が掲げる「ミッション」の実現
- 「ミッション」実現に必要と見なされた複数プロジェクトの横断的コントロール
■プロジェクト・マネージャー層
- 経営層の承認を得た「プロジェクト」の完遂
- プロジェクトに含まれるタスクやプレイヤーの横断的コントロール
■プレイヤー層
- プロジェクトの完遂に必要なタスク対応
例えば、「エンジニアを最高に幸せにする」というミッションを掲げる企業「Ｉ社2」を考えてみましょう。上記役割を適用した場合、Ｉ社は次のような組織的構造を持つことになります。3
組織構造の例
- 経営層の責務： ミッションに必要な「技術情報投稿サイト構築プロジェクト」の立ち上げ
- プロマネ層の責務： 経営層が立ち上げた「プロジェクト」のマネジメント
- プレイヤー層の責務：「投稿機能を作る」等、「プロジェクト」に必要なタスク処理
最初に述べたとおり非常に単純化されたモデルではありますが、
- 各層は直下のレイヤーに対して何らかの管理責任を行う
- それぞれのレイヤー毎に得意な業務領域が存在する
という特徴が見えてきたかと思います。
各役職の「モジュール結合度」を下げる
現在の組織構造をテキトーな図にしてみました。各役職が直接関係性を持っている、いわゆる「密結合」の状態が見て取れます。先述した「役割」を意識しつつ、コイツをどうにか「疎結合」の状態に持って行きたい…。
プログラミングでこのような構造に遭遇した場合、大抵は密結合しているモジュール間に「Interface（契約）」や「抽象度の高いクラス」を噛ましてどうにかします。いわゆるレイヤード・アーキテクチャなんかでよく見られるパターンですね。
問題は「依存関係の切り離しに何を使うべきか？」という点です。これはもう「なんかちょうどいいの使って」という感じもあるのですが、どんな組織でも「定例ミーティング」は手頃感が出やすくてオススメです。ミーティングの開催を拒否する組織なんてほとんど存在しないし、「決めごと」として権威を持たせやすい点がポイント高い…。既に行われてるなら、「場」を再利用するのもアリです。
ちょうどミーティングのアジェンダがプロジェクトの「プロパティ」や「メソッド」として公開されていて、経営層はそれらに依存するイメージです。図にするとこんな感じでしょうか。
ここでひとつ注意点を！この施策はあくまで「ミーティングを使って層同士のコミュニケーションを限定する」という状況作りにこそ意味があります。定例ミーティングの開催自体は目的ではないので、無意味なミーティングを重ねても効果がない点にはご注意ください。（「ミーティングで全部解決するなら苦労しないよ！」と思った方、少なくないのでは？）
ひとまずこれで最低限の体裁は整いましたが、まだまだ改善の余地はあります。余力が出てきたら、さらに結合度を落としていきましょう。Interface（決めごと）の代用として「標準化ルール」を策定し、層の間に噛ましてよりレイヤード・アーキテクチャっぽく仕上げていきます。
ついでなんで、マネージャーとプレイヤー間の結合度も下げちゃいました。
ここまで整えれば、各個人が他層の余計なちょっかいに悩まされることはなく、自分の責務だけをしっかり見つめて作業ができるようになります。ついでに「依存性逆転の法則」も実現されるので、標準化ルールを通じて各役職が交換可能となり、人事もスムーズに…！
ただし、あまりにも役職の部品化が進むと大企業病的なパターンにも陥りやすいです。アジャイル的な組織改善の仕組みも同時に構築できると最高ですね！
おしまい！
最後に要点をまとめてみましょう！
- プログラミング原則を組織に当て嵌めると構造的問題を見つけやすいぞ！
- 「メテオフォール型開発」には「責務」と「結合度」を意識すると対処しやすいぞ！
- 結合度を落とすと大企業病が発生しやすいぞ！ カイゼン文化を定着させよう！
「エンジニアはマネジメントが苦手」なんて評価を受けやすいですが、「こういう発想ならイケる！」という方も少なくないのでは？
この記事を読んだ皆さんのプロジェクトが少しでも健やかになれば幸いです！
おまけ
今回紹介したような形態のプロジェクトには、以前私が書いた下記記事の管理手法がそこはかとなくフィットします。手前味噌ですが、よろしければご参考まで。
禁忌
この手法は「経営層との敵対」が主目的ではありません。あくまで大事なのは「組織的健全性の確保」です。邪魔がいない状況を利用して好き勝手に振る舞うような真似だけは絶対にやめましょう。
「は？ そんなの知らねーし。俺は俺の好きなようにやるぜ」と悪ぶるのもいいですが、最悪の場合、メテオフォールのマジなヤツが発生してプロジェクトが無に帰します。
神は、どこまでいっても神なのだ…。
