開発抽象化レイヤーを担う人

「開発抽象化レイヤー」という記事があった。
興味深いので感想を書いてみる。

※「Joel on Software」という本で翻訳されている。

【1】開発抽象化レイヤとは何か？

ビジネス用のプログラムを書くと言う仕事は、単に技術力があればOKというものではない。

「プログラマの作業しているレベル(たとえばEmacsの上)というのは、ビジネスを支えるためにはあまりに抽象化されている」というフレーズがあり興味を引いた。

つまり、開発者のコードを製品へと変えるプロセスが必要なのだ、と。
Joelは歌手の仕事を喩えに用いている。
いわく、ドリー・パートンは「素敵な歌を歌う」レイヤで仕事しているが、彼女も膨大な実装レイヤを必要としている。レコードの制作、コンサートホールの予約、チケット販売、オーディオ装置の設置、レコードのプロモーション、ロイヤリティの回収。

プログラマの日々の活動(設計し、コードを書き、コードをチェックインし、デバッグし、といったこと)がソフトウェア製品を作り、マーケットへと届けるのに必要なすべてだという幻想を作り出すことにある、と。

プログラマの活動を支えるプロセスとは、

・静かなオフィス環境や無制限のお菓子と清涼飲料水を揃える管理人
・ネットワークとサーバー、ソース管理とビルド環境を当たり前のように使わせてくれるシステム管理者
・プログラマが見つけられないバグを見つけてくれるテスタ
・画面をカッコよい見栄えにしてくれるグラフィックデザイナ
・人々が製品を欲しくさせるマーケティングチーム
・人々が製品を確かに手に入れられるようにするセールスのチーム
・顧客が製品を使えるように助け、プログラマにはサポートへの電話の原因となっている問題を伝える忍耐強い聖者のようなテクニカルサポート

などが必要なのだ、と。
プログラマ1人に付き、7人ものサポート担当者が必要なのだ、と。

つまり、プログラミングをビジネスにする時、開発部隊と営業部隊だけでなく、運用保守部隊やデザイナ部隊、コンサル部隊などが必要で、それらがループになるようなプロセスになっていることが大事だ、と。

人月ビジネスの小さな会社では、このループ構造やプログラマをサポートする体制がそもそもない。
会社のネットワーク管理者はコストセンターだし、オフィスの環境を整えてくれる経理の女性もコストセンター。
そういう所までお金を回す余裕が無い。
だから、いつまで経っても、人材派遣ビジネスから脱出できない。

【2】ソフトウェアチームのプロジェクトリーダーの優先度第一の仕事は、開発抽象化レイヤを構築すること

プロジェクトリーダーの仕事は、プログラマの管理と思われているが、それだけではない。
むしろ、プログラマの生産性を高めるような環境作りが大切なのだ、と最近経験している。

「ソフトウェア企業の競争戦略」では、MSは、プログラマとテスターをペアで開発を進めている。
その利点は、プログラマがプログラミングそのものに注力できる環境にするために、テスターが品質チェックしたり、プログラマがやらない諸々の作業をサポートする点にある。

XPで初めてペアプロの概念が現れたが、その思想の原点はこういう所にあるのだと思う。

プロジェクトリーダーは小さな開発チームではビルド担当者になっていることが多い。
なぜなら、彼がシステムの品質の最終責任者だから、ビルドしたモジュールを自身で管理することが多くなる。
すると、彼の最優先の作業は、ソース管理とビルド環境の構築と運用ルールを決めることになる。

更に彼は、顧客と仕様を納期までに間に合うように調整したり、バグやトラブル対応も受け持つようになるだろう。

そのような役割をプロジェクトリーダーが受け持つようになると、プロジェクトリーダーが仕様を決める人、プログラマがその仕様に従って開発する人、という風に自然に役割分担できるようになる。

ソフトウェアビジネスでは、優れたプログラマを支える環境作りがモノを言う。

ザ・ファシリテーター

「ザ・ファシリテーター」という本を読んだ。
メーカーの管理職の女性リョウが新組織のリーダーに着任する時、ファシリテーションを使って組織変革していくというストーリー。

