ひとつ質問すると、どんなことでもおざなりにせず丁寧に答えてくれる。そしてその回答には「可能な限りわかりやすく伝える」という横山のスタンスが見え隠れします。そこには、エンジニアという職に欠かせない物事の透明化を追求する姿勢と、問いを重ねることで発現する真の課題を見出し、解決することを楽しむ横山ならではの仕事術がありました。

仕事内容の変化と共に拡がる業務領域や責任の範囲。一方で普遍的なこととは

—— ご入社3年目、前回のインタビューは2年目に入られたところだったそうですね。ハコベル入社以降のお仕事の変遷と、現在従事している業務内容を教えてください。

　担当したサービスの変遷はあるものの、それぞれの業務に対する向き合い方や担う仕事内容で見ると大きな変化はないように感じています。と言うのも、入社以降、自分が見る領域が変わったとしても、任された領域のなかでは当然技術的な意思決定を担ってきましたから、その範囲や広さ・深さが「どんどん拡がってきたな」くらいの認識なのです。

　担当したサービスの変遷では「ハコベル運送手配PLUS」の新規SaaS顧客導入のための機能追加などから始まり、「ハコベル運送手配」ではジョイントベンチャー化に伴う100％手配保証や料金タリフの改善などをおこなっていました。その後、西濃運輸様の基盤システムと連携するためのシステム改良も担当し、現在は一般貨物マッチング事業に向き合っているスクラムチームでスクラムマスターを経て、開発チームのテックリードのロールを担っています。ですが、先ほどの話のとおり「よーしテックリードをがんばるぞ」とかではなかったです。これまでが一開発メンバーだったものが、開発チームの技術的な意思決定をする人になったという違いですから。

ひとくちに「課題」と言っても視座によって見える景色は違う。次なる挑戦の段階へ

—— 横山さんとしてはずっと意思決定を変わらずやってきていて、担当領域や責任の範囲など拡がりつつもそれらは「変化」という文脈ではないのでしょうね。

　組織のなかで成長するに従って、任せてもらう業務領域が高度になったり範囲が拡がったとしても、受け持つ責任も自分の仕事への向き合い方も意識的には「変化がない」という表現になるんですよね。

　たとえば、「プログラムを書く」という業務を担う際にも意思決定は発生します。そしてそれを「リリースする」という段階になれば、安定して運用できる「正常な機能を提供する」という責任が生じるわけです。そのように、自分の担当業務がどれだけ小さい機能であったとしても「バグや障害が起きる」という結果になるということは、そこまでの意思決定においてなにか誤りがあったということになります。とにかくこれが本当にイヤなことなんですよ。

　つまり、これまでにだんだんと責任の範囲が増え、各システムを跨いだ意思決定をする立場になったとしても、それらに対するぼくのスタンス事態は変わっていないということになるのです。

　ハコベルに入社して、自分の力で「課題を解決している」という実感がすごくあるんです。いまぼくが指す「課題」は「社会課題」なのですが、これもまた見る視野によって異なってくるものだと思っています。

　たとえば入社当時は本当に小さいバグとかを渡される。システムの「ちょっと壊れているところを直してください」という命題の場合、「システムに入っている課題を直す」という、足元だけを見た状態。
　それがだんだん、「新しい機能を追加してください」となると目線がさらに「機能」にまで拡がりますよね。そうするとさらに、「なんでそんな機能をつくってくださいと言われたのだろう？」と考えますので、そこで視野は「お客様の課題」にまで及びます。
　
　じゃあハコベルは次、仮に売上1000億円に行くぞ！となれば「どうやってそれを達成できるだろう？」というように、視野を広げていくにつれフォーカスする課題も変わってきますし、今の自分の次なる挑戦の段階になっています。

—— 「変わらない自分」と「変わっていく外的環境」での視座によって見えるものやフォーカスが変わるから、そこにおける課題を解決する、ということなのですね。こうした言語化は日ごろから鍛錬しているのですか。

　練習はしていないですが、エンジニアの言語化は作業みたいなもの。たとえばお客様から「ここにこういうボタンを追加してほしい」というような要望はよくいただくのですが、基本的にその要望がそのままプロダクトとして正しいかたちであることは少ないんです。そこで問いを重ねていくわけです。

　「そこにボタンを追加したいというのはどうしてですか？」とお聞きすると、「本当はこっちのページでやってほしかった機能・操作をこのページでできるようにしたいから」といった回答が出てきたりします。「じゃあ、こっちのページが悪いんだな」と気づく。 本質的な課題に到達するまで深掘らないと、本当にお客様の課題を解決するプロダクトをつくることができないんです。なので、要望から真に困っている課題を特定するという作業を日々おこなっています。　

　深堀りって、ふわっとした「これはつらい」みたいなことを聞いたときに「なるほど」で済ませずに「こういうことですよね？」といったん言い換える。それを要求定義といったりするのですが、ふわっとした要望から実際にどういうものをつくるか？と落とし込むには言語化を頻繁におこなっていきます。さらに、「ここにこういうものをつくりましょう」となったものを、最終的にはパソコンで動かすためにプログラミングしないとなりませんから、「どうつくろうか？」という話へ進みますね。
　
　「ここにこういうボタンを出す」ということは、内部的には「こういうモジュールがあって分解しないとつくれない」と道すじを引いていく業務なので、自然と言語化が鍛えられていくんじゃないでしょうか。

