Developers Summit 2015 KANSAI に参加しました

2年ぶりのデブサミ関西に参加してきました。久しぶりに朝から夕方までみっちり参加してきたのですが、とてもよい刺激を受けましたので、書ける範囲でいくつかご紹介できたらと思います。

スライドが見当たらなかったので個人メモみたいな感じになりますことご了承ください。一部ちょっと違うよというのがあると思いますので気になるようでしたらご指摘いただけると幸いです。

2年前(2013年)に参加したデブサミでの所感

2013年は基調講演が「AWS」で、内製回帰の流れや、各業種に応じた適用事例などが紹介されていて、おぼろけながら「クラウド」の世界がこれから急速的に伸びていくんだろうなぁと思っていた頃でした。ですが、そのときはまだ「検証段階」に入ったところなのかなと部分的に感じておりました。

また、ちょうど「DevOps」などのキーワードも流行していたのもあり、ソフトウェアとインフラについて協調体制で行こうよ!って流れもあったりしつつも、当時はHTML5Javascriptなどのフロント技術とかのベストプラクティスや、既存の技術の掘り下げなどをみんなで考えようという感じだったように思います。

参加にあたって

2年経って、フロントもバックもネタは出尽くした感もあって、そろそろ流行の人工知能とか、ビッグデータについてのお話とかがあるのかなと思いつつ、改めて今回のセッションを見てみると・・・そういう感じではない。自分の会社の人の参加率も異様に低かったので若干不安はございました。(ごめんなさい…私は参加してよかったと思ってますよ)

[基調講演]クラウドファーストから、クラウドネイティブへの挑戦 by 東急ハンズ

実は、2013年の基調講演で「東急ハンズ」の移行の話に触れていたというのは、この記事を書いている最中に知った次第でありますが、実際にAWSを使ってどういうプロセスで移行を進めてきたのかという「検証」を含めた「戦略」を聞くことができました。

登壇された長谷川秀樹氏は非常に考え方がシンプルで、1つ1つの考えが的を得ていることばかりでした。それがまた「理想論」だけではなく、それらを「実現する力」「交渉力」なども備えているあたりが、移行に対して非常に前向きになれているのだなと直感しました。(こんなトップがいたら確実に成長するんでしょうね)

段階的な拡張戦略

2008年まではオンプレミスでやっていて、システムは外部のベンダーに任せてたんだけど、謎テクノロジーが増えていきますよね…だからそれを内製化しようとする動きがでてきましたと。

でも、当時のAWSのEC2とかは容量が少なかったりと、思っていたよりも非力だったから全部をAWSに移行するのは厳しいなというのを感じていたそうで、段階に応じて拡張をしていこう。というわけで、大まかに以下のような戦略でいったようです。

  1. EC2を使って、中身の技術は変えずに仮想への移行しようか
  2. 新しく出てきたしくみ(DynamoDBなど)を使ってさらに拡張しようか
  3. Amazonさん全部やってくれそうやから全部移行しようか

この「徐々に拡張」というところのバランスがうまいなと感じました。長い目でシステムを構築する場合に、そのときの最良を選んで、減価償却までそれを使い続けて…って結構あるある話だと思うのですが、「常に攻め続ける」ことで、あるある話のデメリット部分に柔軟に対応されているのだなと感じました。

利用環境の刷新

EC系は今や「オムニチャネル」という言葉通り、すべてのチャネルを統合していこうという流れがすぐそこまで押し寄せてきていて、それらを取り巻くテクノロジーを最大限に利用していかないともうだめだと。そしてその1つ1つのサービスは常にオープンにしてこうよという話がありました。出てきたキーワードとしては以下のようなものがありました。

  1. AWS
    ここは必ずやっていかないといけないよね
  2. Google Chrome
    ブラウザはたくさんあるけどひとまずこれで抑えておこう
    まだ追いついていない技術も色々あるんだけど
    究極論「全部HTTPS」でやりとりしたらいいじゃないか
  3. アップル製品+IOT
    いまや、POSも含めて専用端末なんて古い
    もちろんこれからでてくるIOT関連はどんどん取り入れていく方向
    (ちなみに東急ハンズiPod Touch端末らしい)
  4. 開発言語
    やっぱエンジニアが集まりやすい言語がいい。
    (おそらくものづくりの速度を気にしているのかなと感じた)
  5. レガシーな手法
    一瞬たりともクラサバをつくるのはやめといたほうがいい
    また、レガシーシステムの延命してつぎはぎだらけにするのはもうやめよう

常に最新を見据えた戦略を考えていて、あとはテクノロジーさえ追いついていけばピックアップしていくぞというあたり、非常にドライブ感があるなと思いました。