TOCの「ザ・ゴール」に似ている。

内容が非常に興味深かったので、感想を書いてみる。

【1】ファシリテーションとは何なのか？

良く聞かれる質問に対する回答として「会議術の一つだ」というものがある。
だが、それだけではない。
「Facilletate」という言葉には、「助長する」「促進する」というニュアンスも含まれている。

僕は、メンバーの意見を引き出し、自ら聞いた後に、メンバーを動機付けたり、チーム内のコミュニケーションを活性化して、合意形成を導くものだと思う。

この本では、製品開発の知識が無い女性管理職リョウが、部下となる自分より年上の男性メンバーといかに素早く信頼関係を築き、課題を意識付けて、いかにリードするか、というプロセスでファシリテーションを意識的に使っている。

著者の考え方が随所にリョウの口から語られている。
いわく、ファシリテーションは日本人向きだ。協力して合意形成を重んじるので、ディベートで非難し合うのと違うから。
いわく、日本にもQC7つ道具のように昔からファシリテーションの道具を作っていた、と。

確かに、最近流行している理由は、ファシリテーションが内向きな日本人にフィットしている部分が大きいかもしれない。

ファシリテーションの役割を果たすための中心的人物がファシリテーターだ。
リョウは自らを都合ファシリテーターと呼んでいた。

理由は、自分はビジネスリーダーであり、メンバーをリードして結果を出すのが仕事。ファシリテーターは中立の立場にいないといけないのに、プロセスだけでなく、議論し、自らの意見も述べるから、と。

逆にディレクティブ・リーダーが、従来のリーダータイプとも言える。

日本では、集団の和を重んじるという性向があるため、ファシリタティブ・リーダーを好むという特徴もあるのだろう。

【2】会議術として使う

ファシリテーションを使う場としては、会議が多いだろう。

まず、リョウは赴任直後に、リーダーズ・インテグレーションを使った。
つまり、新任リーダーの性格や立場を部下に理解してもらうための質疑応答みたいなもの。
元々は、アメリカで入れ替わりの激しい管理職の導入に使うのが発端だったらしい。

この場面が面白くて、すぐに引き込まれた。
リョウの自己紹介後、リョウは一旦退出して、ファシリテーターの塩崎が会議を先導する。
外部から来た製品開発の経験も無い年下の30代女性リーダーに対する不信感を部室長から本音として引き出す。
その後、リョウが入ってきて、彼らの質問や不信感に対して、プライベートな話にも触れながら、彼らの不信感を解いていき、自らに課せられた責務を解決するための課題洗い出しに彼らの気持ちを引き入れていく。

話がすごくうまく行き過ぎのように思ったが、そこにはきちんとした心理学の理論的背景があった。
「ジョハリの窓」と「４つの懸念」の二つについて、理解するために整理しておく。

リョウは、ジョハリの窓で言えば、プライベートな話で自己開示し、部室長の不信感をフィードバックとして受け取った。
また、リョウは、リーダーズ・インテグレーションで部室長の受容懸念を言語化し、故意に対立を表面化させて、自分の意見を一貫した立場で回答することによって、信頼を築いた。

この2つの概念を意識的に使うかどうかは、確かにファシリテーションによる信頼関係構築の基盤みたいなものだと思う。

【ジョハリの窓】

ジョハリの窓とは、自分をどのように公開し、隠蔽するか、コミュニケーションにおける自己の公開とコミュニケーションの円滑な勧め方を考えるために提案されたモデル。

人のこころには以下のような4つの領域が存在する。

（１）｜（２）
―――――――
（３）｜（４）

（１）自分も他人も、よく知っている「公開された窓」
　→Open Self Window
（２）自分だけが知っていて、他人には知られていない「隠された窓」
　→Hidden Self Window
（３）自分では気づいていないけれど、他人には知られている「盲目の窓」
　→Blind Self Window
（４）自分も他人も知らない「未知の窓」　
　→Unknoun Self Window

