べにやまぶろぐ

技術寄りの話を書くつもり

夏サミ 2014 『Enterprise TED』聴講メモ #natsumi

昨日は年始に続き今年二回目となるデブサミ(夏サミ)に参加してきました。例によって聴講メモですが今回は最後の「エンタープライズ TED」 から書いていこうと思います。蒼々たる顔ぶれを見て今回参加を決めたといっても過言ではなかったわけですが、期待に違わず大変面白いセッションでした。

司会の gumi 高柳さん曰く、 「TED とは全然関係ない(笑)」けど「今回は公募ではなく現場最先端の人のストーリー」を話してもらう場とのことでした。

以下、メモ書きです(私の主観で加筆修正されていますのでご注意ください)

伊藤 直也 氏〔KAIZEN platform〕
  • PlanBCD は JS のタグをはってもらって AB テストを行うための PaaS。顧客にはミッションクリティカルなサイトもあるので JS のエラーで事故起こすと大変
  • 実装重視、開発速度重視…といっても B2C だからでしょ?とか(お客様との契約もあるし)エンタープライズでは難しい、とか言われることも多かった。
  • id:naoya さんは今まで B2C のサービスを手がけてきたが、KAIZEN は B2B
  • 開発環境
    • GitHub のプルリクを活用した開発スタイル
    • コードレビューのレビュワーアサインは Hubot がやる。デプロイも Hubot 経由(ChatOps)。朝会も Hubot が教えてくれて zoom.us でビデオカンファレンス。
    • UT と E2E テストが準備され、デプロイ前後で自動的にながれる
    • インフラは Chef x Serverspec x Docker を(も)活用
    • 基本リモートワーク : オフィス移転に伴いエンジニア用のスペースを良くしてみたがみんなリモートで働いててそもそもエンジニアが出社せず活用されていない
  • 理念
    • 実装の重視 : KISS (Keep it simple, stupid) and YAGNI (You ain't gonna need it)
    • ハッカー思想 : 気に入らないならまずハックする
    • 非同期に働く
  • 技術的課題は頭を使えば大体解けるので解決は難しくないが、人と人との問題は正解がないので難しい、エネルギーを注がないといけない
    • PM やエンジニアの働き方や価値観をセールス、バックオフィス、経営陣と日々共有するのが大事
  • 結局、経験として B2C と B2B でやってることは変わらなかった
    • 階層のない管理体制「ホラクラシー
    • 非常にアジリティの高い開発をできている
    • SaaS だから、スタートアップだから、人命や物流に関わっていないからというのはあると思う
    • KAIZEN のような事例は世界的には珍しくない
      • B2C でやってきたようなプラクティスが B2B に活用されている (Consumerization of IT)

Hubot を活用したりリモートワークだったりの KAIZEN 社の開発スタイルは別のスライドを見て知っていたのですが、「ホラクラシー」といった組織論が注目されていることや 「Consumerization of IT」のように C 向けに進化した手法が B に流れ込んでいる現象については知らなかったので勉強になりました。

上坂 貴志 氏〔ネクストスケープ〕
  • メインフレーム作ってた頃の方が楽だった(業務・設計プログラミングだけに注力していた)
    • Win95 登場からダウンサイジングが始まって受難の時代が始まった
    • DB 一つとってもいろんなこと考えなくて良かった
    • プログラムが高級化する一方で一行あたりの単価価値が落ちた
    • マウスが登場して操作自由度が増し、いろいろなところに顧客要求が入るようになってきた
    • しかしながらオフショアも進んでいるのでおいそれとコストは下げられない
  • あるとき XP を試してみたがあんまりうまくいかなかった
    • 最初はうまくいった感があるがだんだん目的がわからなくなる(例: 朝会、ペアプロ
      • ペアプロは工数が倍になるとつっこまれた
      • TDD やってると進捗遅くなるとつっこまれた
  • スクラムも試してみたがうまくいかなかった。むしろつらくなっちゃう場合が多いのはなぜか?
    • 様々な手法やプラクティスは、提唱者やそれを生んだ背景がある
    • どういう背景・環境で生まれたかを認識し、現状の環境と何が違うかを意識しないといけない
    • 手法と目的だけ理解して取り入れてはいけない

XP やアジャイルを試しても上手くいかない理由と聞いて、目的や手法だけでなく背景まで理解しないといけないというのはふむふむと聞いていたのですが、最終的につまみ食いが駄目という結論になってしまったのはもう少し掘り下げてお聞きしたかった感じがしました。RDRA は知らなかったので調べてみます。

倉林 寛至 氏〔ネクスト〕
  • 空き家問題 8,200,000 / 60,630,000 戸、現在日本全国で7部屋に1部屋住居が空いている
  • 消滅可能性都市(増田ショック)、豊島区でさえ対象
  • ネクスト社は低価格戦略で戦っている、約200人の開発体制
  • 気合いでなんとかする感じでやってきた
    • ある日2ヶ月くらいだと思ってた案件を8ヶ月かかると言われてぎくしゃくしてきた
  • 気合いから脱却するためにアジャイル開発を勉強・導入した(Scrum Gathering Tokyo へ参加、CSM / CSPO の取得など)
    • ChatWork も導入、fearless change を参考に徐々に浸透させていった
    • 良い物を置いても誰も使わないのでシナリオを描くことが大事
  • ものづくりの現場からビジネス立ち上げ業務への移行
  • なにを生み出すのか?本当に作りたい世界をつくろう

確かに内製に拘ってていざ外注したら圧倒的な速さで返ってきたりすると存在意義というか重大な危機意識が芽生えそうな気がします。最近は Airbnb など不動産系のサービスが話題を集めていますが、実際に日本の7部屋に1部屋空いているという実態は、今後大きなビジネスチャンスになりそうな感じ。あとネクストさんの講演はちょっと前にヒカラボでも聞いていて、そのときはアプリの話でしたが最近露出が増えているんでしょうか。

佐藤 聖規 氏〔NTTデータ
  • アプリケーションライフサイクルマネージメントに関する研究をされている
  • Jenkins 実践入門など書かれている
  • NTT データの社員は 75,000 人、外国人は約半数

PC が落ちてメモとれませんでしたが、社内に潜むスキルの高い技術者をつなげたりプロジェクトの成功・失敗談を共有したりといったコミュニティを 75,000人という規模の NTT データ社内で立ち上げたというお話で、いかにグループシナジーを作り出すかということについて参考になる講演でした。

倉貫 義人 氏〔ソニックガーデン〕
  • アジャイルとは作らなくて良いものを見つける試み(ショートケーキならお腹いっぱいになった時点で製作を終えられる)
  • いくらアジャイルでやっても全て繰り返すなら全部作るのと同じ
  • エンタープライズの定義は何か? => しがらみという共通概念
  • 2020年にブログラマはなくなる?という記事 => ソフトウェア開発が誤解されているのではないか
  • ソフトウェア開発は大量生産でもルーチンワークでも製造業でもない、「モノづくり」ではない
  • ソフトウェア開発とは再現性のない「問題解決・ナレッジワーク」である。故に人数は不要
  • 分業せずに個の力を高め、時間や場所に縛られず、顧客に直接価値を届ける。小さい会社の方が有利
  • 進歩の早いこの世界では一線を離れた上司より現場の方が問題解決できるからコマンドアンドコントロールではなりゆかない、セルフマネージメントの必要性
  • ビジネスの設計からソフトウェアの設計・開発、運用まで全てに責任を持つ仕事 = 「納品のない受託開発」
  • 月額定額、人月ではなく成果での契約、要件定義なしでいつでも仕様変更可能。ビジネスの成長支援=> ウェブの新規事業に向いている
  • 仕様変更は本来喜ぶべきもので、問題解決においては正解に近づいているということ
  • 子育て支援サービス AsMama CEO のソニックガーデン社への感想
  • 今後はゼロから1を作る仕事、それと誰かの問題解決をする仕事が残る
    • プログラミングを手段として問題解決を仕事とするナレッジワーカーが未来の受託開発
    • 3つのチェンジ : Embrace Change, Fearless Change, Social Change

ソニックガーデン社の取り組みも前からいろいろ目にすることは多かったですし社内でも話題に上ることもあったのですが、生で倉貫さんのお話聞いて喋りが面白くて終始笑っていました。ソフトウェア開発が再現性のない問題解決の試みというのは確かにその通りですし、そこがぶれなければ変なもの作って納品して終わりということもなくなるのかなと。あと成果で契約する、というのが一番イメージしにくい部分ではあったのですが、社外取締役というフレーズで多少明確になった気もします。ただやはりその場合はそれだけの個の強さが必要なわけで、それがマニュアルワーカーとナレッジワーカーの境界線だとすると結構つらたんな感じです。