低スキル志向なチームの育て方３選

先日、低スキル志向なチームについて考えてみた。

それは、ある時点で比べたらたまたま高スキルなチームよりは相対的にレベル低かったというものではなく、落ちるべくして低スキル方向に転がっていくという性質をもったチームだった。

今回は低スキル志向チームをより低スキルに育てるポンコツ育成プラクティスを考えてみる。

■ 低スキル側に合わせてルールを設定する

• あるプログラミングテクニックやライブラリについて、初心者には無理だとか、以前にだれかが間違った使い方をしたといった理由で、全面禁止とする文化。
• 実行しながら学習する文化、上手に失敗しながら成長する文化が醸成されず、低いレベルで成長が頭打ちになる。
• 出来るメンバーからアホらしくなって離脱してチームのスキルレベルが下がる一方となり、ルール設定がさらに低スキル向けになって負の強化ループが発生。
• 「メンバーのレベルが上がったら解禁しよう」などと言うが、そんな機会は永遠に来ない。

• 例

  • VC++ と MFC を使った Windows アプリ開発に、クラサバ業界から Cプログラマや Pro*Cプログラマが流れ込んできた時、オブジェクト指向がわからないといった理由でポリモーフィズムが禁止されたり、IDEが使えないからといった理由で小さな関数の禁止といったルールが定められた。
  • Java のサーバサード開発の普及期の現場に、大量の COBOLer や VB厨の軍団が流れ込んできた時にも、小さなクラスやメソッドの禁止だとか、ポリモーフィズムを活用したデザインパターンが禁止された。
  • 最近では Scala 開発で Cats や Scalaz などの圏論ライブラリ禁止や、Shapeless などを用いた型レベルプログラミングが禁止されたりする。
  • 一般的には、小学校のテストの「可換則使用禁止問題」などと同根。

■ テッキー君に「共通コード」を担当させる

• そこそこプログラミングが好きなメンバーに、共通コードや、ラッパーフレームワークを書かせる。で、人材市場で安くかき集めたポンコツ人海戦術軍団に、その共通コードを使った「業務ロジック」を、書かせる。
• 実は人海戦術軍団の中にもレベルの高低ムラがあり、中には共通コード担当のテッキー君と同等以上のメンバーが含まれることもあるが、組織の空気として、人海戦術軍団には技術面は期待しないという暗黙のメッセージが常に発せられているので、レベル高めのメンバーから順にチームを離れていく。
• テッキー君自身も、技術的アンテナの感度が高くて向上心をあればあるほど、劣化する一方のチームの淀んだ空気にも、自分自身の井の中の蛙的ポジションにも耐えられなくなり、早晩離脱する。後釜のテッキー君はさらに劣化したテッキー君になるので、テッキーポジション自体も劣化する。
• Eric Evans が 青い DDD本で言ってたような、「Apply top talent to the CORE DOMAIN, and recruit accordingly.」といった高スキルチーム向けのガイドラインは、邪念として却下する。
• 反省: 自分もプログラマになりたての、サーバーサイド Java に Servlet と JSP しかなかった頃に、こうしたテッキー君ポジションで、ポンコツ軍団向けフレームワークを書いたことがあるが、今では後悔している。業務ロジックチームでメンバーに直接スキル移譲しながら、ドメインのコードを直接洗練させるべきだった。

■ チケット駆動開発「だけ」しかやらない

• チーミングの工夫や、コミュニケーションの活性化はいっさい無視して、とにかくチケットだけ回しておけばOK、それしかないのだ、それで充分だと思い込む。なにもかも JIRA / Github のコメントだけで仕事を進めようとする。
• アジャイルを参考にすると、マニフェストの「プロセスやツールよりも個人と対話を」という価値観に抵触してしまうので、アジャイルは禁教とする。
• フェイス・トゥ・フェイスのコミュニケーションはムダな時間として廃止。自分にアサインされたタスクに無関係な情報には耳をふさぎ、他人の仕事には我関せずを貫徹する。
• 浸透的（osmotic）コミュニーケーションが発生せず、自然なスキルの伝播が起きないので、チーム全体のスキル向上が伸び悩む。
• 誰もが無言で働くようになり、沈黙を破る心理的障壁がたかまる。雰囲気も悪くなって、行き場所のあるレベル高めメンバーからチームを離脱していく。
• 高スキルメンバー離脱 → チームの平均スキル低下 → リソース逼迫 → コミュニケーション省略で負のループが加速。
• 補足：いろんな現場で話を聞くと、「うちは仕様や計画の変更が多いからアジャイルは向かない」なんて真逆すぎるアジャイル理解の発言を聞くことが最近は多いが、そうした無知・無策にも程がある現場で「そういえばJIRA使ってたなあ、てことはチケット駆動開発になるのかなあ」みたいな適当な流れで、ちゃんとチケット駆動開発を研究することもなく謳われるのが、低スキル志向現場のチケット駆動開発。

■ 逆3行要約

• 禁止ルールで縛るより上手に失敗しながら成長しよう
• スキル高い人こそ「業務ロジック（≒コア・ドメイン）」にアサインしよう
• チケット管理ツール使うならチーミングも工夫しよう

アジャイルPM研修に行ってきた

今日は、朝から PMI日本支部ってとこでアジャイルPM研修だった。ちょー遠かった。

受講者はだいたい皆 PMP取得者らしいけど、最近やっと「アジャイル」って単語が気になり始めた感じの、わりとウォーターフォール色濃い目の管理職の人達が多い印象で、自分としては若干アウェイ感。

ただ講師の方と他の受講者の人達の質疑応答が、予想外に興味深かった。

いわゆる上級"SE"的な「上から管理する」って技術に関しては、それなりの知識があって年季も入った人達が、アジャイル的な価値観や手法に対して、どういう懸念や抵抗感や違和感や誤解を持つのかってのが、けっこう生々しく観察できた。

研修の冒頭、各自で自己紹介するところで、「受講の目的／コースに期待すること」として、自分は「アジャイルじゃない現場にアジャイルを導入する方法に、今は特に興味があって、ヒントを得たい」みたいな感じで発言したんだけど、そういう意味でも参考になった。

