それでは、ワークショップを始めます。
最初に一言、自己紹介をしていただいて、今日のセミナーについて深掘りしたいところを中心に議論したいと思います。では、順番に自己紹介をお願いします。

富士通の吉田です。実はアジャイル部会には入っていませんが、UMTPの経営委員をやっているので飛び入りで（参加します）。視察にきたわけではないですが。今日も富士通のメンバーが何人か来ていましたが、あの連中と今、IBMのディシプリンド・アジャイル・デリバリーを毎週輪講していまして、ヤフーさんと同じように、あのぐらいみんなでわいわいとできるような雰囲気を何とか社内に作りたいと思って勉強しているところです。今日は大変ためになりました。ありがとうございます。

スマーテックワークスの鈴木と申します。実は、まだ2年もたたないベンチャーの会社を立ち上げています。ビジネスとしては、テストの自動化を開発して、現在それを展開している最中です。我々のビジネスに関係するアジャイルという部分と、実は我々は社内でもアジャイルの開発をしていますし、ビジネスのシーンでもアジャイルを取り入れています。そういう面では我々は「アジャイル」というキーワードに対しては非常に敏感になっていまして、いろいろなところでの情報収集もしながら勉強させていただいているという形です。
私的には直近、開発に携わっているわけではありませんが、高橋さんのお話に関しては紹介いただいた本を購入しようかというところで、少しは貢献できるのではないかと思っています。よろしくお願いいたします。

豆蔵の山田と申します。今日はありがとうございました。高橋さんとは何度もお会いしているので、「はじめまして」ではありません。私は豆蔵という会社でアジャイルのコーチングや講座の講師をやっています。今日はいろいろ聞かせていただいて共感できる部分がすごくあって、聞いてよかったと思っています。どうぞよろしくお願いします

東芝ソリューションの大森と申します。今日はありがとうございました。社内の開発標準やプロセスをやっています。アジャイルについても取り組みつつある状況です。当社はベンダーですので、社内で自分たち用のシステムを作る場合とお客様から受託や準委任で受けてやる場合と、どちらの場合もアジャイルの使いどころがありますよねというところがいま気になっています。よろしくお願いします。

河合と申します。スクラムはそんなに知らなくて、本を読んで勉強している程度です。前に楽天の藤原大さんという方にお話をここで聞きました。最初は1人で始めて、

そのうち協力会社の人と3人位で始めて、うまくいったので横展開しろと言われて、それにすごく苦労しているという話を聞きました。御社で一番最初に始めたきっかけはどんなところだったかをお聞きしたい。要するにトップダウンで上からスクラムをやれと言われたのか、誰かがやろうと言い出したのか、そこら辺のところを聞きたかったのですが。

ニコンシステムの籬と申します。今回はありがとうございました。アジャイル開発は、当社ではあまりやっていなくて、まさに今、ウォーターフォールのほうにシフトしていっているような状況です。ただ、外の会社はどちらかというとアジャイルのほうにシフトしていっていますので、それがどういうものなのかを少し見たいということで来させていただきました。よろしくお願いします。

オージス総研の原田と申します。私は今さっき来たので、講演の内容を聞けていません。私は現場ではモデラーとして参加していて、お客さん自体はアジャイルでやりたいということは公言していませんが、お客さんのシステムは結構難しくて、そういう複雑性に対処するためには結局、やり方がみんなアジャイルに傾いていくなというのは現場を見ていてすごく思います。その中でやはりプラクティスを入れていくと、失敗した経験から、確かにこういうふうに考えていたら一歩一歩前に進めるかもというようなことが、ピタはまりするなというのが私のアジャイルの印象です。
今日は聞いていないので何を質問していいのかわかりませんが、よろしくお願いします。

今日はありがとうございました。アイ・ティ・イノベーションの仁木といいます。私は、アジャイルに深くかかわっているというわけではありません。私の仕事は、お客様のIT部門の組織の改善やプロジェクトのマネジメントの強化というところで、どちらかというとアジャイルにかかわりが薄いほうです。私どものお客さんでも、やはりアジャイルに着目されていて取り組もうという会社さんが結構いらっしゃって、部会にあまり参加できていない部分もありますが、私も参加させていただきながら勉強して、お客様やIT現場のお役に立ちたいと思っています。今日は本当にいい話を聞かせていただきました。ありがとうございました