エンプラIT業界のスーパースターの条件

EC業界だけではなく、エンプラ界のスーパースターの条件についても、長谷川氏の経験談からピックアップして発表していただけました。

  1. 売り上げを伸ばすためのプロモーションができる人
  2. インターネットテクノロジーがわかる人
  3. 社内の業務システムがわかる人

私なんかはこの場面はグイっと聞き入ってしまいました(笑)

常識にとらわれず捨てていく選択も

このあとに「常識を捨てていかないといけない」というお話があり、長谷川氏の感じている「危機感」みたいなものが伝わってきたのでいくつかピックアップします。

  1. システムROIなんて絶対でるわけないからやめようよ
    大企業はROI気にしているけど、日々天気も変わる。人も変わる。
    そんな中で正確なROIを出すのは非常に困難。
    たくさんのドキュメントを作ってもほとんど見ることはないし、
    結局のところ動いているものがどうなのかというところに落ち着く。
    そんな時間があったらさっさとリリースしたらいいじゃないか。
    (内製化の強み…といったところなのかなとも思います)
  2. IT部門・ユーザー部門のコミュニケーションをもっとせよ
    ユーザーが欲しいものを作ればいいだけの話なのに、
    いちいちIT部門にお伺いを立てを立てないといけない閉塞感。
    すべてが100点になるわけではないけどとにかくユーザー欲しいもの重視。
    そこはちゃんとお互い「やる・やらない」を決めてってやればいいし
    意見を受け取りやすいアーキテクチャにすればいいじゃないか。
  3. システム同士のデータのやりとりをシンプルにしようよ
    リソースに対して限定的なインタフェースを構築していると、
    どうしても拡張性が落ちてしまうし開発人件費がかかる。
    今や回線も太いしサーバースペックも高くなってきているのだから、
    必要なデータはもう全部もらいますというスタンスでやったらいい。

これ以外にも「夜間バッチはやめたほうがいい」とか「ベンダーロックインだけは絶対避ける方向で」とか、結構大胆な発言が多かったように思います。

私なんかは、SIerに所属しているのですがどうしても「細かいところ」で「たくさんお金取りたくなっちゃう」戦略とりがちですね…見習いたいです(苦笑)

 最後はものすごく早回しだった

あまりにも熱いお話が続いた結果、最後のほうは非常に巻き巻きになってしまい具体例などのお話が少し聞けなかったのが残念でしたが、冒頭でも触れましたが全体的に非常にシンプルな考えを持ってシステムの構築をされているのだなと思いました。

また、新しいことをしようとすると、必ずといっていいほど、経営層が「それはなにがおいしいんですか?」みたいな感じになることが多いんだけど、長谷川氏が発表しているその節々に「絶妙なたとえ話」がちりばめられていて、それが非常に明快であり、なるほど…やってみようか…という気になったのは言うまでもありません。

私なんかは、情熱はあるんですが、どうしても技術一辺倒で担当者をねじ伏せてしまおうというところが多々あるので非常に参考になりました。

[午後Ⅰ]サービスをつくりなおす決断をするとき

ChatWork株式会社の山本正喜氏の発表。私自身ChatWorkはこれから使う予定をしているところなのですが、最近PHPからScalaに移行したという話は聞いていて、どういう形で移行したのか、非常に興味があったセッションです。

いきなり驚いたのは、代表取締役の山本敏行氏は実兄というところ…私も兄弟で同じ会社に所属しているので、参加者の方々とは別に、最初のつかみで完全に引き寄せられてしまいました(笑)

開発体制

主に以下の体制で、CTOからのエスカレーションが強めに感じました

  1. サーバー・フロントエンド
  2. 基盤(チャットツール以外の管理画面や支援ツール)
  3. クライアントアプリ(AndroidiOS・DeskTop)
  4. CTO室(アーキテクチャ・R&D)

個人的に、ものづくりにおいてアーキや分析ベースからのエスカレーションってすごく大事で、技術的戦略や分析されたデータをしっかり経営に結び付けて、リーダーシップをとっていく人たちが「CTO」になるべきだと思っているので、この体制は理想です。

当時の振り返り

当時はSkypeを使っていたが、色々と課題感をもたれているようで(わかります)、山本氏が中心になって、少ない予算の中で6ヶ月でChatWorkの原型をPHPで作り上げたのこと。ひょんなことからChatWorkが世に出て行くわけですが、当時からLINEは一般向け、ChatWorkはビジネス向けな立ち位置で成長できるんじゃないかと思っていたそうです。(すでに実現できてますね)