ちなみに、PMP資格を維持するための PDUは、これで7PDU。

あと PMI Agile Certified Practitioner (PMI-ACP) ってアジャイル資格があって、今、取得者 5000人ちょっと（内、日本人7名）くらい。英語のテストだけど、内容的には簡単とのこと。

ほとんどペアプロだけの本

知り合って間もない人とペアプロの話になると、「ペアプロって結構疲れるんですよね。」「そうっすね。ペアプロは結構疲れるっすよね。」ってな感じで会話が終わってしまう事が多いが、本当はもっと語る事がたくさんある。そんな感じの本。

『Pair Programming Illuminated』

250頁くらいの洋書で、ペアプロだけでそんなに書くことあるのかと思いきや、意外と面白い（2002年6月の出版で、ちょっと古いが）。

例えば、ペアプロに関するよくある誤解として以下のような事項が挙げられていて、それぞれ詳しく解説されている。

• Myth 1: 1人でできる仕事のコストを倍にしてるだけ。
• Myth 2: ソロ作業が禁止されている。
• Myth 3: 良いパートナーに当たった時にしか上手く行かない。
• Myth 4: 教育効果はあるが、ある程度習熟したらもう意味はない。
• Myth 5: 良い仕事の手柄がパートナーと半分ずつになってしまう。
• Myth 6: コンパイラが構文エラーを見つけてくれるのでナビは不要。
• Myth 7: ペアプロだとフロー状態に入れないから仕事にならない。

ペアプロ者はこうした事柄について、「そうじゃないんだよね」と自分の中でなんとなく納得してるだけではなく、例えばペアプロを導入しようとしてい>るときや、誰かがペアプロを止めさせようとし始めたときなどに、他者をも説得できるように言葉や論理を用意しておく必要があるが、そのためにも先人達の意見が参考になる。

またちょっと細かい話のようだけど、以下のようなペアの組み合わせについて、それぞれに章を設けてページ数を割いて、上手く行っている場合の効能と、起こりがちな問題が記述されている。

• エキスパート／エキスパート
• エキスパート／平均的プログラマ
• エキスパート／初心者
• 初心者／初心者
• 外交的な人／外交的な人
• 外交的な人／内向的な人
• 内向的な人／内向的な人