オージス総研の竹政と申します。本日はありがとうございました。オージス総研としては、アジャイル開発を推進しています。私のミッションとしては、アジャイル開発そのものというよりも高橋さんの（講演の）最後に議論で少し出てきましたが、デザイン思考や、サービスデザインなどです。アジャイル開発につなげるようなことを考えています。アジャイル開発の上流でユーザーの要求の取得を目的としています。まだまだ普及していない状況で、先ほど話がありましたアーリーアダプターの段階に行っているかどうかというフェーズなので、先ほどのそのフェーズによってどのような対応をとればいいのかという話は非常に参考になりました。ありがとうございます。

アジャイル開発部会の主査をしている中原といいます。私は、もともと日立グループでソフトウェア開発を長年やっていまして、現在は定年退職して大学や専門学校の非常勤講師をしています。日立グループではウォーターフォール中心でやっていたのですが、UMLを社内に普及させるために、UMTPに参加しました。現在、アジャイルに興味があって、まだ引き続き活動しています。よろしくお願いします。

Yahoo! JAPANの荒瀬と申します。先ほどはご清聴いただき、ありがとうございます。私は、先ほども説明したとおり、アジャイルのスクラムを導入してちょうど半年ぐらいたちます。自分のチームだけではなくて、ほかのチームに推進したりサポートしたりしていっているところです。

本日はありがとうございました。Yahoo! JAPANで今、ヤフオクの担当をしている塚越と申します。よろしくお願いします。今までは本当にエンジニアでデータベース回りやWeb回りなどをいろいろやってきて、ちょうど2〜3年ぐらい前からアジャイル開発を取り入れて、プロダクトオーナーをやったり、スクラムマスターをやって、今は推進という形のことをやらせていただいています。よろしくお願いします。

高橋と申します。今日はどうもありがとうございました。実はUMLは竹政さんの本で学びました。赤っぽい色の一番最初の本で学ばせていただきました。会うたびに毎回言います。ありがとうございました。（笑）オージス総研さんとは、かつて所属していた会社で協力会社として入っていたことがあります。

社内のアジャイル開発の推進をしています。僕はもともと30名ぐらいのベンチャー企業にいまして、そこでずっとアジャイル開発をやっていました。その会社がヤフーに買収されることになりまして、アジャイル開発を残したいなというところで、プロセスの標準化をやっている部署に入り、そこで「アジャイルをやるぞ」と旗を振り始めたというのが最初の経緯になります。それから４年やってきているという感じです。よろしくお願いいたします。

自己紹介は一通り終わりましたので、今日のセミナーについて深く議論したいところがありましたら、随時お願いします。

何かやっていたら買収されたと。（笑）でも、それから横展開というのは、トップダウンで横展開しろと言われたのでしょうか。

トップの了承はとっているという感じでした。あとは勝手にやってくれと。だめだったらだめで諦めてというぐらいの感じでした。それがちょうどいいぐあいだったなと個人的に思っています。

結局は成功して実績が認められて広まっていって、皆さん開発がすごく楽しそうな、幸せいっぱいという感じで、僕らの開発の時代は残業や休日出勤は多いし、そんなに楽しいというのはあまりありませんでした。いいなと思います。以上です。

支援チームは何名ぐらいいらっしゃるのですか。

チームとしては私を入れて8名ですが、アジャイル開発の支援という立場では、今は現場に行くのが3名です。それからほかの全社的なところでいろいろな調整をしたり企画を立てたりする1名がいます。

では、チームとしてはいろいろな役割を持たれているのですね。

はい。ほかにも例えば設計技法としてDDDをもう少し周りに広めていこうとか、テストを自動化していこうとか、そういうようなことの担当が数人います。

それはアジャイルのために作られたチームではなくて、もともと標準化や共通的なチームとしてあって。

