ゴールが見えなくなったプロジェクトに立ち向うときに必要なたった１つのこと

目次

はじめに

今更ながら食べるラー油にハマりだした、きびだんご*1チームの @k-waragai です。

チャーハンに混ぜて食べるのが一番ハマっています(美味しいのでやってみてね)

今回は人力で行ってきた本人確認を自動化するまでの軌跡と、そこでの気づきや学びを振り返りながらまとめていこうと思います。

なぜ本人確認を自動化することになったのか

従来の本人確認では、ユーザーからの申請があるとサポートの方の目視チェックを行った上で承認または否認の結果を打ち込み、ユーザーの本人確認ステータスへの反映を行っていました。

申請は多い月で 数万件 を超える事もありかなりの負担を掛けていたと思います。

約10,000件の申請があった場合は1日あたり 約550件近くの申請を捌いてる事になります。

サポートの専門の方はそれだけがお仕事ではなく、いろいろな作業の効率化や改善を行ったりしているのですが、このように件数が多いと捌くのでいっぱいいっぱいになり他の作業に手が回らない状態となっていました。

それを今回は、ユーザーからの申請があると外部サービスによる承認または否認の結果がコールバックとして返却され、それをユーザーの本人確認ステータスへの反映するように変更しました。

反映される場所はユーザープロフィール画面の 本人確認 という箇所で済または 未 となります。

施策が始まって中盤までのお話

施策が始まったのが2018年の12月頃。

仕様面などの確認が済み実際に設計などを進めて動き始めたのが1月頃でした。

ガッツリと仕様を固めて動くというよりはとりあえず手を動かしてみようという形で進められていました。

4月の間は不正案件対策という別の施策が走り一時的に本人確認自動化施策がストップしている状態でした。

5月頃に新しくエンジニアメンバーがアサインされました。

6月頃にエンジニアリーダーの方がご退職され、自分がアサインされ、POが入れ替わりました。

当初の予定では5月末頃に本人確認自動化施策の第一弾がリリースされる予定だったのですが、進捗としては芳しくない状態にありました。

全体の50%も進んでいない状況だったと思われます。

今の現POの方にこのときの状況を聞いてみたところ、何が足りないのかが見えていない状況で進んでいたそうです。

足りない部分が出てきたら実装するという形でパーツパーツとしては作られていましたが、一連の流れとしてがなかなか見えづらく何が足りていないのか何が出来たら何が完成なのかが分からない状況でした。

恐らくこの時はメンバーのほとんどが違和感持ちつつも、このタスク群を消化していけばゴールへ辿り着けると信じて実装をしていたんじゃないかなと思います。

人の入れ替わりや施策ストップなどがあり心理的にはつらい状況にあったのではないかなと思います。

そしてゴールの見えないタスク消化の連続

自分がアサインされて初めて渡されたタスクを実装しようとした時のことなのですが「現実装ではまだ無理ではないか？」という結論に至り、そのタスクが出来る前提条件さえもクリア出来ておらずやる順番などが明確ではありませんでした(ㆁωㆁ；) (渡す前に確認してほしかった)

そのため違うタスクをやる時に別のタスクが生まれ、それをやろうとすると別のタスクが生まれ...のような無限タスク作成地獄みたいな状況になっていました。

後少し後少しを繰り返す状態が続いており、ゴールの見えないタスク消化が始まっていました。

自分が本人確認自動化施策チームに100%入った段階でチームメンバーの目のハイライトは若干抜けていた気がします...。

というのも、本人確認自動化施策をめちゃくちゃ進めてくださった強強のエンジニアの方が居たのですが、その方が退職されて自分がアサインされるという状況から「どうすればいいの？新しい人に教える余裕なんて無いよ？」という感じだったのかなと思います。

自分が逆の立場でも心理的な負担や不安などは大きかったと思います。

完全にアサインされた直後くらいに一番驚いたのが、仕様面のお話をチームメンバーから聞いた時に仕様の認識が揃っていない状況だったことです。

この時自分は嫌な予感フラグがビンビンに立っていたので新規者として既存のものに馴染んでいくのではなく、既存メンバーの不満を集めて全部変えてやろうと思いました。(新しい風を吹かせてやろう的な)

イチから...いいえゼロから Re:Start !!

タスクが無限に出てきていたり、現仕様に振り回されている事もあって、ゴールが見えないと嘆いてるメンバーもいました。

なので、ある昼会の時メンバーに「仮にイチから作り直すとしたらどれくらいで出来そうですか？」というのを聞いてみました。

この時ポジティブな回答を頂ければ頑張ろうか〜くらいのテンションで聞いたのですが、思ったよりもポジティブで再設計しようという決断に至りました。 (もちろんPOの了承も得ました。)

まず自分がはじめに行ったのは、仕様の認識を揃えるところでした。

仕様面のお話をした時に「え、そうなんですか？」みたいな状況が何度かあったのでオンボードを提案しました。

みんなで集まり同じホワイトボードを活用し本人確認のデータの流れや必要な情報を全部洗い出し、疑問に思う部分や認識の齟齬がある部分は徹底的に話し合うようにしました。

これに2,3営業日くらい掛けた記憶があります。

全員の認識が揃ったところで、モデルの再設計を行おうという提案をしました。

このとき利用したのは miro というオンラインホワイトボードを活用しました。