まあ、やってくうちに自然と分かってくる事でもあると思うけど、先達の経験を共有できるってのは助かる。どうせ本に書かれてない問題もいろいろ出てくる訳だし、予備知識があるに越したことはない。(あと各章の冒頭に挿絵入りで書いてある小コントみたいなのがちょっとシュールで面白い。）

その他、ローテーションの仕方とか仕事場のレイアウトとか導入の仕方とか、いろんな知恵が書かれてる。「できるペアプロ者の７つの習慣（意訳）」もシンプルでなかなか良い。

豆知識：三人組でプログラムを書く事を Triplet Programming と言うらしい。1人がキーボード、1人がホワイトボード、もう1人が顧客役に徹するパターンについて、Coplien が語った事があるとの事。

Three Extremos と Three Amigos

M.Fowler の『ドメイン特化言語』を読んでいると、Ron Jeffries について「エクストリームプログラミング（XP）の父と呼ばれる3人の1人」とする訳注があった。

Ron Jeffries は かの有名なC３プロジェクトにいたはずだから分かるし、もう1人は言わずと知れた Kent Beck だろうと思ったけど、もう1人は誰だっけと思って調べてみると、Ward Cunningham らしい。

The Three Extremos の1人に列せられていて、c2 の wikiによるとこうなっている（見覚えはある気がするが、記憶に定着してなかった）。

The Fathers of eXtreme Programming

WardCunningham - the inventor
KentBeck - the articulator
RonJeffries - the realizer

古くからの Kent Beck の盟友で CRC カードを考案したりしたのは知ってたけど、inventer って言われるほどだとは思わなかった。

"TheThreeExtremos"という呼称は、『The Three Amigos』という映画からとったらしいけど、UML 業界でも、同様にこの映画からとった "Three Amigos" が、UML がでた当初からいる。まあ、なんか最近は余り見かけなくなった呼び名だけど。

昔はオブジェクト指向と言えば、ブーチって感じだったけど、昨今の開発でもお馴染みなのは意外とヤコブソンだったりする。

ICONIX なんかで大々的に使われてるロバストネス分析も元はヤコブソンだし、ユースケースなんかもコーバーンが大々的に普及させる以前にそもそもヤコブソンの発明だったりする。近年だとAOPとユースケースを結びつける仕事も興味深かった。

由来となった映画（邦題（『サボテン・ブラザース』）は去年鑑賞したが、なかなか良かった。ちなみに、この映画の元ネタは『七人の侍』だったりするが、こちらは不定期的に20回くらいは観ている。

現場でよくある Agile 認識の齟齬

現場で、開発プロセスをどうしましょうかなんて話をしていると、対話の流れを止めて指摘するほどではないけど、認識の違いが引っかかって嫌なときがある。今日は、そんな事象のメモ。

★ Agile プロセスはユルいものだという認識

	ユルい	キビしい
なんか違う	Agile全般	ウォーターフォール
たぶんこう	Adaptive Software Development、Crystal Clear	XP、Scrum、ウォーターフォール

Agile が総じてユルいのではなく、実はユルいのもキビしいのもある。この見方は、確かものすご〜く前に読んだ Cockburn の本に載ってたものだけど、仮に読んでなかったとしても同じ認識になってた気がする。

ちなみに、同じ High-Discipline プロセスの中でも、XP と ウォーターフォールでは、前者が高効率・高難度で後者が低効率・低難度って事になると思う。寛容な方のグループの Crystal Clear なんかは、ユルい分、XP のような究極的な生産性は得られないけど、その分、負担が少ないって事になると思う。

★ 反復型といえば軽量プロセスだという認識

	軽量	重量
なんか違う	反復型プロセス全般	ウォーターフォール
たぶんこう	Agile系	UP系（AgileUPは除く）、ウォーターフォール

反復型のプロセスはどれもみな軽量だという思い込みもよくあるけど、たいてい「軽量プロセスはドキュメントを作らない」ってドクサも併発してるから、とりあえず反復型にしてみませんかなんて提案しても、習慣による心理的抵抗が大きい。

ウォーターフォール色の強い組織でも、ドキュメント体系を差し当たり尊重したまま、やや長めの期間の反復型プロセスに切り替えた上で、反復型が浸透してきた頃合いを見て、段々と期間を短くしたり文書や儀式を減らして、段階的に軽量にしていくというやり方もある。

アジャイルの資格

アジャイル関連の資格について調べてみた。

アジャイルと認定資格って、なんとなく相容れないイメージで、開発者の間でも物議を醸しているらしいが、最近は結構、動きが活発になってきている。

まあ他の資格と同じで、保有しているからといって実務能力があるって事にはならないだろうが、少なくとも会話が成立するレベルの語彙を持っている事の表明くらいにはなると思う。もちろん実践で成功している人なら、我流に偏らないお墨付きの正統な知識も持っているという事になり、鬼に金棒で言う事が無い。

====
◆ Scrum Alliance: 認定スクラムマスタ 等
すでに日本でも取得者が増え始めている、Scrum Alliance の認定資格。

トレーニングコースに参加する必要があり、日本開催時の受講体験記をネットでも散見する。ただ、これが結構高い。ざっと検索したところ、同時通訳付きで20万、通訳なしで15万といったところか。会社の金ではなく個人で受けるとすると、ちょっとした決断が必要になる。

なんか昔のイメージだと、お金を払って2日間の講習に座ってるだけで取れるって感じだったけど、調べてみると、今は一応、インターネット経由の試験で知識を証明する必要があるらしい。

ちなみに Master 以外には、ProductOwner, Developer, Professional, Trainer, Coach といったものがある。


◆ Scrum.org: Professional Scrum Master 等
URLはここ

Professional Scrum Master I (Fundamental) :
トレーニング・コースも提供されているが必須ではなく、自信があればいきなりネット試験を受験してもよく、そこで 85%とれば合格らしい。

Professional Scrum Master II (Intermediate):
これもネット試験だが、小論文もあるらしい。費用もやや高額。

Professional Scrum Developer:
これはコース受講と試験の両方が要るらしいが、ただトレーニング・コースの方は欧米中心の開催。アジアでは今のところインドだけっぽい。

Professional Scrum Product Owner:
これもコース受講とネット試験。


◆ PMI: PMI-Agile Certified Practitioner

先月、Pilot Programが始まったばかりの PMIのアジャイル認定試験。

以前、PMP の勉強をしていたとき、使っていた問題集でも参考書でも、道路の延伸工事プロジェクトだとか、小売業の店舗拡大プロジェクトだとか、予想外にソフトウェア開発と離れた設問ばかりで、PMBOKってそう言うものだったのかと、ちょっと驚いた。

でも、同じ PMI の資格でも、PMI-Agile のFAQを見ると、馴染みのあるアジャイル開発の用語ばかりで、ソフトウェア開発者としてちょっとテンションが上がってくる。


◆ ICAgile:
ユースケースで有名なコーバーンとかが創立した、ICAgile なる組織でも、認定試験を提供する計画らしい。

組織自体が発足したてで、試験などはまだまだ形になっていないようだけど、この記事を読む限り、結構おもしろそうではある。

Scrum + XP

国内外のいくつかのIT技術系サイトから、RSS 経由で配信される記事をいつも読んでいるけど、この数年、Agile系記事の中での XP 関連の話題がめっきり少ない。

と言っても XP が陳腐化したのではなくて、XP のプラクティス群が、その根底にあった価値観と一緒に既に広く普及し、実績を上げ、評価を確立し、換骨奪胎した形でこの業界に取り込まれて、いまさら extreme (究極)なんてキーワードで語られる必要が無くなったって事なのだと思う。

もちろん、XP の導入に挫折した残念な技術者たちが、プロジェクトの失敗の原因を自分たちの力不足ではなく、XP それ自体に帰結させて、「やっぱ、XP なんかダメだね」なんて言ってるような、底辺な現場も少なくないだろうけど。


で、少なくなった XP の話題の代わりに、スクラム関連の記事が多くなってきていて、たまに Lean と Kanban の話題が上がってくる以外は、ほとんどスクラムの話ばかりになっている。

また、ちょうど一年くらい前に、マイクロソフトのプリセールス技術者から、Team Foundation Server の導入事例について話を伺う機会があったが、そこでも開発プロセスは Scrum を採用していると聞いた。

そんな昨今だけど、XP でアジャイルに入ってきた人が、スクラム導入のために XP のプラクティスを捨てたり、XP的の価値観を矯正したりする必要はほとんどない模様。

XP はプラクティス に着目していて、一方、スクラムは組織と管理に着目していて、両者の対象範囲は意外と重ならなかったりする。重なっている部分も無くはないが、同じ事を言っているだけだったりする。

どうやら、スクラムという枠組み＝フレームワークの中で、XP のプラクティスを実践していくというのが、正しい方向なのだと思う。というか今にして思うと、それぞれを単体で導入・実施するより、スクラム＋XP の組み合わせの方が、大抵の開発現場ではむしろ摩擦が少なかったような気がする。

リファクタリングの因果ループ

リファクタリングの効果をシステム・シンキングで考えてみる

まず、もっとも近視眼的に原因 → 結果を考えるとこうなる。


＋記号は、原因側の増加・強化が、結果側にプラスの効果をもたらす事を意味する。反対に、原因側の減少・弱化は、結果側にマイナスの効果を与える。－記号ならば、原因側の増加・強化が、結果側にとってのマイナスとなる。

つまり、上図ではリファクタリングの実施が開発工数の増加をもたらす事を表している。逆に言うと、重複やらスパゲティコードやらの放置も、直接的には工数を減少させるとも言っている。

これに、「ソースの体質」（ソースコードの読み易さ、書き易さ、使い易さ）と開発作業における「余裕」を付け加えて、因果関係のループを作ると以下の用になる。



要するに、短期的には工数増加をもたらすリファクタリングが、ループを繰り返すに連れて効力を増して、次第に工数を減少させていく様子を表しているが、これを説明してみたい。

解説のため、二つのループに分けると下図のようになる。


上のループは－が一個（奇数個）なので、バランス・フィードバック・ループになる。

つまり「リファクタする」→「工数増える」→「余裕が減る」→「リファクタさぼる」→「工数減る」→「余裕がでる」→「またリファクタする」→「・・・」という感じで、一周ずつ反転しながら繰り返して、適当な均衡点に落ち着いて行こうとする。

下のループは－が二個（偶数個）なので、拡張フィードバック・ループになる。

この場合、「リファクタする」→「ソースが改善される」→「だんだん工数が減ってくる」→「余裕が出る」→「もっとリファクタする」→「もっとソースが改善される」→「さらに工数が減ってくる」→「・・・」という自己強化的な繰り返しになる。

ただしソースの体質改善が開発工数に影響を与える際、遅延（上図のコンデンサー記号）を生ずるのが一般的なので、ループの勢いは最初は弱い場合が多い。

とは言っても、ループの効果は一方向的に増強されるのみなので、「リファクタ実施 → 工数増加」と言う短期的な効果を、いずれ結局は追い越す事になる。

というのが、システム・シンキングで理屈をつけたリファクタの効果。

※実は、ループによる効果の増加を待てないような使い捨て度の高いシステムでは、リファクタしたところで却って費用対効果が良くない事も、同時に示唆していたりする。

ちなみに、リファクタしない場合の悪循環は、「リファクタさぼる」→「体質悪化」→「じわじわと工数増大」→「余裕が減る」→「リファクタしようにもできない」→「もっと体質悪化」→「さらに工数増大」→ ・・・、と言った感じ。

CIのプラクティス

以下、『継続的インテグレーション入門』にのってるプラクティスのメモ

「始めよう」からのプラクティス

• 変更を起点としてビルドを実行する

「CIの紹介」からのプラクティス

• 頻繁にコードをコミットする
• ビルドできないコードをコミットしない
• ビルド失敗を速やかに修復する
• 開発者テストを自動化する
• 全てのテストとインスペクションを合格させる
• プライベートビルドを実行する
• ビルドが失敗したコードを取得しない

「変更を起点としたビルドの実行」からのプラクティス

• ビルドを自動化する
• コマンド１つでビルドを実行する
• ビルドスクリプトをIDEから分離する
• ソフトウェア資産を集中化する
• 一貫したディレクトリ構造を作成する
• 失敗しやすいビルドプロセスから始める
• 複数環境へのデプロイに対応する
• インテグレーションビルドマシンを使用する
• CIサーバを使う
• 手動インテグレーションビルドを実行する
• 短時間でビルドを実行する
• 段階的にビルドを実行する

継続的DBインテグレーションのプラクティス

• DBインテグレーションを自動化する
• ローカル環境でサンドボックスを使う
• バージョン管理リポジトリを使ってDB資産を共有する
• 開発者にDBを変更する権限を与える
• DBAを開発チームの一員にする

継続的テストのプラクティス

• 単体テストを自動化する
• 結合テストを自動化する
• システムテストを自動化する
• 機能テストを自動化する
• 開発者テストを分類する
• 実行時間が短いテストを先に実行する
• 不具合に対してテストを書く
• 結合テストを再実行可能にする
• 一つのテストケースに一つのアサーションを書く

継続的インスペクションのプラクティス

• コードの複雑度を下げる
• 継続的にデザインレビューを実施する
• コード監査による組織標準の維持
• コードの複製を減らす
• コード網羅率を評価する

継続的デプロイのプラクティス

• 動作するソフトウェアを常にリリースできるようにする
• リポジトリの資産にラベル付けをする
• クリーンな環境を構築する
• 個々のビルドにラベルを付ける
• 全てのテストを実行する
• ビルドフィードバックレポートを作成する
• リリースのロールバックを可能にする

継続的フィードバックのプラクティス

• 継続的フィードバック手段を利用する

アジャイル・ワナビーの観察 1

Agile Manifesto は over を挟んで左辺と右辺を対置し、右辺より左辺に高い価値を置くという形式になっている。

◆Individuals and interactions over processes and tools
◆ Working software over comprehensive documentation
◆ Customer collaboration over contract negotiation
◆ Responding to change over following a plan

ただし原文を読むと分かるとおり、右辺の価値を認めた上で更に左辺の方がより重要だと言っているわけで、右辺を害悪や無価値なものと断じているわけではない。だから共にプラスの価値とした上での比較論、バランスの問題とも捉えられる。

従って、右辺の重みを減らすなら、少なくともその効用が減少した分以上は、左辺に由来する効用によって補償されていなければならず、でなければプロジェクトに負の影響が生じてしまう。

さてアジャイル開発者とは、投下したコストから得られる効用の比率が、右辺より左辺の方が高いと考える人であり、その具体的な手法を提示しているのが各アジャイル･プロセスといえるだろう。

但し、その手法＝プラクティスは旧式の開発作法に比べ簡単だとは一概に言えず、それなりの知識と理解はもちろんの事、練習や工夫、或いは集中力が求められたりする（開発者としてはやり甲斐があるが）。

ところが、よくあるワナビな現場やプロジェクトでは、左辺の効力を増加させるための努力によってではなく、単に右辺を等閑視する事によってアジャイル開発になる（＝生産性・品質が向上し変化に迅速に対応できる）なんて短絡的に勘違いしている人が未だに多い。

以下、個別に見てみる。差し当たり、左辺に関するプラクティスの巧拙については割愛し、右辺がなおざりにされる状況だけを記述する。

プロセスが閑却されるケース
今時、ルールでガチガチに固めた単に監査のためだけにしかならないような重量プロセスもどうかと思うが、軽量プロセスって言葉もあるとおり、アジャイルだからといってプロセス不要って事にはなるわけがない。

にも関わらず、なんちゃってアジャイルな現場では、この肝心のプロセスすら無視される。むしろ完全にその場しのぎの行き当たりばったりの仕事が「臨機応変」とさえ捉えられてしまう。

で、たまに組織の上層部の思いつきで、「暫定」標準プロセスが適用されたりするが、長引くデスマの中で有耶無耶にされ、反省も（従って改善も）されないから、永遠に「下手の考え休むに似たり」の悪しきオリジナリティから卒業できない。

反復型なのか非反復型なのかも判別できない、グダグダでノッペリした開発作業が、終わりの見えないまま続いたりする。

（tools に関しては「ツールを減らせばアジャイルに近づく」的な勘違いは、特に見られない。但し、いわゆるアジャイル系･ツールの誤用・過信は非常に多い。これは、ここでのテーマと違うので割愛。）

文書が閑却されるケース
文書の方が有効なコミュニケーション場面ですら、口頭＝喋りで全てを伝えたがる悪癖に染まった現場も多い。伝える側は、無駄な文書化の手間が省けたと最初は思うが、何度も別の相手に同じ事を伝えている事に気づいて、初めて愚策だったと悟る（鈍感な人は、それすらいつまでも気づかないが）。

また、後のリファクタ・軌道修正が困難な箇所の設計すら個人の脳内で完結し、"Working software" が出来上がって来るまで他人のチェックが入らないため、後で一同頭をかきむしる事になるのもこのケース。（そもそもワナビな現場では、ユニットテストが後回しで、CIもロクに実現されていないから、そもそもアジャイルの意味での"Working software"と言えるのか疑問でもある。）

顧客交渉が閑却されるケース
最低限の契約交渉すらないというのは、つまりプロジェクト初期においては単なる安請け合い、末期には単に怒った顧客の言いなりに過ぎないケースがほとんどで、「協働」の本来の姿とはかけ離れている。

初期の交渉がテキトーだから、気が付いたときには既に顧客はイライラあるいは激怒し始めており、理性的にスコープを定める事ができなくなっていたりする。結局はプロジェクト外の上層部の長が出向いて、改めて不利な立場で交渉せざるを得ない羽目に陥る。

計画が閑却されるケース
ここまで記述してきたような、プロセスもなくスコープも定まっていないプロジェクトだと、従うべきプランなんて存在しようもなく、その場その時のアドホックな状況に反射的に反応しているだけとなる。

一応、後の変更を前提とした暫定プランが策定されたりもするが、ノウハウの蓄積の無い未熟な現場では合理的判断の根拠も無く、単なる思考停止の所産だったりする。


･･･というのが wannabe agile な現場でよく見かける愚行の一端。

====
http://agilemanifesto.org/を見ると 2001 とあるから、そろそろ10年になるらしい。

既にアジャイル・プロセスを導入して成功している現場に定住している人から見ると、上述のような現場が未だにあることに驚くかもしれないが、一般的には意外と多い普通の状況だったりする。自分もリーマンショック以降、初めて知る事になったわけだが・・・。

Agile ネタのPM試験小論文

四月に受けていた情報処理技術者プロジェクトマネージャ試験の合格通知が届いた。初めた去年、我ながら理解できない酷い結果だったので、とりあえず一安心。

勉強は、午後Ⅰの過去問のみを徹底的にやった。午前Ⅰは常識問題だし、午前Ⅱは去年勉強済みなので無勉。午後Ⅱの小論文は前回は採点されなかったので若干不安だったが、これも去年かなり練習したので今年はぶっつけ本番とした。

その代わりに、前回少なくとも8割は取れたと思っていたのに4割にも満たなかった魔の午後Ⅰのみ重点的に復習した。4日間くらい朝から晩まで、割と必死に過去問を解いた。

こんな点数になった

	得点	合格ライン
午前Ⅰ得点	91.80点	60%以上
午前Ⅱ得点	84.00点	60%以上
午後Ⅰ得点	78点	60%以上
午後Ⅱ評価ランク	A	-

今回の午後Ⅰが予想8割で78点で、前回試験が予想8割で38点だったという事は、やはり選択問題のマーキングをミスって半分しか採点されなかった可能性が濃厚。これはこれで恥ずかしいが･･･

午後Ⅱの小論文は、問1の「システム開発プロジェクトのリスク対応計画」を選択して、アジャイル開発プロジェクトをネタにして書いた。

設問では、対象プロジェクトに内在するリスクとその分析、またリスク対応計画とその実施状況が問われたが、これが結構アジャイルと相性が良かったりする。個人的にも日頃から、「今時ウォーターフォールなんてやる人達って、その時点でリスク意識に問題があるのでは？」なんて疑ってしまうタイプなので、割とアジャイル＋リスクは書きやすい。

ただ、終了前７・８分になってから、少なくとも600字書くべき設問ウの解答を400字しか書いていない天然ボケに気づいて焦った（そうか、これで去年も･･･）。終了30秒前くらいで200字書き足して、滑り込みで助かった。作文としてはちょっと酷かったかもしれないが、「問いに対する応答」としては一応何とかなったらしい。

それにしてもPM試験に限らず、情報処理技術者試験というとウォーターフォールってイメージだけど、反復型の軽量プロセスでもOKらしい事が分かって良かった。品質／コスト／納期とリスクについての問題意識をしっかり確立した上で、その処方としてのアジャイル導入であり、かつプロジェクト管理の視点でその効果を合理的に語れるなら、マイナス評価にはならないと言う事だと思う。

むしろ現実の業界で、未だにアジャイルについてルーズでアバウトでアナーキーなイメージを持っている人が多くて、こっちの方がよほど問題だ･･･

andLinux に Hudson を入れてみた

つい最近、存在を知った CIサーバ Hudson を andLinux に入れてみた。

ここに書いてるとおりにインストール。コマンド4行くらいで、ほとんど手間要らず。

$ sudo /etc/init.d/hudson start

とすると、ポート8080 ですぐ立ち上がる。ホストのブラウザから、http://192.168.11.150:8080/ でトップページが開く。

まだ何もプロジェクトとか作っていない状態で、いろいろメニューから開いて眺めているだけで、なんだか物凄く便利そうな気配。とっくに使い始めてる人から見たら、何を今更って感じだろうけど、なんか良い感じ。ひさびさにテンション上がる。

とりあえず Hudson から、Maven プロジェクトをビルドできるようにしてみたい。

まずプロジェクトを準備する。

• 適当に Maven プロジェクトを作成する。my-app とした。
• テストメソッドを2本書いて、1本は失敗させるようにしておく。
• これを Subversion に入れる。ここでは /home/svn/myproject というリポジトリにした。

次に、Hudson 側で Maven2 を 設定する

• [Manage Hudson]/[Configure System]を開く
• MAVEN_HOME に /usr/share/maven2/ あたりを指定。name は適当。

できたら Hudson から、

• "New Job"をクリックして、適当にJob Name を決めて、"Build a maven2 project"を選択して、[OK]
• Source Code Management にSubversion、"Repository URL"に file:///home/svn/myproject/my-app を設定
• Build Triggers とかその他いろいろ設定できるようだが、とりあえずそのままで[Save]。
• [Build Now]で実行。
• "Build History"に1行追加されるので、中を見るとテストメソッド2本中1本失敗しているのがわかる。

今度は、

• 2本ともテストメソッドが成功するように修正してコミット。
• 再度、[Build Now]でビルド実行。
• "Build History"に、青い丸で1行追加される。

さらに、そもそもの目的である Continuous Integration をやろうとして、定期的にビルド実行するよう設定しようと "Configure"を開いてみたら、なんか「nightly ビルドとか古臭いから止めときましょう」的なヘルプテキストが書いてある。変更通知をフックしなさいと。なるほど、その通りだ。

Hudson 側で HTTP の受け口が用意してあって、Subversion のフックからリクエストを送るような感じになるらしい。これは、ちょっと一手間かかるみたいなので、明日にしよ。

暗記／SOA manifesto／Agile manifesto

SOA マニフェスト というものが公開されたらしい。

Agile マニフェスト とそっくり。

どちらも「左辺 over 右辺」形式のいくつかの条項でできていて、「右辺の価値を否定するものではないが、それよりも左辺の方をこそ重視する」といったスタンスが表明されている。

まだちょっと固まりきっていないというか、今後も変更がありそうな気配もあるけど、まあ6個だし覚えてしまおう。Agile マニフェストも含めるとちょうど10個でキリがいいからこれも含めてしまう。

暗記というと余り良いイメージがないし自分も昔は嫌いだったけど、最近は暗記できるものは暗記してしまうようにしている。当たり前だけど、情報が脳内に格納されている方が思考の効率が良い事が多い。脳だけあればいいわけだから便利だし。

例えば、この SOA マニフェストなんかも、どうやったら各条項を他人に説明できるかなんて事を、満員電車の中でも考えたりできる。というわけで10問の暗記カードを作ってみた。

SOA / Agile Manifesto

{ "height":160,"width":400,"opacity":0.9,"answer-bg-color":"#FFEEDD","question-bg-color":"#FFEEDD","answer-color":"#006622","question-color":"#002266","caption":"暗記帳 アルファ版"}

??? over processes and tools

<Agile manifesto>

Individuals and interactions
over
processes and tools

??? over comprehensive documentation

<Agile manifesto>

Working software
over
comprehensive documentation

??? over contract negotiation

<Agile manifesto>

Customer collaboration
over
contract negotiation

??? over following a plan

<Agile manifesto>

Responding to change
over
following a plan

??? over technical strategy

<SOA manifesto>

Business value
over
technical strategy

??? over project-specific benefits

<SOA manifesto>

Strategic goals
over
project-specific benefits

??? over custom integration

<SOA manifesto>

Intrinsic interoperability
over
custom integration

??? over specific-purpose implementations

<SOA manifesto>

Shared services
over
specific-purpose implementations

??? over optimization

<SOA manifesto>

Flexibility
over
optimization

??? over pursuit of initial perfection

<SOA manifesto>

Evolutionary refinement
over
pursuit of initial perfection

工業的手法からの類推について雑感

「カンバン方式を適用する間違った理由と正しい理由」という記事。

「その新しい手法を導入するのは何故か？」という問いの答えにも良し悪しがあるという、当たり前な話だが、記事では、カンバン方式の導入について10個の正しい理由と5個の間違った理由が述べられている。

うーん、そもそも、日本発のカンバン方式の話題なのに、日本人の自分が良くわかっていなかったりする。カンバン方式を発展させたリーン方式の方は BPM の勉強で少しかじったけど、システム開発というより製造業の合理化手法としての側面だったので、開発プロセスの文脈で語られてもイマイチピンとこない。確か 自分の周りで Agile が流行りだした頃（2003年あたり）から、リーンはアジャイルプロセスに含まれていたと思うけど、何故だか今までちゃんと調べてこなかった。

個人的に、ソフトウェア開発に製造業や建築業からのアナロジーを持ち込むのに抵抗感がある。最近はそうでもなくなってきた気もするが、ちょっと前まではプログラマを最下層の単純労働者---たとえば、自動車工場におけるライン工、建設現場における穴掘り人足、野麦峠の製糸工のような---程度にしか捉えていない「ソフトウェア開発」観が、今よりもっと優勢だった。コボラー上がりの PM／PL がまわしているウォーターフォール型のプロジェクトには特に付き物で、そういった謬見のおかげで自分もチームの仲間もしょっちゅう酷い目にあった。だから今でも、他業種からの類推をソフトウェア開発に導入しようとする試みには、斜に構えてしまう。

まあ、でも本当に学ぶべきものがあるとしたら、見過ごすのはもったいない。そのうち調べておこうと思う。

まとめ読み：Agile関連記事 8

レトロスペクティブの変化を曲げない2008年9月26日

元記事はここ

せっかくのレトロスペクティブで得られた改善案も、実行しない事にはレトロスペクティブ自体が非効率の元になるというもっともな話だが、こういう記事が出ると言う事は、やはり無駄になっているケースが実際にも多いのだろうか。何となく気分だけスッキリして終わりみたいな。

黒澤明の「生きる」という映画で、末期ガンを患いながら難工事を完成して死んだ主人公の葬式で、集まった同僚達が己を省みて大いに反省し、明日からは主人公を見習って変わっていこうと盛り上がるが、一夜明けると何事もなかったように以前と同様のお役所仕事が続いていくという描写がある。まあつまり、そういう事なんだろう。

当たり前の話だが、レトロスペクティブと言っても本で読んだ直後から上手くいくような即効的なものじゃなくて、実践の繰り返しの中で練度を高めて、なおかつ記事で紹介されているような他者の経験もその都度取り込んで、初めて期待する効用が得られるのだろうと思う。ほんとに当たり前だが。

ちなみに PMBOK では Lessons Learned（教訓）の扱いが定められていて、プロジェクトの進行に伴って、随時「組織のプロセス資産」に含まれる「教訓知識ベース」に蓄えられて、後のプロジェクトの意思決定のための判断材料として使うようになっている。

== 要チェック ==
Force Field 分析：T字チャートで推進力と抵抗力を可視化して力のバランスとして捉える要因分析手法。

まとめ読み：Agile関連記事 7

◆Martin Fowler氏：SOAはアジャイルアプローチで実行可能か? 2008年9月23日

Martin Fowler の bliki のエントリ、「EvolutionarySOA」についての記事。

前提として知っておくべき事 ⇒ Martin Fowlerが、古い論文 "IsDesignDead" で設計における「事前の計画性」と「必要に応じた進化」を対立軸として提示し、当時花形だった XP では後者の価値ばかりが喧伝されていたが、前者の価値もなだまだ失われていないと主張した事。

bliki での Fowler の提案　⇒ SOA においては公開したインターフェイスを気安く変更できない事情から、一見 Planned が適しているように思われるが、WWW に見られるように Evolutionary にも大規模な成功例がある。そこで Fowlerは、Planned と Evolutionary の折衷案として漸次的なSOA開発を推奨する（原文ではGuerilla SOA）。（ここで言う漸次的はIncremental & Iterative のIncremental の方だろう。つまり"alter" ではなく"add onto"と言う事になるか。）

※ 供給側の都合ではなく需要側の都合で、SOA のインターフェイスを変化させていくと言うアイデアは 「Consumer-Driven Contracts」という論文から。


◆レゴはもはや子供たちだけのものではない 2008年9月25日

複数プロジェクトの作業実績／バグ管理にレゴを使うという記事。まあ楽しそうなんだが、外部のステークホルダへの報告だのその他いろいろの都合で、結局、PCにもTracやなにかで同じ内容を記録することになりそう。そうなるとまた情報の二重管理になりそうな･･･。

あと積み上げられたレゴをうっかりひっくり返してしまったら、作り直すのが面倒くさそうとか、いろいろ余計な心配をしてしまう。

この記事から、一応読んでおくべきアジャイルプロジェクトの進捗管理に関する他サイトの記事へのリンクが張ってある。
・Information Radiators（情報発信）
・Informative workspace（情報を提供する作業場所）
・Big Visible Charts

上記リンクで紹介されている関連 agile ツール

• ホワイトボード
• フリップチャート
• バーンダウンチャート
• ビルドステータスランプ

まとめ読み：Agile関連記事 6

◆変化への抵抗に打ち勝つ　2008年8月28日

変化に抵抗する理由について「認識に関するもの／感情に関するもの／行動に関するもの」のとする３タイプの分類が提示されている。また変化への抵抗の形式として、「積極的／消極的」「顕在的／潜在的」「個人／グループ」「攻撃的／臆病」の4つの分類軸が挙げられている。

記事の中で、それぞれの抵抗の理由と形式の組み合わせについて、解決策が提示されているわけではないが、そこそこリーズナブルな解法のパターンが提案されているのはなかなか良い。
問題をパターン化して捉えるのは、やはり最適な手順で解に到達するための基本なのだろう。余談だが学校教育における数学の学習のエッセンスというのは、公式や定理ではなくて、つまりこういう事なのだと思う。

後半で、組織の変革の手法として「The Six Change Approaches」と言うのが紹介されている。Kotterさんと Schlesinger さんが1979年に提案したアイデアで、変化への抵抗に対処するための６つの方法が提案されている。また抵抗の理由としては上述の３分類と若干異なる「Parochial self-interest／Misunderstanding／Low tolerance to change／Different assessments of the situation」が提案されているが、個人的にはこちらの方がより説得力を感じる。

今後は、上記のような抵抗のパターンのそれぞれについて、”The Six Change Approaches”をより詳細に具体的した解法が形式知として蓄積される事が望まれるが、この記事ではまだまだそういう気配はない。

ちなみにこの記事もスクラムベース。なんかやっぱり流行ってるのかな。

◆「技術的負債」に対する新しい見方　2008年9月19日

プロジェクトに途中参画したり誰かのコードを引き継いだりしたとき、プロジェクトのオーナやらマネージャやらにリファクタリングの必要性を説明する事が多いが、「現状、利子の返済だけで首が回って無い状態だから、負債を整理して財務を健全化しないとダメなわけです」なんて例え話で説明すると、わりとすんなり話が通じる事がある。

というわけで、プロジェクトのリソースと成果物を、会計と金融になぞらえる捉え方は昔からよくあって割と説得力があったりするが、「技術的負債」について調べてみると、もともとは Ward Cunningham による1992年のメタファーだとわかる（wikiはここ）。この割と歴史のあるメタファーにまつわる最新の言説を集めて紹介しているのが記事。

本文では負債の減少より資産の増加を重視したアプローチが、最近のアイデアに見られる傾向だとされているが、Alistair Cockburn が2001年に「Agile Software Development」で提示した secondary goal の考えと近いものがある。こちらは、開発を繰り返し連続するゲームと考え、個別のゲームの勝敗（primary goal）と同時に、次のゲームに有利になるような要素をためていく事も重要だとする考え方。

c2 の wiki で、 Debt で検索してみると、いくつか出てきて、これまでにどんな議論があったのかざっくり分かる。ただ、やはり現状では、本物の経済における金銭を計量単位とした定量的アプローチのような手法が確立しておらず、まだまだ感覚的なメタファの域を出ない模様。

今後、PMBOK的 な定量的管理の思想が普及したら、いずれ手法的に洗練される可能性があるかもなんて思わないでもないが。

まとめ読み：Agile関連記事 5

職人的技能 - 5番目のアジャイルManifestoの価値?2008年8月21日

言わずと知れた AgileManifesto の既存４か条に、５番目の条項 "Craftsmanship over Execution"を付け加えようという話。「遂行より職人芸」くらいの意味になるだろうか。

自分も以前は「どこの現場でもそんな価値観だと良いなあ」なんて思っていたけど、今は別にそうは思わないな。なんだか、こんな事を主張するなんて「物凄いプログラム職人なボクをもっと評価してほしい。下手なコードを単に書いてるだけのアホどもとは違うんだよ。」なんて必死に主張してるみたいで、ちょっと恥ずかしい。

だいたい職業プログラマの９割か９割５分くらいは、他の仕事より簡単そうだから「自分でもできそうだ」なんて思ってプログラマやってるだけだろうし。自宅で独習する事も無いし、自腹でスキル投資する事もない。良いコードの美しさも良いコードを書く面白さも分からないし興味無いのが当たり前。食うために仕方なくプログラム書いてる人たちが普通。IT業界に限らず、世の中の大半の「仕事」なんてそんなものだと思う。

ちなみに Alistair Cockburn も『Agile Software Development』でプログラマが読むべき本として紹介している宮本武蔵の『五輪書』の中に、大工の棟梁の仕事として以下のような言葉がある。

「棟梁が大工を使うには、彼らの腕前の程度を知り、ある者は床の間、ある者は戸障子、敷居、鴨居、天井というように、能力に応じて仕事をさせ、腕の悪い者には根太（床板の下に張る横木）を張らせる、もっと悪い者にはくさびを削らせるなど、よく見分けて使えば、能率も上がって手際よくいくものである。」

というわけで、むしろ「適材適所 over スキル至上主義」という方が、平均的な開発現場、特にSI業界では現実的な良い効果があると思う。

(訳文の「Manifestoは5番目の価値であるべきだという提案」という箇所は「Manifestoは5番目の価値"Craftsmanship over Crap"を含めるべきだという提案」の間違いだろう。)

まとめ読み：Agile関連記事 4

◆見積もりは無駄なプラクティスか？2008年8月21日

「見積り」なんて事自体がそもそも金の無駄だから、もう止めました。

という、にわかには信じがたい話だけど、特殊な条件下でなら有り得ないこともないかもしれない。とりあえず開発側の都合としては、完成責任に対して定額報酬をもらうような形態でなく、働いた分だけかそれ以上のギャラがもらえる保証さえあれば、まあ応じられる相談。

後は（というか大部分だが）顧客側の都合になるだろう。予算に関する権限を持っている上位のステークホルダーが「とにかく見積もる事から始める」という固定観念を捨てるという前提さえ成り立てば、いくつかのパターンで見積り自体にかかるコストを節約できるかもしれない。

• まずは開発を開始し、そこで得られる実測値を用いて、進捗率とコストの関係から全体の完成までのコストを継続的に予測。この予測を用いて適当なタイミングで開発続行か打ち切るか判断するというケース。打ち切った場合の投下済みコストを、想定内の損失として受容できて、ゴールの不到達自体はそれほど問題にならないという条件が要りそう。
• とにかく何としても到達すべきビジョンとゴールがあって、尚且つそのための開発者が予め決まっており、見積りを比較して一者を選択するというプロセスを度外視できるというケース。実際に掛かったコストが、その成果物を得るための最小のコストで必要条件だったと納得できるだけの信頼関係が必要条件。
  

やっぱり、ちょっと無理っぽい気もするが、研究開発色の強いプロジェクトならあるかもしれない。

まとめ読み：Agile関連記事 3

◆Minibook: 塹壕より Scrum と XP (2008年8月12日)
『Scrum and XP from the Trenches』という、Scrum プロジェクトの実録風チュートリアル。ややボリュームがある（138ページ）ので、時間が空いたときに集中して読んでみようと思うので、内容はひとまず保留。

それにしても Scrum の記事が多い。もしかして既に XP の後継的な地位に決まってしまってるんだろうか。なんとなく体育会系っぽい雰囲気があってちょっと敬遠していたんだが、そろそろちゃんと体系的に知識を取り込んでおいた方がいいのかもしれない。プロジェクトに参画すると、開発チームリーダ的なポジションになる事が多いから、明確にリーダの権限と責務が定義されているプロセスの方がむしろやりやすいかもしれない。


◆ソフトウェア開発: いつ起きてもおかしくない交通渋滞 (2008年8月15日)
交通渋滞と測定ライトの比喩はそれほどでもないが、「10 Principles of Agile Project Time Management」は気に入った。元ネタには各条文の内容が書いてあり、さらに詳述したページへのリンクもある。


◆アジャイルの採用に関する感覚的な障害 （2008年8月20日）
「年を重ねるにつれて、もっともややこしい問題は技術ではなく人の問題であることに気づいたんだ」って、そんなの大して年重ねなくても分かるだろうに･･･なんて思いつつ見てみると、ちょっと面白そうなのが紹介されている。

• Responsibility Process Model (責任プロセスモデル) Christopher Avery
• Responsibility Virus (無責任ウィルス) Roger Martin
• Ladder of Inference (推論のはしご)　Chris Argyris

どういうわけだが、何しろモデル化されたものは何でも面白そうに思えてしまう（まあよく見ると面白くないモデルも多いが）。あとはカタログ化されたもの好きでたまらない。モデル化されたものとカタログ化されたものがなぜか好きで、なぜか集めてしまいたくなる。