2011年8月17日：アジャイルサムライ@ドワンゴ道場

参加者：@kwappa @yamashiro @akitsukada @lchin + ニコモバ、ニコ生の中の人

前回はこちら。

#「第III部：アジャイルな計画づくり」/ ""

第5章 具現化させる

原文タイトル：

5.1 解決案を描く

原文タイトル：

• ふつうやるよね、エンジニア的には
• 企画に見せる、エンジニアから他の人とも共有するというところがポイントかな
• エンジニア間でも、確かに認識のすれ違いってあるよね（実装方法とか）
• 「チームを選ぶことはアーキテクチャを選ぶこと」はそのとおりですね

5.2 夜も眠れなくなるような問題は何だろう？

原文タイトル：

• 最後の虹の言葉は名言？半分冗談かな
• リスクについて最初に話すのはもちろんいいこと。逆に話さないならなぜ話さないのか。
• リスクは最初に直視することが肝心、とデマルコも言っている
• 見るべきリスク・見なくて良いリスクを切り分ける、大事
• 切り捨てるリスクにしても、一度認識しておくべき
• 一度も意識しないで気にしないのと、認識した上で切り捨てるのは違う
• しゃーなしだな！という切り捨てがだいじ
• たとえば急な人事異動とかは現場レベルでは避けがたいリスクかな
• でも属人性をなくしていくという取り組みはできるよね
• しゃーなしだな！

5.3 期間を見極める

原文タイトル：

• どうしても最初のインセプションデッキをコミットメントだと思われちゃいがちだよね
• 例えばWinXP→Vistaで超時間かかったのに対して AppleのOSXの出し方って短期間なサイクルを感じるよね
• ドワンゴだと６ヶ月てのはかなり長い部類、というかほとんどないかな
• 「リリース日」がまずあって、締切ドリブンで作業して、間に合わなかったら謝るというのがありがちかな
• 自社サービスの会社でよくある光景だ
• 間に合わなかったらしゃーなしだな！って。
• 優先度をつけるのが苦手ということもありがち
• ほんとはどうでもいい機能だけど「大事だ！」と主張してる、とか
• そういうのって、機能入れずにおくと結局あとで「結局いらなかったね」ってなったりするよね
• 優先度つけるにしても、「S,A,B,C」とかのランクじゃなくて、順番でつけるとかにしないとダメだよね
• 案件が来たら、まず締切決まってるか確認したりするけど、どうしてもおおざっぱな順位付けになる
• 順位付けするには、TracよりExcelのほうが適してるよね
• 同感です。僕はGoogle Spreadsheet使ったりしています --fukumori(渋谷道場)

5.4 何を諦めるのかをはっきりさせる

原文タイトル：

• 昨日実際に企画/開発者混じってインセプションデッキつくってみたけど、この項目一番大変だった
• 予算て動かせるのか？
• 人件費だったら「よりスキルの高い人」とか、機材費だったらサーバーこういう構成にするとか、そういうところで予算には関わってくるかな
• たとえばコードの品質を下げたら早く作れて、プラスになるか？
• ある程度は早く出せるかもしれないけど、あとでマイナスの要素が大きく作用してきて、結局プラスにはならないよね
• 実際、その積み重ねで破綻している例もある
• ここでいう品質って、コードだけじゃなくてシステム全体の品質だよね
• たとえばテストを略して早く実装作業を終えるとかあるけど、そういうのって結局すぐバグが出て、品質どころじゃなくて機能を損なっちゃう
• 1stリリースは手動でビルド・デプロイしちゃったりってのも品質を落とすことにつながってる
• この話のなかの、「スコープ」ってどこを指してるんだろう

5.5 何がどれだけ必要なのか

原文タイトル：

