改めて「アジャイルサムライ DevLove道場」第一回の振り返り
前回は割と感想に終止してしまったので、もうちょっと具体的に、参考になった点や後で同様の勉強会を開催する時に役立てたい内容を書いてみたいと思います。
おさらいになりますが、前回のアジャイルサムライDevLove道場で行ったのはインセプションデッキの作成、書籍のPxx〜xxに当たります。この作業の結果、「チームQ」ことカイエダさん、イトウさん、ヤマモトさん、滝川の4名の開発対象は「落ちないYammerクライアント『オチナーーイ』」に決まりました。
開発対象の決定
技術にフォーカスしない
技術要素にフォーカスして開発対象を決めるのは止めた方が良いとの事。オレから「Hadoop使ってなんかやってみたい」と言う意見を出したのですが、実際のユーザーは「中身がどんな実装になってるか」には興味がなくて「やりたいことが実現できているか」が興味の中心なので、技術にフォーカスしてしまうと要件の洗い出しのシミュレーションにならないですね。
具体的にオーナーを１人作った方が決め易い
我々チームQの場合は、「ヤマモトさんが現場のコミュニケーションをYammer中心で行っている」「でも公式アプリはしょっちゅう落ちて仕事にならない」という要望が発端で開発対象が決まりました。この後の作業はヤマモトさんが仕事でどうやってYammerを使っているか、アプリが落ちるのはどんな時か、などなど現状をヒアリングしながら作業を進めて行く事が出来たのでスムーズでした。(時間が足らなくなった事はまた別の話)
メンバーに具体的な要望を持っている人がいない場合には「ペルソナ」を設定するのも良いんじゃないかと思います。
アイディア出しはブレストで
開始時点ではみんなノーアイディアだったので、意見が全く出なくていきなり議論がストップする自体に陥りました。そこでカイエダさんの提案でブレストをすることに。といってもポストイットも無かったので、会話しながら各々テキトーな裏紙に要素を書き記して行くというラフな形でした。
アイディアが無い／出ない時にはアイディアの出易いスタイルを取る。ブレストは今まで構えて取り組んでいたところがあったので、ああいう風に道具も何もなくてもいきなり気軽に始めちゃうというのは初体験でした。
我々はなぜここにいるのか
「我々自身は何を得するのか」を考える
これもワークショップ向け。「我々はなぜここにいるのか」と問いかけを始めると「いやぁ、だってそんなのアジャイルサムライの勉強会に参加したからだろ？」とか迷走しちゃわないようにする事が大事。…ってまぁそんな事言い出す人はまずいないと思いますが。でもどんな答えを出してよいか迷うと思います。
まずはちゃんと開発対象にフォーカスする事。「○○○というプロダクトを作る為に集まった」「×××という問題を解決する為に集まった」が大前提。その上で「これを通じて我々も○○○というメリットを得られる」という、開発に携わる人それぞれのメリットも打ち出しておくと開発に対して能動的に取り組める姿勢作りになります。
エレベーターピッチ
文章フォーマットに頼る
「30秒で開発対象の概要を伝える」のが目的のエレベーターピッチ。どれだけ機能があろうとせいぜい1つか2つしか話せないので、一番大事なのは何かを見極める必要があります。
この作業で役立ったのは「文章フォーマット」でした。アジャイルサムライにも掲載されている穴空き文書に単語を当てはめて行けば良いので、文脈から伝え方から1から考えるよりはずっと思考が楽になります。ちなみに我々の開発対象は「落ちないYammerクライアント」なので「このアプリは『落ちない』という機能を持ち…」という、「それって機能なのか？」とやや日本語的にクエスチョンの残る仕上がった次第です。でも大事な事だから堂々と書かないとね。
パッケージングデザイン
絵は後から差し替えられる
まぁ我々全員SEなんだから絵心がある人なんてまずいないはずでして。写真とかイラストとかも事前に用意していることも少ないでしょうからどうしても自ら子供の落書き並みの絵をパッケージデザインとして仕立て上げることになるんですな。正直かっこわるいし恥ずかしい。でも「気に入らなかったら後から差し替えればいい」と思えば結構ヘッチャラです。恥ずかしがらずにガンガンイラスト描いちゃえば良いと思います。ちなみに我々のイラストはカイエダさんが描いてくださいました。
やらないリストを作る
実在のサービス／製品をモチーフにすると機能が洗い出し易い
我々は「Yammerクライアント」が開発対象ですが、実際にヤマモトさんがお使いになっている状況、頻繁に使う機能なんかをヒアリングする事で「やる」「やらない」を選別しました。業務で使ってるので、利便性に関わる部分ははやり「やる」に多く入ってきましたね。
一方でWebで十分なもの・・・グループの新規作成や新しいユーザーの招待なんかはバッサリ「やらない」側に切り捨てています。あと、オレが挙げた「Twitter／Facebook連携」なんかも「やらない」側へ。唯一「後で決める」に回したのは「投稿情報のローカルDB保存」でした。検索を高速化する上で必要か否か、みたいなところは、もしかしたらサービスから取得しても十分早い可能性もありますし、現時点では保留にしています。
「ご近所さん」を探せ
ほぼ手つかず。周りの人どころかチーム内の人間のスキルセットの確認も十分に行えていませんでした。
解決案を描く
この時点でアーキテクチャを図に起こしたんですが、我々は「やらないリスト作成」の段階で「サーバサイド開発はやらない」と決めていたので非常にサッパリとした図に仕上がりました。・・・そういえばまだクライアントアプリを何で開発するか決めてないんだけど、どうするかね？
夜も眠れなくなる様な問題は何だろう？
落ちたらどうしよう
我々のYammerクライアントは「落ちない」ことが絶対条件なので「落ちたらどうしよう」は一番の不安要素です。…なんかギャグみたいだけど。
あと、「落ちない」を担保する為に何しなくちゃ行けないのかは気がかりです。テストの体制とか期間とか。
スキル
クライアントアプリ開発に用いる技術を決めてないので、そのスキルをどれだけの人が持っているか、が気になりました。
期間を見極める
スケジュールはざっくり1.5ヶ月としました。クライアントだけだし、機能も絞ったからまぁこんなもんだろ、と。あとはクライアント開発に選択する技術とそれを持ち合わせた人間がメンバーにいるか、ですね…。
何を諦めるのかハッキリさせる
トレードオフスライダーというパラメタをいぢくってパラメタ変化させるやつですね。ここまではたどり着けませんでした。どうでもいいですがこれって「べつやくメソッド」みたいだなぁと勝手に思っています。
何がどれだけ必要なのか
ここも手つかず。普通はインセプションデッキの作成って半日〜１日かけるものらしいので、やっぱり2時間のワークショップだと最後までたどり着けませんでした。
総括
実際の開発とワークショップで異なるのは最初の「何を作るか」を決める時点じゃないかなと思います。実開発の場合であれば実際に要望のある顧客がいて、どうやって要件を引き出すか、どうやって具体化・簡潔化していくかが重要になると思うのですが、ワークショップの場合には要望まで一から考えなくちゃいけないので、そこをどうやってアイディア出させるかが円滑にワークショップを進めるポイントになる気がします。
どちらにも通じる事ですが、普段からアイディアが出易くなるメソッドをいくつか用意しておいて、それを如何にパッと使えるかが大事になりそうです。
今回一番助けられた言葉は「あとから書き換えられるんで」。なにも今ここで決めた事が絶対じゃなくて、都度見直しが行っていけるというのは随分気が楽になりました。一番大事な軸さえずらさなきゃ、枝葉の部分は調整の範囲ですものね。
蛇足なんですけど、時々アジャイルサムライを読んで確認しようかなあと思っても時間が短くてなかなかそんな余裕がありませんでした。事前に読み込んでおく事がやっぱり重要ですね。今回はしっかり頭に入ってない部分、正直甘く見てた部分もあったので、次回はしっかり備えて予習しておきたい所存です。
