SmartHR基本機能安定化プロジェクトチームが受賞した賞について

• ベストチーム賞
  チームとして全社ミッションを軸に最も事業貢献したチーム１組に贈られる賞

年末調整機能公開まで3週間。いけると思えたのは公開の3日前だった

ー SUMMITでのチーム賞の受賞後、周りの方はどんな反応でしたか？

kawaida）みんな「おめでとう」と声をかけてくれて、嬉しいなぁ、と思いました。家族にも、会社で評価してもらったんだよ、と話したらすごく喜んでくれて。

sako）キックオフ＆SUMMITの後の懇親会で、普段あまり接点のないビズサイドの人からもおめでとうと言ってもらえました。業務で接する人は、僕たちがやっている取り組みについて知ってくれていますが、そうでない人たちからも声をかけてもらえたのは、授賞式という形で顔が見えたからだろうな、と感じました。

ー このSmartHR基本機能安定化プロジェクトは「わずか3週間で難易度の高い問題を解決した」「各所から急に招集されたチームにもかかわらず、対策の検討から役割分担、お互いのフォローなど高いレベルのチームワークを発揮した」という点が評価ポイントとして挙げられましたが、どうやってその状態から推進していったんですか？

sako）もともと安定化に向けたアプローチが3・4種類動いていました。今回のプロジェクトとしては急に招集されたかたちだったんですが、それぞれに担当している領域があったので、対処自体はプロジェクトチームのなかで小さなチームに分かれて自律的に動くことができたんです。

10月には2024年の年末調整が公開されることになっていて、公開後は年末調整の機能を利用する人のトラフィックが急増するので、それまでになんとかしないといけない状況でした。

kawaida）正直ハードではありましたよね。3週間でどこまでいけるんだろう、っていうのは最初に話しました。

sako）もともとkawaidaさんを中心にやっていたプロジェクトは、少人数で数ヶ月かけて推進して期中に終わらせよう、という目標を立てていたので、それを3週間で終わらせなければいけない、というプレッシャーは大きかったですよね。

kawaida）うまくいけばいいけど、うまくいかないかも、とは思ってました。

ー なるほど。もともと数ヶ月の想定をしていたのに、3週間に縮めて完遂する、なんて一体どうやったらそんなことができるんですか？

kawaida）やらなきゃいけないことを整理して、順番に対応しながら、早めはやめに課題を見出していきました。壁にぶち当たる、というのはわかっていたからです。
今までやったことがない変更だったので、想像していない課題が出てくるだろうな、というのは最初から感じていたんです。全員が経験を持っている取り組みではなかったですしね。

sako）リリースの3日くらい前に「これは週明けには公開できそうだ」とわかりました。

kawaida）もし、検証が完了していなければ、一旦公開をしてからも改修は必要だと思っていたんです。でも、何も改修しないまま年末調整を公開するよりも、一旦最善を尽くし、公開後にリスクに対応するほうがいい、と思ったんです。
ステージング（本番環境での実装に向けた最後チェック工程）に入ってからは、祈るのみでした。ぶっ壊れるかもしれないけどそれでも進める、と判断したんです。

スピードを担保するのは、ゴールを見据えた情報共有

ー 今回は急ごしらえのプロジェクトチームであったと思うんですが、どうやって高いレベルのチームワークを実現したんですか？

kawaida）それぞれの担当領域ごとに、向かっている課題は異なるんですが、経験から得ている情報はあるので、他の領域でも共有し合っていました。なんとなくお互いにそれぞれの課題感は把握しておいて、問題が起きたときにスピーディーに対処できるように、という感じです。
あとは、sakoさんがビズサイドや経営陣とのコミュニケーションを担ってくれていたのも大きかったですね。

sako）経営陣とのコミュニケーションはnabe3と広報のhonyuriさんと3人で協力して進めていきました。nabe3が前職での炎上プロジェクトの経験を踏まえて、経営陣を巻き込んだほうがいい、とアドバイスをしてくれて、経営会議に持っていって説明する準備を進めてくれました。
安定化に向けた改修をやったほうが良さそうだ、という決断から、経営会議での説明まで、丁寧に、でも迅速に進めていきました。

機能改修にあたって、一番不安を感じるのはCSやセールスのメンバーだと思うので、まずはそこにどう説明するかをマネジメントレイヤーに相談し、その後経営陣に持っていって、全社にむけて開示する、という流れでしたね。

そもそも8月から障害が起きていて、そこに9月上旬からのアクセス障害が重なっていたんです。その状況のなかで価格改定プロジェクトを推進し、お客様に対して価格改定の打診をするのはリスクが高い、という話になり、結果的に価格改定プロジェクトも、当初の10月スタート予定から11月スタートに遅らせました。

3週間後の年末調整公開までに改修を終え、ちゃんと安定したという実績を元に価格改定プロジェクトを実施できるのがベストなので、影響範囲は結構大きかったですね。

ー 3週間でやりきるために、心がけたことはありましたか？

sako）安定化プロジェクトのチームメンバーには、それだけに集中してもらえるよう、Directorとしていろいろと調整することは心がけていました。
さまざまなチームから来てもらっているので、チーム側にも一時的とはいえメンバーが抜ける負担をかけてしまうし、チームが持っていた予定の進捗の調整や、期日に遅れたときの評価をどうするか、といった調整も含めて行って、極力みんなが集中できるように、という状態を目指しました。

kawaida）僕が担当していた改善は、最も改善効果が見込まれているものだったので、やらないといけない。でも、改修を入れたことで不安定になってはダメなので、信頼性を担保するためにも、チェックは徹底してやらないと、と思っていました。

