プログラマの思索

最近、いろんな記事を読みながら、アジャイル開発を推し進めると、アジャイルだけでは解決できない問題がどうしても残り、その問題を解決するには政治力が必要になってくるような気がしてきた。
ラフなメモ書き。

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

多分、チケット駆動開発は右寄りのツール寄り。
プログラマ出身で、プログラムにこだわりがある人は右寄りだろう。

逆に、プログラミングから離れて、マネジメント職に就き始めれば、自然に左寄りになる。
プロジェクトリーダーにもなれば、メンバーに的確な指示を出してチームを回す役割を周囲から期待されている。
100人月規模のプロジェクトになれば、プロジェクトマネージャとして、複数人のプロジェクトリーダーに的確な報告と指示を出しながら、プロジェクト全体をコントロールする役割を期待されている。

そうなれば、ツールの運用のような役割は、それだけの技術力を持つ専門的な人を社内でアサインするか、社内にいなければ外部から連れてくるというように外部リソースに預けたりする。
つまり、信頼関係を元に人を動かす能力だけでなく、手元に役割を果たせる人がいなければ、外部から的確な人物を調達する能力も必要とされてくる。
それはまさに組織を動かす能力があるか否かにつながる。

プロジェクトファシリテーションはIT企業の中間管理職研修みたいだ: プログラマの思索にも書いたけれど、プロジェクトファシリテーションのようなチームビルディング技術は、SIの中堅リーダーに最も必要とされる技術の一つだろう。
つまり、中堅リーダーがチームを任された時、チームとしてアウトプットを出しながら、プロジェクトを無事に終了させるために、メンバーの力を発揮させる技術の一つとしてとても有用だからだ。

何故、プロジェクトファシリテーションのような人心操作術がSIの中堅リーダーに必要とされるのか？
何故ファシリテーションが流行しているのか？: プログラマの思索にも書いたけれど、専門性を持った技術者が集まったチームには、中堅リーダーがその役割を代替できない高い専門性を必要とした技術者を必要とするために、中堅リーダーが権力を誇示してもチーム運営することが難しいからだ。

結局、自分よりも専門的技術を持ったメンバーに期待する役割と本来の能力を発揮してもらうために、チームビルディングの技術を必要とするのだろうと思う。
特に、ソフトウェア開発では、パソコンの前に座って黙って仕事する時間が長いために、コミュニケーションを取る時間が他業界よりもとても少ない。
だからこそ、IT業界では他業界よりも、人中心、コミュニケーション重視が声高に言われるのだろうと思う。

【2】プロマネの悩みは誰が解決すべきか : タイム・コンサルタントの日誌から

プログラム・マネジメントは本当にプロジェクト・マネジメントの上位概念なのか : タイム・コンサルタントの日誌から

現代のソフトウェア開発では、スコープ・コスト・納期が固定された請負案件が多く、厳しい制約の中でリソースをうまく切り盛りしながらプロジェクト運営する役割を期待されている。
だが、プロマネが自由に裁量できる範囲は年々狭まっているのが現状だろう。

上記の記事では、そんなプロマネの悩みを解決するには、リーダーシップの強化よりも、プロマネを取り巻く環境をコントロールできる人こそが解決できる。つまり、プロジェクトマネジメントのレベルではなく、プロジェクトマネジメントよりも上位の概念であるプログラムマネジメントのレベルでなければ、プロマネの悩みを解決することはできないだろう、と言っていると理解している。

プログラマにコミュニケーションが足りないと言われる時: プログラマの思索に書いたけれども、プロジェクトリーダーの手ではもはやプロジェクトが手に負えなくなる状況になった時、プロジェクトオーナー(上司)やプロダクトオーナー(顧客)に調整してもらうしかないが、その時は非常に高度な政治力を必要とする。
その意味は、自分よりも上位の権限を持つ人に、自分の要求を承認してもらって状況を改善してもらえるように働きかける必要があるからだ。

特にウォーターフォール型開発ならば、そういう政治力が持っているか否かでプロジェクトの成否が決まる時もある。

【3】スクラム導入で開発を取り巻く矛盾はなくなるのか？ - Yasuo's Notebook

Ceron.jp - スクラム導入で開発を取り巻く矛盾はなくなるのか？ - Yasuo's Notebook

Twitter / akipii: スクラムは、組織に対して変革や改善を継続的に続けるためのプレッシャーを与えることで「組織的な阻害要因」に直面し続ける、という文言を連想させる。 スクラム導入で開発を取り巻く矛盾はなくなるのか？ - Yasuo's Notebook http://yasuo.hatenablog.com/entry/2012/07/21/102721 …

「アジャイル開発の本質とスケールアップ」でスクラムを解説している章があり、そこには「スクラムは、組織に対して変革や改善を継続的に続けるためのプレッシャーを与えることで「組織的な阻害要因」に直面し続ける」という言葉があり、いつも気になっていた。

スクラム導入で開発を取り巻く矛盾はなくなるのか？ - Yasuo's Notebookを読んでその意味は何となく理解できた。
スクラム導入で製品に、品質や納期の矛盾を取り込まないように開発するようになると、開発チームに存在していた矛盾(実際はエントロピーのイメージ)が開発チームの外側に移動し、最終的には組織と開発チームの間で緊張を引き起こすようになるという指摘。
多分、ソフトウェア開発の矛盾(エントロピー)はどこかで捨てなければならないけれど、それを製品に押し付けるか、開発チームの枠外に押しやるか、という選択があり、後者の方法を突き進めれば、組織に蓄えられた矛盾(エントロピー)を包容できなくなったら、組織と緊張関係に陥るのだろう。

そういう状況になれば、組織自身を変えなければ、せっかく開発チームが改善してきた成果が組織の圧力で消されてしまうだろう。
もし組織自身を変えるようにするならば、組織を変える政治力がチームリーダー(おそらくスクラムマスタ)に必要とされるだろう。

そうなれば、もはやプログラミング力や技術力、人中心でコミュニケーション中心といった綺麗事では問題解決できないレベルまで行き着くだろう。
そうすれば、最終的には、権力だろうが権威だろうが、信頼関係だろうが、いずれかに基づいて、他人を動かし、組織を動かす能力を持っていなければ、自分の周囲を変えることすらできないのではないか。

色々考えてみる。

【追記】
とても印象に残ったつぶやきがあったのでメモしておく。
違和感を感じながら仕事している人は多いのだなと思っている。

Twitter / tech_machii: 私は30代にこれで体を壊した．なのでもう二度とやりたくない．それに私は本来，アジャイルの右翼だ．それがいま，左翼ポジションで精神的苦痛を味わっている． アジャイル開発を推し進めると組織を動かす政治力が必要になってくる http://bit.ly/UpmiYi