日本の水産物の最大の取引相手は、輸出入ともに中国（香港を含むとする）なんだそうです。輸入総額が輸出総額の8倍ぐらいあって、やはりあちらは単価が安いからなのかな〜などと愚考しております。

さて、社内勉強会で、GMOの藤村さんをお招きして「アジャイルなオフショア開発」と題してのご講演をいただきました。
タイトル的にはオフショアとアジャイル！？ん！？！？ですが、これが結構たのしかったので、記憶を頼りにメモ。

ざっくり内容

• 口にすると成就する（かもよ！）
  • なんとかかんとかっていう女優さんが好きだー好きだーと言っていたらとツーショット撮影出来た話
  • 仕事もそうだとおもう！
• オフショアの歴史。
  • 90年代からのもろもろ
  • トレンドが中国やベトナムやインドを行ったり来たり、今はミャンマーが熱かったり
  • 中国はもはや安くない。政治的な問題もある。インフラや技術力や日本語使えるエンジニアが整っている。
  • ベトナムは親日だし人件費わりと安いし、インフラや技術力や言語ではやや劣るけどバランスがとれてる
    • 今回はベトナムとのオフショアの話。ハノイ工科大学みたいな高度な拠点もあるので。
  • インドは英語的なメリットとか技術力はやっぱ高い。人件費はそんな安くない。
    • なので、やすさではなく技術力を重視したプロジェクトが多そう？
    • 優秀なエンジニアが集まりにくくなってる
  • ミャンマーは安い
• 今回のお話はベトナムの会社とオフショア
• できないことを諦める
  • 一回のやり取りで完成品が上がらない→諦める
  • 見積の精度が上がらない→諦める
  • 95%からが長い→諦める
    • 細かい修正にいちいち指示書とか超ダルい
  • そこで、RFCモデルの提案（詳細後述）
• 研修はしないとだめ
  • 自習に期待するのは甘かった
  • 地頭がよく技術力はあるが実務的なところが弱い
  • 研修は今のところやりっぱなし感ある
    • フォローアップは課題

RFCモデル（僕の理解）

基本コンセプト

• Request for Commentsではありません。念の為
• ざっくりしたものを作ってもらう。95%までやってもらう。
• 残りの作り込み

内容

• HQ側(受注側、受け入れ担当者)がバックログを準備
  • 仕様をtrelloに書く
• 作業側がタスクに分割
• 通常WIP、Reviewと経ていくことが多いが・・・
  • Rough:70%程度の完成度を目指す（作業者サイド）
    • WIP
    • Review（受け入れ側）
  • Fill:95%程度の完成度を目指す（作業者サイド）
    • WIP
    • Review（受け入れ側）
  • Closing:100%にする（受注サイドのエンジニア！これ重要！）
    • つまり、最後の最後の詰めの実装は、持ち帰ってやっちゃう

ポイント

• R/F/CそれぞれでWIP/Reviewがある
• 仮定1:Roughは精度の高い見積もりが可能
  • 経験的な知見。（僕も経験的にそうおもう）
• 仮定2:Roughに実際の作業時間と100%完成度に至る時間との間には固有の定数係数で説明される線形の関係がある
• そこで、
  • Roughをやる時点でどんぐらいかかりそう？と聞いておく
  • 実際にRoughにかかった時間を測定しておく
  • 実際にClosingまでにかかった時間を測定しておく
  • Roughにかかる時間に対する、Closingにかかる時間の倍率を計算。
    • この情報を、タスクごとに収集しておく。
    • すると、あら不思議、特定の定数に収束してくる（仮定2）
  • そうすると、Roughの見積もりをした時点で、全体の見積もりが比較的精度よく推定できる（仮定1と仮定2の合わせ技）
• 実際のプロジェクトでは、この係数は3弱に収束しそうであった。
  • つまり、「ざっくりしたもの作るのにどんぐらいかかりそうよ？」→「3日ぐらい？」→「（じゃ全体出来上がるのは8〜9日ぐらいか）」のような。
  • この値はプロジェクトに依存するだろう。

よかったこと

• 自己組織化
  • 積んどけば勝手にやってくれる状況
  • レビューもお互いにやってくれる状態になったので品質が安定

課題

• 開発モデルとしてのスケーラビリティ
  • 受け入れ担当者に負担が集中SPoFになる
    • タスクを積むのも、1つのタスクに対して3回以上のレビューをするのも、
  • アジャイルコーチの川口さんより：バックログを積む段階にもボトルネックが存在しそうね。
• カジュアルに締め切りがブッチされる
  • 遅れるのはいいんですよべつに
  • 何も言わずに遅れられるとしんどいです

その他

• 手戻りってある？受け入れ側がRoughからRoughに戻したり
  • あるね。齟齬があったりすると
• 拠点数に対するスケーラビリティはどんな？
  • 試してないけど受け入れ側もチーム化したりするとかあるかも
• 画面とかデザインとかを伴う場合は？アセットの共有とかは？
  • （聞き取れてない）

思ったこと

• RFCモデルについて
  • メトリックの計測がだいぶ大事そう
  • タスクあたりのコミュニケーション頻度は増えるはずなので
  • Done is better than perfectであって、Roughでさくっとざっくりしたものを作ってもらうコンセプトは超イイとおもう
• 今どきオフショアかよ。しかもこんなにがんばってまで。という声は、もっともだそうです
  • 今回のお話の元になったチームはアジアに投げてコスト低減だﾋｬｯﾊｰなザ・オフショアなかんじではなくて、ベトナムの技術的なところに期待してのものだったみたい。
    • なるほど、地域特化型？とでもいうのか、そういう種類のオフショアになってくるのかもな。
    • 受託で丸投げするよりはいいのかも。
    • 個人的に思ったのは、仮にここまでの体制を作れるような環境の会社であって、その国に頼りたい理由がないとすれば、オフショア等に頼らずともいい体制を作れそう。
• 今日の話で一番自分にとって新鮮というか興味深かったのは、具体的なRFCモデルのことでなく、ひとつの開発モデルの生い立ちから育っているところまでの姿をお話として聞けたこと
  • 僕みたいな若い（若いんだってば）エンジニアにとっては、いろんなモデルや手法っていうのはパッケージ化され提供されたひとかたまりの知識体型としてまず入ってくるものであって、少なくとも最初に知った段階では過去の偉人の考えや屍の山はブラックボックス化されちゃってるんですよね
    • そこからいろいろ工夫だったり肉付けだったりしていくけど
  • なので、こういう風に成長途上なモデルとそれを考えた人の話聞けたのはなんか凄い楽しかった
  • 同時に、あ、こういうモデルを考えだすのって、そんなご大層なものじゃないんだとか思った
    • こんなん自分でも考えられるぜ！って言いたいのではなくて
    • 超頭いい人が美しい理論のもとに弾きだした答えではなく、
    • 僕のような普通の人が苦しみ苦しみ抜いてその時々考えたことを集めて体系化したという意味でなんだかすごい身近に感じた。
    • というか、今自分のチームでも自分たちなりのKAIZENをいろいろしてるし、それをまとめればそれだけでひとつのモデルになるなー