スクラムの原典を読み解く(6)
オリジナルの竹内・野中論文を読んで現代のスクラム（ソフトウェア開発）と比較しています。
柔らかなマネジメント(subtle management)
オリジナルでは...
スクラムチームは自律的に運営されてはいるが、全くマネジメントがない訳ではない。マネジメントの役割は、不安定さと曖昧さが混沌に陥らないよう、微妙なラインで管理する。ただし、創造性と自主性の芽を摘んでしまうよな、硬直化した管理を行ってはならない。「自己マネジメント」、「相互マネジメント」、そして「愛情によるマネジメント」の３つを総称して「柔らかなマネジメント」と呼ぶ。
新製品開発の中での柔らかなマネジメントには、７つのポイントがある。
- 正しいメンバーを選ぶ。そして、プロジェクト途中でもグループダイナミクスを観察し、必要であればメンバーを入れ替える。
- 専門を超えて対話が起こるような、オープンな仕事環境を作る。
- 顧客やディーラーがどんな意見を持っているか、エンジニア自身がフィールドに出て行きって聞くように仕向ける。
- 人事評価、報酬制度を、個人ではなくグループ評価を基本とする。
- 開発が進行していく中で、リズムの違いをマネジメントする。
- 失敗を自然なこととして受け入れる。「失敗はあたりまえ。鍵は、早期に間違いを見つけ、すぐに修正すること」（ブラザー）、「成功よりも失敗からの方が学べることが多い。ただし失敗するときには、創造的に失敗すること。」（3M）。
- サプライヤにも対しても、自己組織化を促す。設計の早いタイミングから参加してもらうのがよいだろう。サプライヤに細かな作業を指示してはいけない。課題を提示してどのように解決するかは任せる。
アジャイル開発では
スクラムチームには、「プロジェクトマネジャ」は存在しない。しいて言えば「スクラムマスター」がその立場になるが、トップダウンで意思決定したり、指示命令をしたりはせず、協調型のリーダーシップを取る。特に、2.のオープンな仕事環境づくり、5.リズムのマネジメント、などが仕事となるだろう。
しかし、他の部分についてはアジャイル開発の外側の問題として、従来のマネジメントとの接合部分となり、現在でも議論が多く交わされている。中では、3.のフィールドへ出かける姿勢、6.の失敗に対する考え方は、アジャイルの価値観や原則の中で言及されている。
また、4.の評価制度や、1.の人の選択、さらに7.のサプライヤ（ソフトウェア開発では協力会社やベンダー）の扱いなどに関しては、現実のプロジェクトでは常に発生する課題である。ジム・ハイスミスの『アジャイル・プロジェクトマネジメント』や、メアリ・ポペンディークの『リーンソフトウェア開発』の中にそれらに関する議論がある。
第５回でも述べたが、ここに書かれている4, 7の部分はアジャイル開発の「外側」とみなされることが多く、アジャイル開発に（当然ながら）抜け落ちている部分である。しかし、企業活動としてのソフトウェア開発を考えるときに、埋めていかなければならない部分でもある。
この辺りから日本の考えが出て、ソフトウェア開発と結ぶこと、をやりたい。「愛情によるマネジメント(control by love)」もなんとなく分かるが、具体的には述べられていない。