目次
■おすすめ企業
2018.08.17 2023.12.14 約4分
手軽に投資が行えるオンライン証券会社、株式会社FOLIOを支えるエンジニアにお話を伺う連載の第3弾は、バックエンドエンジニアチームのリーダーである村上拓也氏にインタビュー。アジャイルコーチやスクラムマスターとしての役割も期待されて入社した村上氏に、アジャイルコーチ・スクラムマスターという役割の難しさや組織作りのための具体的な働きについて伺いました。
FOLIO | 連載記事
16人で構成されるバックエンドチームは職能で分けられたチームとしては社内で一番の大所帯。このバックエンドチームをリードするのが、2018年2月に入社した村上さんです。
「私が何をしているかというと･･････」
しばし考え込んで慎重に言葉を選びながら話し始める村上さんは、入社してから組織のあるべき姿を模索してきたと言います。
「FOLIOは、私が入社した時は全体で50〜60人の組織だったのですが、現在は80～90人規模となりました。そしてまだまだ人数は増え続けています。そんな中で私が直接関わっているのは16人のバックエンドエンジニアチームですが、その人数枠にとらわれずどう組織づくりをしていくのかというのは、いろいろ試行錯誤、それこそ失敗もたくさんしながらやってきました」
実際、村上さんがFOLIOに入社したとき、社内にはスクラムに関する資格や深い知見をもつメンバーはいなかったそうです。そこで期待されたのは、Scala でのバックエンドシステムを開発するエンジニアとしての働きに加えて、認定スクラムマスターの知見を生かした役割だったと言います。
「スクラムマスターやアジャイルコーチというのはとても誤解されやすい言葉だなと思うんです。認定スクラムマスターの資格にしても、当たり前ですけどそれを持っているから組織づくりが行えるかというとそういうわけでもありません。資格ということで言えば、プロドライバーが普通免許持っていますよねくらいのものだと思っています」
認定スクラムマスターの位置づけはともかく、開発プロセスやプロジェクト、企業体の改善の救世主とも言われるスクラムマスターや、アジャイル開発のなかでコーチングの手法を用いてチームの自己組織化を支援するアジャイルコーチは、今後ますます注目を浴びる役割と言えます。
自社プロダクトを内製し、FinTechという新たな分野に参入したFOLIOですが、ベンチャーとして急成長を続けるなかで、「将来を見据えた組織づくり」も同時並行で進められています。
ここからは、バックエンドエンジニアチームのリーダーとしてメンバーを支える村上さんの言葉に耳を傾けてみましょう。
（比較的規模の大きいプロジェクトを開始する際に行う”Big Wall”と呼ばれる見積もり手法を行っている様子）
――バックエンドチームのリーダーとして行っていることはどんなことになりますか？
「16人のメンバーに対してやっていることは、最低限のヒューマンマネジメント。具体的な活動で言うと、メンバーとの1on1は欠かさず行っています。もともとFOLIOはリーダーシップを持つ人の集まりで、それを最大限に活かすことで成り立っている組織なので、これまで他の会社に比べてマネジメント層が薄くても機能してきた会社ではあるんです。私にしても、明確にこれをやってと決められているわけではありません。むしろ最近では、アジャイルコーチとかスクラムマスターという言葉を意図的に使わないようにしています」
――意図的に使わないというのはどういう理由があるのでしょう？
「スクラムマスターやアジャイルコーチという肩書きや役割に自分がこだわりすぎていたなという反省があるんですよね。入社当初には積極的にスクラムマスター、アジャイルコーチ的な働きをやっていました。その結果、メンバーから『すごく変わった』『良くなった』と言ってもらえたこともあるのですが、自分にとっては失敗の連続だったんです。必要だと思う働きかけをしたつもりだったんですが、結果的にそれまでうまく行っていたことの動きを遅らせることになったこともあったんじゃないかなというのが正直な感想ですね」
――具体的にどのような働きかけに変えていったのでしょう？
「一例で言うと、現在のFOLIOではLINEさんとの提携、協業により動いている大きなプロジェクトにリソースが重点的に割かれていたり、少し前だとメンバー数に対して進行する開発案件が過剰なこともありました。開発チームの自己組織化を促したり支援することに徹するよりも、まずはプロジェクトの交通整理やサポート役に回ることを優先しています。スクラムマスターは、マネージャーやリーダーと誤解されてしまうことも多いけど、組織をマネージする立場とは少し違うし、リーダーシップを発揮しなければいけない局面はあるけど、リーダーではありません。『チームがセルフマネジメントできるようになることを支援すること』これがスクラムマスターの仕事です。 アジャイルコーチにしても、コーチですから、自分がプレイヤーとして参画するのではなく、各プレイヤーやチームのサポートや支援をするのが仕事になるんです」
――なるほど。それで現在はチームのメンバーとの1on1を中心に組織づくりをしているわけですね。
「以前のFOLIOでは、仮に一人ひとりのメンタルヘルスコンディションとか、モチベーションのコントロールなどの部分の問題があるとしたら、それがすべてCTOのところに行っていたんですね。そもそもCTOがそういうことをする役割なのかという問題と、組織がスケールする中でそこに負担が集中してしまうのは無理があるよねという話をしていて、チームリーダーが自主的にそういう役割を担いはじめているというのが現状です」
――メンバーに対して具体的にはどんなことを？
「新しい機能の開発や、Webシステムで日々起きている問題への対応などありますが、そこに関して自分がリードするのではなく、メンバーがリーダーシップを発揮する上でのサポートですね。主には1on1で出てきた「やりづらさ」だったり、「やりがい」だったりに対して、どんなふうに仕事を進めていけばいいかということを話しています。問題によってはチームや組織全体で考えるように促したり、改善する動きを作ったりしますし、個人的なものであれば必要な場合はフォローします。15営業日かけて、15人のメンバー全員と話すのを1ラウンドとしているんですけど、ラウンドごとにメンバーが似た話をするんですよね。それは普段のメンバー同士の会話に上がっている課題や興味がチームに浸透していっているというのもあると思います。ただ何か問題が起きたとき、何も考えずにメンバーの最大公約数をとるとイケてない結論にたどり着いてしまうこともあるじゃないですか。最大公約数自体が悪いわけではありませんが、一人ひとりと個別に話をしていると、多数決や妥協ではない結論の可能性が見えてくるんですよね。
もう一つ、サービス開発のマネジメントのリードの一人という立ち位置もあります。プロダクト開発を行う上で、何を作るのか？ それをいつまでに作るのか？ そのためにどれくらい人やリソースを割くのかというリリース計画を立てる仕事ですね。いまはこの仕事の割合が多くなっていますが、進行中のプロジェクトに対して、優先順位や依存関係を明らかにして、組織が迷わないように交通整理を行っています」
――そもそもどんな経緯でスクラムマスター、アジャイルコーチに取り組もうと思われたんですか？
「新卒で入った会社が、学生時のプログラミング経験やコンピューターサイエンスのバックグラウンドを見るのではなく、ビジネスマンとしての素養を見て採用して、育てるというコンセプトだったのが大きいですね。自分のキャリアの話になりますけど、私は出身大学自体に理系学部がないというくらいバリバリの文系なんですよ。商学部商学科でマーケティングの一分野である消費者行動を研究するゼミに所属し、新卒で入ったのが金融機関向けにトレーディングシステムを提供するシンプレクスという会社でした。シンプレクスは新卒研修が終わったあとに、システム開発の上流から下流までのうちどの工程を担うかが決まるんですよ。職種としては当時はすべての新卒社員が一律でITコンサルタントで、全員が同じく一律で金融工学やプログラミングの研修を受ける。研修後の配属は新卒社員の適正や強みをベースに決められるのですが、私の場合はソフトウェアのコードを日常的に書くようなプロジェクトに配属されたんですね。そこからエンジニアの道を歩むことになります」
――エンジニアとしては異色のキャリアですね。
「そうかもしれませんね。だから気持ちの中では『エンジニアの村上さん』じゃないんですよ（笑）。エンジニアとして社会人の一歩を踏み出しましたけど、お客様からの電話もすごく取っていましたし。キャリアのスタートがそういう形だったので、その時々で組織に必要なことをやるのが自分だという考えが身についたのかもしれませんね。その後、サイバーエージェントのアドテクスタジオに移ったのですが、ここでは小さいプロダクトの開発リードを務めつつ、元々興味のあったアジャイル開発について勉強する機会がありました。アドテクスタジオは、エンジニアが200人、ビジネス100人、合計300人くらいの人間が働いていて、だいたい10人単位、多くても30人くらいのチームでそれぞれ広告のプロダクトをつくるという形態だったんです。その一方でチームを横断して研究を行うゼミ制度があったんですが、そのなかに『リーン・アジャイル開発プロセスの研究』というゼミがあったんです。ここで学んだことを、仕事で実践できたのがその後に影響を与えていますね。よりアジャイルな開発組織を作れば、価値のあるプロダクトが素早く出せるということを実感できました」
「元々興味があった分野ですが、日本でアジャイルコーチという役割の重要性を認識している企業や、そういうキャリアパスを明確に歩む人は欧米に比べると少ない。そこで自分の実力を発揮できたら、とは思いました。組織の中でブルーオーシャン戦略をとって、自分自身の価値を最大化して組織に貢献するのが自分の生存戦略だと考えているのですが、その結果というか今の答えはそれ、といった感じです」
――そして、FOLIOでの仕事につながるわけですね。
「FOLIOでは、ジョインする際に期待してもらったこともあり、アジャイルコーチ、スクラムマスターの役割をしっかり担えればと思っていたのですが、すでにお話ししたような状況もあり、単に支援する立場だと限定することをやめた形ですね。単一のスクラムでは『9人以上のチームでは機能しない』とスクラムガイドに書かれています。一方で、FOLIOのプロダクト開発に関わるのは、バックエンドエンジニアとフロントエンドエンジニアを合わせただけでも20人にのぼるし、他のクリエイターやビジネスメンバーも含めて何十人もでひとつのプロダクトを作っている。また、スクラムは『ワンストップですべてのことがこなせるチーム』を理想としていますが、FOLIOで採用しているマイクロサービス的な発想とは一見相性が悪そうにみえるというか。マイクロサービスは責務に応じて必要なサービスと組織を組んでいくやり方なので、相反する面も出てきます。そういう状況で、教科書的に『このやり方がいいよ』と、現実の問題をどう解決するかを出発点に考えられなかったという反省はあります。スクラムマスターやアジャイルコーチというのも解決策のひとつであり、今のFOLIOに自分が貢献する形として適してない、と考えたということです。実際の運用に関しては、どちらかに振り切るのではなく、企業や組織ごとに落とし所を見つけてアジャストしていかなければいけません。その辺、いまは柔軟に、問題に即して落しどころを見つけるようにしています」
（「すごい綺麗に参加者が挙手していますが、ヤラセではないんですよ！撮った人のタイミングが上手いですよね。」と語る村上さん）
――アジャイル、スクラムの手法を共有したことで変わったこともありましたか？
「それは間違いなくありますね。方法論、解決策を共有したなかで議論が起きて、そこを出発点に話ができるようになったのはいい傾向だと思いますし、議論が一巡して問題意識が高くなっていると感じます。自然発生的にいろいろなことを自分なりに解釈して改善する人が増えています。改善だけに時間を割いて新しい機能を開発しないわけにはいかないし、新しい機能の開発に忙しくて時間がないから改善しないというのも違うよね、ということを意識して動けているのが良いなと思います。
この会社に入ってすごいなと思うのは、エンジニア一人ひとりがいろいろな仕組みを理解した上でプロダクトを作っているということです。OSS で公開されているライブラリやフレームワークなどをただデベロッパーとして利用するだけではなく、奥深くまで理解して、必要となったら効果的なチューニングもできる。今の自分の立場はエンジニア組織をエンジニアリングする役割なのかなと思っています」
「自分はコードを書けないし、ソフトウェアもつくれないけど、組織はつくれますというのが一番ダサい。だからやっぱりエンジニアとしてソフトウェアやシステムを作れるスキルも保っていたいなと思う気持ちも、もちろんあります」
そう言って笑う村上さんは、「期待値が高い中でプロダクトを生み出さなければいけない」いまの状況が、組織づくりにおいてもやりがいのある環境だと言います。
「FOLIOではやりたいこと、やりたい仕事が明確で、よほど求められるポジションから外れていなければビジネス上の要請や期限と戦いつつも自由裁量でやらせてもらえる柔軟さがあります」
組織にとっていま何が必要かを考え、それに応じて自分の仕事をつくっていく。FOLIOでは旧来の与えられる仕事だけでなく、自分で自分の仕事や役割を創出していく新しい働き方を実践している人が増えています。
「メンバーや同僚と話していて、多様なメンバーの間で共通しているなと思うのは、世の中にインパクトのあるプロダクト、良いプロダクトをつくり続けていくことが重要だと考えていることです。最終的に自分たちのプロダクトを愛せるかどうか、誇りに思うかどうかなんです」
いまや国民的なインフラとなった『LINE』との資本業務提携を発表し、文字通り日本の投資の概念を変えるという新たなチャレンジをするFOLIOは、組織づくりの上でもアジャイルの考え方を取り入れ、持続可能な組織を模索しています。
「エンジニア組織をエンジニアリングする」
FOLIOがこれからさらに成長していくために欠かせないものが、この言葉にあるのかもしれません。
