GYAOの窓際エンジニア 玉利です。
ガチのエンジニアの皆さんからは批判を受けることをあえて畏れず言いますが、世界一の技術を持ったコックの高級レストラン == 儲かるレストラン ではないのです。そして我々も技術があれば幸せになれるわけでもないのです。
バックパッカーゾーンのファングーラオにある、行列の途絶えないフォーのお店。オペレーションも単純で、回転率が良く相当もうかってます
ミシュラン三つ星を得ていたピエール・ガニェールは高級すぎて倒産してますし、渋谷の松濤にあったシェ・松尾も倒産しています。スーパーヒーローの腕に頼っただけで行きていけるほど、この世の中は甘くないんだなと思いつつ、自分は凡人なので凡人らしい生き延び方をしなければいけないと思っています。
私もビジネス書からなにから片っ端から読む方です。その中で、エンジニアと業種的に似ているのはコックの世界だと思います。
コックの世界あるある
- 長時間労働の超ブラック 体力勝負 低賃金
- 技術は個人の資産なので、後輩には教えず「技術は盗め」という
経験主義
どこかで聞いたことのある話ではないでしょうか？
その似通った業界の中でもまれたノウハウが書かれたものがいくつかあり、その中の一冊をご紹介したいと思います。
帝国ホテルのレストラン部門には2つのトップがいて、有名なのは総料理長。テレビによく出ていたムッシュ村上さんはこちらの花型でした。もう一名、調理部長という役職があります。総料理長は夢を語るのが仕事、調理部長はコストコントロールと内部統制をするのが仕事だそうです。
田中シェフは調理部長として、400人以上の料理人が働くレストラン部門の収益化・品質向上・技術の伝承に取り組まれていました。
普通のレストランと違い、数百人クラスの宴会の料理を最高の状態でブレなく提供するには、個人のがんばりでは到底できない「仕組みづくり」が必要になります。
私がぱっと思いつくだけでも、すぐに我々の仕事に役立つノウハウがつまっています。もちろん以下はベテラン料理人達から大きな反発をうけたそうですが、どこかで聞いた話だと思いませんか？
- 本当に建物中央にあるセンターキッチンの導入（エンジニアの腕の差によるブレをなくし、生産集約効果を出す）
- 調理エリアとお客様フロアをつなぐ什器の工夫で食中毒リスクを無くす（開発と運用の分離）
- サプライセンターの導入（車輪の再発明を無くす）
帝国ホテルは世界一流のレベルと評価されていると言って間違いないでしょう。もしも我々がITサービスで世界で戦うなら、かれらと同じレベルのことを、なぜ我々ができていないのでしょうか。
IT業界も事情は同じ。
規模は小さいですが、ベトナムでの開発に自分なりに同じ仕組みを導入しています。
最初の案件で困ったことは、ベトナム側が一般的なWindows端末 + Vagrant + Ubuntuで開発しているのに、日本側では社内用の特殊なLinuxをつかっていることです。開発環境が本番環境と大きく異るというのが致命的にダメなのですが、その経験主義の欠点に気がついている人は弊社内には余りいません。
もちろん、うまくいくわけがありません。しかし世間は、我々の事情をかわいそうに思って待ってくれるほど甘くはないのです。これがわからない人を中国語では井底之蛙とかいったりします。
完全に外部と対等に戦える体制を取ることにしました。すごいことは全くありません。周囲のスタートアップの会社と同じことをするだけの話です。
やっぱり開発するならMacのほうがいい
ベトナム人スタッフに、余剰になっていた型落ちのMacbookを貸与しました。日本仕様なのでキーボードの問題がありましたが、その日本語キーボードも、最初はタイプミスで大変でしたがすぐに慣れました。彼らはウキウキしながらMacを使ってます。ベトナム語に切り替えて。
Macのローカルにrbenvで環境を作り、本番環境もrbenvを使ってそのまま乗っかるように作っています。
Rubymineを半強制的に使わせる
実は私はもうオッサンなので、テキストエディタ派でした。MSX以降、DOS時代に古くはedlinコマンドからVzエディター、その後NIT Emacs、FreeBSDに乗り換えてからemacs、しぶしぶviを使い、netHackで鍛えて来たのですが、周りのRuby使いからおすすめされたRubymineを買ってそのまま寝かせていました。ベトナム案件でnode.jsのコードレビュー用にRubymineを使うようになり、最初はダサくて嫌でしたが、そのかゆいところに手が届く感と優秀なデバッガとコード補完で効率が段違いと気が付きました。
予算をつけてもらい、ベトナム人スタッフにも使ってもらっています。ベトナム側で問題が発生すると、日本側の稼働が跳ね上がるので、極力ベトナム側の品質を上げていかないと、私が死んでしまうのです。
設定も自分の環境をエクスポートして配布しているので、完全に同じになります。問題が発生したら、スナップショットを取って赤丸をつけてチャットで送ると一発で理解してもらえます。通訳挟んだ電話会議よりも効率がいいという方法はなかなかないと思います。MacだとCmd-Shift-4で簡単にスナップショットがとれます。
そして環境に対する彼らの評判は、悪くありません。もともとeclipseを使ってきたようなので、さらに気の利く開発環境になったと思っているみたいです。
Herokuで試せるように作る
これはもう少し先の話になりますが、オンプレミス主体の社内で、できるだけ世間一般的なものをつくることにしています。試験環境はローカルで行って、今のところはVMにデプロイしていますが、そのまま、いつでもクラウドの世界に行けるようにしています。別に社内にそういう方針があるわけではなく、世の中を見ているとこの方向に必ず行くという確信があるからです。
もうひとつ、ベトナム人エンジニアは開発のみで本番環境を触る機会がありません。本番環境を動かす悩みを理解してもらうには、シミュレーションでもいいので実際に体験してもらう以外ありません。
さらにもし彼らが自分たちでサービスを作りたいと思った時に、そのノウハウを教えてあげられないことは悲しいことです。お客様のため、我々のサービスのため、そして彼らの未来のためにバランスをとって仕事にしてあげたいと思っています。
全員が同じことができて、同じように痒いところを共有できる仕組みを作るのは組織の壁があり案外難しいことです。やっている人の話を聞いてみると簡単そうなことなのですが、マネジメントの視点と現場の視点両方ができないと難しいですね。これができるリーダー資質がある人は、100人に1人もいないというのが現実だと思います。それができる人になるまで日々修行です。