課題があるからおもしろい。エンジニアマネージャーが見据える組織と技術の展望

多くの内定を断りレバレジーズを選んだ理由は「自分でつくりあげていける環境」

まずは現在の仕事内容を教えてください。

メイン業務はレバテックのシステムの品質を担保することです。そのために、技術課題の改善や体制づくりをおこなっています。

　

具体的には、大規模なレガシーシステムからマイクロサービス化をおこない、変化に耐えられる汎用性の高いシステムをつくっています。ドメインとしてあるべき姿を考え直して設計したうえでマイクロサービス化し、gRPCの導入やTypeScriptへのリプレイスを通して再利用性やスケーラビリティを高めています。

　

前職ではどんなことをされていたんですか？

前職は大手の事業会社で、企業や行政に向けた固めのBtoBサービスを開発していました。そのサービスは、僕が入社するタイミングでちょうど新規事業として立ち上がったもので、半年後には開発リーダーとして、規模の大きなバックエンドを任されました。

　

この新規事業は経営層からの期待が高く優秀なメンバーで構成されたチームだったため、各メンバーからアジャイルやスクラム、さらにはマネジメントまで学ぶことができ、幅広く成長させてもらったなと思っています。

　

そんな成長環境に身を置きながらも転職を考えたということですが、開発をするなかで感じていた障壁があれば教えてください。

前職では、スピードが遅くなかなか物事が前進しないことにモヤモヤしてました。「大手あるある」かもしれませんが、承認を得るまでのフローが長く何かと時間がかかっていましたね。たとえば、1つのシステムをリファクタリングするためには、30ページくらいの膨大な資料をつくって提出する必要がありますし、承認がおりるまでリファクタリングできないんですよ。これだけで合計2ヶ月くらいかかります。

最終的に転職を決意したきっかけは何だったのでしょうか？

より大きな裁量が欲しいと思ったのがきっかけです。前職が上場している企業だったこともあり、どうしても年功序列の文化が出来上がっていて、長く務めてグレードを上げないとチャレンジできないことが多かったんです。自分が「すでに習得したスキルだけ」を発揮し続けていても、スキルアップはできないと考え転職を決意しました。

　

そうだったんですね。河村さんは数ある事業会社のなかから、なぜレバレジーズに入社を決めたんでしょうか？

いろいろありますが、1番は自分でつくりあげていける環境があったからです。まず前提として、僕は「誰かに教えてもらう環境」をまったく欲していなくて、「1から自分の力でつくっていける環境」を望んでいました。

　

そのため、有名な会社から内定をもらっても、あまり興味を持てずに断り続けていたんですよ。理由は、僕に期待されていることが基礎を学ぶこと前提のポジションだったり、一部の技術だけを求められていたりと、自ら裁量をもって何かを創造できるような環境ではなかったからです。

　

でもレバレジーズは、僕が今まさに関わっている「レバテック」の課題感をありのまま話してくれて、「現状を変えていきたい」と一緒に課題解決していく仲間を求めていたのでものすごく興味を持ちました。
具体的には、レガシーシステムを抱えていて、これから年数をかけて全面的にリプレースしていこうとしていることや、コア・コンピタンスをどうやってつくっていくか、など…。まだまだ未成熟なところに対して、自分がどのくらい変化をもたらせるかを考えたら創造力が掻き立てられました。

　

また、この話を僕にしてくれた先輩のエンジニア社員も圧倒的なスキルを持っていて、一緒に進めることができたらおもしろそうだなと思ったんです。この規模の、このフェーズのレバレジーズは、僕にとって非常に魅力的でしたね。

レバテックの技術/組織課題

河村さんが関わっている「レバテック」の技術や組織の課題について教えてください。

まず技術課題からお話しますね。大きな課題は、先ほど少し触れたレガシーシステムのリプレースです。使っているフレームワークやバージョンが古く、保守・運用されていないシステムが多くある状態でした。古いシステムは扱える人が限られてしまうため、アップデートされずに誰も手をつけられない状態のものもありました。

　

