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

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

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

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

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

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

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

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

ちょっとBABOK でも勉強してみようかと

PMP の期限が切れて、suspended になってしまった。

60 PDUを稼がないとならないので、とりあえず見つけたのが ネットラーニングの BABOK 講座。これで 40PDU。

キャンペーン期間に申し込めたので 34,930 円で済んだが、今現在、価格を見てみると、49,900円になっている。ラッキーだった。

PMBOK が「どのように（HOW）」プロジェクトを回していくかに着目しているのに対して、BABOK はそれ以前に 「何のために（WHY）」「何を（WHAT）」を提供するかに着目した知識体系。

思えば、「何を、何のために」作ってるのか分からないまま開発が進められて、もの凄く残念な事になったプロジェクトもあったなあ（遠い目）・・・

特にベンチャー系の開発だと、新製品開発なのか受託開発なのかよく分からない変なプロジェクトが何かの拍子に立ち上がる事があって、ステークホルダー間で思惑がバラバラなまま、誰がどんな風に使って何が嬉しいのか分からないモノを開発する事になっちゃったりする事がある。

今、8章あるうちの2章までやったけど、資料はなかなかよくできている。できれば BABOK 日本語版も入手したいところだが、6,000円 もするので躊躇してしまう。とりあえず、講座で提供されている資料を当てにする事にする。

せっかくだから、単に PDU を稼ぐだけじゃなくて、現場に持って帰れるノウハウというかヒントが得られたら良いと思う。

あと4、5日で終える予定だけど、まだ 20 PDU足りないのでなんとかせねばならない。できればアジャイル関連で安いものがあれば良いのだけど。

