それでは、ワークショップを始めます。まずは自己紹介をしましょう。お名前と会社名、どのようなスタンスでアジャイル開発をされているかをお願いします。今日のセミナーに関するご質問があれば合わせてどうぞ。

オージス総研の原田と申します。今は、ウォーターフォールでプロセスを作るプロジェクトにかかわっているのですが、そこではカンバンによって「そもそもこの作業の終了は何か?」というような議論を交わすという部分にアジャイルを取り入れています。

私もUATで自分のオープンジャムとしてLTをやらせてもらったのですが、その中でもWhyを大切にしていて、「なぜなぜ」を突き詰めていかないとこれからの時代はダメだよね、という話をしたので、今日のセミナーには非常に共感できるところがありました。

オージス総研の細谷と申します。今日はありがとうございました。私はグローバルビジネス推進部に属していて、お客様が海外でもITサービスを提供できるように、海外に仲間を作っています。その中でブラジルの会社と提携関係を結んでいるのですが、たとえば北米のお客様なら、ブラジルのその会社と組んで同じタイムゾーンでアジャイル開発をできます、というような提案をしています。私も元々ウォーターフォールの文化にいたのですが、海外の若い人は、みっちりドキュメントを書くようなことにそもそも興味がないようです。ドキュメントの文化というのはお作法のかたまりなので、すごく時間がかかって、全然グローバル展開のスピードについて行けません。海外の人と一緒に仕事をするには、アジャイルがあたりまえになりつつあるなというのを日々実感しています。一方で日本の中を見ると、受託開発文化が根深くて、受託側は、ちょっとバグがあるとものすごく怒られたりとか、バグがあるとまず謝るとか、そういうところから抜け出せないので、ビジネスの方向性としてそれをどういう風にアジャイルに持って行けばいいのかを他の仲間と一緒に考えているところです。

ニコンシステムの籬と申します。今はカメラの仕事にかかわっているのですが、アジャイルに関しては今のところ勉強中で、まだ実務には取り入れていません。社内的にはウォーターフォールが多いのですが、非常に人数が少ない、1人や2人などで開発を行っているものは、カウボーイコーディングのような内容でやっていることも多いと感じています。そのような状況なので、実際にアジャイルを取り入れて行きたいと思ってこの部会に参加しています。

今日のセミナーについての質問なのですが、アジャイルで定期的にリリースをする合間に、たとえば「すぐに対応してほしい」などの割り込みが入ってきたときには、どのように対処されていますか。

私は自分たちで考えて自分たちで作る形が多いのですが、6か月でリプレースを行った時のことが参考になるかもしれません。私は他の部署から移ったのですが、他部署でありながら裁量を持たせてもらいやらせてもらいました。ただ、そのときに、やはり横から別の作業が入るんです。自分が知らないところで「これちょっとやっといてよ」みたいな仕事が来る。それが、セミナーでお話ししたふりかえりの計測のところに顕著に出てきます。あるとき、「別の作業は入れてもいい、その代わりに、タスクウォールに四角い付箋ではなく細い付箋を貼ってください」ということにしたら、細い付箋の方が多かった月があったんです。そうなると、「これは絶対おかしい」とみんな思いますよね。別の作業なのにメインになっていると。その後、何か頼む時には僕に直接言ってもらい、取捨択一してもらうことにして、「これをやったらこっちができませんがいいですか?」と確認をすると、別の作業は驚くくらい減りました。リプレースはお金にも関連する大きいプロジェクトだったんですが、それと「これもちょっとやってください」という作業を比べるとどっちが大切ですか?と選んでもらうようにしたら、増えていたタスクも徐々に減っていって、集中してやれるようになりました。別の作業に対するベストプラクティスはないと思うんですが、選択させることが重要で、順位を必ず付けて、同率同位はないとした方がいいです。バックログのように、順番を1レーンで作った方がいいと思います。そうすると、何が増えるかがわかるし、それがあふれていいものかも確認できるし、どうしても必要なら人を増やすか金を増やすか時間を伸ばすか物を減らすかのトレードオフがやりやすいですよね。私はそう持っていくようにしています。

河合と申します。仕事は、オブジェクト指向関係の社員研修などをここ10年くらいやっています。私が開発をやっていたのは昔のウォーターフォールしかなかった時代なのですが、99年に出たXPがとてもショッキングでした。ウォーターフォールはコンピュータが中心なんですが、XPは人間が中心と、視点ががらっと変わっていましたから。あと、私はアレグザンダーの本をよく読んでいるのですが、アジャイルと共通点が多いです。アレグザンダーの本も、アーキテクトがビルを作っておしまいではなく、人間中心の街作りなんですね。一気に全部作らなくて、少しずつ作って行くなど、共通点が多い。また、アレグザンダーはQualityをとても追及しています。ただそれは、人間が絡んで計測できないので、ずばりと定義できないんですね。町にしてもシステムにしても、ユーザーや利害関係者がたくさんいて少しずつ価値が違うので、品質はずばりと答えが出てこないと思うんですが、それでも「なぜなぜ」と考えていかなくてはいけないのだと思います。

