IPA版アジャイルプラクティスのパターン言語集

IPAがアジャイルプラクティスのパターン言語を公開していたのでメモ。
これは凄い。
パターン言語というアイデアは、かなりマニアックな考え方と思っていたのに、世間に認知されてきたのかな？

調査報告書や「アジャイル型開発におけるプラクティス活用リファレンスガイド」を読んでみて、気づいた点を抜粋して書き出してみる。

【元ネタ】
情報処理推進機構：｢アジャイル型開発におけるプラクティス活用事例調査｣の報告書とリファレンスガイドを公開

情報処理推進機構：｢アジャイル型開発プラクティス・リファレンスガイド」を公開～アジャイル型開発の初心者向けに実践ノウハウを事例から分類・整理～

Twitter / IPA_SEC:SECでは、アジャイル型開発で用いられる組織、プロセス、技術等の実践のための指針である「プラクティス」について、先駆的企業を対象に事例調査を行い、リファレンスガイドとしてまとめ、本日3月19日公開しました。ぜひ、ご利用ください。http://sec.ipa.go.jp/reports/20130319.html …

Twitter / hiranabe: "IPA 「アジャイル型開発プラクティス・リファレンスガイド」を公開" なんと、パターン言語記述で力が入っています！ http://bit.ly/ZaDct6 "

Twitter / takepu: 【IPA】「アジャイル型開発におけるプラクティス活用 リファレンスガイド」読んだ。「アジャイル成分300%」の濃厚仕立て。中身の是非は兎も角、IPAがこの資料を公開できる状況になったのだな、と、あらためて実感した。日本、始まった。 http://goo.gl/Rnuo2

Twitter / takepu: 【IPA】「アジャイル型開発におけるプラクティス活用 リファレンスガイド」P.51 とか、「ペアプロ」を写真付きで紹介するなんて、昔は本当、考えられなかった!! http://goo.gl/Rnuo2

Twitter / takepu: これから、日本のソフトハウスは激変するのではないか。だってIPAさんが「アジャイルプラクティス」を公開しているのだから、「IPAが言ってるんだから、やりましょう、いまでしょ？」ってなる気がする...。でも、何も考えずに導入して失敗するパターンががが... orz

【1】2009年度の調査では、約35％の開発プロジェクトでアジャイル型開発手法を実施している。
アジャイルと非アジャイルの技術とプラクティスを組み合わせてより大きな組織に合うようにハイブリッドにすることに苦闘している。
(中略)
国際競争力の強化のため、世界的に主流となっているソフトウェア開発手法であるアジャイル型開発に日本も取り組み必要がある。
しかし、現状、日本では「普及が遅れており、ようやく認知され始めた」段階であるとされる。

まさにその通り。
但し、2012年後半から、日本人発のアジャイル開発の書籍が急激に増え始めた点は注目すべき流れ。
日本のアジャイルコミュニティの影響力が強くなり始めた事実があると思う。

日本人が書いたアジャイル開発本が増えてきた: プログラマの思索

チケット駆動開発の英訳記事が公開されました: プログラマの思索

【2】日本でアジャイル型開発が阻害されている要因。
海外では、同一組織内でソフトウェア開発が行われている。
オフショアでも顧客と開発チームがいつでもコミュニケーションが取れる環境を作っている。
ユーザ企業にIT技術者が多い。

これもよく言われていること。
そのような制約でアジャイル開発をどのように適用していくか。
あるいは制約条件を壊す動きを始めるか。

【3】アジャイル(Scrum、XP、WFとの折衷型など)を適用した調査結果では、「成功した」が５０％を超えているが、「うまくいったがうまくいかなかった面もある」が２３％あるのが興味深い。

日本の現場に合ったノウハウがもっと必要なことを示唆している。

【4】適用プラクティスでは、日次ミーティング・ふりかえり・イテレーション計画ミーティング・イテレーションをほとんど採用されているのに対し、ニコニコカレンダー・かんばん・システムメタファはほとんど採用されていない。システムメタファはゼロ。