—— チームで開発をしているので、皆さんそういう話を「言語化」をしているのですね。

　はい、チームでやっているからこそなおさらで、自分ひとりだけだと「まぁちょっとわからないけど書いてみるかな」とできるんですが、チームでやっている以上は決まり切った状態にする、文字に起こし切ることを徹底しないとみんながつくれる状態になりません。そういうことは日々おこなっていて、これは開発チームはみんなやっていることですね。

　これ、わりと重要なことで、エンジニアだと「誰ともしゃべらずにパソコンに向き合っている」というイメージがあったりしませんか？でもぼくらはめっちゃしゃべりますね！１日のうちしゃべっていない時間の方がないくらい。うちのチームは特に、モブプログラミングとかペアプログラミングをよくやるんですよね。２人とか複数人でひとつの画面を見ながらオンラインで画面共有しつつ一緒にプログラミングするものです。「ここはこうだよね。ああだよね」ってしゃべりながら。

ハコベルの開発は「みんなでつくる」スタイルだからこそ、言語化が品質を左右する

—— 複数の人の集合知によってつくっているからこそ、言語化する能力が不可欠で磨かれていくのですね。エンジニアさんてしゃべらず黙々と作業するお仕事なんだと思っていました…！

　どういったプロダクトをつくるのかを検討する際によく用いる流れとして、なぜやるのか（Why）、なにをつくるのか（What）、どうつくるのか（How）の順に考えていくテンプレートを用います。
　ハコベルではPdMという職種のかたがなぜやるのかを分析しまとめてくれて、それ以降はチームで何をどうやって作るのかを会話しながら決定します。そして実際にものをつくる過程でもかなり頻繁に会話が発生します。

　ハコベルの開発は「みんなでつくる」スタイルだから、言語化が特に品質に関わります。仕事上のコミュニケーション以外でも、最近エンジニア側は週１日は全員出社することになっているのはその文脈からです。出社したら一緒に昼ごはんに行く、とかもメンバー間でのコミュニケーションを促進するための取り組みです。

—— オフラインでの関係の深さも重視しているのがエンジニアの皆さんなのですね。少し話が戻りますが冒頭に出てきた「スクラムマスター」とはどういう役割なのですか。

　スクラムという「こうした順序で物事をつくるとうまくいくよ」という開発方法のフレームワークがあるんですよ。そのなかで開発プロセスをうまく回すために役割のひとつとして、スクラムマスターというのがあるんです。

　基本的にはチームが開発を進める上での障害を検知したり、それの解決を手助けしたり、うまく開発を進められるようにサポートをするような役割です。
　とはいえスクラムという開発手法が必ずしもうまくいかないという経験もしました。JVを設立してしばらくした頃に初めて、外部の開発会社とやり取りをしながらシステムをつくるという経験をしました。外向けに確定させたスケジュールを出すことができず、ずるずると開発期間が伸びてしまって。ちょうどそのタイミングでご入社した平山さんに助けていただきながら、別チームからリソースをもらうなど、開発の体制を変更したりして乗り越えました。

　このときチームで会話を大事にして実装方針を決めていくようなスクラムの開発スタイルを一旦やめて、「How」までをぼくが全部考えて実行するという方針転換をしたんです。外部連携するうえで関係する各社と会話しながら「納期」という概念が出てきました。「Why」「What」「How」までなんとか決めるところまで進めて、見積もりの精度が高いリソースと期間を見込んで実行していきました。一般的にはウォーターフォールというフレームワークを用いた開発に近い形です。
　

　ただ、イレギュラーな事態で「自分がすべて巻き取った」という最終的な解決策になったことはふり返ってみるとあんまりよくなかったと感じてはいます。

—— ハコベルでずっと大事にしてきた開発体制があるからこそ、ふり返ったとき「それを踏襲しもっと他の手があったかも？」ということですか。

　ですね。ふり返りをおこなっていて「なんでそんな状況になってしまったのか？」といった話はけっこうしました。今ちょうど手がけている「運送手配PLUS」をハコベルのプラットフォームへと拡張するために規模の大きな開発があるんですが、詳細の説明を少し省きますがこれもやはり、先を見通すのが難しいジャンルの開発。これに関しては「不確実なものを特定して先にそれをつぶす」ということを意識的におこなっています。

　これもふり返りをもとに、そう進めることが良いと判断した結果、前提方針を「不確実なものをつぶしきる」ことに至ったものです。ふり返りには「ホワイトボードツール」を採用しています。

　プロジェクトの時系列に並べて「開発初期」「中期」「後期」に分け、なにがあったか？という事実を書き出していきます。それに対して良かったことや課題など、「Good」と「More」を書き出していく。それらに対してみんなが「この話題を深堀したほうがいいね」と思った意見に投票をしていき、「Good」であれば「なにがよかったのか、どう継続していけばいいのか」を、「More」ならば「どうすればよかったのか」と導いていけるフレームワークを用いておこないます。