中菱エンジニアリングの古川と申します。三菱重工の関連会社の三菱航空機で民間機を作っているのですが、そこのカスタマーサポートの部署でエアラインさんにサービスの窓口を提供するホームページを準備しています。元々は別の目的の飛行機の組込みをやっていました。今はアメリカのDoDの調達基準が変わって、繰り返しでITシステムを作れということになり、日本もその方向に行くんじゃないかと考えているんですが、取引先ががちがちのウォーターフォールなので、そこにどうアジャイルを適用するかを考えていかなくてはいけないと思っています。

今の部署でもウォーターフォールではやり切れないところが出てきて、アジャイルを導入した方がいいんじゃないかという話があるんですが、そもそも誰もやったことがないので、どうやってやればよいのかがよく分からない。やろうとすると、やはり研修やOJTが必要になりますが、そもそもどうOJTをやればいいのかが分からないでいます。藤原さんはマシュマロチャレンジをされていたと思うのですが、それをやるきっかけや手ごたえや、それによって新人さんたちがどう変わったかなどを聞かせていただけるとありがたいです。

マシュマロチャレンジは皆さんご存知でしょうか。20本のスパゲティと、1個のマシュマロと、紐とテープが配給されて、それで一番高いタワーを作って頂上にマシュマロを乗せるということを、16分か18分という時間で6人くらいのチームでやる、というワークショップです。TEDの動画サイトですべて紹介されているんですが、アーキテクトや建築家は高いタワーを建てます。でも、MBA卒なんかのビジネスマンは建てられないらしいです。「俺が俺が」になってがーっと作って、乗せてバタンと倒れるという定番のパターンがあるそうです。去年、300人ほどの新人の研修で半日何かやってくれと頼まれて、準備の時間が取れなかったこともあって、マシュマロタワーしかない!と思ったんです。用意は簡単なんですが、得るものが結構あるので、皆さんも是非自分のチームでやってみてください。ふざけていると研修チームの人に反対されるかと思ったんですが、「とりあえずやってみてください、ちゃんとした研修なんで見てください」と言ってやってみました。すると、とても盛り上がって、信じられない高さのタワーを建てる新人もいました。

なぜそれをやりたかったかというと、今よく考えている最大のテーマが「サービス開発とは何か」「どうやったらサービス開発が成功するのか」で、それをトライ&エラーでやっているんですが、そのサービス開発がマシュマロタワーにとても似ているんです。サービス開発では、ちょっとずつ建てて大きくしていけばよくて、何か建ててから最後にマシュマロを乗せたりしないんです。それをメタファーとして、我々の開発はインクリメンタルにやらなきゃいけないし、ユーザーも大切だし、自分の自己実現も楽天という会社の中でしたいですね、という話をしたら、そこそこ盛り上がって終わりました。

そのときに面白かったのが、研修チームの人たちからお礼を言われたことです。「自分たち研修する側としても勉強になった」というフィードバックをいただきました。これは、伝えたいことがあってこその研修なわけで、マシュマロチャレンジというワークショップは、シンプルでわかりやすいため、研修チームとしても『きづき』になったということだと思います。伝えたいものがない研修なんて、若者はつまらないから眠たくなるんです。そうではなくて、自分が伝えたいものがちゃんと伝わって、手を動かしながら頭で理解している過程がとても重要だと思います。でも、300人でマシュマロタワーって、壮絶な絵ですよ。手を動かさない人とかも出てくるんですよ。そういうのを見て、名前を尋ねたりして考えて動くことをうながし、チーム連携させていきます。あと、開発部に所属予定の子などはすごく高いタワーを建てることがわかりました。また、その間、研修チームや配属先の上司にそのフロア内を見て回ってもらいました。見ていると面白いんですね。このチームはすごく考えているけど、そっちのチームはどうしてうまくいかないんだろうって。そうしたら、その後の研修の役に立ったらしくて、意外なところに好評でした。

オージス総研の正田と申します。今日は貴重なお話をありがとうございました。私は組み込み部という所属にいますので、組み込みのアジャイルなど、ソフトだけでなくてハードも込みでアジャイルができるのかできないのかが気になっています。また、教育の仕事もしているのですが、新人教育などでは短期間にすべては教えられないので、取捨選択して大事なことから教えなくてはいけないというところがアジャイルと共通するかと思っています。

「地図を捨ててコンパスを頼りに進め」という今回の講演の中で「地図は作る」とおっしゃっていましたが、地図で決められた道を歩くというのではなく、鳥瞰的な地図があって目標を定めたうえで進む、ということだと思います。そのときに、何を残して何を捨てるかの指針があれば教えていただけますか。