アジャイル開発の基本であるタイムボックス開発、コミュニケーション重視は押さえられている。
かんばんはまだこれから。
システムメタファは、業務用語集の代わりとして使われていくためにもっとノウハウが必要だろう。

【5】2009年度と今回の調査では、スプリントバックログのようなScrumのプラクティスの適用率が高くなった。
これは、認定スクラムマスター研修が国内で開催されるようになってきたことにより、Scrumが普及したためであると思われる。
また、紙・手書きツール、タスクボードの適用率も高くなっている。
これは、コミュニケーションを重視するために、事業者と開発者が同一拠点で一体化して開発する事例が多くなってきた事によると思われる。
また、ユニットテストの自動化も適用率が高くなっている。
これは、アジャイル開発がプロセスの側面だけでなく、技術・ツールのカテゴリのプラクティスを実践することの重要性が認識され始めたためと思われる。

アジャイル開発のエンジニアリング側面とプロセスの側面の両方が重視されて実践されていることを示唆している。

【6】B2Cサービスでは、インテグレーション専用マシンや継続的インテグレーションの適用率が高い。
これは、社内システムよりもリリース後に変更が入る率が高く、迅速なフィードバックが求められるためである。

【7】小規模ではイテレーション計画ミーティング、中大規模ではリリース計画ミーティング、人材のローテーションの適用率が高い。
これは、中大規模では、人材を流動化させて、ナレッジやノウハウをいかに流通させるかが課題であると思われる。

【8】プラクティスのパター言語テンプレートは下記の通り。
状況・・・解決すべき問題が発生する状況
問題・・・特定の状況で発生する問題
フォース・・・解決策を選択する上で鍵となる考慮点や制約事項
解決策・・・プラクティスそのもの
利用例・・・プラクティスの利用例
留意点・・・プラクティスを適用する上でコンテキストに応じた留意点やプラクティスをそのまま適用できない時の代替策

これを読むと、IPAはパターン言語をきちんと理解して、アジャイルプラクティスを抽出しようと試みているのが分かる。

【9】日次ミーティングの留意点には「必ずしも朝の時間帯にこだわらず、関係者が集まりやす時間帯に開催する(例えば終業時間帯に開催する夕会)」と書かれている。
これを読むと、たくさんの事例を元に、状況に応じて、問題解決する手法を提案しようとする試みが感じ取れる。
何も朝会が絶対の解決法ではなく、それぞれのプロジェクトに応じて柔軟に対応すべき。

【10】ふりかえりの利用例では、「当初はKPTを使っていたが、ファシリテータの技量にふりかえりの質が依存してしまう、声の大きいメンバーに影響を受けてしまうことに気づいた。そこで意見を集めるやり方として、555(Triple Nickels)を用いることにした」と書かれている。
この内容もよく分かる。
KPTはとても良い手法なのだが、ホワイトボードを使ってメンバーから意見を吸い上げたい時、ファシリテータの能力が高くないと、あまり意見が出ず、肩透かしになる。
日本人は人前で発言することに慣れていないから。

僕もPostItで各人にKPTの観点で書いてもらい、一人ずつ話してもらうようにしていた。
すると、若手や女性の意見が意外性があり、結構貴重な意見になる時が多かった。
そんな観点があるのか、とか、そんな考えを持っていたのね、とか。

【11】「まとめ」ではこんなことが書かれている。

現状、日本では「普及が遅れておりようやく認知され始めた」段階とされるが、アジャイルプラクティスの適用率は高まっている。
一方でアジャイル型開発を導入しさえすれば、生産性・品質・コストに関する問題が解決するという誤った認識も生まれ始めていることから、プラクティスへの正しい理解を広めると共に、「アジャイルコーチ」(外部からの変化)と「組織に合わせたアジャイルスタイル」(内部からの変化)をバランスよく取り入れながら正しい普及活動を進めていくことが今後の課題になるだろう。

