アジャイル開発事例ワークショップを始めます。1時間半を予定しています。まず簡単に自己紹介をお願いします。その後、講演の内容についての質問、それからそれ以外に興味がある点の質問という順番で進めたいと思います。

ニコンシステムの籬と申します。カメラのファームウェアや周辺のアプリケーションソフトウェアを作っている部署にいます。アジャイル開発はかなり有用だと考えていますが、導入するにはまだ至っていません。よろしくお願いします。

ネットイヤーグループの小倉と申します。弊社はWebでのマーケティングの他に、最近はプロダクト開発もやっています。アジャイルに関しては、開発の現場に合わせて様子を見ながら導入したいと思っています。

オージス総研の竹政と申します。よろしくお願いします。会社としてもアジャイルを積極的に推進しています。このアジャイル部会の活動に関しては、アジャイル開発を一般にどれだけ普及させられるかがポイントかと思っています。今日セミナーを聞きに来られたのも、実際にはまだアジャイルを実施していない方たちですが、今後導入するために一生懸命勉強されています。その人たちに少しでも手助けができればと思っています。

アイ・ティ・イノベーションの仁木と申します。この部会にはまだ新参者です。弊社はプロジェクトマネージメントのコンサルティングを主にやっていて、発注側のお客様の立場でPMの補佐や超上流の支援をすることが多いのですが、お客様自身がアジャイルの開発に興味を持って、実際の開発のやり方を今後どうしていくのか、品質管理やマネジメントをどうやっていくのかにかなり関心があったり課題として認識されている方が多くいらっしゃいます。そういったお客様と一緒に色々と検討しているところなので、この部会や今日のセミナーに参加させていただいて、実務での支援の幅を広げていければと思っています。

東芝ソリューションの大森です。SIerですので、お客様からの受託開発と、社内システムや自分たちで使うソフトウェア部品の開発という、大きく分けて2種類の開発をしています。私は今、社内の開発標準を作成しています。ウォーターフォールの開発標準はあるのですが、アジャイルのものはまだありません。その情報収集のために参加させてもらっています。よろしくお願いします。

中菱エンジニアリングの古川と申します。会社は三菱重工の関連会社で、産業機械やエアコンを作っています。基本的に組み込み分野です。アジャイルというと組み込み系はまだまだですが、弊社のエンドユーザーさんでも興味を持たれているようなので、先駆けて情報収集をしたいと思っています。よろしくお願いします。

オージス総研の原田です。社内ではアジャイル開発センターという部署を兼任していて、部署横断的にアジャイルを進める立場にあります。社外の勉強会にも月に10回くらい参加して、色々なところの知識を学びながら会社にフィードバックできればと思っています。よろしくお願いします。

豆蔵の山田と申します。私は一昨年くらいからアジャイルに取り組んでいます。その前はプロセス改善のコンサルだったので、厳格なプロセス定義とゆるやかなアジャイルという両極端を経験しています。最近はスクラム関係の講師もしているのですが、今日のセミナーの質問を聞いていて、皆さん同じようなところを気にしているのだなと思いました。よろしくお願いします。

アジャイル開発部会の主査をしている中原と申します。私は2年前に日立グループを定年退職して、今は大学などいろいろな学校の非常勤講師をしています。大学のシステム設計の講義にアジャイルも少し取り込みたいという気持ちもあります。よろしくお願いします。

ビッグローブの松浦です。今日はありがとうございました。私は今、社内のアジャイルコーチとして、アジャイル開発導入支援や現場改善、組織変革という取り組みをしています。よろしくお願いします。

それでは、セミナーの内容について深く聞きたいところの質問をお願いします。

スクラムの導入はボトムアップとトップダウンのどちらだったのでしょうか。

ミドルアップでした。ミドル層(マネージャレベル)から上げていくというものです。セミナーでも触れましたが、1枚の記事をきっかけに弊社の杉森が情報を得て、実際にやってみようと導入しました。最初はミドルアップで、その後にスクラムをどう使えばよりよくなるかと色々な取り組みをボトムアップでやって、その後トップにも評価してもらい、事業部をあげてアジャイルな開発組織にしようとトップダウンで進めた、という順番です。つまり、きっかけはミドルアップで、それからボトムアップ、トップダウンと融合しながら導入しました。

マネージャ層から上げていくために、社内でスクラムの勉強会などはしたのですか?

勉強会をまずやって、そのあと実際に導入しました。勉強だけしても身につかないので、実際にやってみようということで新サービスを立ち上げました。

プロジェクトを選んでやってみたわけですか?