でも、急速に発展していくサービスに対して、スピードを突き詰めて取り組んでいくうちに、以下の点に目がいくようになってしまう。(よくある話ですよね)

  1. 低いテストカバレッジが増えていく
  2. 命名規則が曖昧になっていく(Message・Chat…どっちでも取れるみたいな)
  3. スケールを考慮できていないところがボトルネックになる
  4. 本番環境と一致しない(ローカルでは起きないが本番では起きる現象など)

また、技術的負債が多くなっていくにつれて、以下の点にも問題がでてくる

  1. 見積もりが大きくずれていく
  2. 蜜結合により影響範囲がわかりにくくなる
  3. 網羅テストがしにくくなりテスト工数が増大していく
  4. SPoF(単一障害点)が多くて、まれな条件で一瞬で落ちるなど
改善への施策

これではいかんということで、カイゼンに踏み切るわけですが、まぁ経営層はなんで動いているものを作り変えるんだと…こうなりますよね。山本氏も経営層に説得するのに非常に苦労したようですが、当時のスライドの画像がその的を得ていて、思わず笑ってしまいましたが、非常にわかりやすかったです。

カイゼンでは、ボトルネックになっている処理をSQSに持っていったり、スケールアウトを容易に行えるような仕組み作り。DynamoDB・CloudSeach・SendGridなどさまざまなサービスを利用したりと、とにかく完全に刷新したなという印象を受けました。

受けたと同時に、旧システムからの移行はどうするんだろというところも気になりました。というのもファイルデータだけでも76TB(テラバイト)あるそうなので、容易に移行なんてできるはずもないと思っていたからです。

再構築のメリット

なお、メリットとしてはやはり以下が上げられます

  1. 既に確定した仕様でコードを再設計できる
  2. 再実装時に仕様の細かい精査ができる
  3. 最新の技術を制約なく利用可能

ということで、これらをどの言語でやるかというところで、

  1. Ruby (不採用)
  2. Python (不採用)
  3. Scala (採用)
     静的型付き言語の保守性とパフォーマンス
     AWSはJavaSDKがもっとも充実している
     リアルタイム処理と相性がいい

となったようです。ScalaはDDDとのからみもあったのかなと感じた次第です。(どの言語でもDDDは実践できるようですが、PHPからの移行、チーム編成、静的型付き言語など総合的にみて相性がよかったのかもしれないです)

新旧混同のしくみ

やはり既存システムをとめずにゼロベースでやるのは非常に難しいと考えていたようで、既存システムを動かしつつ、新システムを稼動させるといった感じ。

そのつなぎは大まかには「API(APIベースにすることで蜜結合を防ぐといった戦略もあった)」でたたけるようにしていき、徐々にデータを新システムに移行させるような方式を取っているようでした。

このあたりは新旧との間に「新たな層」を作ることで、利用ユーザーからはシームレスになっていることと、蜜結合を極力排除することで、エンジニア側からは拡張容易性が格段にUPしているのではないかと思いました。

最後に

やはり「作り直す」というのは相当な「覚悟」がないとできないものだなというのがヒシヒシと伝わってきました。

システムはある程度まで構築すると徐々に技術的負債が生まれてきて、でもそう簡単には改善できなくて、いっそのこと「こんなの1から作り直したらいいやん」とかいう人がチラホラでてくるんですが、それを「経営にうまく寄り添わせた状態で具体的にこうしよう」というところまで考えている人は少ないように思います。

いや、最初からいいもの作ればいいやんという発想は安直ですが非常に大事ですよ。ですが、それもそれで時間との戦いになって、サービスのローンチが遅れてしまえば競合他社に抜かれてしまうので非常にリスキーでもあります。

この両方のバランスを「DDD」という新しい設計で切り開いているあたりが、非常に参考になりましたし、これからどういう風に成長していくのか個人的にはすごく期待しております。

[午後Ⅱ]ゲーム開発素人集団がゲーム作り始めていつのまにか40倍の組織になっていた話

後発だったゲーム業界への参入、ノウハウ0、少ない開発者によるものづくりの体制から、徐々に拡大していく過程で起こってきた問題点などを聞けました。技術スコープというよりも組織スコープの内容でしたが、これから大きくなっていく組織を考えていく上で非常に重要な観点を学べる内容でした。

採用の罠

「技術力:熱意・コミット意識が少ない」

 と

「熱意:こだわりが強い・リーダー意識の欠如」

私は採用にはどちらも重要だと考えておりましたが、一長一短あるということです。おっしゃるとおり何かしらの「バイアス」がかかってしまい、適切な判断ができないことも多くあるように思います。

これを打破するにはやはり「対話」が必要で「人柄・一緒にやっていけるか」をきちんと見ていけるように、採用側も努力していかないといけないなと感じました。