僕が暗黙的に感じていたこと、直感的に思っていたことがズバリ書かれているなあと思った。
また、「アジャイル」がビジネスとして成り立ち始めていること(例えばアジャイルコーチとしてコンサルタントになる)、Scrumが言う組織的阻害要因(organization impediment)にも触れて、それを継続的に解決しなくてはならないことを示唆している。

【12】また、「まとめ」ではこんなことが書かれている。

契約の違いはプラクティスにあまり影響を与えていないが、海外と国内の環境の違いを踏まえると、日本の環境では特に以下のプラクティスを活用する必要がある。

・ファシリテータ(スクラムマスター)
・顧客プロキシ
・共通の部屋

【12-1】スクラムマスターの必要性は、スクラムの新しさ: プログラマの思索にも書いたように、発注者(プロダクトオーナー)と開発チームのバランスを取るためだ。
顧客や開発者とは別の独立した役割であるスクラムマスターが必要で、スクラムマスターがいることでそれぞれの役割が一方的に強くなることを防ぐだけでなく、本来のゴールを認識させたり、スクラムチーム内部で発生した課題を解決するために組織的阻害要因を取り除くことに注力する。
従来のプロジェクトマネージャの役割は、プロダクトオーナーとスクラムマスターに分割されるべきなのだろう。

【12-2】顧客プロキシは、受託開発の場合、SI側に顧客の代理人としてプロダクトオーナーを配置することに相当するだろう。
但し、僕の経験では、顧客プロキシのハードルは高い。
SIではいわゆる業務SEが顧客から要件を引き出してまとめるために、しょっちゅう出張で出かけたり、開発チームへフィードバックしたり、要件定義書を作るためにかなり時間がかかったりして、彼がボトルネックになる時が多い。
牛尾さんや倉貫さんも既にそのような事例と注意点を指摘されている。

アジャイルはなぜ失敗するのか？～教科書には載っていない反復型開発の3つの掟（4/4）：企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

アジャイルはなぜ失敗するのか？～教科書には載っていない反復型開発の3つの掟: プログラマの思索

ITエンジニアのスキル向上ゼミナール - 【中級】反復開発　現場のノウハウ 第2回：ITpro

図4●顧客の“代理”を立て，プロジェクトに常駐
TISの倉貫氏はXP開発を進めるに当たり，常時プロジェクトに参加してもらえない顧客に代理人（ユーザーのシステムを長年開発している開発者）を立て，プロジェクトに常駐してもらった。同氏はこのプラクティスを「顧客プロキシ」と名づけた

【12-3】共通の部屋は、XPのオンサイト顧客と同じ。
プロダクトオーナーと開発チームが同じ場所で仕事することで、いつでも仕様確認や本来の優先順位を議論できる場を作り出すこと。

最近注目すべき流れとしては、トヨタ生産方式やリーンの考え方を元に、かんばんを使った手法がある。
部屋の壁やホワイトボードにかんばんを作り、機能(フィーチャー・ストーリーカード)やタスクカードを載せてプロジェクトの進捗や課題を見える化する手法だ。

かんばんとスクラム 両者のよさを最大限ひきだす

「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ

チケット駆動開発の目的も最終的には、かんばんが目指している「プロジェクトの見える化」「透明化」をサポートすることにあると思っている。

【13】「プラクティス(パターン)を現場から発信できる場作り」では、「もっと日常的に現場の開発者が自分たちの工夫を言葉にして、それを社内や社外にかかわらず共有しながら、現場の知を交流させて新しい知を生成していく必要がある」と書かれていて、全く同感。
日本人技術者のスキルは、海外と比べてさほど劣っているとは思わないし、DOAや品質管理などでは日本独自の技術を持っている。
にもかかわらず、そのような技法が共有されておらず、現場の経験知がバラバラに散在していて、参考にしづらい。
ノウハウをパターン言語として再発明して、新しい言葉による価値の創造に向かえば面白いだろうと思っている。