あってというところです。そこからだんだん役割が微妙に変わっていって、今の形になっています。講演でエバンジェリストという話をしましたが、外のそういった人たちを見つけてきて、「リーン・スタートアップをあなたは周りに広めたいのね。ではエバンジェリストを名乗って」という感じでやるのも一緒にやっています。

最初の段階は、やはりスクラムマスターとしては入らないではないですね。スクラムマスターは、チーム内でなってもらう人を決めてもらうという事ですね。すぐにスクラムマスターになれるものでしょうか。

できる人とできない人の差が激しいです。もともとおしゃべり上手とか賢いタイプの人はすっと立ち上がりますが、「どちらかというと寡黙だよね」みたいな方だと時間がかかる場合があります。

時間をかけてもやってもらう必要があるのですね。

寡黙でも割とロジカルに考えられる人だと、静かだけれどもきちんとできているという形なのかなと考えています。現場で話をしていると、その課題に対する原因は何ですかねという話をしたときに、感情的にはわかるけれどもロジックのつながりはないような原因を出してきてしまったりする。そういうことが起きていると、外れた問題解決をすることになってしまいます。社内を見ていると、そういうのが散見されている。そこをうまくフォローできるスクラムマスターのいるチームは、早く立ち上がる印象があります。

やはりキーはスクラムマスターになるのですか。プロダクトオーナーはどのような位置づけになるのですか。

役割分担なので、どれが一番大事でどれが2番目というのはあまりなくて、プロダクトオーナー、スクラムマスター、開発チームの三者のバランスがある程度とれていないと厳しいという感じはします。プロダクトオーナーがめちゃくちゃ強いという話になると、みんなプロダクトオーナーだけを見て仕事をし始めることになりますし、スクラムマスターが強いと、今度はスクラムマスターをリーダーとして仰ぎ見るように仕事をし始めてしまうところがあるので、そこのところのバランスは結構大切です。

荒瀬さんの話で、プロダクトオーナーが3人いるというようなお話がありました。3人もいるとプロダクトオーナー同士の矛盾がないのかなと思ったのですが、それを交通整理するのは誰なのでしょう。

私のところでいうと整理しているのは自分で、やはり矛盾はあります。例えば見積もりとかスケジュール、規模が聞く人によってずれがあったりしますが、そのずれをスクラムマスターの私が吸収することはあります。

ほとんど同じ質問になりますが、荒瀬さんのお話と塚越さんのお話で、プロダクトオーナーのロールが少し違うのかなと思いました。荒瀬さんのお話では、最初からプロダクトオーナーまで含めたチームっぽい感じがしていたのですが、塚越さんのほうは少し対立軸がある。それをなくしたらうまくいったみたいな話がありました。プロダクトオーナーというロールを若干違う感じで使われているのかなと思ったのですが、そうではないのですか。

プロダクトオーナーが何をするか、どういう戦略で物を作っていくかを決めるだけなので、そういう意味だとあまり違いはない。

プロダクトオーナーもコーディングはするのですよね。

プロダクトオーナーはうちの場合は全くしません。

しないのですか。荒瀬さんのほうはする。

しますね。

だから違うのですね。

そうですね。

荒瀬さんの（話）を聞いて私も理解できませんでしたが、プロダクトオーナーが3人、開発者も3人で兼任でしたね。プロダクトオーナーの調整を誰がするのか。普通1人だとうまくいくように思いますけれども。

プロダクトオーナーはプロダクトオーナー同士で密に連携をとってもらうように、プロダクトオーナー戦略ミーティングみたいなものを定期的にやって意思の統一はしています。そこではプロダクトオーナーだけが集まって、今後の自分たちのプロダクトをどういう方向に進めるかを決めています。

どういう体制にするかはチームで考えるわけですか。

そうですね。

開発標準にアジャイル用のものを追加したというお話があったかと思います。追加したものは、量としては薄いのでしょうか（少ないのでしょうか）。