やってみようと思った時に、たまたま、同じグループのメンバーがそのプロジェクトに参加していて、スクラムでやる気になっていました。

お客様からの請負ではなく、自社のサービスで使うソフトウェアの開発ですか?

ビッグローブは自主サービスなので、自分たちで企画しながら作っています。

その場合のプロダクトオーナーはどういう方がなられるのですか?

ビジネスのことを考えている事業部の人がプロダクトオーナーになることが多いです。

その方の参画度合いはどのくらいですか?

プロダクトオーナーになる人は複数のプロダクトを持っていたり新しいサービスを企画している忙しい人なので、なかなか1つに集中してもらうことは難しいです。でも、1つのプロダクトに集中できるよう環境づくりをしているところです。

サービスにスクラムを導入して成功したというのは、計画通りにリリースできて、サービスもうまく目標を達成したという意味ですか?

はい。

3点お伺いします。アジャイルは、失敗をしても、きちんと計測して、ふりかえって、プロセスを調整すればよい、という考え方だと思うのですが、そういう文化がない場合にはどうやって導入すればよいでしょうか。それから、アジャイルなソフトウェア開発では持続可能なペースで労働することを重要視していて、たとえばeXtreme Programmingでは週40時間以上は働かないことを明確に定めていますが、このような働き方はできているでしょうか。最後に、スクラムを使ったプロジェクトで、プロダクトオーナーやスクラムマスターがいないままで立ち上げてしまったチームはありましたか。

3番目からお答えします。プロダクトオーナーがいないものはまずありません。いないと、そのプロジェクトでどのようなプロダクトを作ればよいかが分からないですから、プロダクトオーナーは必須です。スクラムマスターは、チームが成熟していて自己組織化されたチームになっていれば、スクラムマスターを置かなくても構いません。実際に我々のグループではスクラムマスターなしでやったことがあります。

プロダクトオーナーという明確な役割の人が参画するのではなく、プロダクトオーナーに相当する立場として、たとえばマーケティングの人などが参画しているチームなどはありますか?

それに近いのでは、デザイナーさんやユーザーエクスペリエンスを考える人などが入ってくる場合はあります。

次に、1週間40hについてですが、これは我々にとっても課題です。計画と見積もりも、実際にやってみないと自分たちの出した見積もりが適正かどうかが分かりません。それで40時間で終わらないことがあるので、どうすれば精度を高くできるかをふりかえりながらやっているところです。試みとしては、今どれだけ残業しているかを自分たちで見えるようにしています。残業時間だけではなくて、幸福度というメンタルな面も出しています。開発者はモチベーションや健康に比例して生産性が変わってくると思うので、今日の幸福度を5段階で出すなど、チームみんなで確認しています。

もう1つの文化の導入方法について、まずポイントとなるのは、自分たちで考えてやってみるということです。こういう課題があるのでこのやり方をしてみようと自分たちが決める、決めたことを実際にやってみて、本当によかったかどうかをふりかえる、よかったら他のチームとも共有する、という流れで、1つのチームから他のグループのチームにも文化が広がっていきます。チームごとに集まって15分の朝会をやるのですが、私の職場にはチームが複数あるので、他のチームと共有したいことを話すためのグループ全体での朝会もやっています。自分たちがやってみてよかったことや、気を付ける点、ノウハウを共有する場です。そこで興味を持ったことを教え合ったりします。

それはデイリーでやっているのですか?

はい。チーム単位の朝会は開発のためのものですが、グループ全体の朝会は他のチームに貢献するための会です。こんないい点や悪い点がある、とか、こんど勉強会をやるから興味がある人は来てくださいとか、そういう話を、別のプロダクトを作っているチームが集まって共有しています。

それは全員参加なのですか?

そうです。今は25人くらいいるので、円になりにくいのですが。

今日のセミナーで、壁を作らないだとかみんなが同じ役割をできるようにするというお話がありました。ウォーターフォールのマネジメントでは、こういった作業があるからこういう役割の人が必要だというように考えて体制を作りますが、役割を決めないならどういう人を集めてチームを作っていくのか、教えていただけますか。

チームを作るときにどういう開発を期待しているかをプロダクトオーナーから発表してもらいます。それをチームメンバーが聞き、やりたいと思う人は手をあげます。そこで、マッチングしている人を選び、チームを作ります。

セミナーでコワーキングスペースのお話をされていましたが、それは専用の部屋が用意されているのですか?

いいえ、開発ルームの真ん中などにあります。自分たちの環境の中に普通にあるという感じです。

それは色々なチームに広まっているのですか?

盛んに行われすぎて、その場所が取れないくらい活発に使われています。

