急成長に伴い、煩雑化・複雑化していたアサイン管理

岩瀬氏：まず、今回のテーマである「アサイン管理」の背景について、SHIFTという会社の規模感から教えていただけますか？

森川：SHIFTは第三者検証の会社としてはじまり、いまでは「日本最後発SIカンパニー」として事業を拡大しています。

会社規模は急速に大きくなっていて、現在1.4万人規模です。私が入社した5年前は数千人でしたから、かなり急成長しています。

今日お話しするアサイン管理ツール「ハマツー」では、常時6,000人のアサイン、約1,600件の案件をまわしています。

さらに驚かれるのが、月平均で180人が入社しているということです。

それだけ人の出入りが激しいなかで、HRシステムと連携して人の情報を吸収し、膨大な案件に割り振っていく。それが、このツールに求められる役割でした。

岩瀬氏：それだけの規模のアサイン管理は、そもそもむずかしい課題ですよね。このツール開発は、どのような課題からはじまったのでしょうか？

森川：経営層から「稼働率の引き上げ」というミッションが降りてきたのがきっかけです。当時、会社の売上はどんどん上がっていたのですが、なぜか営業利益との乖離が生まれはじめていました。

原因は販管費の膨張、つまりアサインがうまくいかず「空き要員」が出ていることでした。仕事は増えているのに人が余っている。

これはスキルやリソースの割り振りがうまくいっていない証拠です。そこで「稼働率の引き上げ」という、非常に重要なミッションが部門に課せられました。

現場に話をヒアリングし、Excelがその原因の1つであることを突き止めました。10ほどある事業セグメントが、それぞれ独自のExcelでアサイン管理をしていたのです。

岩瀬氏：いわゆる「秘伝のタレExcel」ですね。Excelは何でもできてしまうのがよい点でもあり、悪い点でもありますよね。

その「秘伝のタレExcel」は、具体的にどんな問題を引き起こしていたんでしょうか？

森川：まず、部署間の人の融通が利かない「縦の壁」が生まれていました。次に、深刻だったのが現場担当者の疲弊です。

中間管理職の方々はExcelの自由度を活かして、ものすごく高機能なシートをつくっています。しかしその一方で、入力する現場担当者の方々は、その複雑なExcel運用に悩まされていました。

ウルトラワイドモニターでも見切れないほど横に長いExcelが作成されるなどがあげられます。

岩瀬氏：その強大な敵と、どう戦ったのでしょうか？

森川：私たちは当初、Excelをドン・キホーテが戦いを挑んだ風車のように、「倒すべきドラゴン」だと思っていました。

その風車の恩恵を受けている人もいるため壊してはいけないし、そもそも素手では壊せません。

こちらは私たちの感情の変化を表したライフタイム曲線です。開発フェーズと、それに対するExcelへの勝ち負けの感情です。

最初は、テックリードが3日間で開発してくれたことで、「これでExcelというドラゴンに勝てるぞ」とみんなが思っていました。

ところが、全社展開しようとヒアリングをはじめると、先ほどお話ししたセグメント別につくられた秘伝のタレをWeb化してほしいという要望が次々と飛んできました。

それをテックリードが吸収できなくなり、気持ちが落ち込んでいきました。

岩瀬氏：なぜうまくいかなくなったのですか？

森川：「日割りでのアサインを管理したい」「時短勤務のパターンを考慮してほしい」など、Excelの自由さを前提とした細かい要望を吸収していくうちに、システムがどんどん複雑化していったのです。

「Excelとの戦い」の結末は？

岩瀬氏：そこから、どうやってV字回復したのでしょうか？

森川：転換点は、BIツールの導入でした。開発が難航する一方、経営層からは「数字を見たい」という要望が絶えずきていました。

当初はアプリ内にカッコいいサマリー画面をつくろうとしていたのですが、見たい数字は毎週のように変わります。これでは開発が追いつかない。

そこでテックリードと相談し、BIツールを導入してBIチームにビュー作成を任せ、開発チームとBIチームを分離することにしました。