めちゃくちゃ薄いですね。A4だったら3枚におさまりそうです。なぜかというと、今、荒瀬と塚越から言っていたように、プロダクトオーナーと開発チームの関係性も、3000人のものづくりのメンバーで結構ばらばらで、それを一律に規定するのが難しい。力関係がばらばらなところを標準化するのは非常に難しいので、そこは諦めて標準化をどういうふうに考えるかを考え、「安心してアジャイル開発に取り組んでもいい」という印籠として標準を作ろうと思って、ほとんどスクラムガイドで言っているようなことを標準として改めて社内の言葉やルールと合わせて書き直しました。
例えば、社内でどうしてもやらなければいけないセキュリティー上のアクティビティーみたいなものがあります。そういったものはこのタイミングでやりましょうねとか、アジャイルの形に当てはめている。これを作る際には例えばセキュリティーの部署であったり、J-SOX、内部統制をやっている部署に行きました。こういうことをやりたいけれども一緒に頭をひねってくれないかという話をし、「こういうふうに当てはめたらオーケーかな」「いいっすよ、いいっすよ」「じゃあやります」とやってきました。

わかりました。ありがとうございます。

ロールに関しての質問ですが、高橋さんの自己紹介のスライドにCertifiedの3職（Certified Scrum Professional、Certified Scrum Master、Certified Scrum Product Owner）というのがありますが、ほかのスクラムマスターもCertifiedされている方ばかりというわけではない。

ほとんどいないです。

では、特に推進もされていない。

はい。

スクラムマスターの教育的なものはコーチをつけてやると。

支援チームの私どもやエバンジェリストが行って、例えばデイリースクラムをやっていたら後ろについて、「今こうなっているでしょ、こうなるでしょ、こういうふうに言ってごらん」みたいなことをやったりします。それとか本人が立ち振る舞っているのを見て、終わった後に「あそこのシーンではこういうふうに言ったほうがいいかもしれないね」というようなことをインプットするイメージです。

スクラムマスターの選定や任命はどういうふうに決められるのですか。

スクラムとはこうで、スクラムマスターはこういう人ですと一通り説明した後に、「では、この皆さんでやるんですね。誰がやりますか」と決めてもらいます。

チームで決めてもらうか、立候補される方もいるのですか。

立候補する人もそれなりにいます。半々ぐらいですかね。自分でチームの課題を把握しなければいけなくて、把握した課題に対して自分で対処するかチームみんなで対処していくかを決めて、積極的に動かなければいけないので、無理やり誰かに「お願いします」と頼んで「僕は向いていないから嫌です」という形だと、うまく働かない可能性が高まる。なるべく本人たちでうまいこと決めてもらえるように話します。

いいですね。わかりました。
今、普及もされていて、さらなる展開というのは何か考えられているのですか。

プロダクトバックログを作る。要は要件リストを作る。それをどういうふうに作るかというのは、実はスクラムの枠の中ではあまり語っていません。そこら辺を含めて、ビジネスの全体を回していくときに、開発というのは一部であって、どういうふうに要件を決めていったらいいのだろうというところでのリーン・スタートアップがあったりデザイン思考があったり、サービスデザインがあったりするわけです。その辺をやっていかなければいけないかなと思っています。
あとは、現場は理解し始めました、経営陣も理解しています、真ん中の理解がこれから、という課題。

中間層が理解していないということは最後まで起きるのですね。

起きます。主にそこを最近どうしようかなと。

中間層というのはポジションで言うとどのあたりですか。

一般的に中間管理職と言われている層ですね。とはいえ、ヤフオクはかなり進んでいます。

そうですね。

以前外国人の方を呼んでセミナーを打ったのですが、通訳を頼んだ人がヤフオクのサービスの責任者で、一通り通訳してもらった後に「これいいっすね、やります」と。そういう意味ではすごくついていました。

そういう意味ではすごくやりやすかったですね。

そういうのは最初の段階ですぐにわかる人とわからない人と分かれてしまうのですか。

そこはさっき（講演で）話した普及曲線（で言う、アーリーアダプター）のところで、最初からわかる人はある程度課題意識をはっきり持っていて、社内に事例があろうとなかろうと、やらないことには改善しないだろう、と考えてやってくれる人です。まずそういう人たちを先につかまえないといけないと思っています。
なかなか始められない人も、後になってから「やります」と言ってくる人もいるので、そういう人は最初から無理やりやってもらおうとはしないです。

