「なんのために作るのか？」「何が正しいか？」経営と開発が同じベクトルでフラットに議論するカババの開発組織
自動車フリマサービス「カババ」を開発した、株式会社アラカンの魅力に迫るインタビュー。非エンジニアである代表の田中がエンジニアチーム、プロダクト開発にどのように向き合っているのかをインタビューしました。
この記事では、株式会社アラカンの開発プロセスやエンジニアチームとの協働、経営者として意識しているポイントを紹介しています。田中社長とエンジニアチームのコミュニケーション方法を深掘りしていきましょう。
議論を重ねた開発プロセスで、開発目的の合意を大切に
ープロダクトの開発プロセスについて、具体的な進め方を教えていただけますか？
私を含めたすべてのスタッフからの要望に対して、毎週行うミーティングで優先順位やスケジュールをディスカッションしながら決め、開発を進めていく流れです。
要望はSlack上に具体的な要望を書き込み、まとめるようにしています。
私からは「プロダクトの新規機能の追加」や「大幅なプロダクトの仕様変更」のような事業目線の大きな観点から要望を出すことが多いです。一方で、社員はカババの裏側にあたる管理画面を触って業務を進めることが多い為、現場からは、日々の仕事の中で不便な事や効率の悪い部分「ミスが起きやすい作業をIT化で改善して欲しい」という要望が多いです。
開発の優先順位は、誰かの一存ではなく、エンジニアメンバーと議論しながら決めています。
ユーザーの満足度を上げてサービスの不満を解消したいと考えているため、原則として、価値を提供できる機能の開発を優先順位高く開発するようにしています。それぞれの機能の目的を経営、現場、開発チーム間でしっかり共有をしつつ、開発を開始しています。
ーエンジニアメンバーとのコミュニケーションで、気をつけていることを教えてください。
ユーザー向けの機能はもちろんのこと、社内メンバーが業務で使用する機能を開発する際も「なんのために作るのか？」を、お互いに合意することが大事だと考えています。
また、要望の全てをシステム化することを前提に考えるのではなく、例えば業務向けの機能については、社員がオペレーションの中で手間をかければ解決できる部分も含めて考えることを意識しています。
エンジニアとディスカッションをして、機能の追加や削ぎ落としを決定し、1つ1つ仕事を行っています。
また、過度な残業をしてでも、プロダクト開発を進めることは求めていません。限られた時間の中での最大効率は求めますが、エンジニアのワークライフバランスを保つことを意識しており、エンジニアの業務量が多い場合は、優先順位を組み替えたり、スケジュールを見直したりしています。
また、何かをフィードバックする時に、Slackを使ったテキストコミュニケーションではネガティブな印象が残ると思った場合は、口頭で丁寧に説明することを心がけています。
ーメンバーとディスカッションを重ねながら開発を進めているとのことですが、このようなスタンスを取っている背景を教えてください。
以前は私の指示に従いエンジニアメンバーと深い議論なく開発を進めていた時期もありました。
そのとき、私が開発を依頼したあるサービスを、エンジニアは私が希望した期日を守りたいという一心で、自ら率先して残業をして作ってくれたんですよね。しかし、開発したサービスは鳴かず飛ばずで終わってしまいました。
エンジニアは、依頼通りの期日を守るために身を削って開発したのに、サービスが売れない結果に終り、無駄骨を折る感覚になったのだと思います。フラストレーションが溜まった様子が見て取れました。
これをきっかけに開発する時には、私とエンジニアでサービスを作る目的や背景、成功確率をディスカッションするようにしました。
一つ一つの開発に対する重要度や緊急度を理解してもらうことで意味のある頑張りができるようにしたのです。
またこれには、エンジニアのモチベーションを保つ効果もありました。エンジニアは、自分が作った機能がプロダクトを使う人にどんなふうに役立ち、感謝してもらえるのかを知って、仕事のやりがいに繋げています。
流行の経営スタイルではなく、普遍的に大事なことを意識
ー会社全体の経営についてもお伺いします。会社を経営する上で意識しているポイントを教えてください。
流行の経営スタイルではなく、人間や世の中にとって、普遍的に大事なことを意識しています。
経済学者ピーター・ドラッカーの書籍を読み、そこによく登場する「誰が正しいか」ではなく「何が正しいか」を大事にしています。これは、議論や決定に際しては、誰が提案したかではなく、その提案の内容が正しいかどうか、つまりその提案が事実に基づき、目的達成に適しているかどうかを中心に考えるべきだという考え方です。そのような考え方からも、組織を縦方向ではなく、なるべくフラットにする意識を持っています。
組織の縦階層を増やすと、率直な意見を言いにくくなるので、組織をフラットにして横の階層を増やし、社員が意見を言いやすく風通しの良い組織にしたいです。
また、意見が言いづらい組織では、重大なミスを見過ごす可能性も高まるため、エンジニアのライフワークバランスを尊重するなど社員満足度が上がるような経営を、日々意識しています。
ー社員満足度を重要視している理由を教えてください。
会社の売上は、働いている社員次第で変わります。私は顧客満足度と同じく社員満足度も売上に直結すると考えており社員のモチベーションが低いと生産性も下がるので、経営者として社員満足度を上げることを意識しています。
ー社員満足度を上げるための取り組みは何かありますか？
先ほども申し上げた通り、無理な残業はせずにワークライフバランスを保つことを意識しています。また、スキルを上げる為のバックアップをしています。社員には、新しいスキルや世の中で流行っているスキルを身につけるための時間を用意しており、必要な書籍の購入やエンジニア同士の勉強会や交流会への参加費用も会社が負担しています。
最近はAIの流行を受け、プロダクト開発にAIを組み込むための時間を確保しています。
CTOとスペシャリストの採用により、理想の開発チーム構築へ
ー開発組織の話に戻りますが、今の開発チームにはどのような課題がありますか？
開発チームの課題は、2つあります。
エンジニアの人数が不足していることと、インフラやプロジェクトマネジメントなど、各分野に精通したプロフェッショナルなエンジニアが不在であることです。
エンジニアの人数不足により開発スピードが追いつかずサービスに滞りがでています。
また各分野のスペシャリストが現状いないため、1人のエンジニアがフルスタックエンジニアのような形で、私との折衝業務やインフラの構築や保守、コーディングを担当している状態です。
これだとエンジニアの成長を考えた場合にも、広く浅くはカバーできる人材になるかもしれませんが一つの仕事を深堀できず、スキルの底が浅くなる危険性があります。
ーエンジニア不足が課題とのことですが、今後どのような人を求めていますか？
マネジメント能力が高いCTO、インフラなどITの各分野に精通したスペシャリストの2つの人材を求めています。
ITの分野ごとにスペシャリストを入れ、マネジメント能力の高いCTOが取りまとめる。このような組織を作ることが、既存のエンジニアのスキルを伸ばし、生産性を高めることに繋がると考えています。
社員のスキルを効率的に上げる方法は、その人よりもスキルの高いエンジニアに直接教えてもらうことですよね。エンジニアが1人で書籍や教材などで学ぶよりも、スペシャリストを一人入れ、その人から教わることでスキルアップのスピードは加速します。
結果、サービスの立ち上がりや事業拡大が早くなり、社員へ金銭的な報酬や役職をフィードバックできる状態が理想ですね。
ーCTOに何を期待しているのか教えてください。
CTOには、プロフェッショナルが率いる各部門の状況を統括する仕事を期待しています。あわせてプロダクトオーナーとしても、アラカンの開発したサービスを理解し、プロダクトの改修や追加を判断する仕事をお願いしたいです。
ただ、現実的にCTOとプロダクトオーナーの兼務が難しければ、2名体制にすることも視野に入れています。
CTOとして最も重視している点は、エンジニアスキルの高さも大切ですが、エンジニアの頑張りや仕事のクオリティを正しく理解できることですね。
与えられたミッションの難易度やプロダクト開発の大変さを理解し、正しい情報伝達のもとでマネジメントできるCTOがいいチームを作れると思っています。
プロダクトオーナーとしては、プロダクトの先にある、サービスを利用するエンドユーザーや社員が気持ちよく使える状態を想像して目指せる人が理想です。
CTOには、システムに関わるすべての権限を移譲し裁量高く働いていただきたいと思っています。