アジャイル開発で最初に捨てたのは、ミーティングです。週次定例など、週単位でやる意味はないと思ってやめました。それで、朝礼だけやるようになって、今はふりかえりしかやっていません。進捗報告会もしません。やめて困ったことはありません。逆に、週に1回1時間のミーティングを10人でやるとしたら、10時間使うわけです。10時間を単価で考えると結構な量になりますよね。しかも生産的でなく何も生み出さない可能性もある。その10時間をプログラミングに費やせるので、単純に工数を稼げます。今のチームでは、たとえばユーザーからの問い合わせの対応など、日々の運用の作業が定常的にあるんですが、それを僕がマネージャになってからは、僕がやるというルールにしました。その分、全部プログラムを書きなさいという形にしたので、メンバーは一日7.5時間勤務のうち、たぶん7.5時間プログラムしか書いていないです。そうすると、成長力などが全然違いますし、びっくりするくらい伸びる子もいる。逆に時間を使わせてもらっている意識が生まれ、そういうのがプレッシャーになって成長せざるを得ないと感じるらしいです。「つまらない仕事を僕がやっている、つまる仕事をお前らにやらせてるんだから成長しないわけないよね」っていつも言ってます。いいプレッシャーにしたいなと思っています。

ニコンシステムの根岸と申します。籬を含め10人くらいのグループをまとめる仕事をしています。そのグループでは一人一人が全然違う仕事をしています。ただ、カメラを作るという同じ目的を持っていますので、チームとしてまとまったやり方ができないかなと考えています。アジャイルを実際に持ち込むかどうかは別として、その考え方を導入できるかと思ってここに来ました。もともとの動機は「アジャイルって何?」から始まって無謀かと思いながら参加させていただいています。皆さんのお話を聞かせていただいて勉強になっています。

東芝ソリューションの大森と申します。よろしくお願いします。社内の開発標準やプロセスを決めたりメンテナンスをする仕事をしています。弊社にはウォーターフォールを前提とした規定(開発標準)があるのですが、2か月などの短いプロジェクトではやり切れません。たとえばデザインレビューの日程調整だけで1週間かかったりするからです。それを何とかできないかと考えています。アジャイルでなくてもいいのですが、何か現状を打開するものを探したいということで、こちらに参加させていただいています。今日のお話には非常に共感しました。お客様に出すものではなく、同じ部署内で自分たちで使うものであれば、アジャイルでやれそうな気がしたのですけれども、お客様に出すものにも適用するには開発標準を変えるまたは広げる必要があり、心配や不安からの反対が予想されます。それに負けずに自分の熱意をどうやって維持するかというところも課題になるかと思っています。

私が入社したときに標準化グループに配属になったのですが、そのときに標準化をやめようと思いました。理由は単純で、存在した標準化が不便になってきていると感じたからです。大森さんほどはっきりと反対されるわけではなかったんですが、標準化をやっている理由が「昔からやっているから」だったりするんです。ノウハウが引き継ぎできなくて、何か意味があるはずだとみんなで考えても答えが出ないことがあるじゃないですか。それを捨てていくと、ほとんど捨てることになってしまいました。昔はそれが必要だったけれども今は合わないものってありますよね。たとえばインフラレベルの規定では、AWSなどを使うならテンプレートを作ってコピーすれば終わりだし、それが標準になると思うんです。

それは共感するんですが、これまでの開発標準と比較して「あれがやれてませんね」のような細かい指摘をされた場合に、それをどう打開するかが問題です。実際に開発している人は手いっぱいなので、少しでも軽いプロセスを求めているのですが、それを導入しようとすると、「それで意味があるのか」などと言われて、肝心のところに話を持っていけない場合があります。今日のお話を聞いていて思ったのは、いきなり規定を変えるのではなく、その前に社内で部品を作っている部署などで実績を上げて、アジャイルでもどんどんいいものができていますということで横展開をすればいいかなと感じています。

この議題については私も言いたいことはいっぱいあります。ただ、私は「横展開」とは絶対に言わないです。できないですから。できるイメージがないです。

前に一度トップダウンで新技術の施策展開をやったことがあります。それはMDAだったのですが、トップダウンですぐに展開するよう言われたので、研究所で練り上げ中の技術をいきなり複数部門で試行評価しました。「使えない」と言われたり、良い結果に対しても「評価はエースのxxさんがやってるんだからMDAには関係なくできたはずだ」などと言われる結果になりました。それで、草の根もやらなきゃならないかとその時に思ったんです。今日は色々とノウハウを教えていただけると嬉しいです。

豆蔵の山田と申します。私はプロセス改善のコンサルや、最近はアジャイルの教育をやっています。標準化のようにプロセスに人を合わせるというやり方と、それとは逆の方向で人にプロセスを選択させるというアジャイルのやり方の両方を持っている方が、プロセス改善の幅が広がるかと思い、アジャイルに取り組み始めました。私自身が「ここが今までとやり方が揃っていないので直してください」と散々やっていた罪悪感もあり…