もともと個人的に思考整理で利用しており、今回のモデル再設計の話し合いは数日かかる見込みだったのと常に変更したものを残してドキュメントとして可視化されている方が後々役に立つ事から利用をしました。

※ モデル遷移図

まずは、現仕様のモデルを前提に申請からどういうデータが必要でどういうモデルがあると嬉しいのかを1つずつ話し合いながら線を繋げていきました。

そして新しいモデルを作るにあたっては、以下の点を気にしながら作っていきました。

• なぜそのモデルがいるのか
• なぜそのカラムが必要なのか

当たり前なことなのですが、背景などを共有する事を怠ると「なんでこうなったんだっけ？」ということが増えます。

増えるとどうなるかというと保守できなくなります。

なので必ず作るにあたっては理由などを説明しました。

説明した上で話し合いを行いながら2日程を要して道筋が見えたのでタスクを洗い出しマイルストーンをつけました。

この頃、ヌーラボのBacklogは慣れれば上手く活用できるのですが現状施策自体も遅れておりここで手間を取るわけにもいかないということでスプリントバックログを Trello で行い、プロダクトバックログを スプレッドシート で行うようにしました。

ここで全体の見積もりなどがおおよそ完了したので後は手を動かすのみとなったので全力疾走をしました。

実装フェーズに入ってから、vueなどの実装で「Reviewが難しい」という声や「そもそも実装がよく分からない」という事が上げられたので、モブプロやペアプロを積極的に行い、ポモドーロ・テクニックなどを活用して実装を進めました。

最初は、何も分からないから手が止まるといった声が上がっていましたが、ペアプロを数回行ってからは恐怖心などがある程度拭え実装やReviewを分担して行えるようになりました。

この頃並行してスクラムイベントの見直しなどを行ったり、スプリントのタスク消化ベロシティを計測してみたりといろいろなことを導入しました。

ついに本人確認を人力から自動化へ

joinしてからチームビルディングや再設計など密度の濃い時間を過ごし3ヶ月...ようやくリリースすることが出来ました！

最初は設計やメンバーのスキルアップ的な部分がメインで若干初速は遅かったのですが、後半は巻き返すようにベロシティが上がってスムーズに進んだ印象です。

また自分たちの実装したコードに対しても自信を持っておりいい結果になったなと思いました。

これはエンジニアメンバー全員で考えて納得するまで議論したことで、オーナー意識が芽生え自分たちの実装に自信が持てたんじゃないかなと思います。

余談ではありますが、自動化してからサポートの目視対応件数が 75%削減 したことによって他業務の改善などに手を回せるようになったりと良い結果が出ています。

時間換算するとおよそ 月あたり80時間分の工数削減 に繋がりました。

また、マイナンバーが含まれていた場合マイナンバーが含まれている書類を完全に消去しなければならず、今まではサポートの方がissueチケットを切ってエンジニアが作業するという流れになっていたのですが、こちらも自動化するようにしました。

他にもいろいろと楽するような取り組みを行っています。

気づきや学び

現POの方と当時の事を振り返りながら話した時に認識が揃っていると思い込んだまま進むとどこかで大きいズレが生じてしまい手戻りになる可能性もあるので、認識が揃っているという事を解釈で進めるのではなく話し合って確かにするプロセスは重要だったと仰っていました。

まさに再設計をした理由もそれなので 認識を揃えることの重要さ を改めて実感しました。

また、チームでは以下の事を意識してコードの実装を行ってきました。

「新しい人や知らない人がなんでこういう実装をしたのか聞かれた時に説明のできる実装をしよう」

これは単体ファイルの一部の話ではなく、関連や全体図などを含めての話になります。

これは最初のフェーズでオンボードを行った理由に当たります。

チームの入れ替わりや新しいメンバーが入ることはよく起きます。

また、自分たちがそのコードの保守から外れ別の誰かがそのコードの保守に回ることもあります。

その時に同じチームだったのに「出来る人がやってたのでよく分かりません。」と説明出来ないコードに価値は無いと思っています。

自分たちが実装したのに説明できないコードを誰が担保できるというのでしょうか？

分からなそうなら巻き込む一緒に覚えるということがチームビルディングでは大事なのかなと思います。

そうすることでチームとしての生産性が将来的にグッと上がると実感しました。

また、新しく入った方など他の方に説明する時に画面の遷移図やモデルの繊維図があると大変うれしいのでそういったものを記録として残すように miro を活用しましたが、これは大正解でした。

実際今でもアップデートを常に行っており、これを活用して新しく入られた方に説明する時に役に立ちました。

最後に

今回は 認識を揃えること の重要さ、そしてそれを実現するためには地味にオンボードって重要だよねって事をテーマにブログを書きました。

この他にもチームビルディングとしてスクラムイベントの見直しやスプリントを２週から１週に変更したりなどいろいろな改善は行っていました。

本人確認自動化施策で行った設計のポイントや実装面のお話はまた次回に出来たら良いなと思っています。

そして、 ドキュメントとして残すのに miro は良いので皆さんも使ってみてください(ㆁωㆁ*)

それではまた次のブログでお会いしましょう٩(๑´0`๑)۶

最後になりますが、私達本人確認自動化施策チームが頑張った本人確認を試してみてください！

👉 https://crowdworks.jp/identification_request_top

クラウドワークスでは、チームビルディングやスクラムに興味のあるエンジニアを募集しています！

www.wantedly.com

*1:きびだんごの由来は、名前ガチャで決まりました。