アジャイルで「偉大な習慣を身に付けた技術者になれ」
金武明日香（＠IT自分戦略研究所）
2010/4/15
| アジャイル開発を行う技術者が集まるイベント「アジャイルジャパン2010」レポート。「体験しよう！ 考えよう！ 行動しよう！」をテーマに、さまざまな角度からアジャイルを考察したイベントの模様を、前後編に渡ってお届けする。 |
4月9日と10日、日本アイ・ビー・エム本社にて「アジャイルジャパン2010」が開催された。テーマは「体験しよう！ 考えよう！ 行動しよう！ 日本のアジャイルはここにある」。プロジェクトマネージャやリーダーを中心に、200人以上の参加者が集まった。
■60％が「使われない機能」
1日目は、「はじめてのアジャイル」として、チェンジビジョン代表取締役社長 平鍋健児氏とSonicGardenカンパニー長の倉貫義人氏が講演を行った。
 |
チェンジビジョン 平鍋健児氏 |
いまアジャイル開発に注目すべき理由として、平鍋氏は「従来のウォーターフォール式開発では要求が劣化することが問題」と指摘した。ウォーターフォール開発では、発注してから納品するまでに時間がかかる。開発している期間中に市場環境が変化すれば、欲しかった機能そのものが不要になってしまう可能性がある。実際、システム全体の60％以上が「使われない機能」であるという。
なぜ、このようなことが起こるのか。顧客企業とSI企業の「目的」が異なることが一因だ。顧客企業は、ビジネスを成功させるために「システム導入」というリスクを取る。一方、SI企業は契約に基づいた実装が仕事である。顧客企業は、予算内でシステムを構築させるため、できるだけ多くの機能を発注時に盛り込もうとする。しかし、発注した機能が本当に必要なのかどうかは、システムが完成するまでは分からないのである。
| エンジニアライフ コラムニスト募集中！ |
あなたも＠ITでコラムを書いてみないか 自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある！ コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中 |
アジャイル開発では、「最初にすべてを決めるため、不要な機能が増える」「開発期間が長い」という問題に対して「機能を徐々に追加する」「開発サイクルを早める」というアプローチを取る。アジャイル開発の方針は、以下の言葉に集約している。
「アジャイル開発では、プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を価値とする」（「アジャイルソフトウェア開発宣言」）。
 |
会場は満員 |
■「アジャイルという言葉はキャズムを超えた」
「アジャイルという言葉はキャズムを超えた」――平鍋氏はこう主張する。「スクラム」が一般的になってきたことが、理由の1つとして挙げられる。スクラムは「無駄を取る考え方」で、日本で生まれてアメリカで体系化された。「コンセプトが広がり、経営層の言葉として『アジャイル』が使われるようになった」という。
しかし、アジャイルを現場に採用するのはなかなか難しい。「企業風土や変化への抵抗勢力」が最も大きな障壁になるという。「品質は保証できるのか」「ドキュメントをどう作ればいいのか」「コストはどうなのか」といった意見が出てくる。
では、実際にアジャイル開発を導入すると、生産性は改善するのだろうか。平鍋氏によれば「生産性」「品質」「TTM（Time to Market：製品の市場投入までに要する期間）」が大いに改善するが、「コスト」についてはウォーターフォール開発とそれほど差が出ない。「コスト削減のためにアジャイル開発を導入するのはやめておいたほうがいい」と平鍋氏。
最後に、平鍋氏はアジャイル開発の課題を説明した。アジャイル開発は、10人規模のプロジェクトでは多くの成功例があるが、大規模開発の場合はそれほど成功例がない。また、顧客をずっと開発に付き合わせるため、お互いに苦労する。「しかし、アジャイル開発でできる領域には、アジャイルを取り入れていくべき。顧客が満足し、エンジニアも満足して働ける環境のためにアジャイルは必要」と平鍋氏は語った。
 |