フィードバック、自己開示で（２）と（３）を縮めていく。

【Ｊ．Ｒ．ギブの４つの懸念】
他人との関係を築くために、人は自身の心身を守るために防衛本能が働く。
その懸念が４つある。
その懸念が解消されていく過程は下記の通り。

受容→データの流動的表出→目標形成→統制

これらの過程を通じて、グループもメンバーも成長していく好循環が生まれるという構造になっている。

【3】ファシリテーションに論理的フレームワークは必須

リョウは、社長の目標に対する開発センターの課題を洗い出すために、色んなツールを駆使し、部室長のやる気を引き出していく。
この過程がすごく面白い。

リーダーズ・インテグレーション後、研修所で部室長たちとアクションプランを議論するリョウ。
当然、部室長たちは高すぎる目標に反発する。
でも、本音の議論ができていると感じて意に介さないリョウ。

そして、パレート図、ヒストグラムで会社の現状を説明し、SWOTを使って、会社の長所・短所・対策について話し合い、現実の認識を共有化させる。
SWOTで出てきた課題から、課題と期待のマトリックスにして、アクションプランを作るためのデータを揃えればよいという方向まで持ってくる。

更に、何故課題が解決できないのか、その理由をマインドマップに部室長に書かせるリョウ。
「～できない」ばかり書かれたマインドマップを3日も書かせた後、全てのカードを肯定形に変えて議論し直した。
すると、あら不思議、何を変えなければならないかというアイデアだけでなく行動指針までハッキリしてきた。

リョウはこれを「浮力の原理」と言った。
つまり、「発散→収束→決定」という流れを使って、問題を図式化し、見える化させて、皆のモチベーションを引き出したこと。

マインドマップを議論に使うときのやり方を初めて教わった気がした。

とまあ、他にも色んなツールが出てくるけれど、それらは論理的フレームワークそのもの。
つまり、問題を解決しようとしたり、課題を洗い出す時の論理の枠組みを個人の頭だけでなく、皆の認識方法として共有化させること。
メタ認識とも言える。

例えば、MBAではこういう論理思考ツールが紹介されているが、それらは、MBAを習得した人たちの共通の論理フレームワークでもあるので、MBAホルダーたちでは、ファシリテーションのモデリングツールを意識せずとも自然に論理的に議論できることも意味しているように思う。

IT業界では、UMLやDFDなど、システム分析やシステム設計でお互いの認識を共有し合うモデリング言語が既にある。
それらを一般化したものがファシリテーションのモデリング技術と言えるのかもしれない。

ファシリテーションはコミュニケーション活性化のスキルぐらいしか認識していなかったけれど、問題を図式化して課題を洗い出すプロセスにも使えるという点は非常に新鮮だった。

IT業界では、プロジェクトファシリテーションという概念で更に特化させている。
要注目です。

RedMineリンク

Webベースのプロジェクト管理ツールの筆頭は、Tracだろう。
しかし、最近は、RedMineが気になって仕方ない。

RedMineの最大の特徴は、ガントチャートやバーンダーンチャート、カレンダー機能が使いやすいこと。
気になったリンクを張っておく。

「プロジェクト管理ツールredMineをWindowsで使ってみる 」

「redMine が流行らないたったひとつの理由(vs trac) 」

「Railsで作られたプロジェクト管理ツール"redMine"」

「RedMine　Demo project」

でも、やっぱり、TRICHORDがいいかなあ？

JudeからRoRのWebアプリを作る

気になった記事をリンクしておく。

「Judeのクラス図からActiveScaffoldのコードを自動生成する」

うしおさんの記事で、興味深いのは、「こういう風に作ろうかな」と曖昧に書いたクラス図から、Webアプリが簡単に作れること。
RoRとActiveScaffoldのおかげで、かなり楽に作れる。

【再考】プロジェクトリーダーの仕事

「プロジェクトを成功させる 現場リーダーの「技術」 」を読んだ。
この本は、プロジェクトリーダーがプロジェクトファシリテーションをどのように使えばよいか、というヒントがたくさんある。
プロジェクトリーダーの仕事について、自分なりに考えたことを書いてみる。

