アジャイルの左翼は開発者自身の能力向上を前提にしている

僕が尊敬する@yusuke_arclampさんが、アジャイルと組織論の関係について記載している記事を見つけたのでメモ。
ラフなメモ書き。

【元ネタ】
アジャイルって組織論ですよね（DevLOVE2012ご報告） - arclamp

アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：ITmedia オルタナティブ・ブログ

なんで全員にリーダーシップを求めるの？ - Chikirinの日記

【1】@yusuke_arclampさんがずっと講演で話されている「アーキテクチャとマネジメントのギャップ」については、僕自身も別の文脈で腑に落ちない部分を感じている。
現代は、@yusuke_arclampさんが言うように、技術革新が速すぎて理論が追いつかず、実証主義的にシステム開発のあるべき姿を追い求めようとしている時期なのかもしれない。

【2】アジャイルが組織論に行き着くという話に関連して、Scrumの自己組織化の発想は、プロマネがチームの全てを管理するのではなく、メンバー自身が自己管理した方が上手くいくというものだと思っている。
そのために、Scrumではメンバーに軍隊のような厳しい規律(ディシプリン)をメンバーに要求するし、その責任と采配をメンバーに預ける。

【3】似たような話として、なんで全員にリーダーシップを求めるの？ - Chikirinの日記では、何故アメリカでは特に個人にリーダーシップを求められるのか、という話がある。
リーダーシップを持って活動した経験がある人ならば、組織やチームにおいて、自分がどのように振る舞ってチームに貢献すればいいのか、という姿をイメージして自発的に行動できる。
リーダーシップを持つ人は、そもそも他人から指示待ちで動く必要もないのだ。
逆に、リーダーシップを持って活動するという経験のない人は、組織の中でわがままに振る舞うか、指示待ち人間になってしまう。
組織が今必要としていること、今の自分の能力提供できることについて、比較検討して行動していくことがイメージできないからだ。

【4】また、似たような話として、「フレームワークを使いこなすための50問」では、プロマネが忙しすぎて組織運営のボトルネックになったり、業務が専門化しすぎてプロマネが部下の仕事内容の全てを理解できなくなっている危険を解決するために、2つの方法を試した話がある。

ある企業では、業務内容を形式知化するために、マニュアル化を推進した。
マニュアルを中心にプロマネや新人がノウハウを共有できると思ったわけだ。
しかし、失敗したとのこと。
理由は、高度化・専門化していく業務のスピードにマニュアル整備が追いつかず、膨大なマニュアルが時代に合わなくなりがちで、結局使われなくなった、とのこと。
マニュアル改定が仕事になってしまい、本来の業務の効率化やノウハウ共有に至らなかったわけだ。

別の企業では、プロマネになる一歩手前の３～６年目の若手層に対し、プロジェクトマネージャ化を進める対策を実施した。
つまり、プロマネが各技術の専門家である部下の内容を理解するのではなく、部下がプロマネとして自分の進捗管理を行い、プロマネの意を汲み取って自発的に行動できる環境を整えたわけだ。
すると、この方法は成功した、とのこと。
理由は、部下自身でタスクの抜け漏れをチェックでき、妥当な工数見積を自分自身で行い、作業を制御できるようになった。
更に、部下自身で各タスクのゴールを明示でき、自身のリスクをマネージャに明確に提示できたため、マネージャは、リスクを自ら探してリスクの背景にある業務を理解する必要もなく、提示されたタスクとリスクで判断できるようになった、とのこと。

【5】いずれの話でも、メンバー自身がマネジメントスキルないしリーダーシップの能力を身に付ければ、管理者と作業者という関係ではなく、作業者自らが自分で判断して行動し、自分の能力や作業範囲を超えるリスクはマネージャに判断や指示を仰ぐという関係へ変化して、組織自身が活性化することを示している。
開発者自身のレベルをお互いに高め合うような環境が必要ではないか？

多分、アジャイルの左翼が本当に目指しているものは、そのような環境づくりではないかと思っている。