育成用のチームで作ったプロダクトを外に出すことはしないのですか?

今はまず経験を積むためにたくさん作っているところですが、今後は出していきたいと思っています。

今はあくまで社内で作って評価するという段階ですか。

そうです。

それは通常の業務内で作っているのですか?

そうです。

チームメンバーの方は、1つのプロジェクトに入っているのですか? それともいくつか掛け持ちしているのでしょうか。

基本は1つです。スクラムマスターは兼務することもあったのですが、1つに集中した方がいいです。

プロジェクトが終わると、そのままメンバーが固定されるのではなく、次のプロジェクトが立ち上がるときに入れ替えをするのですか?

入れ替えもあります。それ以外に、6か月以上経過したプロジェクトでは必ず1人は入れ替えるようにしています。同じチームだとマンネリ化してしまうためです。馴れ合って成長しなくなるので、新しい風を吹き込むためにもメンバーをシャッフルすることは必ずやっています。

それは珍しいですね。普通は「変えるな」が基本ですよね。それはマンネリになるのがまずいからそういうアプローチを取ったのですか?

そうです。それぞれのチームに色がありますが、それだけが正しいわけではなくて別のアプローチもあります。それに気付くにはやはり内側から新しくしていかないと難しいかと考えて、今はそのようにしています。

そうすると、ベロシティは一度落ちますよね。

そうですね。一旦見直しが入りますから。また、新しいメンバーが入ったときには、そのメンバーの成長ストーリーとして、その人が成長するまでのベロシティを含むポイント見積もりをしています。

個々の人の成長ストーリーはどなたが見ているのですか? 入ってくる前は別のグループで誰かが見ていたわけですよね。

入ってきたときに、今までどのようなことをしてきて、どういうことをしたいかを共有してもらいます。つねにチームとして見えるようにしておきます。

開発標準や、それほどかっちりしたものでなくても、チェックリストやノウハウ集などは作られていますか? たとえばプロダクトバックログを使用するときに、性能目標も早いうちに決めなければならないというような、忘れがちだけれど忘れずやらなければならないもののリストなどはあるのでしょうか?

あります。チートシートと呼んでいるものです。たとえば朝会では「昨日やったこと」「今日やること」「課題」という3つの質問をチームで共有するのですが、それ以外にたとえば会議が多いチームでは「何時に誰が集まって何をするかを確認する」などと、チームそれぞれでチートシートを作っています。それから、性能目標などの決めなければならないことについては、チームで何をもって完了とするかを「Doneの定義」としてリストにしています。

それは、見たくなったら見えるように置き場があるので、必要になったら他のチームのものも見に行って参考にするということですね。

はい。各チームのホワイトボードに貼っています。それから、大切なのが、賞味期限を決めることです。今回この期限まで導入します、それ以降はもう一度見直しましょう、というように期間を決めておかないと、改善しなくなり成長しません。

セミナーの中で「ステークホルダーの圧力に負けないプロダクトオーナー」という話がありましたが、私が1年ほどやったアジャイル開発のチームでは、プロダクトオーナーがボトルネックになってしまいました。1年ほど開発したにもかかわらず、バックログを見直すことがなかったからです。優先順位で並んでいなくて、「今回のスプリントは1番と5番と8番と25番」のような状態になっていました。それでは全然うまく行かず、最終的にエンドユーザーに「だめだ」と言われてしまいました。そういうわけでプロダクトオーナー教育が重要だと思ったのですが、ステークホルダーに勝てたという理由はどこにあるのでしょうか? 私が行っていた現場のプロダクトオーナーはシステム会社出身だったので、データモデルやモデリングの話ができるし、プログラミング言語についての会話もできていました。ランチミーティングなどで一緒に紙飛行機を作ったりしてある程度スクラムの流れは覚えてもらっていたはずなのですが、最後にステークホルダーに対抗できるところまで力を持ってもらえませんでした。負けないようにするきっかけのようなものがあればヒントをいただきたいのですが。

プロダクトオーナー勉強会を始めたという話をしましたが、まずはスクラムを理解してもらいます。それから、プロダクトオーナーの人の性格に応じて、「プロダクトオーナーにはステークホルダーと協働してチームになってもらいます」だとか「プロダクトオーナーにはビジョンと権限を持って1つのことを考えてもらいます」という話を勉強会でします。一度言うだけでは分からないので、同じことでも何度も話をして気付いてもらいます。重要なのは、現場でプロダクトバックログを作ったりステークホルダーと協働しながらやっていくのと、勉強会への参加を並行して行うことです。そうすると、学びから得たものと実際に現場で得た気付きとを融合して身につけられます。すると、アジャイルコーチが言ったことはこれだったのか、などと意識しながら発言や行動をしてくれます。