意味がある指摘ならいいんですけど、ささいなどうでもいいようなものは困りますよね。

はい。そういうのもあって、私も気持ち的にはアジャイルの方を広めたいと思っています。今は教育の仕事も増えているので、人にアジャイルはどういうものかを伝えるときに、どんな話のされ方をしているのかなど興味を持って聞かせていただきました。共感できるところがとても多く、気持ちがすごく楽になりました。

社内でも「アジャイルとは何か」という話をしてくれと言われます。最初のうちは引き受けていて、「こういう考えで、事例もあり、結果も出ました」という話をすると、その場では「うちも導入したいです」などと盛り上がるんですが、全然後につながりません。「あの話はどうなりましたか?」と聞いても「忙しいからできていない」みたいなことになるんです。ですからそれ以来、「とは」話、つまり「アジャイルとは何か」という話は絶対にしないというポリシーでやっています。ただ、それでコンサルをするのはつらいと思います。私は逆にできる人がすごいと思っています。

「すごくいいですよ」と言っても、どうしても気持ち的に今までのところにしがみついていて、別の飛び石に飛び移れない企業さんが多いと感じています。そこをどう持っていけばいい方向に導けるかを最近はいつも考えています。

「人、金、物、情報」のような時代になっているのに、「アジャイルとは何か」を人に尋ねている時点でもう情報が取れていないですよね。そこに対して説明をするのが自分にとってメリットがあるのかどうかが分かりません。それよりもコンサルなどをやっている人は必ず、「何が問題なんですか」と尋ねるそうです。そっちを先にやらないと、アジャイルとは何かを話して「うちの問題にマッチする」とか「これをやったらうまくいきそう」と考える人はやはり少ないでしょうから、大変だろうと思います。

問題は尋ねるんですが、「そこはいいから、こっちの方を教えてほしい」となるんですね。

そのあたりが難しいですね。

オージス総研の伊藤です。今日は勇気をもらえるお話をいただきまして、ありがとうございました。私は、Scrumなどを含めてとびとびでだいたい7年くらいアジャイルの経験があるのですが、本格的にやり始めたのはこの1年半くらいです。アジャイルを本腰を入れてやる前は、当事者意識がなくて「私はこのシステムのことは知らない、やりたくない、だから伊藤さん、やって」というような人たちの、問題が発生したプロジェクトの火消しや後始末が主な仕事でした。その現状を変えるにはどうすればよいかをずっと悩んでいて、1つのあり方がアジャイルなのかなと思い至りました。具体的には、それまでの組織やルールの階層内のロールに関係なく、お客様のためにみんなで頑張らなくてはいけないという風に、チームやメンバーが考えるようになって初めて、いろんな問題を解決できるんじゃないかと思い、それからアジャイルというものを色々と学ぶようになりました。今の時点では、アジャイルはルールを乗り越えたところの継続的な改善だと私なりに理解しています。ただ、はたして自分の認知しているルールというものが本当にルールなのか、周りの人のルールと合っているのか、乗り越えていいルールなのか、あるいは乗り越えなくてはいけないとしてどこまで乗り越えられるのかというところで、悩むことが多い状態です。そこが日々火消しをやっている今の時点での課題だと思っています。

オージス総研の竹政と申します。オージス総研ではビジネスイノベーションセンターという部署で組織横断的な活動を目指して動いています。アジャイル開発に関しては、私どもの会社もアジャイル開発を行っていますが、それとは別にこのアジャイル開発部会でも活動をしています。実はこのアジャイル開発部会は、元々オフショア開発部会でした。オフショアに出すときにどのようなガイドラインが必要かというようなことを検討していた部会なんです。ただ、オフショアの開発手法などは、大手を中心にだいたい確立してきたので、UMTPでガイドラインを作成してもそれほど必要ないんじゃないかということで少し路線を変更し、アジャイル開発部会という形になった、というのがこの部会です。基本的には名前を変えたわけなんですが、オフショア部会の常連メンバーがそのままではなく、新たなメンバーも増えています。オフショア部会のときのメンバーは、アジャイル開発がやりにくいような組織の中で、実際に大きな開発などを先頭に立ってやられていたり、ポジションが上の人が多いのですが、そういう方がアジャイル開発を取り入れないことにはなかなか本流になりにくいかと思っています。大森さんなど、そのような開発の方のご意見も吸収しながらやっていければいいなと考えています。

アジャイル開発のコミュニティは色々ありますが、アジャイル開発が非常に好きな人や、実際にやっている人が集まっているんですね。やっていない人は少し入りにくいと思うので、そういう人とのかけ橋のようなものができないかな、という意図でやっています。