WYDKYDK が読めたよ！ ﾜｰｲヾ(´ρ`)ﾉ゛ﾜｰｲ

Alistair Cockburn の本に出てくる変な綴りの言葉。意味は分かるけどなんて発音するのか、ずっと分からなかったけど、何の気に無しにググってたら見付けた。

なんかソフトウェア開発とは全然関係ない、オレゴン州の自治会か何かの議事録らしき文書だけど、WYDKYDK ("wid-kee-dik")とある。カタカナにするとウィドキーディクみたいな感じだろうか。

綴りが珍しいのは略語だからで、もとはこんな文。

What you don't know you don't know

簡単な英語だけど、構文が分からない人が意外と多い。順を追って見てみると、

You don't know it.
あなたはそれを知らない

↓

What you don't know.
あなたが知らないもの

↓

You don't know you don't know it.
あなたはそれを知らないという事を知らない

↓

What you don't know you don't know.
あなたが知らないという事を知らないもの

といった感じで、入れ子になってたりして、プログラマには親和性が高い気がするんだが。

ところで、現場ではこの WYDKYDK への認識が足りない人が、例えば WBS を作ったり作らせたりすると、困った事になる。

「これだけ詳細化したんだから、見積りは正確なはずだ」なんて思考様式なんだけど、そもそも認識されていない事を詳細化しようもないし、予測に組み込みようもない。

正解は、何らかの形で現実に実行してみて「知らない事」を「知らなかった事」に変えていく事なんだけど、下手な人はこの当たり前の事ができず、日程にバッファを組み込むといった程度の、稚拙な手に走ってしまう。 まあ現場ごとの文化とか、プロジェクトごとの事情とかもあるけどね。

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らしい事が分かって良かった。品質／コスト／納期とリスクについての問題意識をしっかり確立した上で、その処方としてのアジャイル導入であり、かつプロジェクト管理の視点でその効果を合理的に語れるなら、マイナス評価にはならないと言う事だと思う。

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

PMBOK と waterfall

ソフトウェア業界にいていろんな人と会話する中で、たまに PMBOK の話題になるが、PMBOK とはウォーターフォール型開発のためのプロジェクト管理手法であって、アジャイル系のプロセス・モデルには馴染まないと思っている人が結構多い。

そもそも PMBOK は、ソフトウェア開発のための知識体系ですらないけど、まずそこからして誤解が多い。

ちなみに、手元の PMP の参考書に載ってるケーススタディを適当に抜き出すと、

• オリンピック支援チームを収容する建物の建設プロジェクト
• 映画製作のプロジェクト
• 郵便局に新しい料金システムを導入するプロジェクト
• 高速道路を拡幅するプロジェクト

とかだったりする。ソフトウェア開発に限ったものでは全くないし、ましてウォーターフォールとか、なおさら関係ない。

（もしかすると PMBOK 関連の記事をチラ見して、「立ち上げ、計画、実行、監視コントロール、終結」からなる５つのプロセス群に、ウォーターフォールのフェーズ「要件定義、設計、実装、テスト、移行」を勝手に脳内マッピングしちゃったりしてるのかも。）

だからと言ってアジャイルに親和性が高いのかというと、そう言うわけでもない。結局、相当の応用力が要求されるという点では、どんなプロセスモデルを採用しようと変わらない。例えば経営学という知識体系が、どんな会社の経営を対象とするのか問題にしていないのと似ていると思う。

ただし、アジャイル開発者が PMBOK を勉強するのをためらっている理由が、冒頭に書いたような誤解だとしたら、決してそんな事はないので、お勧めしておきたい。プロセスについて日頃から考えている人ほど、面白く感じられると思う。

BPEL 要員の集め方

前のポストで BPEL スキルについてあれこれ考えて、こんな図を描いてみた。
これをベースに要員調達について、特にどんなスキル・キーワードを条件として用いるべきか考えてみる。ポイントは以下のようになる。

• 上図、また前ポストで示したように、BPEL技術は階層を成したXML技術構造のやや上層に位置し、XML×SOA×ワークフローが交叉する複合的な技術でもある。この特性をどう扱うか。
• そもそもBPEL 技術者は絶対数が少ないが、これにどう対処するか。

■ 駄目な集め方
多分、こんな感じだと上手くいかない。

必須スキル：○○社BPEL製品

調達担当者は、「○○社BPEL製品経験者」ならば、当該製品のノウハウはもちろん BPEL標準仕様からXML・SOAの基盤技術まで一通りマスターしているだろうと考えて、下図のようなスキル分布を期待する。（調達担当者が要素技術について多少なりと理解しているという想定。やや楽観的だが。）
ところが現実の応募してくる人のスキル分布は、こんなふうになる。

畢竟、ただただ言われるままに、IDE上のグラフィカルなエディタを何十時間かいじってきただけの経験だと、どこまでが現場のローカルルールで、どこからがツールの仕様で、どの辺りが標準仕様なのか全く未分化なままだし、それを自覚することもないから、応用というものが全くきかない。XMLソースを普通に読み書きするだけの事を、異様に恐れたりするレベルの人。

で、普通なら正味のスキルを面談時に精査して、合格レベルに満たないなら次の応募者に期待という事になるが、そもそも BPEL技術者の絶対数が少ない上に、さらに「△△社」で絞っているものだから、「選ぶ」なんて贅沢な余裕が生じる程、応募者は来てくれない。

こんな応募条件を出すくらいだから調達者側のレベルからして推して知るべしで、面談で正しくスキルチェックができるほどの技量もない。従って、結局は職務経歴書に記載の「△△社BPEL製品」という記号の有無だけで採用が決まり、面談は形式的な挨拶程度ということになりがち。

■ マシな集め方
改善するとこうなる

必須のスキル
　・XMLスキル（XSLT、XPath、XML Schema）
　・SOA、Webサービス
望ましいスキル
　・BPEL (○○社製品ならば尚可)
　・その他ワークフロー技術

とりあえず、応募者がいないと比較も選別もできないから、思い切って該当者の少ない BPEL経験は必須から外してしまう。それに替えて XML／Webサービスのスキルを必須とし、高スキル技術者を募る。XML／Webサービス技術者も中～高レベルのとなるとそう多くはないが、それでも同等レベルの BPEL技術者よりは、はるかに流通している。

下図のような技術者を期待して待ち、首尾良けば、複数の候補者からベストな数名を採用してチームに組み入れる事になる。
もちろん BPEL 標準および△△社のツール／プラットフォームについての学習工数が発生する事にはなるが、基礎スキルが充実していれば採用者側が心配するほどには時間も労力も掛からない。

また上述の駄目な例として挙げたような特定ベンダーの条件を外すことで、下図のような技術者にも門戸を開くことになる。

このタイプの BPEL 技術者なら、作業開始の要点とローカルルールについて簡単にレクチャーし、座席を適切に配置しておけば、業務要件の把握していく作業のついでに自然と習得できてしまう。

むしろ、XML 良く知ってる人が BPEL や 特定ツールを習得するための工数について、募集側が過度に多く見積もっている場合、プロセスを BPEL で書くという作業を募集側自身が良く理解していない可能性がある。

つまるところ「XMLで定義・公開され、XMLをやり取りするサービスを、XMLで記述したプロセスで動かす。」という事に尽きるわけで、必要なスキルがどんなものなのか簡単に分かりそうなものだが、実際の現場はそうじゃなかったりする。

■ 応募者側からの見方
ここまで募集する側の視点で書いたけど、逆に応募する側、BPEL技術者の視点から言うと、「BPEL経験」だとか「○○社BPEL製品」なんて必須指定がある案件は、募集側の見識を疑ってかかる事もできる。

特に、そういった選択肢を過度に狭め得る条件を必須にしておきながら、そのくせ「急募」だったり「稼働時間高」なんて場合は、プロジェクト自体も採用側の思考も、とっくに破綻していると考えてまず間違いない。

まあ不景気だし、金に困っている場合などは、タコ部屋かマグロ漁船に飛び込む気持ちで、敢えて短期間やってみるって選択もありかもしらんが。