その辺が面白いですね（笑）。非常に興味深い。

弊社のように、もともとメーカーから来ている会社は、クオリティーアシュアランスという別のチームがいたりします。ヤフーさんの場合は、そういう品質保証は別のところがやるということはないですか。

今はないです。経営陣がかわる前まではありました。

そういうところがあると、それとの折り合いをアジャイルはどうするかというのが結構大きな課題に（なる）。

一度、そういったチームにスプリントレビューに毎回来てもらうように声をかけて、と現場にお願いしました。その場で精査はできませんがクイックには見ることはできるので、最後にがっと（まとめて）やるよりは幾らかいいのではないかとは話しました。ちゃぶ台に全部ご飯がそろってからガシャンとひっくり返されるより、お茶を置いたらガシャンのほうがまだましでしょうという話をよくします。（笑）

余談ですが、この前、NECさんの話を聞いてなるほどなと思ったことがあります。QA側から見る時にバグの目標値というのがありますよね。何キロステップの間にバグがこのぐらいあるはずだからと。それをどうするのかということが困りますと。アジャイルでは、例えばtest-drivenでやっていたら、それを数えていたらバグにならない。バグを起こすことがまず開発なので。そこで、どういうものをバグとして見るか、どういうものはバグとして見ないかというのをあらかじめ決めましたと。なるほどなと思ったのは、スプリントが終わって次のスプリントで出たものはバグですと。

僕も昔、それやりました。（ほかにも、）すぐに直さないのはバグにするとか。意識的にバグとして残すようなところはやったりしました。

それが、キロステップ当たり何個でということで品質を見るとおっしゃっていました。

実は私はSIerさんのコーチングに入ったことがあるので余談でお話しすると、いわゆるバグ曲線を描くときに、「リリーススプリントでそれをやってください」と言いました。「もし本当に必要だったら、リリーススプリントでそれを入れて1スプリント回してください。ただ、1スプリント分の費用がかかりますけどね」という形で。

リリーススプリントというのは何回かやるものですか？それとも最後に一回だけ？

リリースする前にやるものです。

NECさんは3回に1回、バグだけ見るスプリントがある。3回に1回だけそれをはかる。

面白いですね。

しかも3回に1回だけドキュメントを書くのです。ストーリー、機能はふやさないで、ドキュメントを書くのと、残っているバグを潰すのを3回に1回やる。

それは、出荷というかリリースを伴うからそのタイミングでというわけではなく、
品質を把握するために定期的に実施するのですね。

全体が12回のスプリントだったら、3回に1回というのを4回まわす。

同じ課題があるので非常に参考になります。

僕がここで説明してもしようがないですね。NECさんはちゃんと発表されているので、そちらを見て下さい。

ヤフーさんはQAをなくした。QAがあるときと今ないときとで品質は変わりましたか。

今、課題になっています。

リリース後のトラブルの状況とか。

実は不具合の件数としては増えているというデータが出ています。ただ、リリースしている回数そのものが大分変わっています。例えばリリースごとに不具合が起きる比率で数えたときに、それがクリティカルなレベルなのかは、まだ確認できていません。ただ、肌感として増えていますし、最近もヤフーメールが長時間とまったりしてご迷惑をおかけしていますが、そういう「ちょっとまずい感じがするね」というのは最近実際に出ています。
ただ、早く出して早くマーケットに働きかけてシェアをつかみに行きましょうというときに、副作用として出てきているというところはあります。解決していくべき課題です。

テストをなるべく自動化して、生産性というか開発効率を上げましょうということがあるのかと思いますが、ほぼ100％自動化できるものなのでしょうか。

それはコードカバレッジの話をされていますか。

コードカバレッジのほうもあるだろうし、Seleniumなどを使えば、多少は自動化できますよと聞きますが、そうはいっても100%の自動化が可能なのでしょうか。

どうですか。

ヤフオクの場合だと、単純なユーザーインターフェースが入らないようなもの、例えばMAPIみたいなものはなるべく自動テストというか、test-drivenで書いていって、ユーザーインターフェースが絡むようなものに関しては本当に最低限の単体テストだけ書いておいて、あとは手動でごりごり計測しているような状況です。