それに関連して質問なんですが、藤原さんは元々SIerにいらっしゃってウォーターフォール型をやられていたとのことですが、現在の楽天ではなく元々のSIerにいたとして、そこでアジャイル開発を推進するということはできたと思いますか?

先ほどのバックログの話のように、やりたいことがたくさんあるので優先順位を付けなきゃならないんですが、それをお客さんに言うのは結構厳しいですよね。ただ、計画通りにやるのがエンジニアの仕事ではないとお客さんに言って理解していただいたことがあって、そのときはウォーターフォールでしたがすごくフレキシブルな開発ができました。一次請けの人に丸投げされたものを「こんなものはできるわけがない」と偉い人に言うと、「そうだよね、じゃあできる方法を考えなきゃね」という風になり、それ以降はずっとそういう柔軟なやり取りになったので、できるといえばできるんじゃないでしょうか。ただ、向こうの人も一緒に勉強してもらわないとならないし、自分たちも勉強しなければいけません。どうやればうまく行くかを真剣に関係者で考えること。それをすればできる気がします。経験的にですが。

そのときはどういう業種のお客さんだったんですか?

外資系のお客様が多く、普通に業務アプリを作ってました。業界はいろいろでしたが、Webを使うものが多かったです。メンバーの年齢が近かったのもよかったかもしれません。

外資系ですか。日本でまだなかなか進まない理由は何か考えられますか?

平鍋さんがおっしゃっていたんですが、アメリカではサービスを自社内で開発していて、SIerという言葉がありません。ですが、日本では誰かに作ってもらうんです。ただ、だから日本じゃだめだと言ってもしょうがないですし、できない理由もない。SIをやっていたときはウォーターフォールだったんですが、ウォーターフォールで成功したので、違うやり方をしたかったんです。受託も楽しかったし、作るのも楽しかった。なのにアジャイルを始めたのは、そこから先に行くため、実績を作るためです。

開発者が楽しいという他に、お客さんを巻き込む必要があるかと思いますが、それにはお客さんにとってのメリットを提示する必要がありますね。

それは難しいのではないでしょうか。成功する方法を教えろということですから。売り込みにくいです。

伝えにくいですが、どう説得すればよいでしょうか。

日本人の友人で海外で仕事をしている人がいます。日本の会社を相手に海外でものを作っているんですが、最近は、2か月でとりあえず作ってみて、できたプロトタイプを見てから継続するかどうかを決める、というお客さんが増えているそうです。海外の会社はそういう契約になっていますね。日本でもこれから増えていくと思います。

やってみて、良いとわかれば増えていくかもしれませんね。

第一次アジャイルブームのときにアジャイルをやっていた人は、今では管理職になっていますが、第一次で失敗した人は敵に回ってしまっています。どうやったらうまくいくかが分かっていないんですね。アジャイルでイベントをしても、昔からいる人に発表してもらうような内容になっているので、興味はあるけれども新しい人には入りにくいです。困っている人と会議ができるようなイベントをすると分かるかもしれませんね。カンファレンスだけでは、その場はよくても先が続きません。椅子を2つ用意して、質問のある人はその椅子に座って、悩みに答えてもらう、そういうアプローチがいいかもしれません。ただ、前もって事前知識は勉強してきた方が効率的だと思います。現在は、アジャイル開発についての情報は書籍もインターネット上の情報も結構あります。

中原と申します。オフショア部会から引き続いてアジャイル開発部会の主査をしています。日立グループで38年間、ソフトウェア開発やシステム開発をした後、今はフリーで大学や専門学校や職業訓練校などの非常勤講師をしています。なぜアジャイル開発にまだ関わっているかというと、38年のうち最後の方はシステム開発の生産技術を担当していたので、そのあたりを改善したいという思いがあるのと、いま大学で教えているシステム設計論の内容も少し変えたいと思っているからです。今は当然ウォーターフォールがメインになっているので、うまくアジャイル開発で改善したいというのもあってここに参加しています。

日立グループはウォーターフォール中心の大企業ですが、生産技術本部などはウォーターフォールに限界があるのが分かっていて、アジャイル開発を普及させたいようです。ただし、すぐには普及しないと思います。なぜかというと、ウォーターフォールの作り方や決められた指標があって、それも長年積み重ねてきたものなのでそれなりに使えるのです。ただ、それだけではなかなかうまく行かない。たとえば今日のお話にあった「Done率」だとか「20%のKPI向上」のような指標はウォーターフォールでは見かけませんね。ウォーターフォールではバグ率やQAの指摘率やレビューの指摘件数などを使っていますが、それをアジャイルの指標に変えていくことの難しさがあります。上を説得するには、ある程度その企業でやっているシステム開発に近い事例で説得しないと、普及させるのはなかなか難しいかと思っています。ウォーターフォールで満足しているわけではないんですが、やめるとなるとその弊害があるんです。やめてちゃんと品質保証ができるのかと言われると、「こうすればできます」と提案するのが難しいです。

