2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
リンクをコピー
記事をブックマーク
屋代昌也氏(以下、屋代):それではパネルディスカッションのセッションに入ります。パネリストのみなさんには事前にいくつか質問をしています。その中からチョイスして、気になるところをガンガン質問し合いながら、話していけたらと思います。
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.12.20
日本の約10倍がん患者が殺到し、病院はキャパオーバー ジャパンハートが描く医療の未来と、カンボジアに新病院を作る理由
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.17
面接で「後輩を指導できなさそう」と思われる人の伝え方 歳を重ねるほど重視される経験の「ノウハウ化」
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05