職種の差

中途採用の場合はどうしても「前職」を元に判断をしてしまうし、採用された本人達も「前職」ベースで仕事を遂行していこうとするために、仕事のやり方にばらつきがでてしまい、どうしても揉め事が多くなりがちになるとのことでした。

確かによく口癖で「前の現場ではこうしてましたから」とか言う人は多いように思います。(悪いことではないですけど、それに固執しすぎるのはよくないと思います)

しかも後から入ってくる人は、仕事内容が「ワーカー的」なものが増える傾向にあるため、内容に価値を見出しにくくなるというのは同感でした。DMM様は、これに対して1人1人にフォーカスを当てた「体制図」を作り、

  1. メイン業務
  2. やらない業務

を明確にし、合意をとることでこの差を埋めていきましたということでした。大変そうだけど、人間って「これを頼む」といわれるとやっちゃうし、逆に「これは誰かがやる」って決めていたら任せちゃったりできますよね。

曖昧耐性(これが一番大事)

組織の制度・体制の不十分さというのは、人の増える速度が速ければ速いほど追いつかなくなるもので、かといって1000人規模のしっかりした制度・体制をきっちり作っても、やはり所属している人数によりけりで、枠の中に納まりきらないことが多々ありますよと。

なので、曖昧なものを曖昧として受け止められるかという「曖昧耐性」がとても必要になってきます。「まぁいいか」の精神でしょうか、とにかく「目の前の仕事」を淡々とやっていける「平常心」といいますか、そういうのが大事ですねと。

でも、だからといって不満がないわけではないので、そこは必ずマネージャーがキャッチアップできる体制を必ず作りましょうというところです。

  1. 個人面談は1ヶ月・1回・30分
  2. 面談共有は2時間・月4回

80人いたら、約 48時間 / 月 の時間を割いている計算にはなりますが、こういう個別の面談を設けることで、何かを発言しようという意識はでてくるように感じているようで、DMM様もこの4つの中でも非常に重要だとお話されていました。

確かに、昔は飲みに行ったり、社員旅行があったり、そういう文化もありましたが最近はそういうのもあまりない文化になりつつあるなかで、1人1人と向き合う時間って削られていきがちですし、人数が多くなると少しずつでも主体性が薄れていってしまうので機会を与えるという側面だけでとらえてみても重要だなと感じました。

根付かないクレド(=行動理論)

私自身、所属している会社にクレドが根付いていないので、イマイチピンと来なかった部分ではありますが、行動理論というのは、上の人が作っていくのではなく、チーム内の推奨文化としてチーム単位でつくることで愛着を持たせ、お互いの行動を意識しあうことで、価値観の共有を図っていこうというお話がありました。

ただし、これはあくまでもチーム内の話で、部・社に当てはめられるかというとそうではないようです。

最後に

組織って小さい間は、個々の裁量の幅が大きく、常にアンテナを張っている状態で主体的に動いていることが多いですが、大きいものは少し作りづらい。

かといって組織を大きくしていくと、大きなものにじっくり取り組めることはできるものの、個人の裁量や主体性が少しずつ薄れていってしまうがゆえに、少しずつ中で歪(ひずみ)がでてきてしまい、それを放置していると幹そのものが折れてしまう。

組織というのはコミュニケーションが非常に大事だけど、とりあえず話せばいいとかで完結するのではなく、お互いの「合意」を中心とし、その先にある「ゴール」に全員が導けるように組み立てていくものなんだなと感じました。

組織ってこれといった「ゴール」はおそらくないような気もするので「常に変わることのできる柔軟性」を持った人を、じっくりと「育成」していくことが重要なのかもしれないです。

長くなりましたが・・・

このほかにも参加したセッションはあったのですが、記事のボリュームが非常に大きくなりそうなので割愛させていただきます…(ごめんなさい) が、総括をすると「現場のカイゼン 2015年版 」といったところでしょうか。

昨今はさまざまなテクノロジー・開発手法の選択肢が非常に多くなってきていますが、ただそれらも栄枯盛衰といいますか、諸行無常といいますか、「常に変化」していくものだとも感じます。

その変化にうまく対応できるアーキテクチャであったり手法をうまく取り入れ、チーム内でトライアンドエラーを繰り返す。そして、そのナレッジを新しい変化にうまく結びつける体制を作っていくことが、これからの未来のシステムを構築していく上で重要なファクターであるということはどのセッションでも感じたことであります。

技術者に限らず、この業界のすべての人が常に新しいものにチャレンジできるような土壌を作り続けられるように、私も日々の行動を少しずつ「カイゼン」していけたらと思いました。

はぁ・・・うまいことかけたかしら・・・汗