目指せ、現場における最適解！：Agile Japan 2016 レポート(5)

本セッションは、コードクオリティの青木氏と、同社でチームビルディングのサポートをしているダイアログデザインの高柳氏の2名で発表が行われました。

青木氏のプロフィールに

「こうあるべき」という開発を目指すのではなく、現実の予算・期間・リソースの中での最適解を見つけることに力をいれる。

とありますが、まさにそうした姿勢が反映された事例発表でした。そして青木氏が実践していることのよい面を見つけ共有したい、現場で活用してほしいという高柳氏の熱い想いと相まって「そんなことしているんだ、すごいね」で終わらず、「明日からなにかやってみよう！」という気持ちにさせるセッションでした。

セッション開始前

開始前から盛り上がる会場

開始10分前に会場入りした自分の目に映ったのは、熱気に包まれた参加者たち。高柳氏がなにやら説明し、参加者同士が熱心に議論しています。
席について聞いてみると

• Agile Japanに参加した目的
• このD-1セッションに参加した目的
• セッションの内容を誰に伝えたいか

について話していることがわかりました。

自分のチームは「仕事が人についている」という問題を抱えています。この問題に役立ちそうな「チーム構成」や「人を育てる」に焦点が当てられていたことが参加の理由でした。

手渡されたカードにセッションの内容を伝えたい人の名前を書いて、いよいよ始まりました。

セッションの内容を伝えたい人に「チームへ」と書きました

一味違う！？高柳氏の「ガオ流事例発表の聞き方」

最初に高柳氏より「ガオ流事例発表の聞き方」の説明がありました。セッション前、事例発表中、聞いた後、Agile Japan後の5つのステージに分かれ、さらに8つのやることに分類されています。

ガオ流事例発表の聞き方

初めて出会う講演スタイルだったので、とても新鮮でした。
「考えながら聞いてほしい」「事例からよいパターンを見つけ、現場に生かしてほしい」という想いを感じました。この後の事例発表も、参加者が要素を抽出しやすいように前提の提示から始まり、質問・回答形式の構成になっていました。

前提の類似点を探す

ここからは青木氏にバトンが渡され、事例発表が始まりました。

まずは前提のすり合わせからです。
コードクオリティは社員数12名、初回リリースまでの期間は、3～6ヶ月が多いそうです。契約形態は、チームをばらばらにしないため、すべて請負とのことでした。

具体的なチーム編成や複数プロジェクトを並行しているかどうかの話はなかったのですが、自分も10名前後のチームで開発しているので比較的近い状況かなと思いました。

青木氏による事例発表

なぜプロトタイプ開発を始めたのか？

プロトタイプとウォーターフォールの融合

前提の説明の後は「なぜプロトタイプ開発を始めたのか？」という質問から始まりました。

コードクオリティでは、プロトタイプとウォーターフォールを融合したハイブリッドスタイルで開発を行っています。基本はウォーターフォールですが、ウォーターフォールには仕様変更が避けられない、見積もりが困難という問題があります。この問題を解決するために、1～2週間でプロトタイプを作成しユーザーが触って確かめられるようにします。ユーザから得たフィードバックをもとに何度かプロトタイプを作成し、最終的にウォーターフォールに落とし込んで開発するとのことでした。

プロトタイプを導入することで、開発コストを抑え、仕様変更に対応できるようになります。また、プロトタイプを重ねてシステムの要素を半分くらい構成するので、理解が深まり、ウォーターフォールに入る際には十分な見積もり精度を得られるそうです。

請負契約でユーザに安心感を与える

契約形態は、プロトタイプでは準委任契約、ウォーターフォールでは請負契約と分けているそうです。
「最後まで準委任契約でもよいのでは？」と思いましたが、最終的に請負契約を結ぶことで開発者に完成責任が発生するので、ユーザに安心感を与えられるそうです。
請負契約に発注者側の心理的メリットもあるのは発見でした。

プロトタイプ開発で注意していることは？

受け継げるソースコード

「プロトタイプ開発で注意していることは？」という質問には

• システムの拡張における品質を維持する
• 価値のあるシステムを開発する

の2点が挙げられました。

1点目の「システムの拡張における品質を維持する」については、1回のリリースはゴールではなく通過点だという話がありました。システムによっては、ゴールが10年以上先のこともあります。最初のリリースは早くできても、次のリリースに時間がかかっていたら、最終的に品質が悪いことになってしまいます。
そこで、コードクオリティという社名の通り、コードの質を大切にする、つまり、ソースコードを受け継げる状態にすることを意識しているそうです。こうした状態を維持することで、ピーク時の増員も容易になります。開発を支える重要な要素だと感じました。