【１】課題と問題の違い

　「課題と問題は違う」というフレーズがある。
　この本では、下記のように定義している。

a.問題・・・目的達成の障害となる現象。例：トラブルなど。
b.課題・・・目的を達成するために解決すべき事象。プロジェクトの仕事は課題と捉えうる。

　現場でプロジェクトが立ち止まってしまう時、その事象が問題なのか課題なのかを見極めることは重要だと思う。

　問題となる事象は、因果ループ図で言うと、悪循環の負のループに陥っている構造のこと。
　特に、トラブルが起きた時、応急処置で解決することも大事だが、根本的な原因は何かを探ることも大事。
　そうでなければ、同じようなトラブルが何度も繰り返される。
　この種の管理スキルは、リスク管理で捉えることが出来ると思う。

　課題となる現象は、この課題を解決すればチームが前進する、というポジティブな問題とも言い直せる。
　だから、プロジェクトリーダーは、課題を定義し、課題を解決するHowをイメージして、担当者をアサインできれば、後は、課題をトレースすればいいだけ。
　課題さえ定義できれば、後はHowを考えて、アクションを起こすだけにすぎない。
　この種のスキルは、PDCAサイクル。

　目的から課題がスムーズに導かれるのは良い傾向とも言える。
　つまり、ゴールから論理的に導ける課題があるということ。これは、チームメンバー全員で、ゴールも課題も共有しやすいことを意味している。
　ゴールツリー、ロジックツリーから自然に導けるはず。

　この時、課題を細分化した時、課題には、What課題とHow課題の2種類があると言う。

　What課題は、ロジックツリーの第1階層に当たる。　何を実現するのか、価値があるものは何か、という観点に相当する。
　How課題は、ロジックツリーの第2階層以降に当たる。どうやって実現するのか、と言う観点に相当する。

　課題管理をすると、課題の粒度や優先順位付けに迷ってしまう所にある。
　どの課題が最優先なのか、この課題を解決するにはどれだけのリソースが必要か、を考える時、課題を細分化しないといけないが、細分化しすぎて混乱する時もある。

　僕のイメージでは、顧客からの要求はWhat課題にまで落とし、担当者1人でアサインできる粒度までHow課題を落とす。
　そうすれば、複数のHow課題をまとめたら自然に一つのWhat課題(つまり要求)が実現できることになる。

【２】問題(課題)解決がプロジェクトリーダーの仕事

　プロジェクトの仕事は課題と捉えうることもできる。
　また、突然起きるトラブル解決も、プロジェクトリーダーが解決すべき仕事の一つでもあり、責任に含まれる。

　プロジェクトリーダーに要求される役割は、論理的フレームワーク(メタ認識)を使って、問題を図式化し、チームメンバーに共有させることだと思う。
　その時に必要なスキルは、問題を図式化するモデリング技術と、チームメンバーに説明し鼓舞するファシリテーション技術。
　
　自分がプロジェクトリーダーになってから、アクティビティ図を使って、作業フローを説明する時が多くなった。
　誰が何を担当するか、そして、自分の作業はチームのどこに位置するのか、をメンバーに説明し納得してもらうことはすごく大事。
　役割と責任範囲を明確にすると、メンバーは仕事しやすくなる。
　複数のメンバーの作業のインターフェイスを調整するのがプロジェクトリーダーの仕事だと思う。

【３】管理と言うより演出

　「プロジェクトをストーリーに見立てる」というフレーズがあり、なるほどと思った。
　プロジェクトは必ずスタートとクローズがある。特に、プロジェクトをクローズする定義をあらかじめ作っておくのが大事だと思う。
　そうでなければ、プロジェクトの評価が悪くなり、従ってメンバーの士気も下がる。
　必ずハッピーエンドになるように持って行く準備をしておくことだ。

