CTO経験によって「システムに対してやり切る覚悟」を携えハコベルへ！トラブルなくお客様の業務を止めないプロダクトづくりに熱中
リモートワークと出社のハイブリッドで仕事をできることも働きやすさのひとつ、と語る北川 大輔。本人いわく「発言によってばかにされたり、嫌な思いをしたりすることがない」、という心理的安全性も相まって発言に責任を持って働く意欲につながると言います。目標だった「30歳までにCTOになる」ことも実現し、あらためてハコベルで情熱をもって開発に臨む姿をご紹介します。
システム開発部 軽貨物運送手配システムグループ
北川 大輔 Daisuke Kitagawa
新卒で株式会社ドワンゴに入社しフロンティア開発部所属。エンジニアリングを軸に企画開発から品質保証、保守運用サポート等の幅広い業務を担う。その後「30歳までにCTOになる」目標に基づき、ベンチャー企業でCTOとして参画。仕事を通して物流課題に直面する出来事を契機に、社会課題解決を望み2023年２月、ハコベル株式会社入社。現職。
従業員規模1000人の企業での幅広い業務経験を経て、少数精鋭ベンチャーで目標としていたCTOに就任
—— 現在ハコベルでエンジニアとして勤務なさっておられますが、これまでどのようなご経験をしてきたのでしょうか。
新卒で入社したのは従業員1,000人規模のエンタメ系企業で、次に転職したのは数人の従業員規模のベンチャー企業でした。それぞれ極端に異なる環境下に身を置いて…、といったところでしょうか。新卒からエンジニアでありつつ幅広い業務を担当し、企画・開発・品質保証・保守・運用・サポートと、ありとあらゆる仕事を経験させてもらいました。
具体的にはドワンゴという会社で、主に高校生もしくはインターネットを通じて教育を受けたいかたにオンラインで教育サービスを提供する「N予備校（現：ZEN Study）」というサービスで、企画や開発に従事していました。そこからベンチャーに転身したのは、私のなかで「30歳までにCTOをやる」という目標があったから。縁あってCTOでのオファーをいただいた経緯で転職することになりました。
—— 目標にしておられたCTOですが、実際に経験してみていかがでしたか。
なにからなにまで自分でやるという経験は、現在のハコベルでのテックリードで仕事をしている礎をつくれたのではないか、と今改めて感じるところが多いです。「システムに対して面倒を見るのは自分だ」という、土台、覚悟といったものをCTO経験で手に入れることができましたね。やはり、いち従業員の立場ではなく最高技術責任者という「すべての責任を負う」という立場、仕事特性からそこに至ったのではないでしょうか。
望んでいたとおりの経験を積んでいたとき、偶然に遭遇した出来事によってハコベル転身を考えるようになったのです。関与していた事業において、ある工場地帯で人材が不足しているという話がありました。もしくは、そこを回るトラックが少ないという課題がありまして、それらに対しサービスを提供することで社会問題を解決できる、といった内容でした。その過程で、運送業界が実は今後ドライバー様の成り手が少ないことや、反対に荷物の数はEC隆盛等もあって増加の一途であるとか、そうした課題があることがわかってきたわけです。「自分もその業界に身を置きたい」。そう思ったことが、ゆくゆくハコベルを知るきっかけとなっていきました。
「エンジニアは問題解決が仕事」というハコベルの考えに深く共感。システムは日々新陳代謝をして腐らせず維持していく
—— そうしたご経験から目の当たりにした物流課題によって、2023年２月にハコベルへご入社になられます。具体的にどのような業務を担当しておられますか。
現在は、軽貨物のシステムを作成する開発グループのリーダーを務めています。私がメインで従事しているのは主に、PdMプロダクトマネージャーがシステムをご利用になる方々のさまざまなご意見を吸い上げ、すり合わせてこられた内容を具現化していく業務です。たとえば社内のユーザー部門や、ビジネスグループであったり、運送会社の場合もありますし、ドライバー様であったりとさまざまです。そうした皆さまの「どういった機能やサービスが欲しいか？」といったご意見をまとめてきてくださるんですね。もちろん、私自身が直接ユーザーのかたにヒアリングをしたりご提案をするなどを経て、使いやすさを加味したうえで「なにをつくるか？」といった部分を決めていくこともあります。
システムというと、リリースしたあとはあまりメンテナンスも不要というイメージもあるかもしれませんが、我々が主にやっていることというのは、「そのシステムが腐らないように維持する」という面もあるのです。
少し具体的にお話しますと、使用しているライブラリやパッケージなどが陳腐化したり古くなっていたり、あるいはセキュリティ上の問題があるといった際に、それらを取り除いて新しいものに変更することが必要です。そのほか、新しくこういった機能が欲しい、ああいった機能が欲しいといったご要望を常にいただきますので、それにお応えするというのも我々チームのミッションのひとつとなっています。
—— つくって終わり、ではなくシステムはずっと新陳代謝していくのですね。さて、ハコベルのエンジニアチームの特徴についても知りたいです。
ハコベルはけっこう特徴的だと思います。チームごとに方針がまったく違うんですよ。要するに、最善と思われるやりかたを各チームで採用することができます。たとえば、あるプロダクトをつくるとしても、ペアプログラミングといって二人一組でガッツリやっていくチームもあれば、基本的にはひとりで進めていくというチームもあるんです。さらに、使用ツールもプログラミング言語も、それぞれのチームで独自に選定することができますし。
会社によっては、使用するツールなり言語なりを統一しているところはあるのですが、ハコベルではそれぞれのチームごとの独立性と言いますか、「チームにとって本当に良いものを選択する」ということをすごく大切にしているんですね。
また、ハコベルのものづくり、プロダクト開発についてでは、たしか中村さんが仰った言葉がすごく印象に残っています。「エンジニアはプロダクトをつくる、もしくはプログラムを書くことが仕事ではなく、問題を解決することが仕事である」という言葉。「エンジニアは」と主語を置きましたが、これは別にエンジニアに限らないのかもしれないですよね。このことは自分の戒めとしても置いていて、ハコベルのチームでは、一人ひとりがその意識を強く持っているな、と日ごろから感じています。
問題解決能力を高めるために、各人の経験値から多数の引き出しを持っておく
—— 至言ですね。もうひとつ、「プログラミングは手段であってそれは目的ではない」といったこともお話されていたと記憶しています。
私もそこは同じように考えています。先ほどチームによって使用するベストな言語やツールがあると考えているかたが多いと話しましたが、それとけっこう同義なのではないかと考えていますね。「エンジニアは問題を解決するのが仕事」とした場合に、たとえば荷主様側の課題として、「荷物を送りたいときにトラックが見つからない」といった課題に対し、素早く解決する方法として私たちが提供するトラックマッチングがありますよ、とか。社内で運送手配を使ってこういうことをしたい、けれど現在の状況ではそれができないというときに、「私たちはこういうことができます」というように、いろいろなかたが「本来こうしたいのにできない」と考えていることが、その課題や問題にあたるのではないかと思うのです。なので、課題は人によってさまざまにあるものですよね。
—— これまでに特に印象的だったことがあれば教えてください。また、ハコベルのエンジニアに欠かせないことはなんでしょうか。
まさにいま、取り組んでいるプロジェクトですね。取り組んでいる最中なので詳しくはお話ができませんが、言える範囲でお話しますと「大規模なリアーキテクト」です。リアーキテクトというのは、システムの構造を変えるという意味ですね。
たとえば実際にシステムを運用していくにあたって必要な手数、工数を減らしながら、オペレーションのミスや実装のミスを減らしたりすることができるようになります。それだけでなく、いまビジネスチームが「こういったことをやりたい」という要求があった際に、私たちが提供しているシステムでは不可能な場合にも対応できるようにする、など。これらによって、粗利を増やして販管費を下げる、つまり会社の業績をよくすることが期待できるわけです。
ハコベルのエンジニアに欠かせないことは、問題解決能力への感度だと考えています。ただ、これはエンジニアにのみ問われるものではないと思いますが、一方でエンジニアには特に求められていると言えます。そのためにも、多彩な経験からくる引き出しの多さが大切で、たとえば特定分野の知識量の深さであったり、運送業界の知識の有無やトラックドライバーとして働いた経験があるとか。他には過去に大きなプロジェクトの経験があるかなどもそうかもしれません。障害が起きた際に原因の仮説を立てるうえで、引き出しの多さは重要になってくるのです。
荷主様・運送会社様・ドライバー様というお客様とハコベル、そして社会の「三方良し」を目指して、プロダクトを磨き続ける
—— そういう意味では北川さんにおいてはCTO経験による経営的視点を身に着けたことも該当しますよね。仕事を進めるうえで工夫していることはありますか。
あっ、それは大きいかなと思います。先ほど「粗利を増やして販管費を下げる」といったことを言いましたが、減価償却の話や資産計上といったところも、前職で貸借対照表とにらみ合いをしてきた経験が活きていると思います。取締役会の資料をつくるなどもしていましたので。なにがどこで活きてくるか、人生わからないなと感じています。
また、いつも心がけていることがあるのですが、なにをするにおいても記録を残すこと。仮にある技術的な決定をする際に、「なんでその決定をしたんだっけ？」と後からその背景を追うことができないと、過去におこなった判断が正しかったのかどうかの検証ができなくなるのです。そうすると、「変更してよいのかどうかわからない」という問題が発生するんですよね。大昔に書かれたコードが残っているときに、消してよいのか判断がつかない、といったことはけっこうあることなんです。
ですので、ソースコードにコメントを残して「なぜこの処理をしているのか」、「どうしてこういう数字になっているのか」や、「それはこういう背景による」といったことを残すようにしています。これをしておくと自分も助かるし、チームの皆さんも助かるし、さらにはあとからチームに参加するかたも助かることになりますから、これを積極的にやるようにしています。
お客様がご利用になるものをつくるということは、品質を預かっているわけですから、すべて記録を残すこととは、逆にリスクヘッジになっている一面もあるのかもしれませんね。
現に「こういう動作って正しいですか？」というご質問をいただいた際にも、絶対に正しい答えが必要なときにはソースコードが頼りになるので、そのときに情報があるとお返事できるスピードに大きく差が生まれてしまうんです。やはり情報を残しておくということは、いろんな局面や人にとって役立つのだと思っています。
—— 現在感じておられる課題と、北川さんがこれから手がけてみたいことがあれば教えてください。
そうですね、ひと言でいうともっとも課題と感じていることとしては「システムの複雑性が高い」ことでしょうか。「ハコベル運送手配」は他のハコベルのプロダクトと比べて歴史が長く、かなり以前から運用されているプロダクトです。そのため、最初に書かれたソースコードが10年近く前なんですよね。その過程でいろんな機能を付け加えてきているので、複雑性も伴っているのです。データもさまざまな過程を経て、保存したり削除したりしてきていますから、工夫のしがいがあります。。
保守や新たな機能実装は、高まった複雑性を下げていくことで安定して行うことができます。適切なメンテナンスを行っていく必要があるのですが、それを難しくしているのが、いま現在もお客様が日々ご利用になっていて、データや案件をお預かりしている状態で進めなくてはならないことです。お客様の業務に支障が出ないようにすることは絶対ですので、動いているものを正常に動かしながら良くしていくことが求められています。よく、「電気が流れたまま、鉄塔の送電線を付け替える」みたいなたとえをするんですが、まさにそのイメージですよね。動いているまま、その活動を止めずに良くしていく必要があるのですから。
一方で、今後手がけてみたいこととしては、新規事業が立ち上がることがあればぜひ携わってみたいです。もしそうしたタイミングがきましたら、「できます！やります！やりたいです！」と、手を挙げる準備はしておきたいですね。
他には少し抽象的な表現になりますが、荷主様・運送会社様・ドライバー様といった「お客様」と当社ハコベルと社会と、この三方が満たされるような「三方良し」の精神を実現させられるように、私たちのプロダクトをより便利に安定的に使えるように、引き続きプロダクトを磨いていきたいと考えています。
この記事が気に入ったらサポートをしてみませんか？