例会部会
先号  次号

「第176回例会」報告

PMAJ例会部会 原 宣男: 9月号

【データ】
開催日: 2013年7月26日(金) 19:00~20:30
テーマ: 「アジャイルプロジェクトマネージャーの役割」
  ~アジャイルイノベーション成功の鍵~
講師: 竹腰 重徳氏/(株)アイネット 代表取締役
講師略歴及び講演概要:
    こちら のリンク先の例会案内をご覧ください。

【はじめに】
 アジャイルは、近年、特にWeb系、オープンソース系のソフトウェア開発において重視又は着目されている手法で、利用者の要求を随時取り入れる、プログラムを短いサイクルでリリースする、日々試験の結果をフィードバックする、計画よりも具体的な実践を重視する等、従来のウォーターフォールモデルとは異なった特徴を持つ開発手法です。
 今回はアジャイルプロジェクトマネジメントとアジャイルプロジェクトマネージャーの役割について、(株)アイネットの竹腰代表取締役にご講演頂きました。
 尚、講師はPMAJジャーナルに「アジリティ」のタイトルで連載頂いております。
 以下に当日の講演内容の要点を記載しましたが、講演スライド(60枚)に盛りだくさんの内容が記載されておりますので、詳しくは講演スライドをご参照ください。
 又、当日の質疑応答については、講演中随時受け付ける形で進められましたが、当紙面上は末尾にまとめて記載しております。

【講演概要】
 講師は講演の冒頭で「お伝えしたいこと」として、以下の2点を挙げています。
アジャイルは顧客価値実現のためのイノベーションツールである。
アジャイルPMがアジャイルイノベーション成功の鍵である。
 また、併せて以下の2点についてもキーポイントとして挙げられました。
プロジェクトマネージャーがアジャイルマネージメントのキーである。
マインドをセットしないとアジャイルがうまくいかない。
 以下、この内容に沿って詳細を説明されました。

1.アジャイルの背景
2004年に全米競争力評議会でまとめられた提起書では、製品が世の中に出てから市場の25%を達成するまでに費やした年(=スピード)を記載しているが、自動車が55年かかっているのに対し、インターネットはわずか7年で達成していることがわかる。
同評議会では、「イノベーション」とは、市場と顧客価値を作っていくものであり、チームワークが不可欠となると言っている。
ヨーゼフ・シューペンターはオーストリアの経済学者で、いろいろなものを組み合わせて、新しいものを作るのが「イノベーション」であると言っている。
iPodやiPhoneは、既存のものを組み合わせて製品化し新しい価値を生み出した「ビジネスモデルイノベーション」と言える。
日本では1958年に経済白書のなかで「イノベーション」が「技術革新」と訳されたが、「イノベーション」は、もう技術的な所謂「テクニカルイノベーション」ではなく、品質についても使われていて世の中に普及する新しい概念を全般に指す言葉となっている。
2008年にエリックリースがマネジメント手法「リーンスタートアップ」を発表し、この中で、① 顧客のニーズは健在的なものと潜在的なものがある為、製品を市場に出してみないとわからない、② 製品開発だけでなく顧客開発が重要である、③ 顧客を見つけ仮説で作り反応を見る、④ 金をかけずに仮説を立てて作ってみる、ということが重要と提唱している。これには「アジャイル」がフィットする。
計画駆動型開発(=ウォーターフォール)は、顧客要求が予め明確で開発者側に正確に伝わり、変更が無く、プロジェクト計画が予定通り進み、前工程に間違えが無い、という前提で進められるが、「ビジネスモデルイノベーション」においては、元となる要求がなかなか決まらない、開発者側に伝わらない等のため、この計画駆動型開発では、68%が失敗プロジェクトになっている。即ち、「ウォーターフォール」は「イノベーション」に向いていないのである。
ピータードラッガーは「企業の目的は顧客価値の創造で、顧客の欲求を満足させるもの」ととらえている。顧客の欲求が顕在化している場合は「マーケティング」であり、顕在化していなければ「イノベーション」である。
トヨタ自動車の創業者である豊田喜一郎氏は、米国に行った際にスーパーマーケットを見て、ジャストインタイムを思いついた。それを形にしたのが、大野耐一氏である。今まで、まとまった本はなかなか発行されなかったが、「トヨタウェイ」で明確になった。「トヨタウェイ」の2本柱が「知恵と改善」 (Continuous Improve)と「人間性尊重」 (Respect for People)である。
一橋大学名誉教授の野中郁次郎、竹内弘高が1986年のハーバード・ビジネス・レビューに載せた論文「新新製品開発ゲーム」で、高いパフォーマンスを上げるチームは、「自己組織的チーム」であるとのべている。「自己組織的チーム」はラグビーの「スクラム」と同じで、「アジャイル」の「スクラム」はこの論文から引用されたもの。即ち「アジャイル」は日本発である。

2.アジャイルの価値
重要なのは対話型コミュニケーション、これを重視する。
コミュニケーションは口頭で伝え、余分なドキュメントはいらない。実際に動くものに価値がある。
相互作用が不可欠。開発者、顧客、ステークホルダーが依存してシステムを開発する。
「アジャイル」の価値観は優れた企業の価値観と同じである。