今回は過去に開発したもの、前のスプリントでやったものでここをさわるから、そこは手動で再確認しようかみたいなものが入るということですか。

前のスプリントというか、GitHub、Jenkinsみたいなものに使っていて、コミットしたタイミングでそのまま自動テストが走ってチェックされるような状況です。そこで、テストを通過しないものはそのままメールが飛んできて、すぐ直しましょうみたいな。機能ごとのブランチみたいなものが分かれていて、そこが100％になってからリリース用のブランチに回されていく。

ここで「手動でやらなければいけないテストがありますよ」みたいなのは、印をつけておくか何かするのでしょうか。

印とかは今のところつけていません。

では、手動のテストをもう一回やる必要があるかないかも、変える内容によると思いますが、大事だから確認しなければねというのは、タスクの洗い出しなどをしているときに忘れずに思い出そうとか、そういう感じでしょうか。

タスク自体にテストというタスクを張って。

「○○テストをもう一回やること」みたいに。

そこは特にないですね。リリース前に全員で一回、全部さわってみるというところでカバーしています。

わかりました。
そのリリース前とおっしゃっていたのは、さっき品質を上げるためのスプリントをおっしゃっていた、ああいう特別なスプリントでやるということですか。

特別にはやっていなくて普通のスプリントをやっていて、ストーリー、プロダクトバックログアイテムがだあーっと流れていて、ここまで行ったらリリースしますという線が引いてあって、その直前にテストストーリーみたいな（ものがあります）。

みんなでさわる時間を見込んでおこうという。

そうですね。テスト用スプリントのバックログアイテムみたいなことをやって、それを話すような状況です。

もしかしたら今、想定しているシステムの規模が違うかもしれないなと思いました。今、塚越が話しているのは（スマートフォンの）アプリの話です。iPhoneなどのアプリはシステムの規模としてはそんなに大きくない。ですから、直前に2日ぐらいあれば相当見られます。一般的に受託会社がやる大きめのシステムの場合はさすがに無理な話なので、もう少し文書化するというような作業が必要です。

今まで社内で適用していて、この分野にはちょっと合わないなという分野はありましたか。

社内でレガシーな状態のシステムを一新しようというプロジェクトがあって、それは見事に向かなかったです。無理でした。アジャイルとかではないのでという話でした。
面白いなと思うのは、見える化はやはり効きます。成果が見えるようにするというところで、やらなければいけないことをずらっと並べる。選挙に当選すると名前のところに花をつけますよね。あれを終わったところにつけていく。どんどん花が増えるようにする。かなり見ばえがよかったですね。（笑）「やっているな、これは。進んでいる、進んでいる」と。

そういうアウトプットや進捗なども、壁にポスト・イットなどを使用するではないですか。非常にわかりやすいですが、後に残しておきたいときはどうやって残されるのですか。

僕のところは、張っているものをそのまま保管しています。

それ自体を。

見たいときに見る。今回みたいな過去にさかのぼってスプリントを発表するときはそこから引っ張り出してきて、このときこういうことがあったなみたいな感じで作りました。

そのままなのですか。

アルバムをひもとくように。

当時、字が汚かったなとか。

結構な量になりますよね。

はい。

僕の場合は、写真に撮ってそのまま残している状態です。

それはありかなとは思います。写真だと文字が識別できないときもありますね。でも、活字落としはつらいですね。

まめなチームはやっているところもあります。

やっていますか。

チケット管理システムにタスクを出し終わった後に、わざわざ手で打ち直して両方アップデートする。「それはしんどくないですか」「うん、しんどいです」「やめないの」と聞いたら「やめないです」「頑張ってね」みたいな。

その情報をとっておくのは何のためにですか。

チケットごとにコメントを残せる（から）ではないですか。チームとしてはそこでやりとりを残しておきたかったらしい。その用途で使っていたのです。

過去のやりとりをどこかのタイミングで使うことがある。

スプリントの中で皆がわあーっとやりとりするらしいので、忘れてしまうのだと思います。トラッキングの目的というよりは、スプリントの中での記録用。

呼び起こすための。