また、勉強会で得たことの他に、期待値の交換をやります。プロダクトオーナーとしてこういう役割があって、こういうことをやってほしいということを言っておきます。ステークホルダーは色々なことを言ってくると思うけれど、それをすべて鵜呑みにせずに、こういうことを言われたらこうしてほしい、といったことを事前に伝えておきます。プロダクトオーナー勉強会のいいところは、座学やワークショップによる自分の気付き以外に、何を期待されていてどう動けばいいのかが分かることです。

プロダクトオーナーとプロダクトオーナーの上司に参加してもらって、こういうことをしなければならないから権限移譲してくださいという話をするのも、プロダクトオーナー勉強会の一環ですか?

はい、そうです。上司には特に初期の段階では入ってもらった方がいいですね。プロダクトオーナーが何をしようとしているかを認識してもらう必要がありますから。プロダクトオーナーとステークホルダーの間で意見がばらばらの状態でチームメンバーに話をされても、メンバーは迷ってモチベーションが下がりますし、時間も無駄になってしまいます。

アジャイルを組織的に展開されているのであえて質問したいのですが、今までウォーターフォールで開発されていたときの品質保証部や標準化のチームがなくなるなど、組織の形は変わったのでしょうか。

品質保証や標準化のチームは、たとえば出荷判定などで活躍されるかと思うのですが、我々は出荷判定会議をなくしました。自分たちのプロダクトを品質の観点から自信を持ってリリースできるか、プロダクトオーナーが要求したことが満たされているか、などを出荷判定会議で確認しなくても、スクラムでは、スプリントの中のデモで、動くソフトウェアを使って確認することになっています。品質保証部の、いつの工程でどれだけバグが出て、どう解析して、どういうリスクがあるか、リスクに対してこれまでどう対応していたか、残存バグがどれだけあるのか、などをつきつめていく作業は無駄な時間になってしまうことが多いです。その時間で、ソースコードをきれいにしていったり、次に計画できるものを考えていくことができます。そのために我々は、開発メンバー全員に同席してもらって、自信を持ってリリースできるかを挙手してもらいます。自分たちは最善を尽くした、動くソフトウェアのデモをして確認してもらった、だから大丈夫です、というところを確認する。そこで1人でもNGと言う人がいたらリリースできないことになっているので、品質保証やテストの担当者は置いていません。

これまでプロセスを提供して守らせる立場にいた人たちは、部署自体がなくなって各チームに行って活躍しているのでしょうか。それとも、部そのものが別のアプローチをするようになっているのでしょうか?

弊社には、標準化グループは今はありません。

部品を作ったりツールを調達する生産技術部のような部署はありますか?

社内の業務をもっと効率化するためにツールを提供しているチームはいます。Redmineのツールを社内用にカスタマイズしたりしています。

社内の開発をアジャイルなやり方にしたことによって、今までとは違ったやり方をするよう変わってきているということですか?

はい。

品質保証部はなくなったのですか?

グループ会社にはあると思いますが、弊社にはありません。品質を上げるためにどうすればよいかは自分たちで考えています。

それで特に大きい事故も出ていなくて、不良は減っていると考えていいですか?

はい。

出荷判定会議をやめたのに伴って、残存バグやリスクの一覧表など、数字取り自体もやめたのですか? それとも、数字はどこかにあるけれども、それをきれいに文書化したりはしないということですか?

文書化しないということです。数字というより、どういうものが残っていて、どれだけ害があるか、今後再発させないためにはどうすればよいかを、ふりかえりとしてチーム全員で考えて対策をします。

バグ件数やバグの傾向分析などはしないということですか?

それもふりかえりのときにやります。

やるタイミングが違うのですね。

そうです。

基本的に、最後にまとめてやるのではなく、常にやっているという形ですね。

そうです。常に問題がない状態に改善していきます。

だから、今までで言うバグ曲線はあり得ないのですね。

書けないですよね。

そもそもテストを先に作って、それが通るようにコードを書いてしまいますから。他の勉強会でのことですが、品質保証部からバグ数を出せと言われたけれども、テストの数イコールバグ数だと言って出すか、ゼロか、どちらかになってしまう、と話をされていた会社さんがいました。今までの観点では書けなくて苦労されているようでした。

品質の観点では、何に価値があるのかを考えるように意識しています。出荷判定の何に価値があるのか、特に価値がなければなくそう、という観点が大事かと思います。

