クーリエでは、サービスや各事業部の課題をオープンな環境で報告する仕組みがあり、交わされる情報が当事者だけでは見えないような新たな課題の発見や、サービスをより良くするためのヒントに繋がるケースも多々あります。

今回は、各部署から寄せられる情報の整理を行うPjMのサングウをインタビューしました。

チャレンジを続ける原動力は地元愛？

-まずはどんな経緯でWeb業界へと進まれたのか教えてください。

地元の地域ポータルサイトを運営する企業へ新卒で入社して、レスポンシブデザインを実装するプロジェクトにWebディレクターとして参画した経験がきっかけです。

昔から地元が好きだったので、生活に密着した地域の魅力が意外と発信されていない状況を勿体ないなと思い続けていて、学生時代も地域創生をテーマにスポーツ振興や都市設計の分野を研究していました。

プロジェクトがひと段落したタイミングで、次のキャリアを探していたのですが、そこでクーリエの求人を見つけて、成長市場で業界No.1のシェアを獲得しているポータルサイトの裏側を知りたいと思ったこと、「地域間の情報格差を解消して、日本の介護全体の最適化につなげる」ことが地域活性化に取り組みたいと思っていた自分のビジョンともマッチしたことから、入社を決めました。

実際に今、クーリエの事業は単なる個人や一企業の課題を解決するサービスではなく、業界や産業全体を変えるプラットフォーマーとして新たな成長フェーズにあります。

-新規事業が生まれたり、それと同時にものすごいスピードで組織が立ち上がったり毎日が目まぐるしいですよね。（笑）

はい、多くのカスタマーやクライアントに活用してもらうことが最優先事項であったところから、今は顧客からのフィードバッグを高速でプロダクト改善に反映していくことや、そのためにシステムの保守性を向上することが喫緊の課題となっていたりと、事業課題やそこに対するアプローチ方法も変わってきていますし、そこで経験を積んだことで、僕自身の知見もかなり幅が広がりました。

地域ポータルサイトを見返しながら「今の自分ならこうするな」と考えたりするのですが、クーリエでは驚くほど細部に至るまでIA（情報アーキテクチャ）にこだわってUX（ユーザー体験）を追及していて、前職のリニューアルでやっていたことは何だったんだろうかと思うレベルです。（笑）

-サングウさんは日々かなり多くのプロジェクトを回しているイメージですが、意識していることはありますか？

顧客ニーズ獲得のチャンスを逃がさずに、より早いスピードで開発とリリースを繰り返す仕組みをつくること、現場で起こる課題がスタックしないよう厳密なスケジュール管理を行いながらプロジェクトを最短で完了まで持っていくことが僕の役目です。

「ゴールはどこか」「いつまでに達成するのか」「どういう工程で進めるのか」を自身で落とし込んで、プロジェクトを遂行しています。

入社して早々焦ったのですが、クーリエでは「ただ出勤して今日のタスクを終わらせる」くらいの気持ちでいると、周りメンバーの成長スピードの速さもあって、すぐにギャップが広がって置いていかれてしまうと思います。

正直にお話しすると、納期に間に合わない、もしくは未達といった失敗経験もあります。ただ、そのような場面で失敗そのものを指摘されたことは一切なくて、「なぜ間に合わなかったのか？」「残タスクは？」「どうやって巻き返すのか？」と聞かれます。

そうすると「ここからどうするのか？」を自分自身で考え抜く方向に気持ちがシフトするので、過去には固執しないで、ミスや失敗は必ず組織や自分の成長に変える癖が今では身についたと思います。

なぜDevOpsなのか？

– 開発システムの運用ルール変更にはどのような背景があったのでしょうか？

事業成長の過程におけるひずみがシステム構築の複雑さを生んでしまうことを、エンジニアの中では「技術的負債」という言葉で表現したりと、なかなか前向きに捉えることが難しいこともシステム開発する上で起こる課題です。

クーリエでは開発者がエンタープライズレベルで事業に関わっていて、事業も組織も発展途上である点が面白さだと思うのですが、不確実な何かを作っていくために必要なのは、過去との対立ではなくて、現在進行中のマーケットやオペレーションの状況を知ることだと考えています。

クーリエって、やりたいことがあったときに、数字などで根拠を明確に伝えることができれば、いくらでも実現できるんです。

だからこそ、オペレーションサイドとの情報の分断をなくすDepOpsの必要性を開発者の皆さんに理解してもらい、開発者が自ら決めて動くことのできるチームにしていきたいんです。

DevOpsに向けての取り組みのひとつが、開発システムの運用ルール変更です。

まずは、ナレッジが蓄積されていないといった開発チームの課題を各部署の案件責任者に伝え、リリースプロセスを1つのフローとして仕組み化し、開発側と運用側が一緒に進めていくための土台を再構築しました。

たとえば、管理プロジェクトが終わるまでに必要な工程を細分化して必要な工数を出し、「それならこのプロジェクトは何月何日の何時に終わるね！」と、開発側と運用側で認識を合わせて、時間単位でマイルストーンを敷いています。

開発側と運用側に「具体的な工程の理解」と「終わらせる意思」があれば、「目標時間になったが終わらなかったので、追加工数が必要だ」と後から考えるのではなく、着手してから終わるまで、常に「その時間までに終わらせるためにはどうすれば良いのか」を意識し、協力しながら開発を進めることが可能です。

予定した工数に対して実装にかかった時間は開発者の評価にも直結するので、開発者の方は皆さんかなりスピード感のある開発をしてくれています！

もちろん、ただ早く終われば良い訳でもなく、成果物として目的の満たさないものが出来上がればFB対応が発生してその分余計な時間がかかってしまいますので、運用側の目的を正確に汲み取り、かつ時間内に終わらせるスキルが求められています。

社内外から注目されるような開発組織にしたい

– 手応えはどうですか？

たとえばシステムエラー時などに相互で共有する情報の解像度が高まりましたし、その結果、解決までのリードタイム短縮にも繋がっています。

どれだけ先を見据えてシステムを構築したとしても、完璧なものなど存在しませんし、一つでも多くの問題を解消していくことに時間を使おう！という考えに共感してくれるエンジニアさんがいたら、ぜひクーリエに加わっていただきたいです。

結構タフな経験だとも思いますが、クーリエの成長フェーズで経験を積めば、「どこでも活躍できる」という自信を得られることは間違いないです。

技術広報の社内担当者にアサインされたので、そんな強いチームをつくって、事業だけでなく、「クーリエの開発組織はイケてる」と、世の中のエンジニアさんにチームから認知してもらえることが密かな野望です（笑）