　プロジェクトをストーリーだと思えば、ストーリーに出てくる担当者が役者であり、プロジェクトリーダーは演出家だと喩えることが出来る。
　担当者が思う存分力を発揮できるように、責任範囲を決めて、開発しやすい環境を整えて、割り込みタスクを防ぐのがプロジェクトリーダーの仕事。
　管理という言葉を使いたくなるが、実際は、メンバーをサポートし、メンバーをゴールへリードするのがお仕事。
　そこには、信頼関係という基盤があり、権限と責任が発生する。
　この部分を円滑化させる技術がプロジェクトファシリテーションなのだと思う。

　この本で眼を引いた一節が「リーダーの演出」。
　プロジェクトリーダーも、チームの一員であるのだから、その役割がある。
　だから、メンバーにその役割が見れば分かるように、言動を一致するように努めたり、約束を守る、包容力を持つ、などの基本所作が必要とのこと。
　結局、プロジェクトと言う舞台では、メンバーだけでなく、プロジェクトリーダーも俳優の一部なのだ、と。

　時々、プロジェクトリーダーも現場の仕事をやる一担当者になる時もある。
　この本では「伝家の宝刀はひっそり抜く」と語られている。確かにリーダーが一担当者になると、チーム全体を見る人がいなくなるので、混乱してしまう危険性を孕む。だから、いつも刀を抜いてはいけない。

　更に「抜かない刀はさびる」とも。確かに、プログラミング技術は鍛えないと、最新技術に乗り遅れてすぐに落ちる。常に最新技術の動向はおさえておかないといけない。

　現場で働くリーダーにとって、参考になる知恵がたくさん詰まっているように思った。

Javaで関数型言語みたいに書く

「Javaで関数型言語のcase式みたいに書く」記事を見ると、Javaでも、IF文やSwitch文を値を持たせられる。
その記事に載っていたソースは下記の通り。

class CaseExpPpoku {
public static void main(String[] args) {
char nengou = args[0].charAt(0);
System.out.println(
nengou == 'H' ? "平成":
nengou == 'S' ? "昭和":
nengou == 'T' ? "大正":
nengou == 'M' ? "明治":
"？？");
}
}

すげぇ。。

kanasan.jsでも、JavaScriptのprototype.js を皆で読んでいた時、三項演算子を3個も繋いで処理を行うソースがあった。

三項演算子は使わない方がいい、と言われていたが、このソースを見ると、三項演算子はLispのS式みたいなもの。
オブジェクト指向という思想とは違う発想。

オブジェクト指向も既に15年以上も使われて、いい加減、賞味期限が来ている。
次の新技術は、関数型言語なのかもしれない。

ペアプロ再考

11/30にXPJUG関西主催の「スタートアップXP！」で「プログラミング以外にも使えるペアプロ」というタイトルの講演をしてきた。
その時の講演内容について、もう一度振り返ってみる。

【1】でも、ペアで作業する時は多い

　実際の現場で、ペアプロの経験は僕はない。
　でも、ペアで作業する時は実は多い。

　本番リリース作業では、オペレーションを行う人と、チェックリストを見ながら監視する人のペアが多い。
　同じく本番DBのメンテナンス作業も同じ。
　本番システムでは、作業ミスは許されない。

　他スタッフの話を聞くと、開発工程(プログラミング)だけでなく、設計やスケジュール作成でも、ペアで作業する時があると聞いた。
　つまり、工程に応じて、ペアの呼び名が違うのかもしれない。

a. 設計→ペアプランニング
b. 開発→ペア作業(ペアプロ)

　業務系でも、Web系でも、組み込み系でも、ペアで作業しているシチュエーションは実は多くないだろうか？

【2】一人で作業する時は結構サボっている

　IT業界における自分たちの作業を今一度思い出してみよう。
　実は、一人で作業している時は結構サボっていないだろうか？

・調査ついでにネットサーフィン
・IMしたついでにお喋りする
・メモするついでに2時間もWikiへ書き込み etc.

　PCは仕事道具だけでなく遊び道具でもある。
　8時間働いているつもりでも、実質の稼働時間は、6時間も満たないのかもしれない。
　だから、一人の作業は動機付けが弱くなりがちで、品質が甘くなるのだろう。

