2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
屋代昌也氏(以下、屋代):それではパネルディスカッションのセッションに入ります。パネリストのみなさんには事前にいくつか質問をしています。その中からチョイスして、気になるところをガンガン質問し合いながら、話していけたらと思います。
1つ目の質問です。「自社の開発体制や開発の進め方、開発のおもしろさや強みについて教えてください」。じゃあ最初はGlobeeの上赤さん、よろしくお願いします。
上赤一馬氏(以下、上赤):はい。開発体制ですね。基本的にエンジニア7名とデザイナー1名の1チームで開発をやっていて、他にもQAやCSなど、コンテンツ作成も一応チーム内に含まれてはいます。進め方は“チケット駆動開発”で、それをいかにシンプルにやっていくかだと思います。
スクラムを入れようかという話をしたことはありましたが、現状ではそこまで仕組み作りをしないということで、かなりシンプルな開発体制になっていると思います。
タスクはトップダウンとボトムアップ。要するに、経営決定したやりたいことと、現場で決めたやりたいことを両方チケット化して、それを優先度付けしています。基本的にPdMである私が優先度付けを行うのですが、メンバーから「ちょっとこのタスクを優先してやりたいです」と言われたら優先度を上げる方法で進めています。
おもしろさでいうと、やはり教育分野かつToCブランドなので、ユーザーの意見を聞きやすい。ユーザーの声を感じる機会がかなり多いと思っています。
Twitterではずっと「abceed」とエゴサーチをしていますが、「abceedでスコアが上がりました」「学習しやすいです」という意見を聞くことがけっこうあります。さらに、今は学校展開もやっているので、実際に現場で使っている生徒さんの声やリアクションなどを知る機会もかなり多いです。そういった意味でかなり楽しいと思っています。
現場のチームもユーザー体験へのこだわりがかなり強い人が多いので、一緒にものを作っていて非常に楽しい環境だと思っています。あとは、ベンチャーでよくありますが、会社全体で1つのものを作っているところが強みだと思っていて、営業チームや英語のコーチなども実際にabceedのことをとてもよく知っていて、学校展開をする時もすごく力を入れて説明してくれています。
英語のコーチの中にも、もともとabceedのユーザーで、abceedのファンとして入ってきてくれた人もけっこういます。会社の全員がabceedのことをとてもよく知っているわけです。そういった意味では、一緒に働くことや全社一丸となってものを作っている感覚を味わうことができるのは、非常に楽しいと思っています。いったんそんなところで大丈夫です。
屋代:「スクラムのチームをどうしようか」という話がありました。そのあたりは、カミナシさんがもう少ししっかりやっていると思うのですが、どうでしょう?
原トリ氏(以下、トリ):ここが理想の世界だったら「カミナシにぜひお越しください。本物のスクラムを見せてあげましょう」と言えるのですが。僕が思うスクラムの本質は、複数の役割・責任を持った人が協力関係を作りながら価値をユーザーに提供していくことだと思っています。
その組織が大きく拡大していったり、お客さまの規模が変わっていったりします。そんな中、プロダクトマネージャーの役割や、ソフトウェアエンジニアが何に責務を持っているのかがきちんと定義されていない状態でガンガン走ってきてしまっています。
役割に基づく協力関係ではなく、合う・合わないでバトルになってしまうこともあり、やはり組織として未熟なところがどうしてもまだあるというのが本音です。
だから、今のカミナシは、スクラムというかたちにメチャクチャこだわっているわけではありません。スクラムをやるなら、スクラムの価値が出るやり方で進められるように個人が努力しないといけない。チームとしても努力していかなければいけない状況です。
屋代:スクラムを完璧にやるとなると、やはりけっこういびつになってしまいますよね。
トリ:そうですね。形を崩すか崩さないかが一時期ソーシャルで話題になったことがあるかと思いますが、価値が出ているなら別に良いんです。価値が出ていないけれど形を崩してやっているとなると、「それは何のために崩しているんでしたっけ?」という話になるので。
ちゃんとやっていくことはけっこう大変ではあるものの、それが文化として定着すれば、すごく強みになるのではないかという気はします。
屋代:やはりそのあたりも含めて、エンジニアの成長も大切にするおもしろみが、カミナシさんの中ではあるんですか?
トリ:そうですね。それをちゃんと継続的に実現できるようにしていきたいとはもちろん思っていますが、カミナシのおもしろさは「全部触れるよ」だと思います。
例えばバックエンドのチームに所属している時、プロダクトアウトの気持ちが強いエンジニアは「フロントエンドのこの部分をいじれば、ユーザーにメチャクチャ価値が出るはずなんだけど、うちのチームのものじゃないからいじれない」と考えてしまいます。
フロントエンド側からすると「バックエンドのAPIをこう変えてくれたらすごく良い価値が生まれるんだけれど、バックエンドのチームがやってくれない感じだから、画面表現でお茶を濁すか」とフラストレーションをためている人たちがけっこういると思います。
カミナシは、フェーズの面でも、この先の組織の作り方の面でも、ファンクションで切るというチーム体制を取ろうと思っていません。
システムアーキテクチャを構成図にした時、上にユーザーがいて下にクライアント、サーバー、データベースと並んでいくと思います。それを横に切っているチームの切り方が、フラストレーションの原因だと思うのです。例えばフロントエンド、サーバーサイド、インフラ、SREという切り方。
カミナシはそうではなく、原則としてチームを切る時は縦に切る。ユーザーに価値提供をするラインを切らずに、一本に保つようにやっていこうと思っているのですが、大変そうだなぁと。
(一同笑)
そんな感じです。カミナシのおもしろみは、そこにあるのではないかと思います。
屋代:なるほど。
話がすごくチェーンしていくのですが、たぶんそのあたりをメチャクチャ悩んでいるのがみてねさんだと思っています。
大きい組織ならではの縦割りと横割りのマトリクス関係がなかなか大変そうだと思うのですが、そのあたりを含めてどうでしょう。おもしろみや開発の進め方など、みてねさんはどのような感じでしょうか。
酒井篤氏(以下、酒井):今のトリさんの話を受けてなのですが、僕たちもプロダクト開発においては基本的に何でもできるというのはベースにあります。例えば、iOSのアプリを作る人も、RailsのAPIの課題をちょっと解決してレスポンス速度をちょっと上げることもスッとできる体制にはしています。
あとは、そういった何でもできることをいかに支援するかというところで、専門性の高いSREが常に横で待っていてくれる状態を作っています。今、わりとそこは理想的にできていると思っています。
もともと、みてねも15人ぐらいになるまでは1チームでやっていて、僕もインフラを書きながらiOSのアプリを書いていた感じでした。そこにおもしろさはあるのですが、やはりどこかで限界がきます。「もうこれはSREチームの能力を超えたな」と。
SNS時代や『モンスターストライク』など、もともとMIXIは大規模なサービスが得意だったので、そういったスキルを発揮して活躍しているメンバーにちょっと助けてもらいながら、SREチームを立ち上げています。機械学習が必要だと思ってその専門のチームを立ち上げた時、MIXIならではの良さが発揮できたと感じました。
エンジニアとしてプロダクト開発をする上でのおもしろさもあります。ちょっと話が変わってしまいますが、私たちは海外展開をしています。そこのユーザーに対しての価値提供という面で、日本のお客さまだけではない変わったリアクションが得られるので、そういったおもしろさはあります。
今はユーザーの規模感でいうと千数百万人いるのですが、だいたい1/3ぐらいは海外のユーザーなのでかなり影響度は高く、日本国外に価値提供ができる現場になっていると思います。おもしろみでいうとそんなところです。
トリ:いいことやんけ。
(一同笑)
上赤:酒井さんに1個質問があります。15名まで1チームでやっていた話がありました。今、うちのチームも8名ぐらいで、チームをいつわけるかがずっと課題になっています。15名でチームをわけようと思ったきっかけや、何が回らなくなってチームをわけようと思ったのかなど、そのあたりをうかがいたいと思います。
酒井:先ほど少し話した部分で、ユーザーの規模に対して専門性が必要になってくるレベル感を肌で感じる瞬間がありました。例えば、スケーリングの問題やレスポンス速度の問題など、データ量もアクセス数も増えていく中で、ちょっと手に負えない状況が何ヶ月か続いた時期があったのです。
そうなってくると、チームをわけるというより、まずはチームに1つの土台を作ってそこに専門性の高い人を入れることが必要なアクションとしてあった感じです。もう1個は、10人、15人でやっていると話がまとまらないことが普通にあります(笑)。朝会をやっても30分も40分もかかってしまう。
上赤:なるほど(笑)。
酒井:1個の意思決定をしようとしても、みんな優しいのでお互いの意見が気になります。意思決定をするまでの時間がどんどん長くなっていく感覚があったので、そこはやはりチームをわけるきっかけになったと思います。
上赤:うちも朝会が徐々に長くなってきています(笑)。チームに1人増えると、朝会が少し長くなると感じています。
酒井:1人あたりの時間を減らすわけにもいかないので。
上赤:そうですよね。
(次回に続く)
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには