シスナビで長期受託開発を担当している士業法人向けのシステム開発事例を紹介します。この案件は途中で担当者の引き継ぎがありつつ、お客様から高い評価をいただき、現在で既に5年目の長期案件となりました。事例の紹介に合わせて、どのようなチーム運営をしたのか、さらに引き継ぎ案件が失敗・炎上してしまう負け筋があるのか、といったトピックでお話を伺いました。

<プロジェクト概要>
士業法人の勤怠、売上、給与等を管理するシステム。2021年秋から開発スタート。

OS：Windows
言語・フレームワーク：PHP/Laravel、JQuery
データベース：MySQL
ローカル開発環境：Docker(Laradock)
ソースコード管理：Gitlab
タスク管理：Backlog

<登場人物>
島田さん：SI事業本部1G部長。宮崎県出身。エンジニアとしてPM、PLの経験を積んだのち、同郷の藤田社長の誘いでシスナビに幹部として2019年入社。3児のパパで育児に奮闘中。趣味はスケボー、ドラム、畑仕事。

Yさん：2021年入社。SI事業本部1G所属キャプテン。2022年春に本案件をPMとして引き継ぎ。趣味はギター、筋トレ、サウナ

エクセルで管理していた職員の売上データ等をシステムに統合

-本プロジェクトの概要をご紹介お願いします

Y：私が参画した時点では、士業法人向けの勤怠管理システム機能を主に開発していました。ただ、そこからシステムの規模が広がり、各職員の売上管理ができるようになったりと機能の拡張を続けてきました。

本システムのコンセプトとしては、勤怠、売上等の各職員と強く紐づけられるデータをうまく整理し、同じシステム上で効率的に業務を行えるようにするというものと捉えれば良いかなと。元々はエクセル等でバラバラに管理していたので、システムが稼働してからはかなり業務効率化が進んだと思います。

島田：Yさんが参画する前に私と他のメンバーで既に開発を始めていたんですが、その時は勤怠管理よりさらに前の機能で、各職員ごとに異なる時給と稼働時間からエンドユーザーへの正しい請求額を算出する機能を開発していました。職員ごとの売上実績を管理する新機能を開発するフェーズの前に、私からYくんにプロジェクトを引き継ぎました。

ゼロから始めて現在まで既に5年にわたって受託いただいているので、Yさんの開発力や顧客対応が素晴らしかったということだと思います。Yさんに任せてよかったなぁ…。

-Yさんにお聞きします。本プロジェクト内で印象に残っている開発は？

Y：印象に残っているのは、島田さんからプロジェクトを引き継いだ後に始まった、職員ごとの売上管理機能の開発ですね。単に売上金額を入力できれば良いのではなくて、職員ごとに異なるレートを設定できるようにしなければいけない。

さらに、難しかったのが、職員が自分が獲得した案件に手が回らないときに、他職員にその案件を振るということがあります。そのため、案件を獲得してきた職員にインセンティブを付与できる機能が求められました。

正しいデータを保存したり、SQLからデータを引っ張ってきたりと、とにかくさまざまなテーブルが紐づいていたので、その中から正しい条件を作るという点で難しかったです。難易度としては10段階で7くらいはあったのではないでしょうか。一応その開発は昨年の秋くらいに完了し、今は細々した改修を進めている段階です。

-非常に複雑な機能開発だったんですね。どうやって乗り越えたんでしょうか

Y：開発を開始してSQLの知識と技術が不足していると感じたので、開発と並行してとにかく勉強しました。「達人に学ぶSQL徹底指南書」という本があって、これをひたすら読んで手を動かしていたらなんとかなったという感じです。この本はこれからSQLを身につけたい人には本当におすすめなので、是非購入してください。SQLはどんと来いという感じになれますよ！

モチベータータイプのリーダー像が求められている

-開発はYさん以外にどんなメンバーで進めたんでしょうか

Y：私がPMのような立場で、約3ヶ月間ごとに交代する感じでサブのメンバーに入ってもらいました。だから、基本的には常に私を含めて2〜3名のメンバーでプロジェクトは動いています。