今日のセミナーについて質問なのですが、「20%のKPI向上」とか「Done率」のような指標はウォーターフォールでうまく使えるのでしょうか。ウォーターフォールの限界は大抵の人が分かっていますよね。要件が最初からフィックスするわけがなくてある程度の手戻りはあるので、それをなくすためにアジャイル的なやり方が必要だというのはある程度分かっていると思うんですが、今までのやり方をやめてそのように変わるのはなかなか難しいでしょうか。「Done率」などがウォーターフォールの指標よりもいいということがうまく説明できれば広まりやすいかと思うのですが。

経験ベースの話になりますが、僕のところは若者中心のチームなんです。だから、理由は分かりませんが彼らはすぐできるんです。逆に、ある程度開発経験のある人間はついてこれないことが多い気がしています。たとえば朝礼ができません。昨日やったこと、今日やること、課題点を尋ねるんですが、みんな集まって必ず10分以内に終わらせなきゃいけないので、ストップウォッチを使って「10秒経過」のように言うんです。つまりプレッシャーをかけて、タイムボックスを決めるという癖をつけないといけないのですが、それについていけない。「昨日は、えっと、設計をしていました」のように報告にならないんです。きれいなドキュメントは書けるんですが、コミュニケーションがうまくなくて手早く要点を伝えられない。そんなような人にはアジャイルは伝わらないなと重々感じています。関わっている業務の種類だったり、それぞれのやりかたもあるわけなので、強制する必要はないと思います。

ありがとうございます。あまり時間がなくなりましたが、他に質問がある方はいらっしゃいますか?

初めて社内でアジャイル風にやろうとチームを組むとして、仕様決めをする人が重要になるかと思っています。というのも、発注者に当たる、本当に決める権限がある人でないと、言われたとおりに作っても、上長のところに持って行って「だめだ」となると迷走してしまうように思ったんですが、その理解で正しいんでしょうか。それとも、発注者に当たる人よりもまずエンジニアのリーダーの人がとにかく重要なんでしょうか。最初のチームのメンバーの選定の時に、注意すればいい点を教えてください。

初めてやるときにどういうメンバーを集めればうまく行くか、ですね。僕が初めてやったときは、他にメンバーが2人いいたのですが、2人ともスキルがあって、アジャイルのやり方は知らないけど、気が合ったんです。だから「こういうやり方がしたい」というのが伝わってやれた部分があります。その時には、「言われたことをやる」のではなく、自分で考えて仕事を作ってもらおうと試行錯誤していました。メンバー自身も、今までは言われたことをやってきたけれど、うまくいきそうにない方法でやらされていたという意識があったので、試したやり方にしたら大成功しました。彼らからいいアイデアがどんどん出てきました。

上下関係がはっきりしていて、年齢差があって、という関係より、思いついたアイデアをどんどん出していけるような雰囲気やメンバー構成だったということですか?

構成するときに一番気にするのは、一緒に働きたいかどうかです。それ以外では…

すぐ説教しちゃうリーダーとか、何か思いついたことを若手がやったときに「それが何なの?」とか言っちゃうリーダーとかよりも、何でもアイデアを出してごらんとか、そういうのを重視した方がいいんでしょうか。

細かく指示をするマネージャとか、評価のときに細かく見る人とかは、まずうまくいかないです。私も失敗しました。チームで決めたことにマネージャ判断が入り過ぎたら「それなら自分で決めればいいじゃん」と言いたくなりますよね。委譲を考えてやることはとても重要なキーになると思います。

そのような場合は、チーム外の人間のレビュー自体をなくすか、チームに入ってもらうといいんですか?

そうだと思います。口を出したいなら自分でやればいいんです。それが一番説得力があります。

社内でやってみようかというときに、そのあたりは心配です。

過去一回ですけど、大失敗しましたね。あと、フラットにというのが結構難しいです。今は、若手が多くて僕の言うことを聞いてくれるんです、先輩なので。みんな役職とかは気にしないんですが、僕がいてみんながいるという関係です。僕はたまに1週間とか全然口出しをしないときがあって、何もせずに彼らがちゃんとうまく考えて動いているかを横で見ていてチェックしたりするので、チームの一員ではないんですね。でも、世話を焼いてくれるおじさんが近所にいて、面倒な申請などをやってくれる、という感じなので、上下関係ではないんです。年齢だけで先輩後輩というのは私が好きじゃなくて、先に生まれたから偉いわけじゃないとずっと言っています。あとは外国人の留学生も多いので、年齢は重視しませんね。もちろん先輩は尊敬していて、最初は「藤原さん、上座に座ってください」とか言うんですけど、最近は上座にそいつが座っているとか、そういう風になるように色々と工夫しました。たとえばオージスさんだったら評価面談とかはあるんですか? 昇給は年1回とか2回とかですか?