　ペアプロを体験してみると、「疲れる」という言葉が良く出てくる。
　理由は、他人の眼があるから、気が抜けないこと。
　1.5時間1セットで休憩を入れないと、集中力が持たない。

　ペアプロは、実は体力を消耗するぐらいの集中力を必要とする。

【3】ペア作業のキーワード～ナビゲートとドライブ

　ペア作業では、「ナビゲート」と「ドライブ」の2つの単語が良く出てくる。
　言葉の定義は、ネットで見当たらなかったけれど、僕は下記で理解している。

１・ナビゲート
　ゴールへの道程を誘導する。水先案内人のイメージ。

２・ドライブ
　ゴールへの道程から外れないように進む。
　比喩としては、システム開発というデコボコ道を車で走っている時、ハンドルをしっかり握って前進するイメージ。

　XPでは、ドライブという単語は良く出てくる。
　ドライブできるためには、二人でコミュニケーションをやり取りできて、作業を進めることができなければならない。
　更に、ハンドリングしながらアクセルを踏んでいるのだから、二人のリズム、作業のリズムが重要。
　特にテスト駆動開発では、テストプログラムと実プログラムを切り替えながらプログラミングするリズムが大事。

　ナビゲートもドライブも、プロジェクト管理の重要なタームと見なすことも出来る。

【4】ペア作業の意義

　ペアで作業するパターンは、OJTのような教育ペアと、開発者＆テスト担当者のような品質ペアの2種類に分けられる。
　ペアで作業すると、下記の長所があるように思う。

１・二人の目による品質チェック
２・意思決定を勇気付けてくれる
３・自然な役割分担が生まれる

　だが、Ruby関西の人達といると、彼らは別の欲求があるように感じる。
　彼らは「俺のプログラムを他人に見せたい！」という強い自己顕示欲がある。
＃何せ、彼らはライブコーディングするからね。

　ペアプロは、ペア同士が緊張する関係ではなく、俺はこんなにすごいんだぜ、とアピールする場でもある。

【番外編】XPの定義でしっくりくるのはどれ？

　講演の最後に、「XPの定義でフィットするのは次のうちどれですか？」と聴衆に聞いてみた。

1・チームの能力をパワーアップさせる開発手法です。
2・個人の責任と勇気を重んじる人間中心の開発手法です。
3・チーム内のコミュニケーションを活性化させる開発手法です。

数えてみたら、
1.4人
2.10人
3.10人
でした。

僕が思うに、

1.マネージャの観点
2.プログラマの観点
3.プロジェクトファシリテーションの観点

なのです。

XPJUG関西やPFP関西の人は主に、マネージャクラスなので、１又は３の立場が多いです。
だから、プログラマの観点の人が多いのは意外でした。

僕の思いとしては、XPはプログラマのためにあると思っているので、2に共感してくれる人が多いのは嬉しかった。

【まとめ】

日本では、アジャイルと言えば「XP」。
XPを知って4年経つけれど、今でも色あせない。
XPは面白いし、熱いです。

JavaScriptは関数型言語だ

今日、11時過ぎにkanasan.js#2に行ってみた。
既に20人以上も会場にいて、プレゼンが始まっていた。
なんと朝9時から夜9時まで、12時間のマラソン勉強会(^。^)

最初は、前回の復習。
講演者の話す内容は非常に面白かった。
継承、MixIn、wrap、いずれの具体例も非常に興味深い。

それから、Prototype.js1.6.0のコードリーディング。
12時間かけて、1000行を読んで、ようやくAjaxオブジェクトの所まで解読しましたよ！

JavaScriptは面白いなと思った箇所がある。
Prototype.jsの内部で、Hashを作っているソースがある。
そのソースに、intersect() という関数があり、その定義は、Lispみたいなソース。
つまり、無名関数をつなげまくって、わずか2行のソースで、二つのリストの共通部分を取り出す。

intersect: function(array) {
return this.uniq().findAll(function(item) {
return array.detect(function(value) { return item === value });
});
},