世の中のパラダイム変換に対応し、 日本ソフトウェアの競争力を強化する |
■アジャイル開発の「守破離」
続いて、倉貫氏がアジャイルの実践方法について講演を行った。倉貫氏はアジャイル開発によるプロジェクトをいくつもこなし、TISの社内ベンチャー SonicGardenを立ち上げている。倉貫氏は「守りつくして破るとも、離るるとても本を忘るな」という千利休の言葉を引用し、「守破離」をアジャイル開発で実践する方法を提示した。
「守」：プラクティスを忠実に守る
「破」：“ふりかえり”で自分たちのやり方にあわせる
「離」：ビジネスに合った開発手法にする
 |
SonicGarden 倉貫義人氏 |
倉貫氏は、アジャイル開発でうまくいった事例とうまくいかなかった事例を取り上げた。初めてエクストリームプログラミングを取り入れたプロジェクトは成功したが、次のプロジェクトではうまくいかなかったという。原因は「要件定義や品質保証などは従来どおりのやり方で行うなど、独自のプロセスを踏んだため」だという。受託開発におけるアジャイル開発に疑問を持った倉貫氏は、社内システムでアジャイル開発を実践した。このプロジェクトは、成功を収めたという。その後、倉貫氏はSonicGardenを立ち上げて、アジャイル開発でクラウドサービスを運営している。
さまざまなプロジェクトを経験した倉貫氏は「受託開発とクラウドでは、サービス形態がそもそもまったく異なる」ことに気が付いたという。その考え方が「Point of Sales」と「Point of Use」だ。車の品質は買った時点で、後は劣化していく（「Point of Sales」）。一方、飛行機に乗る場合は、いつでも最新のサービスを利用できる（「Point of Use」）。受託開発は車と同じように、完成した「もの」を売る。一方、クラウドでは「サービス」を売る。
「受託開発とクラウド、どちらがいいというわけではなく、それぞれのビジネスに合った開発手法を選ぶべき」と倉貫氏は主張した。
■まずは始めてみる、それがアジャイル
「『受託だからアジャイルは採用できない』とか、『本当にうまくいくのか分からない』という声をよく聞く。しかし、完璧でなくてもアジャイルは始められる」。倉貫氏はこう提言する。まずは、プラクティスを型どおりに「守」ることが必要だ。
● KPT分析を使った「ふりかえり」を行う
「Keep＝よかったこと」「Problem＝課題」「Try＝またやってみること」を分析。2週間に1回ふりかえりを行う。ノウハウや問題点をチームで共有することができる。
●ペアプログラミング
「ペアプログラミング」には、「いいことはできるだけたくさんやろう。コードレビューはいいことだ。だからずっとやろう」という哲学がある。非常に体力を消耗するため、「2時間で1回」のサイクルを3回行う。
●バーンダウンチャート
進ちょくを「見える化」する。縦軸に作業量、横軸に時間をとり、タスクを0地点まで減らしていく。メールでエクセルシートを配布するということはしない。あくまで、視覚化するのがポイント。
●タスクかんばん
作業を「見える化」し、タスクや不具合を共有する。それぞれの作業には「未実施」「実施中」「完了」のタグを付ける。
●朝会を行う
毎朝、立ちながらミーティングを行う。15分程度でミーティングを終了する。
■偉大な習慣を身に付けたプログラマになれ
アジャイル実践のポイントは「改善を習慣にすること」である。「僕は偉大なプログラマではない。偉大な習慣を身に付けたプログラマだ」というケント・ベックの言葉を、倉貫氏は引用した。
しかし、習慣を身に付けるのはとても難しい。では、どのようにして習慣化すればいいのか。ポイントは2つ、「見える化」と「小口化」だ。大きな作業では面倒くさくても、小さくすれば身軽に動け、身軽に動ければ習慣化できるという。 「毎日歯を磨くのは習慣です。しかし、月に1回3時間歯を磨くのは、習慣とはいえないでしょう」。
重要なのは「自分たちのビジネスに合った開発方法を選ぶ」ということである。そのために、アジャイルは選択肢の1つとして有効ではないか、と倉貫氏は提案した。
――後編に続く。
●Togetterまとめ
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