呼び起こすための。会話の記憶は紙には残しづらい。チーム全体的に記憶力に自信がない場合は、そういうふうにしておくほうが後でいいのではないか。

ユーザストーリの分類をなさったりしますか。アプリというかそのものの開発と、それ以外に「課題」という分類を用意しようとか。社内で、開発するに当たって例えばGUI部品が候補が三つぐらいあるけれどもどれにしようかと選ぶところを「課題」というユーザストーリに分類した結果、最初のころは課題が多かったが、だんだんアプリの本体の開発が中心になりましたというようなことがありました。そういうふうに区分けするとやりやすいということはありますか。最初はやってみたのですが、それはそうだよねという感じになって、別に分けなくていいのかなとか、あるいはもっと工夫をなさっている方たちがいらっしゃるのか。

個人的に今、質問のポイントがつかめなかったので、すみません。

ユーザストーリを追加していくときに、例えばこれは実装側からの実装上に当たってのお願いですというような、何でもいいですけれどもユーザーストーリーをさらに整理するような観点は何か必要なのでしょうか。

ユーザーストーリーをさらに分解して整理するということですか。

分解というか、仕様が決まって作っていくだけというユーザストーリなのか。それとも仕様というか欲しいものはわかっているが、そこのグラフを出して表示するとあるけれども、グラフを描くためにまずどのGUI部品というかグラフの部品を決める必要があるというユーザストーリなのか。後者の場合、これは技術調査のストーリーですというふうに印をつけて、この技術調査が終わったら本当のグラフを描くというのを実現しますということをやったことがあります。

なるほど、理解してきた。（荒瀬さん、）理解できたでしょう。

はい。つくりたいものがあって、その中でここまでが調査とか部品を入れる、ここからが実装とかですね。

そうです。やりたいことは見えているけれども実現手段がわからないとか、何か情報を集めないと着手できないとかそういうのがあって、それとあとやるだけというので大きく分けてみました。あるいはほかに何とかというのもありましたとか、特に分けなくてもうまくいっていますとか、その辺をお聞きできたらと。

私のところは分けました。分けてよかったのは、見えない部分があるので、そうすると予想以上にそこのストーリーを完了させるには時間がかかりますと。このストーリーが終わらないと次のストーリー、その後を引き継ぐストーリーがスパイクになってしまうので、それを完全に分けることによって別なストーリーに着手できたりしました。こちらのほうは時間がかかりますが、ほかのメンバーは待機するのではなくて、その次の全く別のストーリーに手がつけられたので、そこはよかったと思います。

そうですよね。私たちの中では、プロダクトオーナー自体はいつも話をしているから、これは難しい課題をやっているからねとわかりましたが、その上の「アジャイルをやっているって、どんな感じなの」みたいな上司に説明しているときに、「なぜこれだけいつまでも進まないの」と言われて説明しにくかったので聞きました。わかりました。ありがとうございます。
さっきペアプログラミングを自主的にするようになったとおっしゃいましたが、例えば最初にペアプログラミングをみんなやってみようよとやってみて、気に入ったチームは続けるみたいに推奨なさっているのでしょうか。

特に推奨していませんが、開発チームのほうでやりたいという人が勝手にやっているような状況です。

それも、作ろうとしているシステムによって向き不向きというより、やはり人の性格などがあって、一律いいとか悪いとかは判断できない。

そうですね。やはり合わない人はあまりやりたくない、1人で作ったほうがいいみたいな人も中にはいるので。たまたまうちのチームが、自分の書いたコードも共有しておきたいし、ほかの人から指摘をもらいながらというのも意外と楽し（く感じてい）そうで、しゃべり好きが好きだったというのもありますね。

経験の浅い方に有識者の人がついてあげて、技術力も上がるというようなパターンが多いのでしょうか。

あまり技術力の差はないような人たちでやっています。

では、外部の目ではないけれども、やっているそばからコメントしてもらったほうがはかどるならと。あと、さっきおっしゃっていた共有がその場でできるから。

そうですね。

わかりました。

ペアプロを導入したことで、効率といいますかコストパフォーマンスはどんな感じでしたか。