Rubyで言えば、上記の関数は、ブロックを2個使っているのと同じ。
最近のJavaScriptは無名関数を多用することで、エレガントに書こうとしているように見える。
これってLispに似てないか？

JavaScript読書会でも議論になったが、無名関数を使った場合、変数のスコープがJavaの場合と微妙に異なる。
レキシカルスコープ、ダイナミカルスコープの話もあった。

Haskellにあるcurry化のような関数(curry)を定義していたり、実装内容は、関数型言語の影響を強く受けているように思える。

関数型言語っぽい使い方をする利点は、変数が1回しか代入できないことよりも、無名関数やクロージャを使って、関数をまるで変数のように使い回すところにあるように思う。

そして、イベントの発火のようなロジックを手続き型言語よりもエレガントに書ける部分にあるように思う。

だから、Ajaxのようなイベント処理でビックリするような使い方ができるのかなと思ったりする。

今までJavaScriptは使えない言語と思っていたが、「JavaScriptは関数型言語である」という認識で、今後も注目していくつもり。

能力の罠(Competency Trap)

　3月末のSEA関西で「能力の罠(Competency Trap)」という話を聞いた。
　これは、「正しいプロセスを省いて誤った学習を積み重ねるうちに、能力が頭打ちになる」という内容のこと。
　この言葉は、プロジェクトリーダーの立場にいる人は身につまされないだろうか？

　実際、プロジェクトを切り盛りしていると、時間や人という制約の中で、本来踏むべきプロセスを省いてリリースすることはよくある。
　しかし、それをやり続けると、システムの品質が落ちるし、もっと重要なことは開発者の作業品質が落ちる。

　この症状は、日本のＩＴ業界でよく見られる。
　
　「能力の罠」に陥る誘惑に駆られる時は多い。
　でも、数少ない経験を通じて、結局、正攻法しか解決策はないのだ、という気がしている。
　プロセスを省いて成功するうちに、手抜きの感覚を覚えて、最終的に、何も制御できなくなる。

　悪循環に陥った時、その状況を根底から覆さなければ何も変わらない。
　そして変化させた時、結局、「機能を新規に作るよりもバグを潰して品質を高めることを優先する」ような正攻法に戻している。

　状況を根底から覆す方法は、リソースの再配置か、プロジェクトのゴールそのものの変更という政治力のいずれかしか方法がないと思う。
　この状況では、リソース管理やリスク管理というプロジェクト管理のスキルそのものが問われる。

　また、ＩＴシステム開発は、モノ作りと違って「人の能力は加速度的（速度じゃないよ）に成長する」ことを仮定しないと成り立たない。
　そのためには「人を成長させる環境作り」がすごく大事ではないか、と最近よく感じる。

　プロジェクトリーダーとしては、アサインする開発者に、プログラミングを経験させながら1ヶ月前よりも今日、昨日よりも今日、成長することを期待している。
　理由は、システムのアーキテクチャや仕様も慣れてくるだろうから、最終的にはもっと工数を短く出来るでしょ、と。

　でも実際は、同じような失敗を繰り返し、成長しない開発者も多い。
　そうすると、プロジェクトリーダーとしては、プロジェクト後半になると工数計算できなくなるからすごく苦しい。

　だからプロジェクトリーダーは、「人を育てる」ことを意識しなければ、人は成長しないし、チームの進捗も進まないと最近経験した。
　この時に必要な技術は、「プロジェクトファシリテーション」。
　チームのメンバーを信頼することが大事。
　つまり、チームメンバーにある程度の権限を与えるものの、最終的な責任はプロジェクトリーダーが負うということ。
　このとき、プロジェクトリーダーは、ディレクティブ・リーダーではなく、ファシリタティブ・リーダーになってくる。

　プロジェクトマネジメント(PM)とプロジェクトファシリテーション(PF)は、プロジェクトを回す両輪。
　PFP関西で聞いた講演では、PMはループ、PFは前進する方向なのだという比喩を聞いたことがある。
　その比喩がようやく実感できるようになってきた。