【KAIZEN platform】性善説で成り立つストラクチャードカオス

people_20140924_1

KAIZEN platform Inc.

技術顧問

(左)伊藤 直也 氏

ニフティ、はてな取締役CTO、グリー統括部長を経てフリーランスとして活動。ブログやソーシャルブックマークなど10年間、ソーシャルメディアの開発と運営に携わる。著書に『入門Chef Solo』(達人出版会)『サーバ/インフラを支える技術』『大規模サービス技術入門』(技術評論社) など多数。

KAIZEN platform Inc.

Chief Product Officer

(右)瀧野 諭吾 氏

GREEならびにGREE Internationalで、ゲームプロダクト・ゲーミングプラットフォーム・アドテクノロジー分野におけるプロダクトマネジメント及びにプロジェクトマネジメント領域の組織マネジメントから実務全般を担当し高い実績を誇る。2014年2月よりKAIZEN platform プロダクト責任者。

KAIZEN platform Inc. に聞いてきたこと

20140924_logo

2013年3月設立。リクルートで最年少エグゼクティブとしてアドテクノロジーの部門をリードしてきた須藤 憲司氏をはじめ、経験豊富なメンバーが創業した注目のスタートアップ企業。WebサービスのUI改善を推進する「planBCD」を開発・提供しています。

会社設立からたった1年ほどで、コアメンバー7人から50人(2014年9月時点)の組織へと急成長したKAIZEN platform inc。成長スピードだけではなく、SqwiggleGoogle Hangout を活用したリモートワーク、HUBOT による作業の自動化など独自の開発スタイルが注目を集めています。

さまざまなメディアで取り上げられているKAIZENカルチャーの本質はどこにあるのか?どこを目指しているのか?急成長中のプロダクトを作るチームの哲学を、開発部門・プロダクト部門それぞれを統括するお二方にお話を聞いてきました。

KAIZENの壁はコミュニケーション改善だった

― お二人が入社した時期を教えてください。

瀧野氏「僕が入社したのは2014年の2月頃です。といっても、去年の11月頃からよく遊びに来ていたので、現場がどうだったかは見ていました。」
伊藤氏「僕はフリーランスなので社員ではなく、技術顧問になります。顧問契約が始まった当初は、元々知り合いだったCTOの石橋さんに僕の知見を週1位で会社に来て、アドバイスするという形だったのですが、現在は空いている時間にはKAIZENのオフィスに居るようにしています。」

― ジョインした当時はどのような組織でしたか?

瀧野氏「コミュニケーションがとにかく足りていませんでした。優秀な人材はそろっていて、売り上げも順調に伸びているのに、チーム内のコミュニケーションがとれていない。入社してすぐにそれを感じて、思わず電話で伊藤に「これじゃあダメだ!」って怒ったくらいでしたからね。(笑)」
伊藤氏「最初にメンバーがぐっと増えたのがエンジニアチームだったので、コミュニケーション不足の顕在化も早かったです。月に1度、開発合宿をするんですがその時にメンバーが「開発手法を変えるべきだ」とか「システムのこの部分が古い」とかの話をするんですね。でも僕からしたらその話はすべて的外れで、コミュニケーションの量が圧倒的に足りてないし、仕組みも全く構築されていないと指摘しました。」

瀧野氏「その話が伊藤から出たときは、経営メンバーは全員ロードマップなどの企業戦略的な話をしようとしていました。ですが、伊藤がその話を全部押しのけて「コミュニケーション不足を解決すべきだ!」と主張したので、じゃあどうすれば良いかと悩むメンバー。いろいろ聞きたいし取り組んでほしいけど、週1しかいない伊藤。(笑)」
伊藤氏「しかも、コミュニケーションが大事だ!とか言っておきながらその日の飲み会には参加しなかったからね(笑)
まぁこれは笑い話ですが、この問題を解決するのにコミットしなくてはならなかったので、KAIZENに来る頻度を増やすようしました。」

― コミュニケーション不足を問題視したのはなぜですか?

瀧野氏「会社が急成長しているタイミングで「コミュニケーションが先決だ!」なんて言っていた僕らだったので、メンバーからは「それがいま最優先なの?」という感じで見られていたんじゃないかと思います。
ただ、当時のプロダクト&エンジニアチームのメンバーはいずれも第一線で活躍してきたプロフェッショナルばかり。開発や仕事のプロセスがすでに確立されている人たちばかりだったことで、基本的なコミュニケーションなんていうことは議論の的にすらならなかった。キャリアの長い人が多いとどうしても、自分のやり方が正しいかどうかを疑う機会なんて無くなってしまうんですよね。そうなると議論が先進的になってしまうのも仕方ない気はしました。」