• 盛りだくさんだな
• 職能横断型、ジェネラリストを推してきたけど、けっこうはっきり役割決めちゃうのかな、という印象。
• ジェネラリストも必要だけどスペシャリストも必要だよね
• 具体的に物事すすめるのに役割は必要だし
• 顧客に対して、バス運転手なってよ感はあるね
• 概算予算
• 開発メンバーは予算に意識を向ける機会は少なめかな
• どちらかというとメンバーまで決まってて、その中の一員として動く機会は多いのだろう
• 実際にインセプションデッキ作ったけど、概算予算は自分のところではしっくりこなかったから削ったな
• とはいえ、規模感は出さないといけないというのはあるね

第6章 ユーザーストーリーを集める

6.1 文書化の難しさ

原文タイトル：

• むしろ書かなすぎだと、もうちょっと書いて欲しいと思う瞬間もあるよね
• ドワンゴ的にドキュメントが納品物ではないというのはいいことだと思う
• 必要なことを文字にして残しておくことはとても大事だ、要件とかたとえばAPI仕様とか
• 日本に限らずだけど、みんな母国語が下手なんだと思う

6.2 そこでユーザーストーリーですよ

原文タイトル：

• 実際ユーザーストーリーやってる？
• やってない
• やってる
• できるポイントでは積極的にやってる
• インデックスカードやってる？
• 品証部署とのやりとりで使ってる。ｲｲﾈ！
• テスト項目自体のレビューはやっている？コードレビューはやらなくてもテスト項目のレビューはするようにしている
• 企画/品証/開発含めテスト項目レビューすることで、仕様漏れや間違いが防げた、情報共有が進んだ

6.3 よく書けているユーザーストーリーとは

原文タイトル：

• 「交渉の余地がある」というのは、つまり「細かく書きすぎない」ということだな

• 顧客と一緒にテストを考えられるということもありそう

• ヤングと仕事をしていて、「ケーキおいしいです(^q^)」が抜けがちだな、と実感することがある

• 開発者が、自分の手を出せるところを始点で考えがちということか

• 縦割りな意識にもなりがちなんじゃないか「俺はDBやるぜ」「Ajaxやる」

• 「独立している」ユーザーストーリーは難しいこともある

• 粒度にもよる

• 独立したストーリーを作る、開発をする、テストをするってのがなかなかできない人もいる

• 画面遷移順じゃないとできない、と考えちゃったり

• ビッグウェイブ・デイブ

• 「非機能要件」というと硬い言い方だけど、必要だよね

• 「デザインはまじかっこ良く」はどうしたらいいんだろう

• コンセプトデザインがあるものだから、それに見合っているか従っているかという観点で見られるんじゃないか

• お客さん、その代理としてのデイブがデザインを見る、エキスパートとしてのデザイナがアドバイスすればいい

• テンプレート、別にこのままじゃなくてもいいけど、いいテンプレだよね

• ユースケース駆動開発に似てるけど、UCの場合は余分なものもついてきちゃってた。このインデックスカードはLightWeightだ

6.4 ストーリー収集ワークショップを開催しよう

原文タイトル：

• ブレストのうまいやり方的なはなし！
• 絵を書くのは重要、っていうか有効、便利。でかいホワイトボードは必要だ
• 「はずかしいアウトプットをしたがらない」という人に対しても、ホワイトボードでぐちゃっと図を書くというのはアウトプットの敷居を下げる効果もある
• ここではワークショップ１回で解決する風にも読めるけど、１回じゃなくてもいいはず
• 1日かけてワークショップやってストーリーが10～40あってそれで6ヶ月の計画が立てられるってのはちょっとしっくりこない。。
• この章は説明がおおざっぱだと思う
• 社内だと、企画者内でのブレスト、開発者内でのブレスト、と段階がわかれがちな気もする
• コンセプトデザイン、絵コンテ、ペーパープロトタイプがここに入っているのはちょっと意外
• その３点はもうすこし詳細なことを表す使い方をしてきたなー
• このためにペーパープロトつくらなきゃってことはない、使えれば使うというのでいいんじゃないかな

---

次回は「第7章 見積もり：当てずっぽうの奥義」からやります。

ドワンゴ道場トップ