実際に計測していないので何とも言えないのですが、やはり感想的な話だと、疲れるというかコードで一行一行気が抜けないような書き方にはなったという話は多かったです。1人で書いていると、妥協したような書き方が出てきてしまいますが、人の目があるとやはりちゃんと書かなければと。

ただ、純粋に積み上げる工数という観点では、ペアプロをやると若干上振れするというか。実装フェーズにおいては2倍になるわけですよね。

実装フェーズでは2倍になる。

要は2人分というだけですけれども。その後、同時にレビューしているとか、そういうところでその後のフェーズも絡めて考えるとだんだん目減りし始める。コスト的な観点でいうと、2倍までは行かないけれども、そこそこかかっている。ただ、1人でぼうっとスタックしている時間の分、工期としては短縮できているので、さあこれをどう考えようというのは悩みどころですね。

そうですよね。それに否定的な人にどう説明するかというのが難しいかなというのがありまして。

途中で言われていた、何か問題があったときに誰でも直せるとか誰でもレビューできるというところにきいてきている。

そうですね。

あと1人で作っていて、ここをどう実装しようかと、とまどうときがあります。それが大分減ったというのはありました。

はまると大体ヤフーニュースを見ますからね。今、宣伝をしたつもりですけれども。（笑）

疲れたなという。

ペアプロでやると品質が上がったのですか。感覚的な感想でよいです。

感覚はコードの読みやすさみたいなものは上がったように感じます。

バグ件数までは、わからないですね。

件数ははかっていないので何とも言えないです。ただ、構造化の仕方、あとは単純な話で変数名や関数名のつけ方みたいなものはよくなりました。
ひどい話、昔のコードを見ると、マニュアルでファンクション名「test」とか「tmp」ファンクションみたいなよくわからない（ものがあって）、ふざけるなと思いました。そういうのはまずなくなりました。

それはいい。では保守に役立つ。

保守には役立つかもしれません。

特にそのへんはヤフーの中でクリティカルにきいてくるところで、システムを出してからリアルなユーザーのフィードバックがばんばん返ってくるので、そのときになるべく早く手を入れられるソースコードになっていないと、出すスピードがおくれていってしまう。そうするとどんどん評判が下がっていって、ビジネスとしてもうからなくなってしまう。実際、問題になってきています。早くやろうという意識がついてきたので、早くやるために技術の面では何を担保しなければいけないのかという話が、ようやく深まり始めたなというところですね。

ほかにありますか。モデルの話はなかったけれども、UMLは設計あたりに何か使われたのですか。（笑）

ちゃんと作るとかはやっていなくて、「ここを作るときに迷っているんだよね、設計のやり方をどうしよう」というコミュニケーションにたまに使ったりする。

そういう上位のアーキテクチャみたいな設計書などは作りましたか。

必要であれば作る。

モデルで作りましたか。

モデルできちんと作って残そうというのは特にはありませんが、複雑だったりしたら後から誤判断にならないようにキープしておこうかなぐらいですね。

明示的に書いて残しましょうではなくても、打ち合わせでこんな感じでと言えば皆さんわかるぐらいに理解というか、UMLの読んだり書いたりは皆さんできますよと。

きちんとしたUMLとは違うかもしれませんが、お互いに共有できるぐらいにはなっています。

少し違うかもしれないけれどもちゃんと伝わっている。クラス図とシーケンス図とさっきおっしゃった配置図のあたりを使われる。

そうですね。

シーケンス（図）、クラス（図）、ユースケース（図）、サーバー構成などは残しますし、残し方はきれいにドキュメントにする場合もあれば、おっしゃるとおりホワイトボードにざあーっと描いて、それを写真に撮って、ドキュメントとしている場合があります。

紙に描くだけ描いてタスクボードの隣に張ってあるだけとか。

あとはホワイトボードに描いて、「消さないで」と書いてあって、それはホワイトボードの意味がないみたいな。（笑）

乾いて消せなくなってしまう。

乾いて消せなくなってしまう。除菌の拭くやつで（拭き取ると）すごくきれいになる。

よろしいですか。では、時間になりましたので、以上でワークショップを終了します。どうもお疲れさまでした。