ハノイにブランチオフィス作ったよ+DevOpsのお話

もともとうちのdai(松本大)さんが東南アジアの複数の国で多くのレストランを経営していたということにも起因しますが,ベトナム,ハノイオフィスがついに5月2日より正式に稼働となりました!
ひいてはかねてより採用を決めていたQuangと大学教員のDuongのジョインで,一緒に開発をしていきます.

オフショア・ニアショア開発って

そもそもウチが東南アジアに行ったのは友人がフィリピンで開発会社を作って面白そうだったから何ですが,そもそもニアショア開発・オフショア開発の違いとかを整理しておきましょう.
Wantedlyをお読みの方だったらこの用語解説は不要かもしれませんが,

・オフショア開発:言葉の通り,海外に開発をまかせるよ
・ニアショア開発:オフショア開発の1種で,より近い国に開発を任せるよ(日本の場合,中国,韓国,ベトナム,フィリピン....)

ニアショア開発にするメリットとしてはやはり時差がありますね.
大きな会社で24時間コールセンター体制をしくとかならまだしも,スタートアップが手を出すに当たって,まずインドやブラジルなど遠い国は特殊な素材があって云々カンヌンではない限りまず候補には上がらないでしょう.ソフトウェア開発ならなおさらですね.圧倒的にコミュニケーションや管理がしづらいと思います.

ニアショア開発で気をつけること

ここはめちゃくちゃ内容の濃い記事が書けそうなので次週以降改めて別記事で書こうと思いますが,もちろん大変な目にも会いました.
ニアショアと言っても一意ではなく,当たり前ですが,その国々によって国民性や習慣,文化があります.
うちでは今のところフィリピンとベトナムで開発をご一緒させていただきましたが,この東南アジアの国同士でも大きな違いがあります.
どんなオフショア解説のWebサイトにも書いてあると思いますが,簡単にいうと

フィリピン人:オプティミスト,楽観主義者の人が多いイメージで「OK」に豊富なバリュエーションがあります.女性はそうじゃないかも.柔軟で困った時はお互いに助け合うということがしやすいけど,仕様を渡しても日本のクラウドソーシング感覚のディレクションだとまず仕様通りにはならない.英語はネイティブなのでコミュニケーションはどんなところでもしやすい

ベトナム人:真面目,決まっている仕様が細かければをその通りにする能力は高い.新しい技術の知識も比較的浸透している.ただ英語事情は日本と変わらないくらい?

そもそもベトナムには多くの日本企業が進出していて,それゆえに日本企業とのやり取りは慣れているし,水準も高いけど,フィリピンと比べるとコストは高い.またどんな国にせよ,やはり日本とは違う国で育った人たちなので,仕様として書かれていることの認識が違うということが非常に多いです.

オフショアにおけるDevOps

ハノイオフィスは最終的にはWannabeを一緒に開発・運用をしていくことを考えていますが,まずウチが取っている受託案件を一緒にやろうと思っています.

どちらにせよしばらくの間はDevOps(簡単にいうと開発と運用)で言ったら,Developmentをハノイ,Operationを日本でやることになるわけですが,この区分けや開発プロセスの設計については非常に考えてなお,まだ結論は出てないですww
どちらにせよやってみながら修正していくしかないのですが,今回実践するカスタムDevOpsを紹介します.

DevOpsのイメージ


画像はこちら(https://medium.com/@neonrocket/devops-is-a-culture-not-a-role-be1bed149b0)のIrmaさんの記事から転載させていただいてます.

そもそもDevOpsって定義が曖昧でいろんな開発プロセスの複合でありながら開発者と運用者が最初っから最後まで協力しながらプロダクトを作り上げる手法で,別にアジャイルと別物とかそういう議論にはなりません.

また,開発者と運用者が協議するということはそれなりに開発専門用語を排除した環境が好まれるため,イベント駆動の設計が向いていると思います.また,その上で,やはりMTGの効率化のため,仕様ベースの話を求められることが多いのですが,これ結構危険で,前述の通り「仕様」として書かれている言語への認識のズレが多発します.

僕は先日素晴らしい良書「ユーザーストーリーマッピング」に出会ったので,こちらはリアルな体験談を元にまた別の記事を書こうと思いますが,ユーザーの体験,Behavior駆動のPlanning,すり合わせが非常に有効だと思います.

僕らのDevOpsはIrmaさんの画像とは少し違って,(まだ清書できてなくて字も汚くてすんません...)


1.Plan
 すべてですよね
 目的とユーザーストーリーマッピングの整理を行い
 Behavior => Feature => E2ETest という風に落とし込んでいきます.このBehavior/Feature/Testのセット
 はメインリポジトリの1つのIssueになります.
 また,ここで(7)で行うプロセスに必要なログ設計なども平行して考えます.ここは目的によりますね.

2.Create
 ここではまず,Featureを細かく分割し,IssueとUnitTestを作ります.
 各ドメイン毎に1つのリポジトリを作り,そこの管理者がIssueを立てて,PMがレビュー,そしてスプ
 リントのバックログをまとめます.あとはいわゆるスクラム開発です.

3.Verify
 Unit Testと修正を行います.

4.Package
 定期的にパッケージ化(iOSならTestFlightで動かせる状態でアップロード)をして大きいFeatureの確認
 を行います.
 2~4は繰り返しですね

5.Configure
 Deployのための設計を行います.インフラの設計や整備,各付随サービスの整備などを行います.

6.Release
 リリースを行い,場合によってはバージョニングをします.

7.DS Process
 集めたログなどを用意した分類器・学習器などにかけて,(1)で企画した機械学習手法を実践します.
 ここはいわゆるデータ・ドリブンな学習です.

8.Monitor
 データ,アクティビティの視覚化,7の結果を用いたアナリティクスを行います.ここが次のロードマッ
 プのステップに至るアイディアになります.
 いわゆる人間による学習ですね.

1に戻る

というようなプロセスを踏んで行こうと思います.こういうこと御指南いただける先輩いたら教えてください...
にしてもテスト駆動となるとやっぱりElixir&Phoenixになおさら完全移行したr.....

リアルにElixir / Phoenixエンジニア募集してます!!!!!!!!!!!!!

https://www.wantedly.com/projects/207779

Railsもまだまだ工夫しながら使って行こうと思ってます!!!!

もうちょっとPythonで気持ちよく書けて綺麗にテスト設計&MVCベースアーキテクチャのフレームワークができるとDS部分とWeb部分でシームレスに採用ができていいんですがね.
でもそれは No free lunch のようなものですね.

株式会社SIMULA Labs's job postings

Weekly ranking

Show other rankings