昇給は年1回ですが、ボーナス面談を年に2回します。

ということは、6か月で1回のイテレーションですよね。僕はそれが長すぎると思ったので、人数が少ないのもあって毎月やるようにしています。だから、目標設定や経過報告を1週間や1か月に1回やります。1時間とってランチスペースなどで対面で座って、この1か月に何をやっていたかのプレゼンをやらせて、もっとうまくできるところや僕がサポートできるところを検討したり何に興味があるかを聞くようなことを、1か月のイテレーションでやっていました。初めてアジャイル開発を導入したときは、最初はそれを毎日やっていました。毎日1時間その人と話すというのをずっとやっていたら、3か月くらいかかりましたが、最終的には2週間に1回でよくなりました。朝はまず朝礼を始めて、「昨日あった面白い話」を絶対誰かがしなきゃならないというルールにして、そのネタが面白いかどうかというアイスブレイクをします。それから今日はこういうことをやりますという報告をしあって、それから仕事を始めた瞬間に、まず1人目のテーブルに行って、今日は何をするか、どういうことを考えているかを1時間ずっと聞きます。それが終わったら隣の人のところに行って、「こういうことをやっているらしいけどどうする?」という話を1時間、というのをずっとやっていました。それは、マインドを変えるとかいうことではなく、そこまでやらないと最初は伝わらないと思ったのでやった感じです。それをやりすぎてプログラムする時間が減るのはナンセンスなので、そのコストを割くために自動化だとか僕みたいなマネージャが必要なわけです。

それで、さっきのメンバーを集めるという話ですが、アジャイル開発の原則で「意欲に満ちた人々を集めてプロジェクトを構成します」というのがあって、私はそれに従っています。意欲があるかないかをまず最初に聞くようにしています。

オフショアで連携が悪かったり、リリースが遅れてしまったりで困っているプロジェクトが社内にあります。それを何とかしなければいけないということで、選んだ経緯は聞いていないんですが、アジャイルを導入してみようという話になりました。相性も含めて上司にもいい人を選ぶ必要があるのかと気になっています。

中原さんがおっしゃっていたように、伝えるのが難しいというのはもちろんあると思います。ただ、私は今の会社でアジャイル開発を推進するのには力を入れていなくて聞かれたら答える程度なんですが、苦労したことがないんです。反対されたこともないですし。もちろん、失敗したことはあります。でも、チームメンバーも恵まれたのか偶然なのか、アジャイルなどに興味がある人はだいたいモチベーションが高いのでうまくいくことが多いんです。特殊かもしれないですけど、日韓中ベトナム人とかでやってもうまくいきます。

それでは、時間もあまりありませんので、最後にどなたか質問のある方はいらっしゃいますか?

変な質問で申し訳ないのですが、職場で、周りにうつ病の人や残業が毎月多すぎる人などはいますか?

おそらくいると思いますが、うちだけが特別だとは思わないです。プレッシャーはやはりあります。しかも元ベンチャーですし、ベンチャー時代の気持ちを大切にしようという人も大勢います。どうしてそれを質問されたのですか?

アジャイルの利点として、Time to Marketが縮まるとか、小出しにできるなどと言われますが、その他に開発現場が元気になるというのがありますね。意外にこれに反応する人が多いんです。職場が活性化するとか元気になるとか言うと、他の会社の情報システムの部長さんなど、反応する人が多い。アジャイルをやると本当にそうなるのかが私も知りたかったので、お聞きしてみました。

なるほど。最初にアジャイルをしたときは、開発はとても盛り上がりましたね。メンバーのみんなが口を揃えて言うには、やはり楽しかったと。間違ったことは言わないですし、プレッシャーはもちろん与えるんですけど、成長してほしいという願いがそこにあるわけなので。その後もそれぞれ道は違いますが、みんな活躍しています。

ただ、気を付けなければならない点もあります。今、Scrumが流行っていますね。スタンドアップミーティングをして、バックログを作って、意思決定者としてプロダクトオーナーがいて、定期的に出していくというやつです。あれがマネジメント層にすごく受けるらしくて、北米などはほとんどScrumだそうです。そのブームはすごいと思うんですが、それだけではうまくいかないと思うんです。毎朝朝礼をするだけでビジネスが成功するわけがないんです。僕らはエンジニアだから、技術力が必要です。僕はXPの考え方など、エンジニアリングからアプローチする形が好きで、今のチームは若手の育成が重要なミッションでもあるので、手法としてはXPが近いです。XPをベースにしてまずは底上げをする、そして力が付いたら、もっと加速させるためにScrumを学ぶというのはありだと思う、という伝え方をしています。いいフレームワークではあると思うんですけど、そのための前提条件が満たされていないとだめなのではないかなぁと思っています。スキルのあるエンジニアなら何をやってもうまくいくんですよね。それを履き違えないようにしなきゃ、というのは今のメンバーにも伝えています。小手先でアジャイルをやるんじゃなくて、何のためにやらなきゃならないのか、そのためにはどういうスキルが必要か、をずっと考えてやらせないといけないので、そのための時間を取るために僕が雑用をして、みんなにプログラムを書いてもらっているんです。それが過ぎたら本当に楽です。勝手にやってくれるし、困った時しか僕のところにこないし。