価値とはなにか？答えは一つではない

2点目の「価値のあるシステムを開発する」については、今までは「予算と時間をかけて不具合のないものをリリースする」という考えが主流でしたが、「不具合があっても予算と時間をかけずにリリースする」にも価値があるケースがあるそうです。そのため、ユーザの意見を取り入れながらベータ版リリースを繰り返すといった開発もしているとのことです。

価値をどこにおくか、なににお金をかけるかは、つくるものの性質によっても変わってくるそうです。ユーザが求める価値を一つに限定しない姿勢が大切だと感じました。

さまざまな工夫で現場の課題に立ち向かう

ここで、青木氏から「ここだけの話」として

• プロトタイプで要件を確定するためには？
• プロトタイプとウォーターフォールで契約を分けるには？
• 「不具合をなくす」ことと「早く便利なサービスを提供する」ことのバランスを考える

の3点について、さまざまな現場での工夫が紹介されました。

これまでの話からは、特に問題もなくうまく回っている開発現場だと感じていましたが、そんなことはなく「少額の予算でプロトタイプを作成してほしいユーザに対して、コストをかけずにどうやって要件確定までもっていくか」や「瑕疵担保責任がないと不安だから全て請負でやってほしいというユーザと、どのように契約を結ぶか」といった課題を抱えており、試行錯誤しながら取り組んでいる姿が印象に残りました。

チームビルディング

スキルは人につく

ここからは高柳氏にバトンタッチ、チームビルディングの話に移りました。

チームビルディングの際、チーム状態を把握するためにスキルマップを作成しているそうです。スキルマップの作成手順は次のとおりです。

1. チームで行なっているタスクを洗い出す
2. 洗い出したタスクを誰がやっているか考える

このような手順で進めるのは、技能よりも役割をベースにスキルマップを作成したかったからだそうです。
技能ベース、たとえばJava Level.1のようなスキルマップでチームの技能を見る方法には

• 技能を持っているメンバー＝作業をするメンバーとは限らない
• 技能ベースで詳細なスキルマップを作成すると管理しきれない

といった課題があります。それよりも、たとえば交渉者という役割がある場合、交渉者はなにを行い、どれくらいのレベルにあるのか、といった粒度で共通認識を持つことができれば十分ということでした。この役割ベースで作成したスキルマップをもとに、チーム毎に必要な人材を定義し、育成・教育に役立てているそうです。

最後に参加者同士でセッションで得た情報を共有し、終了となりました。

セッションを聞き終えて

「ガオ流事例発表の聞き方」を実践することで、自分の現場と照らし合わせて考えることができ、「仕事が人についている問題」を解決するためのヒントを2つ得ることができました。

1つ目は「役割を切り口にすることでチームの実態が見えてくる」ことです。
チームにある役割を考える過程で、複数の役割を兼務しているメンバーがいることに気づきました。兼務しているメンバーには、知識だけでなく仕事も集中しており、属人化や開発速度の低下につながっているのではという推察に至ることができました。

2つ目は「コードを受け継げる状態をつくる」ことです。
コードを受け継ぐのは、メンバーの入れ替わりだけでなく、担当領域の変更でも発生します。コード＝システムを受け継ぐコストが高いと「時間もないし、いつものあの人にお願いしよう」となり、仕事が人についている状況を改善できません。自分の現場でも日常的に起きていることなので、改善の必要性を感じました。

青木氏の苦労話を聞いて、「自分たちはこうやりたい」「こうすればうまくいく」を無理に進めるのではなく、自分たちの考えと現場の状況をすり合わせながら進めることの大切さを改めて感じました。「こうすればうまくいくのに、どうして伝わらないのだろう」と嘆くのではなく、相手がなにを求めているかをしっかり聞いて、お互いの考えの落としどころを見つけながら進んでいきたいと思います。

参考文献

• 「請負で企画・開発・運用・拡張まで担当するアジャイルチーム」（青木智英、高柳謙、2016年）

Agile Japanとは

• Agile Japanとは
• 公式サイト：Agile Japan
• Twitter：@agilejapan
• Facebookページ：Agile Japan

レポートコーナー

• Agile Japan 2016 レポート
• Agile Japan 2015 レポート
• Agile Japan 2014 レポート
• Agile Japan 2013 レポート
• Agile Japan 2012 レポート
• Agile Japan 2011 レポート