どう考えてもここは手数が足りない、と諦めたいこともあったんですが、でも必要なことだからやるんだ、というマインドだけ持って、やらない理由を考えないようにしていました。他にやる人もいないし、全力で最善を尽くして、後は祈るだけ。

ステージングまでマージしてからは、エラーが起きたらすぐに対処できるように、PCの前で寝ていました・笑。

目先の問題解決だけでなく、入口から解決することを目指した

sako）根本的な不安定さの解消にあたって、まずkawaidaさんの担当領域を解決しないといけませんでした。
でもトリガーとなったのは、レスポンスの悪さや、負荷をかけている重たいなにかも原因になっている、と考えて入口のレスポンスの解消のところから解消したほうがいいだろう、と判断したんです。

このプロジェクトを始めるタイミングで、何をどこまで求めるのか、は議論しましたが、ゴールを決めづらい部分も多いので、期限を切って判断していった感じですね。

今回は3週間、というデッドラインが決まっていたものの、3週間で終わるかどうかは、さまざまな要因を解決していかないと見えない部分もあったので、可能な限りのアイディアを出して推進つつ、一つひとつの課題を解決していってゴールがある程度見えてきたタイミングで、何をどこまでやるか、の決定は都度調整していきました。
やってみたもののうまくいかず、今回は一旦諦めたところもありましたね。

kawaida）今回のプロジェクトは、期間が決まっていてとにかく早くやらなければならない、という状況だったこともあり、普段はできないアグレッシブな決断がたくさんありました。
とりあえず改善してください、という状態だったので、強気にいくしかなかったんです。

影響範囲が明確じゃないところもあったので、想定外の問題が起こらないように、と考えるとチェック項目が増えてしまう。でも、とにかくスピード感を持って取り組むことが重要だったので、どんどんレビューをして判断し、改善を加えていきました。
効果が出なくて戻したものもありましたが、そのあたりも素早く判断していましたね。

sako）これまで、機能としての品質が劣化してきている部分が見えていても、お客様から要望のある新機能の開発を優先して価値を伸ばしていくことにフォーカスしていました。そのつけが回って起こったことを、3週間で修正することができました。

これまでの意思決定は間違いではないと思いますし、成長にもつながっています。ただ、今回の障害はこれまでの意思決定の積み重ねが土台にあるので、以前と同じままではまた障害が起こってしまうと思います。これからは品質も含めてちゃんと意思決定はしていかないといけない、と改めて思いました。

kawaida）今回は問題を解決できたから良かったですが、そもそも問題にならないことが一番いいんですよね。だから、先回りをした改善活動はしていかないとだめだな、と感じています。

sako）全社への説明会に向けて、一番迷惑をかけてしまったビズサイドに対して「謝罪」をするべきなんだろうか、と迷ったんです。でも謝罪をするよりも、何をどう解決するのか、をきちんと伝えるほうが大切だ、と考えながら説明会に臨みました。

説明会の場で、ビズサイドから頂いた質問は、開発の責任を問うものではなく、どういう状況でどう解決する目処があるか、に関することがたくさんあって、全社で問題を解決することに向き合える会社なんだな、と感じました。

仕事をするうえで、心がけていること

ー おふたりはそれぞれ、仕事をするうえでこだわっていることはありますか？

sako）Directorとして、一人ひとりが活躍できているか、パフォーマンスを出せているか、は気にするようにしています。
仕事のアウトプットだけでなく、最適なコンディションで働けているか、というところも気にかけていて、もし活躍できていない状況にあれば、溜め込んでいるものがないか、をマネージャーやチーフを通して確認することもありますね。

成果を出せた、と本人が実感できる状態にするために、自分自身の成果をちゃんと認知してもらうことも大事だと思っています。
開発はチームワークで仕事に取り組むので、成果を出してもチームの成果に見えてしまうことがどうしてもあります。
なので、個人としてどういう成果が出せたのか、を一人ひとりにちゃんと伝えて、自覚を持ってもらうのも大切なことだと考えています。

kawaida）僕は情報格差が生まれないように、整理して共有することを意識しています。
とくに新しいチームの場合、今なにが起きていて、何をしなければならないのか、の理解に差が生まれがちです。なので、情報を伝えるにあたってドキュメントを起こし、こういう問題があって、こういうことをしなければならない、ということを書き出して、自分の頭にとどめないようにしています。
そういう情報の共有をきっかけとして、みんなが考えていることも引き出せるんです。

うちの会社では、課題感を整理して提案できる人が多いな、と感じます。課題を感じたときにどう整理するか、を悩むこともありますが、ちゃんとそれを言語化して共有するのは大事ですよね。

ー 今後の目標などがあれば教えてください

sako）今後は、エラーを起こさないよう、いつも先に手を打てるようにしていくことが求められると思っています。ユーザーが「動いていて当たり前」だと思う機能の開発も進んでいくと思うので、同じ不具合を繰り返さないために、必要な取り組みを増やしていくことが求められるフェーズです。

kawaida）キックオフでCPOのadachiさんが「安定は当たり前品質だ」といってましたよね。それを満たすプロダクトを作るのことを大前提として、いろいろとアプローチを変えていかないといけない。
新しい開発にも取り組みつつ、より安定性が大事だという認識を共有するための情報を揃え、ことが起きる前に先んじて対応していくことが必要だと思います。

今までは更に新しいものを、に重きを置いてきましたが、プロダクトのパフォーマンスがユーザーの満足いくものであるか、を改めて見直すことも大切ですね。

ー おふたりとも、貴重なお話しを聞かせていただき、ありがとうございました！

取材・文／@Miranda（カルチャー室）
写真／@okie（広報室）