　基本的にふり返りはチームでおこないます。自分個人のふり返りは個人でしますが、プロジェクトのふり返りは必ずチームでやりますね。何度も言いますが透明性をすごく重視しているからです。自分しか知らないことや、自分しかできないものはダメなんです。個人のキャリアという側面で見た場合には、自分にしかできないものがあってもいいかもしれませんが、それはまた別の話ですね。

プロダクトの力で「世の中に貢献したい」。「ハコベル配車管理」が当たり前に使われている世界を目指して

—— チームでの「ふり返り」がプロダクトの品質に大きな影響を持つのですね。それにしてもここまで透明化を追求するものかと驚きました。

　そうですね。基本的に開発する物事で自分にしかできないものはないようにする必要があるのです。
　（ふり返りツールでの実例を提示しながら）これがタイムラインで「事実」。こういうことがあった、というのをチームのみんなが書き出したものです。上下に「Good」と「Bad」を分け、それぞれ良い点やダメだったことを記載していますね。コメントはあくまでシンプルに、深堀は別の欄でしますから。この事例のふり返りでは、ある問題が起きたという事実に対して、なにが問題だったのかをふり返り、次のアクションを決めるところまでおこなったものです。

　ふり返りはプロジェクトだけでなく毎週行います。その場の進行もスクラムマスターの仕事の一つです。その週「なにがあった」といった事実を書き出して、良かったこと、もやもやすることなどすべて表に出します。（実際使用したフレームワークを提示しながら）「スプリントゴール」という目指すべきゴールを明らかにして、これに向かって「いいね」と感じたこと、もやもやと感じていること、後ろから吹いている追い風、さらには手元にブロッカーとなっていることはないか、将来の不安はないか、といったことを書いていくものです。みんなの総意としての意見が投票によってフォーカスされ、これをさらに深掘っていく。これを毎週やっているわけですね。

　こうしたふり返りは、個人ではなくチームみんなでおこなうことで見えなかったものが見えたりしてすごく面白いですし、着実に次がバージョンアップされていくのです。

—— 横山さんは新卒でご入社で、既に新卒者のメンターなどもしているのですね。メンバーへの関わり方など意識していることはどんなことでしょうか。

　ぼく自身の新卒時の経験からも、まずは「ひとつ大きなものを周りの助けを得ずにやり遂げる」ことが力になると思うんです。そう思いつつも、ふだんチームでやろうという意識が高いせいもあって、口を出さずに見守るというのはすごく難しいところです。

　いまの開発スタイルだと２週間でひとつ機能をつくりきる必要があるので、「成長のために1人に任せきる」こととの両立やバランスの取り方は悩みながら進めています。みんなで会話しながら進める基本スタイルのなかで、教育的観点では理想と現実のジレンマを感じていますが、それはぼく自身の学びの機会でもある。いずれにしても「なにを解決すべきか」の課題設定に帰結する問題と思っているので、そのときフォーカスするのがなにか、ということでバランスを図っていくべきなのかもしれません。

　知識の平準化を通したメンバーのエンパワーメントを意識しています。「運送手配PLUS」は特にシステムの構成がとても複雑なんですが、それにも関わらず自分が join したタイミングはドキュメントがなかったりして一定の開発ができるようになるまでに時間を要しました。これでは他のメンバーが入ってくるまでに大事な部分のドキュメントを整備し、オンボードも最初はメンバーに併走してもらって安定して立ち上がってもらえるようにしました。
　それ以外ではこれまで、スプリントが未達になりそうなタイミングなどで自分が巻き取る、みたいな手段を採りがちだったのを、一歩引いてサポートするように意識しています。

—— チームでの開発だからこそ、チーム力を発揮できる環境整備をしているのですね。今後の目標、またどんなかたがハコベルの開発には向いていますか。

　ハコベルのエンジニアとして実現してきたいことは、運送会社さんがみんなハコベルのプロダクトを使って業務をしていることが、当たり前の世界になっていることを目標としています。
　プロダクトの力で「世の中に貢献したい」という思いが、自分のがんばり次第で実現できそうな実感を持てるのがハコベルという会社です。けっこうがんばらないといけないですし、プロダクト的にもまだまだ課題も山積みではありますが、自分たちがすごくがんばったら「実現したい未来は達成できるんだろうな」という実感がある。絵空事では決してないと感じられるんです。

　　ハコベルの開発チームは、プロダクトをつくること、課題解決が楽しめる方が向いていると思います。
　どのポジションであっても、開発チームが向き合うべき課題に適切にフォーカスすることが求められます。課題に対する本質的かつ現実的な解決策を考えることであったり、適切にリスクを判断して意思決定し、実行に移すことだったり。そして、これらの活動を継続的に行い、改善し続けること、決して思考停止に陥らない、ということをみんなが大切にしているので、ハコベルが1番になる日が必ずくると考えています。