岩瀬氏：古い話ですが、MVCモデルのように、ビューを分離してデータを入れる部分と切りわけたのが、成功の鍵だったのでしょうか？

森川：そうですね。BIには、2010年ごろに「導入すればすべてが解決してみんなハッピーになる」という、いわばBI伝説のような風潮がありましたよね。

今回のケースは統計分析などを含む広義のBIではなく、単純に「数字を見たい」という要望に応えるための狭義のBIでしたが、この考え方がうまくはまりました。

MVCでいうビューの部分を完全に切り離し、「ビューは開発しない」とテックリードがプロダクトオーナーに対して宣言したのが重要でした。

この判断によって、ユーザーは見たい数字を見ることができるようになり、開発チームはビュー開発の負荷から解放されました。

岩瀬氏：最終的にExcelには勝てたのでしょうか？

森川：いえ、最終的に勝てたわけではありません。

たどり着いたのは「共存」です。私たちが目指したのは、Webツールにまずデータを入力してもらい、そのデータをExcelにエクスポートして使ってもらう、という流れをつくることでした。

岩瀬氏：順番を逆にしたということですね。

森川：そうです。結果的に、現場はWebツールも使い、裏ではExcelも運用している。けれど、Webツールへの入力がExcelより若干はやい。

この状態にもち込めたことで、ようやくプロジェクトは安定しました。

今回得た最大の学びは、「Excelに勝とうとするな、共存を探れ」ということですね。

Excelを倒さないで、歩みよって共存していくことが実は正解だったんです。

耳は大きく、手は小さく、声は大きく迅速に──現場起点の開発哲学

岩瀬氏：今回の取り組みのなかで、抽象化してほかの人も応用できる教訓はありますか？

森川：「耳は大きく、手は小さく、声は大きく迅速に」という標語のようなものにまとめてみました。簡単に図解すると、下図のようになります。

まず「耳は大きく」というのは、要望をよく聞くということです。

岩瀬氏：言葉でいうのは簡単ですが、プロダクト開発と同様、本当に困っていること、つまりペインを抜き出すのはかなりむずかしいと思います。どのように工夫されましたか？

森川：おっしゃる通り、会議室で「ヒアリング会」を行っても本音は出てきません。

効果的だったのは、喫煙所のようなインフォーマルな場所で「最近どうですか？」と雑談ベースで聞くことでした。

そこで「あれ、実は大変なんだよ」という声が拾えたら、改めて会議をお願いしていました。

また、データも活用しています。リリースした機能が全然使われていない場合は、すぐにリサーチします。

要望の声が大きかった人自身が使っていないこともあるので、「お忙しいと思いますが、すぐ使ってください」と交渉しに行くこともありました。

岩瀬氏：そして「手は小さく」。これは「つくりすぎない」ということですが、具体的には？

森川：聞いた要望をすべてつくると、引き継ぎたくない「魔改造アプリ」になってしまいます。

ですので、コアなデータ構造は壊さない範囲で実装したり、先ほどのBIのように機能を外部に切り出したりして、小さく、素ばやくリリースすることを最優先としました。

開発面では、GUIテストはやめました。単体テストとAPIテストに絞り、APIテストも外部ツールは使わず、すべてコードに組み込んでビルド時に動くようにしました。

岩瀬氏：なぜGUIテストはしないのですか？

森川：Webアプリなので、Playwrightを使ったとしても遅いからです。また、社内ツールなので、手元でさっと確認すればOKという運用にしています。

実際、画面で致命的なバグはほとんど起きていません。

これは、オリジナルコンポーネントを組まず、フレームワークの標準機能のなかで開発していたという、フレームワークの選定も理由の1つだと思います。

岩瀬氏：そして「しっかりアピール」。これは重要だと思っています。成果はしっかり伝えないと、特に1万人以上の規模の会社になると全然届かないですよね。

アピールするときに何か気をつけていたことはありますか？

森川：大きく2つあります。1つは「声の大きい人」に、個人チャットで「あなたのためにつくりましたよ」と個人チャットで直接伝えることです。