伊藤氏「自分たちが習得してきたやり方をそのままKAIZENの開発でもやろうとしてしまう傾向が強くありました。問題なのは、その開発手法の良し悪しとかいう是非ではなく「自分はこういうやり方をしてきた」という話をメンバー同士でしていなかったこと。つまり、コミュニケーションが足りていなかったいうこと。
丸投げされても技術力で何とかできちゃう知識や環境があったんだろうけど、そのまま人がどんどん増えていってプロダクトも大きくなっていったときに必ず問題になってくる。だからこれは絶対にいま直ぐ解決しないといけないという信念は揺らがなかったです。」

精神的コストは後回しにしない

― 社内の賛同を得るまでに時間がかかりそうですね

瀧野氏「一回、システムに障害が起きてお客様にすごく迷惑をかけてしまったことがありまして。あの時は本当に大変だったよね。」
伊藤氏「うん、あれは大事件だったよね。めちゃくちゃデカいシステムが書き換えてあって、それが原因で障害が起きたんだけど、そのシステムが変更されたことを誰も知らなかった。書き換えられたことはデプロイされてて、Githubで見える状態にはなっていたけど、プッシュされただけじゃその重要性とか影響がどこに起こるかなんてわからないから。」

― 具体的にはどのような施策を行ったのですか?

people_20140924_2

伊藤氏「1ヵ月間、開発をすべて止めました。具体的に言うと、バグ・不具合修正以外はしませんでした。開発サイクルを回していくための、内部的な開発は一切ストップ。」

瀧野氏「その時は、経営合宿でプロダクトのロードマップを決める予定だったのですが、前に進みたくてもこの状況じゃ進めないと思って開発を止める決断に至りました。
1か月間でやったことはすごくシンプルです。ものづくりに関わるプロダクト、エンジニアチーム全員でビジネスロジックを把握して、皆で読み合わせて理解する。あとは主要機能の疎結合化とe2eテスト自動化。」

伊藤氏「メンバー同士の情報共有も全くありませんでした。自分がなにを担当していて、なにをすべきかはクリアだけど他の人がやっていることは知らないという状態。具体的に実施した一例でいうと、Qiita:Team を使ってログを残すようにしました。チャットでやり取りしている内容とかも「どうしてそれ Qiita:Team に書かないの?」と言ったり。

使い始めのころは小姑のように毎日こつこつ言い続けましたね。めんどくせぇ奴だなと思われていたんだろうなぁ(笑)それまで社内では別のツールを使っていたので、Qiita:Team を使うことでの成功体験がなかった。だから導入当初は僕の日報だけが延々と投稿されていました。」

瀧野氏「日常的に使っているツールを変えるコストって、思っているよりも大変ですよね。だから一気に変えろと言うのではなく、1つ1つ出来る部分から移行していくのが大切。あと当社の場合は、代表の須藤が書くようになったのも良いきっかけでした。今では営業やバックオフィスの社員も Qiita:Team を使っていますよ。やっぱり社長の力ってすごいよなぁ(笑)」

開発のやり方は企業が独自で確立すべき

― 現在はどのような開発手法を取り入れていますか?

伊藤氏「手法はかなり変わっているので、一般的な会社で一般的なやり方をしている人が、KAIZENにくると面食らうと思います。独自のやり方を貫こうとすると、新しい人がはいってくる度に教えないといけないという苦労はありますが、そこは注力してドキュメントを残すようにしています。」
瀧野氏「アジャイルとかスクラムの手法が流行って久しいですが、教科書通りそのまま取り入れてもほとんどのケースで上手く行かないと思います。ものづくりのプロセスは、自分たち自身に合わせて、企業が独自に改善し続けることが重要です。」

― KAIZEN流の開発手法を表すとするなら?

伊藤氏「一言でいうと「ストラクチャードカオス」です。例えば Google はカオスのなかにストラクチャーがあるとよく言われています。一見すると全員バラバラに動いているように見えるけど、その動きは構造化されている。あるべきものを作るために、タイミングや手法を合わせる。稟議や承認といったルールで縛るのではなく、各々がやるべきと思ったことをやるという姿勢がより重要視される風潮です。
これが成り立つのはお互いの信頼関係、つまり性善説だと思います。大きい会社とかでルールがガチガチに固まっている理由は恐らく「人間とは怠惰で働かない上に、ミスを起こす。だから働かせるための構造や、ミスを犯さないための秩序が必要である」という頭が前提にある。一方で僕らは「人間は働くし、ミスをしないように努めるはず。それでも人間だからミスが起きてしまうのは仕方ない。」と考えています。」