これによって、障害が起きたときに誰も直せなかったり、開発を進めたいとなったときに誰も仕様がわからなかったりと、多くのリスクがあります。開発のスピードも遅くなりますし、保守・運用のコストもかかります。

　

一方で、モダンなシステムのメリットは、無駄なコストや人的な損失を生み出す原因を排除できるので、スピードが速まったり、運用・保守も楽だったりします。あとは大規模なアクセスにも耐えられるようなスケーラビリティなシステムにしていくためにも、リプレースは必須ですね。

　

レバテックとしては、世の中のニーズや変化に素早く対応できるシステムにしていかなかればなりません。つまり、アジリティやスケーラビリティを担保できるシステムにしなければならないのですが、現在のレガシーなシステムでは実現が難しい状態です。

　

そこで手段として、マイクロサービスアーキテクチャを採用しています。これにより、レバテックのシステム内における再利用性や変更容易性を高められるようにしています。

　

さらに、マイクロサービスアーキテクチャの開発を進めるうえで、TypeScript、gRPC、クリーンアーキテクチャ、ドメイン駆動設計などを利用しています。

　

なるほど。では、開発側の人がドメインを理解していることで具体的にどんなことが変わるのでしょうか？

ドメイン駆動開発の理想形は、ソフトウェアをつくることではなくつくった先にあります。「ビジネスにどう活かすのか」を考えるのが1番大事なので、開発して終わりではないということをエンジニア全員に意識してほしいです。

　

アジャイルやスクラムと似たような考え方なんですが、「そもそも今自分たちが考えているデータやドメインは、何のためにやっているのか」を考えてまずは1つつくってみる。その変更優位性を高くして、「さらに早いサイクルでつくっていける環境を整え、ビジネス展開できるようなソフトウェアにしていきましょう」という考え方なので。結局ドメイン駆動設計を実践しないということは、より良いソフトウェア開発に繋がらないのではないかと考えています。

　

アジャイルやドメイン駆動開発をしっかりおこなっているところは、ドキュメントが揃っていて開発しやすい環境をつくっているんだなとか。ちゃんと現場の人たちがその先を考えてやっているんだなという印象はありますね。

続いて、組織の課題について教えてください。

事業開発ではよくある課題かもしれませんが、開発部が事業部に対して請負の関係になってしまっていたところが1番の課題でした。所属しているエンジニアも「指示された仕様を受け取って実装し納品」と言われたことをただこなしている状態でした。

　

その考え方から直していかないといけないので、やはりアジャイルのような考え方を取り入れていかないと進まないと思いましたね。改善思考に至ることもなく、指示されたシステムをつくることに注力してしまい、技術的負債を生み続けていたので。

　

そして2つ目の課題が体制です。僕たちの1番の目的は「事業を伸ばすこと」です。でも、その目的を達成できる体制ではないと感じるところが多かったです。たとえば、保守・運用にリソースを割くフェーズではないのに続けていたり、そもそも保守・運用すべきシステムではなかったり…。誰も「このタイミングでリプレースした方がいいのでは？」という提案をすることができていませんでした。これは、すべてを現場任せにしていたのが原因のひとつです。みんなその場しのぎで言われたことをこなすことが精一杯だったんだと思います。

　

でもこの課題の本質は、事業スピードに組織や人が完全についていけなくなってしまい、そこに投資できないことだと思っています。

　

だからこそ、まず事業だけに目を向けず組織にもコミットできる体制をつくる必要があります。現場任せというのは一見裁量があるようにも感じられますが、体制が整っていないのをそのままにしておくと過去起きていたような悪循環が生まれてしまい、必要な判断ができなくなってしまいます。

　

組織は事業づくりの基盤なんですね。そのために今取り組んでいることがあれば教えてください。

まず体制をつくることに注力しています。最近読んだ本のなかに「チームトポロジー」という概念があって、現代にはどういった組織や開発が合っているかというところをわかりやすく書いていてくれてて。開発組織はこの概念を参考にチーム体制をつくっていこうと思っています。

　