そこまで基礎力が付くと、エンジニアとして何をやらなければならないかを自分で分かって自己完結しているから、Scrumでやらせても走れるということですか。

そうです。サービスを育てたりユーザーと関係を作るほかに、人を育てなきゃならないんです。人としてやらなきゃならないのは、エンジニアならスキルを身に付けることと、もう1つは人間として成長することです。それをやらせないとだめだなと思ったので、さっき言った1か月に1回の1時間のミーティングでは、2つの線を引いて、まずエンジニアとして1か月後にどうなっているかを書かせます。それはみんな書けるんです。でも、次に人としてどうなりたいかを書かせると、全然書けない。考えないことが多いからかもしれません。それで、その1時間のうち45分くらいずっと考えて、まずはこれにチャレンジしてみましょうなどというのを続けていくと、本当に成長したなと感じられますし、逆にそれがあると自分の上司にも伝えやすいですね。彼らがどんなことで悩んでいるかも成長度もわかりますから。エンジニアリングは捨てないし、人間性ももちろん大事にする。まずはそれを今試しているところです。もし彼らが今後SIなどの開発会社に転職などしたらどうなるかは分からないですけど。

紙をいっぱい書いてちゃんとしたものを作れ、とか言うと驚くかもしれませんね。

今、そういう世代が来ていますね。

最初からウォーターフォールは知らないんですか?

知っているけどやったことがないんでしょうね。

学生がそんなことを知っているとは思えないし。

一部の学校では教育でやっているらしいです。そういうのを知っている子がうちの会社に入って、ウォーターフォールの現場でもっとアジャイルにしたいと言う子もいます。

なるほど。

そういう世代がこれから先どんどん入ってきます。

御社でもウォーターフォールでやっているところはあるんですか?

もちろんあります。大きいサービスの場合はライフラインに似たようなシステムになります。だから、そこは守れないとだめなんですが、他の部分ではアジャイルをやれるところはある、という取捨ですね。

アジャイル開発にいかにモデリングを適用すれば効果的かというのがこの部会の研究テーマなので、最後に、モデリングについてお伺いします。藤原さんの経験から、こういう局面でモデリングを使ったらよかったなどというのはありますか?

モデリングというのは何を指しているんですか? データ設計とかですか?

データ設計もありますが、クラス図などのダイアグラムはどういうときに使えばいいでしょうか?

モデリングとの関連についてはちょっと考えてみたんですが、たとえばデータ設計の場合だと、今はRDBをほとんど使っていないんです。どちらかというと硬い感じがして柔軟にやりにくい部分があるので。今流行りのKVS(key value store)を使っていて、それを選んだのは、キャッシュ的に速いとかスケールするほかに、みんなが口を揃えて言うように柔軟に変えやすいからなんです。初めに何でもいいからテーブルを作って、後でなんとかすればいい、という考えが今僕らのところにはあるので、しっかりモデリングをしないと言う方が正しいかもしれません。徐々に改善していくんです。いきなり最終的なモデルを考えることは、うちのメンバーはしないと思います。

UMLではないかもしれないけれども、シーケンス図や状態図のような何かしらの図は書くんですよね。コミュニケーションの道具としての図はあると考えていいですか?

はい、それはみんな書いています。

それは、その場でちょちょっと書いて捨てるんですか?

書いて、写真を撮って、終わりです。

それをみんなでシェアするんですか。

シェアして、終わりです。

特に正式なドキュメントに残すということではないんですね。

ビジネス側に見せるときにはきれいにしなければなりませんが、それ以外は全然しません。全部、タスクボードとホワイトボードだけです。でも、最近の若者はドキュメントを書くということを学校で習っているらしく、ちゃんと書こうとするやつがいるんで、それを真剣に邪魔しています。「意味あるのか?」って。(一同笑)

今は学校でそんなことを教えるんですか?

学校で教えますよ。教えているところが多いんじゃないでしょうか。

放送大学で情報システムの設計のことを話していて、少しだけ聞こえたんですが、WBSの書き方なんかも教えていましたね。

そのカメラに撮ったものは、たとえば将来サービスに手を入れようというときに、また出してきて見たりするんですか?

します。だから、全部残しています。きれいにする必要がないというだけですね。

自分たちが分かれば十分ということですか?

いえ、第三者が見て分からない時点で、たぶんその図はだめなんです。だから、分かるように書くようにしています。

ありがとうございました。それでは、これでワークショップを終了します。