瀧野氏「組織には、攻めの業務と守りの業務があるので意見が対立してしまうことも当然あります。でも役割が異なるからこそ、様々な観点から課題に取り組むことで良いアウトプットを生み出せるのは言うまでもありません。例えば、PMとエンジニアは編集と作家に例えることができます。作家がいないと作品は生まれないけど、編集のサポートによって作品自体がより市場にフィットした形に昇華されます。その関係性は対立ではなく補完関係にあるべき。
PMはエンジニアをあごで使ってはいけないし、逆にエンジニアはあいつの企画がダメだとか言ってPMを批判するべきではない。この相互コミュニケーションが円滑に進むように、一歩ひいた立場で調整したりアドバイスしたりするのが僕たちのようなマネジメントの役目です。」

― 今後、どのようにサービスを拡大していくのでしょうか?

people_20140924_3

瀧野氏「様々な困難を乗り越えて、ようやく良いプロダクトを生み出していくための環境が整ってきたので、改めて達成しようとしている価値・解決しようとしている課題に向き合い直したいと考えています。メンバー間のコミュニケーションが円滑に進んでいるし、情報共有を大事にするカルチャーも根付いたので、問題解決スピードがとにかく速い。」

伊藤氏「そうだね、開発スピードは効率化しつづけたおかげでとても速くなった。ただ、このままアクセルを踏み込んで一気に拡大するのではなく「本当にお客様が求めているものを提供できているか?」を問う時間を確保するべきだと思う。コミュニケーションの問題を解決するために1ヶ月間、開発を止めたときのようにね。速くなった開発スピードによって空いた時間をさらにスピードを速めるために費やすのではなくて、お客様の抱えている問題を理解できているかを考える時間に充てていきたい。」

バランスよりもこだわり重視!KAIZENが求めるPMとは

― 適切なブレーキを踏むために必要なものとは?

瀧野氏「プロダクトデザインに圧倒的なこだわり・信念を持てる人を探しています。スタートアップ企業には「アクセル」だけでブレーキの存在を忘れている人が多いと思う。1ヶ月間、開発をストップさせてでもボトルネックを排除したり環境を整えたり、組織が大きくなっていってサービスが拡大していく前に整えておくべきことを一緒に考えることができる人。目先の問題解決にのみ捕われず、向き合わなければならない課題の本質を理解し、解決していくことを一緒にやっていきたいです。」

伊藤氏「エンジニアとしての観点でいうと、僕らと一緒になってものづくりしてくれるPMがいい。PMの経験はないけど、エンジニアとしてものづくりへの熱量をすごく持ってやってきたという人も合っていると思います。
あとは圧倒的なこだわりをもっている人!KAIZENのエンジニアに1人、誰にもないこだわりをもっている人がいるのですが彼はエンジニア全員が書いたコードすべてにレビューをします。僕がコードを書いてコミットすると、席まで飛んできて「直也さん、この部分がだめです」と指摘してきたりする。一見、自己顕示欲が強いようにも見えるけど彼がこだわっているのは、メンテナンス可能な品質を維持していくこと。確かに細かいなぁと感じてしまう部分はありますが(笑)彼がそのこだわりを発揮するようになってから、コードの品質は格段に上がりましたからね。」

瀧野氏「そういう意味でいうと、KAIZENで募集しているPMは一般的にWebディレクターと呼ばれる企画や調整をする人とは異なるかもしれません。ユーザーやお客様への提供価値を品質高く実現するために、何を作るのかを自分自身で定義しプロダクトとして体現していくことを一緒にやっていきたいです。なのでプロダクトマネージャーやプロダクトデザイナーという職種で募集をしているし、これができる人の需要はこれから増えてくると思います。」

people_20140924_4

ロジカルに構造化した仕組みをセンスと技術でKAIZENしたい

― KAIZENで働くことの魅力について教えてください。

瀧野氏「PM未経験でも、プロダクト大好きっていうエンジニアなら大歓迎です。KAIZENのプロダクトを素直にいいね!って言えるものにしてほしい。BtoC向けサービスはオリジナリティ溢れるUIが競争力になるので、プロダクトを作る際にもこだわる傾向がありますが、日本のBtoBサービスはまだまだ使いづらいものが多い印象があります。」