その考え方が重要なのは理解できるのですが、実際の会社だと品質保証部をなくすこと自体にどうしても踏み込めません。アジャイルもそのプロセスの中で動かしてしまうという、誰が見ても無駄なことになってしまいます。品質保証部をなくすという決断はどなたがされたのですか?

品質保証部は分かりませんが、出荷判定会議がなくなったのは、自分たちでボトムアップで働きかけて、出荷判定をやっていたマネージャが「なくしてもいい」と決断したからです。

私もそこは一番尋ねられます。品質保証部の人がいるのですが、どうすればいいですか、と。今のお話では、品質保証部ではなくマネージャがやっていて、かっちりとして組織ではなかったのがよかったのかもしれませんね。

デモのときに品質保証の人が一緒に確認することはないのですか?

品質保証ではなくステークホルダーの人は確認します。その他に、セキュリティテストや負荷テストは必ず通っていなければなりません。それが事前にできている状態でデモをします。従来のプロセスの中でも、本当に必要なものは必ずやっています。

置き換えたということですね。弊社はどうしても品質保証はなくせないのですが、最後にまとめてやるのではなく、タイミングを変えることはできるかもしれません。

そのように対応してくれるならいいですけれど、昔と同じ対応をそのままアジャイルに適用されると、アジャイルがウォーターフォール型になってしまいますね…。(一同笑)

ウォーターフォールでは部品やフレームワークの再利用で生産性を上げますが、アジャイルにそういう考え方はありますか? そこにモデリングはどのように絡んでくるでしょうか?

部品の再利用は、設計がよくできているとうまくいきます。設計がしっかりできてコードを書くのと、できていなくてコードを書くのとでは、生産性やスピードが3倍くらい違います。プロジェクトに応じてモデリングが必要なものと必要でないものが出てくるのですが、自分たちで「この設計図が必要だ」、「これがないと今後の保守ができない」と判断したり、プロダクトオーナーから「これは作ってもらわないと安心できない」と要求されたものを確認して、本当に必要ならクラス図を書いたりします。本当に実装できるレベルに設計が落とし込めていたら、ソースコードは早くきれいに書けます。部品の再利用や保守や変更を考えたときのモデリングや設計の力は、アジャイルでも重要だと思います。

概念モデルは実際の作業に入ってから作るのですか? それともその前に作るのですか?

それはいろいろなケースがあるのですが、たとえば業務システムであれば、データモデルを作ったり概念的な設計をして、問題ないか、本当にこの項目が必要か、などを話し合う機会があります。

データモデルを作るのはスプリントの前ですか?

ケースバイケースです。

スプリントに入ってからは、その中で使うものを設計するのですか?

セミナーでは触れなかったのですが、スプリント0というものがあり、チームを作って、環境を構築し、モデルとして作ったものが本当に実現できるかを確認するようなことを、準備期間として行います。そこで出てきた課題は、設計にフィードバックをして変えたりします。それで下地ができたうえで、スプリント1で開発をするように工夫しています。

それは1つのスプリントの中で行うのですか?

スプリントの中で何ができるかのゴールを決めます。たとえば2週間の中で達成するべきゴールは何なのかと、優先順位を決めます。そして最後にチームでゴールを達成できたか、達成できなかったら次はどうするかなどを確認します。ゴールの計画を立て、実際にやることの計画を立て、実現できる計画なのかを確認するといったことを常にしています。

モデルはその時に使いますか?

ケースバイケースです。モデルを使うと良い場合に使います。

ウォーターフォールを10年以上やっている人は考えを変えるのが難しいとおっしゃっていましたが、そういう人は少数派なのですか?

そうです。うちのチームのメンバーに関しては、従来からやっていた人が2割くらいです。最近入ってきたメンバーにはウォーターフォールを知らない人もいます。先日は、「プロジェクトリーダーは何をする人ですか？」などと聞かれて、スクラムマスターとプロジェクトリーダーの違いで議論したところです。

外部の勉強会は、どのようなところに出られていますか?

私の場合は、アジャイルコーチをしているのでスクラムのイベントが多いのですが、それ以外は開発系ですね。自分でも偏っていると感じているので、マーケティングなどももっと勉強しなければと思っています。領域がいろいろあるので優先順位を付けてやりたいところです。

社内の他のメンバーの方も社外のものを結構受けられているのですか?

はい。グループ全体の朝会の中で、「昨日こんなイベントに行ってこういう気付きがありました」のように共有しています。メールやメッセンジャーなどと違って、直接会話で伝えられるのがいいですね。

以上でワークショップを終わります。ありがとうございました。