具体的には、テックリードをできる人を増やしたいんですよね。現場のチームに入って全メンバーの技術力の底上げをしてくれて、システムの品質を担保してくれる。そういった人が複数人いてくれると各チームが安定し、レバテックの事業全体がさらに成長していくと思っています。現在は、僕を含めた数人でいろんなチームを回って各チームを醸成させようと動いています。

課題があるからおもしろい。エンジニアの組織改革

河村さんが考えるレバテック開発部門の理想形があれば教えてください。

僕の個人的な理想ですが、たとえば新しい事業が立ち上がったときにすぐにベストなメンバーをアサインすることができて、スピード感をもって実装できるような体制をつくりたいと思っています。

　

今レバテックでは、どんどん新しいサービスが生まれています。その大元となるシステムの完成度を上げていくことで、新しい事業との連携がうまくいくようになります。エンジニアリングはそういった事業を伸ばすための手段なので、それを実現できるようなエンジニア組織をつくりたいです。

　

そのために、エンジニア自身が事業内容をしっかりと理解し、より良い方法があればエンジニアから提案することが必要です。事業側と連携して最適なシステムをつくっていける組織にしたいですね。

　

では、河村さんもそういった開発組織の構築に興味をもってレバレジーズへの入社を決めたんですか？

そうですね。僕はフロントからバックエンドまで経験してみて、技術を極めていくこともおもしろいなと思ったのですが、事業を成功させるためには「組織」という基盤がないとそもそもの高い技術も価値がなくなってしまうことに気づきました。
だからこそ、エンジニアの技術を活かしてより良い事業をつくっていくために、組織づくりをできる人材になりたいと思っています。

続いて、仕事のやりがいを教えてください。

ここまでお話してきた技術課題や組織課題がたくさんあるところです。そういった課題をどのように解決していくかを考えていくのは僕にとってやりがいです。課題がないところで仕事をしてもおもしろくないと思うんですよね。改善できるところがたくさんある分、何から手をつけたら良いのかわからないときもありますが、アプローチ方法を模索するのは楽しいですよ。

　

そんな改革のひとつとして最近は教育体制をつくり、今年の7月から一気に変えました。

　

たとえば、AWSの担当者に来てもらい、勉強会を開いてもらっています。
これは、インフラに対応できる人が少なすぎるという課題から取り組むことになりました。アプリケーションの具体的なところだけを開発して終わってしまうことが多かったので、そこを改善していこうという意図です。

　

あと、今月からアーキテクチャのスキル向上にも注力していて、月一で組織全体の勉強会をおこなっています。これまでは、こういったスキルアップの取り組みをチームごとにおこなっていたんですが、現場に丸投げして属人的になってしまうのは違うと感じたので、全体で実施することになりました。

　

河村さんを起点として、さまざまな取り組みがスタートしているんですね。これから挑戦したいことはありますか？

繰り返しにはなりますが、テクノロジーで事業を引っ張っていけるようにまず組織をしっかりとつくっていきたいです。そのためにエンジニアが成長していける環境とは何かを突き詰め、行動に移していきたいと思っています。

　

そしてシステムとしては、リプレースを進めてマイクロサービス化にもチャレンジしています。進めるなかで気づいたのは、エンジニアのスキル不足だけが問題ではないということです。システムを変えるためには、根本的にドメインを変えていく必要があります。

　

たとえば、「案件のあり方は本当にこれが正しいのか」や「求人のあり方は本当にこれが理想的だったのか」など、もっと根本的なことまで遡って考えて、手段を変えていく必要があります。そうすることで今あるサービスを次のステージに近付けることができると考えています。

　

河村さんはどんな人と一緒に働きたいですか？

あたえられた宿題をこなすのではなく、自分で課題を見つけてその課題を解決するためにいろんな学びを通して自分を磨き、推進していける人です。

　

結局、僕がつくりたい組織は切磋琢磨できる環境なんですよ。そのためには、良い意味で刺激が必要なんですよね。自分の強みを活かしつつ、課題に飛び込んで組織ごと引っ張っていきたい人はレバレジーズに向いていると思いますし、一緒に働きたいと思っています。