伊藤氏「プロダクトとエンジニアが一緒にサービスを作っている会社は日本ではまだ少ないけど、海外では主流になってきているんじゃないかな。slackSqwiggle はBtoCアプリケーションのやわらかさや使いやすさを取り入れたBtoBプロダクトの良い事例だと思います。KAIZENのものづくりはプロダクトの需要が明確なBtoBの世界で、BtoCでのアプリケーション開発経験を活かすことができるのが特徴です。」

瀧野氏「そうだね、BtoBの良いところはニーズがはっきりしていること。当てなくちゃいけない的も見えているし、当てたときのメリットも認識できる。僕らが理想としているのは、その的を当てるまでのプロセスを、ロジックや技術で改善・効率化し続けるなかで、使い心地がよく美しいプロダクトとして世に出して行くこと。日本ではまだ事例が少ないプロダクトマネジメントやプロダクトデザインに挑戦したいという人は、ぜひKAIZENに来てください!」

geechsマガジン記者手記

業界で長らく活躍してきたお二方だからこそ、経験値からくる組織論や技術力のお話が中心だと思っていたところ「何よりもコミュニケーションが大事」という、いわばチームで働くにはあって当たり前とも思えるお話でした。しかし、お二人が説くコミュニケーションのあるべき姿は、チーム全員が持つべきマインドや信念の統一を掲げることで「性善説」という本当の信頼関係が成り立つというもの。壁を壊すことの大変さ、あるものを変えることの重要性。そしてそれを超えていくことで得られる成長を見据えた、崇高な考え方に触れることができた、貴重なインタビューになりました。

 

こんなエンジニアを探しています

  • 会社名

    KAIZEN platform Inc.

  • ポジション

    プロダクトデザイナー / プロダクトマネージャー

  • 必須要件

    ・場の課題を把握するために、行動し、仮説を立て、プロダクトが提供する価値として言語化できる能力
    ・ユーザーインタビューやユーザーテストを通し、プロダクトのあるべき姿を描き、現在抱えるプロダクトの問題点を提示する能力
    ・提示した問題点をIssueとproblemに分類し、問題の優先順位をつける能力
    ・問題点に対して、複数のプロダクト解決案を提示できる能力
    ・複数の解決案から開発リソース、開発期間などの現実の制限条件から現実的な解決策を選択する能力
    ・解決策をより具体化し、エンジニアやデザイナーが実際に開発できるレベルの仕様に落とし込む能力
    ・自チームおよび他チームと議論を行い、双方納得した上でプロジェクトを進めることができる環境を作るために必要なコミュニケーションスキル
    ・Issueとproblemを見極めてIssueにフォーカスして議論を進めることができるファシリテーションスキル
    ・論理的かつ簡潔で読み手のコストをできるだけ小さくするドキュメントを作成するスキル
    ・数値ドリブンな開発を推進するための基本スキル
    ・サービス構造を把握し必要十分なKPIを設定する能力
    ・数値を読み取り、サービスがどのような状態であるかを定性的に理解し、改善するためには定性的に何がボトルネックになっているかを把握する能力
    ・ボトルネックを把握した上で解決策を具体的に提示する能力
    ・プロダクトがどのような手順でどのように開発されていくのかが理解できるレベルでのプログラミングに関する基本的な知識と経験。(自分で実際にリリースされるレベルのプロダクトを自分で作れるレベルは想定していない)


  • 推奨スキル / あると良い経験

    ・Webサービスにおけるサービス内容を企画した経験
    ・Webサービスにおけるマネタイズ構造の企画構築した経験
    ・運用開始後にユーザー感覚などの定性的な視点とKPIなどの定量的な視点を鑑みてサービス改善のPDCAサイクルを回した経験
    ・0からサービスを企画し作り上げて大失敗し、それを糧にして次のサービスで成功を収めた経験
    ・企画、仕様書作成、開発、検証、リリースまでの一通りウォータフォール開発サイクルを行った経験
    ・開発会社の開発進捗管理などのマネジメント経験
    ・ワイヤーフレームを作成した経験
    ・ウェブデザインに関する体系的な知識とその運用経験、またはそれを補うセンス
    ・ボタンの配置など変更によってユーザー行動が大きく変わるということを肌感覚で感じた経験
    ・ビジネスレベルの英会話スキル


  • 求める人物像

    ・家族・同僚を大切にする人
    ・自分の技術で世界に通用する製品を作りたい人
    ・技術だけでなく、事業目的まで含めて総合的に考えられる人
    ・自身が中心となって事業/プロジェクトを推進していける人
    ・新しい事を勉強する、求めることに貪欲な人
    ・英語でコミュニケーションを取ることに抵抗がない人
    ・自らの活動をオープンにするオープンマインド


関連する記事