メンバーに対して詳細設計とコントローラー設計を書いて渡して、それに沿ってやってもらうという進め方をしました。中には実務経験のないメンバーもいたので、ある程度ビジュアル化しないと無理だろうということで、自分だけで進める時は書かないコントローラー設計も書きました。実務経験がないとはいえ元々優秀なメンバーが揃っていたので、ほぼ問題なく開発を進行することができました。

-メンバーの教育やチーム運営は、どういった姿勢で臨まれましたか

Y：私は今の20代に対して教える場合は、丁寧にやり方を教えてあげるのが良いと思っているので、具体的な指示を細かく出していきました。

後は指示を出しつつも任せるということですね。僕は立場が人を作ると思っているので、責任を与えて自分で考えることで、経験が浅い人であってもスピード感を持って成長できるように工夫しました。

チームのスタイルもいろんなものがあると思うんですが、リーダーである自分が引っ張っていきつつも横並びであるのが私にとっての理想の形。あまり偉そうにならずにメンバー全員でやっていくのを意識しました。

個人的にはモチベータータイプのリーダーが今の最適なモデルなのかなと思っています。私より技術的に優れたエンジニアは世の中にたくさんいると思うので、そういった方に任せていきつつメンバーの力を最大限発揮させる空気感を作ることが求められるのではないでしょうか。世の中にいる人で言えば、日本ハムファイターズの新庄監督とか、広島東洋カープの新井監督のようなリーダーを目指したいですね。

引き継ぎ案件の負け筋とは

-島田さん、改めて引き継いだ側からの感想をお願いします

島田：本当に自分は当たり前に引き継いだだけなので、これだけ成果を出してくれたのに感謝の言葉しかないです。私から彼に伝えたのは、ドキュメントのメンテをしろというアドバイスくらい。一人もしくは少人数で開発していると、どの設計書がいつのバージョンなのかわからなくなってミスが起こりがちなので、そこには気をつけてねと。あとは、たまに見積もり金額がこれで良いかの相談はあったかな。

Y：島田さんが後ろにいてくれる安心感があって思いっきりやれたと思います！

-今回は引き継ぎがすごくうまくいったケースだと思うんですが、世の中には引き継ぎでの炎上案件も多いと思います。引き継ぎ案件の負け筋みたいなものってあるんでしょうか。

島田：負け筋は明確にあります。

まずは構造的なところで、実務者でない管理者が出てきて引き継ぎを行うパターン。これはかなり炎上、失敗するパターンが多い。さらに実務者の間に入る人が多ければ多いほど引き継ぎはうまくいかないので、引き継ぎは実務を行う当事者同士で行うこと、これは鉄則だと思います。

また、プロジェクトを離脱する引き継ぐ側が、最終日まで現業務を行っているパターンもまずい。「上長が引き継ぎやっといてねとだけ伝えてあとは放置。いざ引き継ぎ者が退職したらまともな引き継ぎがなされていない。何も残っていない」というケースを耳にすることがあると思うんですが、大体このケースです。引き継ぎの管理者がいない。

「引き継ぎ」も業務の一環なんですよね。具体的には、棚卸し（何をどこまで引き継ぐのか）、スケジュール管理、やりきれなかった時の対処法（リスク管理）などなど。これらを管理する人がおらずして、本人任せで最終日まで業務をこなしながら、更に並行で引き継ぎもするというのは無理があるんです。

もちろん、普段から業務の棚卸をしておいて、どこに何があるか整理しておくことも大切。必要な情報はここにアクセスすれば良いという情報も含めて、最低限の整理がされていれば目の前にある１ヶ月くらいの業務はなんとかなります。

ただし、目先の業務の先にある全体の目的とか開発イメージを持てなくて、先々行き詰まるケースもあるので、単なる作業に必要な情報だけでなく全体のコンセプトやこれまでの流れを共有する時間はあった方が良いと思います。

Y：今回は島田さんの引き継ぎがしっかりしていたので、僕もスムーズに業務に入れたというのがプロジェクト自体の成功要因として大きいと思います。今後私が引き継ぐ側になることがどんどん増えていくと思うので、負け筋の引き継ぎにならないように気をつけていきたいですね。