パネルの部
事例発表の後は、『ソーシャルコーディング革命後の開発委託の世界』と称し、"ソーシャルコーディングクラスタ"な面々を招いてのディスカッションとなりました。
事例発表講演から引き続く形で、司会には和田氏。
パネラー陣には、こちらも引き続き参加の西村氏（委託側、ビジネス面を担当）に加えて、永和システムマネジメントから以下2人が登壇。
- 浦嶌啓太氏（受託側、技術面を担当）
- 角谷信太郎氏（受託側、マネージャ、プロセス面を担当）
計4名が当時を振り返りつつ、トークを重ねていきました。
依頼を受けた際の永和システムマネジメント側の当時の状況について
角谷氏：「（和田氏からの"永和さん的にはどうだったのか、という問い掛けに対して"）先程の話の中でGithubやPivotal Trakcerが出てきていましたが、一応話を聞く前に一連のツールは導入が完了している状態でした。ただ、それ以前までの開発環境でそれらのツールは使っていたものの、いろいろな制約などに引っ張られる形で『（使用感が）何か違うな』と思っていた部分もあり。完全燃焼していない感がありました。それら制約、受託開発での制約がない状態だと、一体どうなるんだろう？と思っていたところ、今回の話（QA@IT）が突然やってきた次第です。私達の方としても、『おっ、来たか！ やってやるぜ！』という思いと『やれんのかな～』『制約が分かれた時に、お前はできるのか？』という思いの両方がありました」
『技術的負債』について
西村氏：「どこまでがビューティフルという自己満足で、どこまでが技術的負債対策なのか。（綺麗過ぎるアーキテクチャ問題）負債を溜め込んででも開発速度を極限まで上げる理由も、ビジネス的にはありえるのではないか。離陸しなければ、そもそも開発が継続できません。現実に責任を負う側からすると、葛藤する部分ではあります」
浦嶌氏：「どこまで追求するかというなら、ケースバイケースというしかありません。今回の場合ではゴールを定めておらず、誰も結末は知りません。より良いものを日々積み上げていくしかないのです。基準になるのは目の前のコードのみ。最初に作ったプロトタイプのまま進むという選択肢もありましたがやりませんでした。予測できない、先が見えない中でうまく進めていくことを考えると、綺麗なコードであることは重要でした」
角谷氏：「プロトタイプは内示をもらってから1か月で作りました。関係者が注目している中でStackOverflowの日本語版を作るために潜入調査などを行い、経営会議をマイルストーンに置いて動き始めました。@ITの人に使ってもらえるように、足掛かりを見つける。5月にこういうのを出します！とアピールするために作りました」
西村氏：「スピード上げてください、と言われたらいくらでも上げられます。でも、そうやった場合で幸せになったことはないですよ、と浦嶌氏に言われました」
和田氏：「ちなみに、プロトタイプのコードは本当に消したんですか？」
浦嶌氏：「はい、消しました」
角谷氏：「でもブランチは残っています（笑）」
浦嶌氏：「ドメインを把握し、表現するかという部分について注力しました。QAサイトにおける質問回答をバージョニングする上でどうやってうまく表現するか。その辺りを踏まえて前に進めました 」
和田氏：「浦嶌氏に、（スライド中に）引用した文章の中でお聞きしたい部分があります。『テストコードは"3回作れば勝てる仮説"』について」
浦嶌氏：「2回目作りなおして3回目作れば、勝てるだろうと。今回は1回捨てて2回目で作りました。お客さんのいる中で、そういうことはそうそうできません。折り込んでおかないといけない部分があります。今回はそれが初めてできました」
QA@ITの今回の案件、これは『特殊解』なのか？
和田氏：「今回お話いただいたこの案件、この案件は特殊なものなのでしょうか？」
角谷氏：「実際受託開発に携わっている人からするとホワンとした回答になってしまうかもしれないですが、こういったものは、"全部特殊"なのではないでしょうか。特殊じゃないプロジェクトなんてないでしょう。ただ、そうやってしまうと禅問答みたいになってしまうので、それは置いておいて話を先に進めましょう。
僕の"マスターセンセイ"の一人、Jim Copliens氏が言っていました。『繰り返し起きる解決策がパターン。3回起きたらパターンです。1回ならアクシデント、2回ならインシデント』皆さんもQA@ITのように実践して欲しいし、実際我々も他の場所でやり始めています。
そういった意味では、このケースも特殊ではないのかもしれません。ビジネスの現場の人が解決したい問題、それらをITを使って解決する。成果を出すためには、何を準備したら気持良く仕事ができるんでしょうか？ ソーシャルの中で、自分が困っていることを頼みながらサービスを作り上げるチームを作ることは、今後絵空事でなくなるのかもしれません。そんな成果を出せる潮流は、今は特殊かもしれないけど、もしかしたら出来始めているのかもしれないです」
和田氏：「この案件だけが抜きん出て特殊という訳でもないし、繰り返し来ているから偶然ではないのかもしれないですね」
まとめ
セッション総括として、和田氏は以下のようにここまでのやり取りを振り返りました。
和田氏：「今回新鮮だったのは、西村さんからこれまでのような回答・意見を聞けたということ。"これで良いんだ"と言ってくれただけでなく、動くサービスとして納品する所まで立ち会うことができた。こういうお話が聞けることは機会として稀だと思います」
西村氏：「実装とは関係のない仕様書という話は時折聞くが、それに比べたら、Rspecなどのコードを見ると読むことができます。コードを見れば良いのでは、とも思いました。結局、ブラックボックスはよろしくありません。（委託側も、可能であるならば）コードを見れば良いじゃないか、と。下手に見ない方がうまく行くというのもありますが、踏み込めるだけ踏み込んでいくというのも、分かった方が良いというのもアリなのではないでしょうか。そんなにうまく行くことはないのかもしれないけど、コードを読めば良いだけの話なのかな、という気もします。テストコードが仕様書です。実行可能な仕様書です。"これで良いじゃん"と」
和田氏：「PO（プロダクトオーナー＝西村氏）がコードを読めた。結果として、不安を安心と思う節目が変わった。今回はそこが重要なファクターとなったのではないでしょうか。"こっちの方が安心できる"という状況を見ることができたのが一番面白いと思いました」
最後にもう1度、"今後のAction"として西村氏から「クライアントを開発プロジェクトに巻き込んで、目標やコードを共有しよう！」、和田氏からは「アクションカードに、今日明日で何が変わったのかをどこかにアウトプットする、ということを、ブログやTwitter、Github…何でも結構なのでやってみてください」と改めて会場の参加者に語りかけ、セッションの幕とともにDevelopers Summit 2013、1日目の幕が閉じました。