もう1つは、定期的にリリースノートを投稿しつづけることです。この2つの広報めいた活動を地道につづけていました。

岩瀬氏：テックチームやDevチームの社内広報は重要な取り組みだと思っています。とてもいいプラクティスですね。でも、気をつけないと、広報活動はついサボりがちになりますよね。

森川：おっしゃる通りです。一時期ポストをやめたら、次に再開したときにまったく「いいね」がつかなくなり、注目度が下がってしまいました。継続は力なり、と痛感した瞬間でした。

岩瀬氏：逆に、この取り組み全体を通して「これは失敗したな」という経験はありますか？

森川：一番の失敗は、「よいものをつくれば、自然とみんな使ってくれるだろう」と思っていたことです。

最初は、私たちのツールが既存のExcelを駆逐できると、少しおごっていたのかもしれません。でも現実はまったく違いました。

そこから、現場の「秘伝のタレ」を深く理解し、アンテナを高く張ることの重要性を学びました。

よいものをつくるだけではダメで、どう使ってもらうかまで設計しないといけない。それが苦い思い出であり、大きな学びです。

脱Excelの取り組みを「DX」と表現してこなかった理由

岩瀬氏：過去から現在までの苦闘の歴史、よくわかりました。では最後に、この先にどんな未来を描いているのか教えてください。

森川：次は「アサインAIマッチング」に取り組みたいと思っています。

お客様の要望や案件の特性データに対し、スキルDBや社員のコンディションといったリソースデータをかけあわせて、最適なアサインをAIが提案する、という構想です。

まだ走り出したばかりですが、自動運転のレベルわけのように、段階的な目標を立てて進めています。

岩瀬氏：そのデータ活用で、面白い発見はありましたか？

森川：アサインデータがとれるようになったことで、プロジェクトマネージャー（PM）のタイプがみえてきました。私が勝手に「鬼将軍」と「仏将軍」と呼んでいるタイプです。

例えば、100人の部下を率いてプロジェクトを成功させたとします。

そのとき、部下全員が燃え尽きてボロボロの状態で帰ってくるのが「鬼将軍」。一方で、みんな元気でスキルもアップして帰ってくるのが「仏将軍」です。

これまではニュアンスでしかわからなかったことが、データで可視化できるようになってきました。

鬼将軍はむずかしい案件に投入し、会社が手厚くケアする。仏将軍は安定したお客様を担当してもらう。そういった戦略的な人員配置が可能になると考えています。

岩瀬氏：そのAIマッチングやPMの分析には、正確な人事データが不可欠ですよね。ただ、社員にスキル情報を更新してもらうのは、かなり大変だと思いますが、いかがでしょうか？

森川：おっしゃる通りです。そこで私は、発想を逆にしたいと思っています。

「データを更新してください。いつか役に立ちますから」では誰も動きません。そうではなく、「あなたのキャリアに役立つ、こんな便利なツールがあります。

だから、データを更新しませんか？」という順番にしたいです。「ツールがあるからメンテナンスする」という流れをつくるのが理想ですね。

岩瀬氏：さて、あっという間に時間となりました。最後に、森川さんがこの経験を通じて、一番伝えたいメッセージをお願いします。

森川：今日、岩瀬さんと話していて気づいたんですが、私たちはこれまで、この取り組みを「DX」と一度も呼んでこなかったんです。

なぜなら、「DX」という言葉をいってしまうこと自体に弊害があると感じていたからです。

現場が属人的なやり方で必死に戦っているところに、外から「みなさん、今日からDXをやります」といったとしても、激しい反発を受けることが想像できますよね。

「DX」ではなく、「仕事を楽にしてくれるツール」なら、みんなが歓迎してくれます。

ですので、流行りの言葉を掲げるのではなく、現場に寄り添い、彼らが「面白い」と感じるものをいかにはやく提供できるか。

それこそが、結果的にDX推進につながるのだと学びました。「DX」といわないことこそが、DX推進の最大の鍵だったのです。

岩瀬氏：森川さん、本日は貴重なお話をありがとうございました。

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）