3.アジャイルプロジェクトマネジメント
ジムハイスミス氏が「アジャイルプロジェクトマネジメント」を提唱している。以降にそのキーポイントを紹介する。
「アジャイル」と「ウォーターフォール」の違いは、「アジャイル」は価値の高いものがあったら最優先でやるという点である。「アジャイル」では、制約条件よりも価値を大切にする。
プロジェクト立ち上げ時に作成する「アジャイル憲章」はできるだけ簡潔に作る。又、エレベータに乗っている時間内で読めるようなステートメント(=エレベーターステートメント)の作成に心がける。
「ユーザ要求」は、ユーザの視点にたった簡潔な表現の「ユーザーストーリー」にまとめる。
(=アジャイルのXP (エクストリームプログラミング) という手法)
「ユーザ要求」を「プロダクトバックログ」に入れ、優先順位を付ける。「アジャイル」は優先順位で物を決める。
「プロダクトロードマップ」はオンラインショッピングでの行動と同じである。これは、ユーザ側が準備する。(メンバーになるとか。)プロセスがどのように流れるかを明記する。
時間を区切ってその間(=反復期間)で物を作り、それをいくつか組み合わせた形で「リリース計画」を策定する。
「反復計画」は、2~4週分の「ユーザーストーリー」を切りだして行う。
進捗管理は「デイリースタンドアップ」で行う。進捗は壁に貼って、皆がわかるようにする。作業は、タイムボックス化する。
「反復レビュー」において、「出来ようが出来まいが、時間が来たら終わる。」というのが、「アジャイル」のルール。反復期間中は変更を認めない。オーバーフローしないよう、優先度の高いものから行う。
「反復レトロスペクティブ」では、反復期間中のことを振り返る。アジャイルでは反復が終わったら振り返る。(Continuous Improvement)
「アジャイル(スクラム)チームの役割」で、「アジャイルPM」は開発そのものには責任を負わない。

4.パラダイムシフト (アジャイルマインドセット)
「ウォーターフォール」から「アジャイル」へ考え方を変える。
PMの役割が、「ウォーターフォール」では「指示命令と管理」であったが、「アジャイル」では「リーダシップ(サーバントリーダーシップ)とコラボレーション」である。

5.アジャイルPMの役割
「アジャイルPM」は「アジャイル」の価値原則がわかっていないといけない。
プロダクトオーナーや組織に対し、「アジャイル」の価値を理解させる。
期間の長いプロジェクトにおいては、「アジャイル」と「ウォーターフォール」を組み合わせる。
受託でもできる「アジャイル」開発の実例としては、C & IT社の例がある。

6.アジャイルPMに必要な知識とスキル
必要なのは「アジャイル」知識とスキル(ツールと技法、知識とスキル)、及びビジネス関連知識
人間関係のスキル: サーバントファースト、サーバントリーダシップ:相手のために尽くす。
    アダプティブリーダシップ:相手の成熟度に応じて導いていく。

7.アジャイルイノベーション
製品開発にエンドユーザが参加する形で世の中が動いている、ハイブリッドが決め手となる。
価値指向の契約になってくる。(ISO9001、CMMIのレベル、顧客満足価値)
今後、イノベーションの必要性が増している。アジャイルはイノベーションのツール。
すなわち、「いつアジャイルイノベーションか?今でしょ!」

【質疑応答】
質問:新製品開発において、何が重要ですか?
人が重要です。人との対話で新しいことが生まれます。
アジャイルは顧客との協調。顧客が参加しないアジャイルはありません。
質問:チームでの情報交換で、どこまで形式知化し、どこまでが暗黙知とするか、何か基準はありますか?
会社の方針には従う必要はありますが、残したほうが良いドキュメントはケースバイケースです。
アジャイル開発では、プログラムを読むとドキュメントが残っていきます。
他のチームにはSNSの社用版を作って情報をシェアします。
質問:アジャイルは制約を破っても良いですか?
アジャイルは高い価値を得られるなら、制約を破ってもよいと考えます。
質問:アジャイルの対象はソフトウェアだけですか?
ソフトウェア開発だけでなく製品開発にも利用できると思います。
質問:スクラムは通常何名位ですか?
7名±2名くらいです。
質問:大規模なシステムにもアジャイルは適用できますか?
サブシステムごとにアジャイルを適用し、全体はウォーターフォールを適用することになると思いますが、まだ大規模なシステムへの適用を経験していないため、今は判断できません。

【所感】
 20年ほど前、システムはバッチ処理が中心で、オンライン画面はその入出力機能に過ぎず、プログラム言語もCOBOLが多く使われていてSEやプログラマは比較的技術を習得しやすいものでした。又、要求機能の実現方法も限定されていた為、ユーザも選択に迷う余地が少なかったと思います。一方、現在はブラウザを介したWeb画面がオンライン処理のフロントに使われ、プログラムも部品化して多様化し、言語も多岐にわたっていて、その技術の習得は容易でなく、SEやプログラマは専門化してきています。
 このような環境の変化に対し、従来より使われてきたシステム開発手法やプロジェクト管理方法が通じる訳がないと感じていたのですが、この「アジャイル」に関する講演を伺って、目の前に立ち込めていた雲が開けた思いがしたのは筆者だけではないと思います。
 今回の例会では時間の関係から講演中には充分な質疑応答が行えませんでしたが、講演後の懇親の場に多数の参加者が残り、活発な意見交換が行われたことは非常に有意義であったと思います。
 あらためて、ご講演頂いた竹腰様に感謝いたします。
以上

ページトップに戻る