こんにちは。Backlog ninja チームのarataです。2017年10月からヌーラボの京都オフィスに所属して、日々Backlogの改善に力を注いでいます。本記事ではNuice Practice Awardの記事でも紹介されたヌーラボの社内稟議システム「Eringi」と1ヶ月に及ぶ研修についてご紹介します。
ヌーラボの研修とは
過去の記事（1, 2）にもある通り、ヌーラボでは新しく入ってきた人のために1ヶ月間の研修を行なっています。
研修といっても基本的に中途採用で入られた方が多いため、基本的な技術の習得をメインの目的とするのではなく、チームでの仕事の進め方や、ヌーラボがサービスとして大事にしていること、ヌーラボの社内文化を伝えるのをメインの目的とのこと。
実際の研修でもメンターについてもらい、どのように仕事を進めていくのか、プロダクトとしてどういう点を大事にしたいのかをみっちり教えてもらいました。具体的にどういう内容だったのかは後述します。
余談ですが、ヌーラボの京都事務所は、DIY研修という伝統行事があり、今までも家具を作成したり、手拭いを染めたり、はたまたオフィスを創ってしまったりと、DIYが大好きな文化があります。
「京都 オフィス DIY」
で検索していただければ、その軌跡がご覧いただけると思います。
稟議システムを作る
今回の研修の題材として「ヌーラボらしい稟議システムを作る」を割り当てられました。
Nuice Practice Awardの記事でも少し触れられていますが、これまでヌーラボには稟議に関してヌーラボらしい運用はあったものの、きちんとした承認フローもそれを助けるためのシステムもありませんでした。最近は急激に社員も増えてきたため、バックオフィスの方々の作業量も増えてきていてかなり大変だったそうです。
仕様を決める
技術的なことを決定するのはメンターや京都オフィスの面々だけでも問題ありませんが、全体的な運用や仕様を決める際には、稟議についてよく知る福岡のバックオフィスの方々の力なくては進みませんでした。
今回はBacklog、TypetalkやCacoo、meetsなどを駆使してリモートで打ち合わせを行い、どういうものを必要としているのか、どういうものであればみんなが扱いやすいかなど詰めていきました。
個人的に印象深かったのはインセプションデッキを使って共通認識を合わせていったとき、今まで若干フラフラとしていた方針が固まり、これ以降プロジェクトがしっかり回っていったことです。これはとても衝撃的な瞬間でした。
技術を決める
実際にシステムを作るにはどういう道具を使うかということも考えないといけません。
今回は仕様決定や開発も含めて1ヶ月ということもあり、全てを作り込むのは無理だろうという判断から、稟議の申請を行うために使いなれたBacklogを、申請者・承認者への通知にはTypetalkを使い、ワークフロー部分はバックオフィスからの提案でQuestetra BPM Suite（以下Questetra）を使うことになりました。
また、これらの間の糊としてAWS lambdaを使用することとしました。また言語は前職がRubyメインだったため、久々のウォーミングアップとしてJavaを選択しました。
さあ設計と実装だ
土台が決まったので、ここからは設計と実装です。とはいってもAWS lambdaは未知の領域だったりしたので、大まかな設計の後はトライアンドエラーで実装と細かな部分の設計を進めていきました。
バックオフィスの方々やメンターと大まかなシナリオを作っていきます。結果、稟議申請から承認完了までは以下となります。
- 申請者がBacklogに課題を起票。これが稟議の申請となる。
- BacklogからWebhookでAWS API Gatewayを通してAWS Lambdaを起動。LambdaからQuestetraのワークフロー起動、Backlogへのコメント追加、申請者と承認者に対してTypetalkで通知を行う。
- 承認者がQuestetraで稟議を承認すると、QuestetraからAWS API Gatewayを通してAWS Lambdaを起動。次の承認者へ通知を行う。
- これらを最終承認者が承認するまで続ける。
言葉で書くとわかりにくいですね、図にするとこうなります。
申請者の申請をトリガーとして、稟議のワークフローが始まります。基本的に申請者はBacklogとTypetalkの通知、承認者はTypetalkの通知とQuestetraでの承認画面をチェックすればいい感じにしました。
Questetraのワークフローについては、実際に稟議のワークフローを設計するバックオフィスの方々に実装してもらい、AWS Lambdaを呼び出す箇所はこちらでそのワークフローに手を入れる形で実装を進めました。
合わせて、BacklogやTypetalkのAPIリファレンス、AWSのドキュメントとにらめっこしながらLambda側も実装していきます。
今回はAWS SAM CLIを使用してAPI GatewayやLambdaの管理、ローカルでの動作確認をおこないました。久々にJavaで書きましたが特に苦労したところもなく、その点に関してはあまり書くことがありません。
AWS SAM CLIではローカルでlambdaの起動・処理が行えるため、非常に開発しやすかったです。ローカルでは問題なかったのに、実環境ではJVMの起動前にタイムアウト発生し処理できないなど、いくつかはまりどころもありましたが、適切なメモリー量・タイムアウト時間の設定を行い解決していきました。
フィードバックを受ける
ここまでの仕様決定や実装の間にもいくつものフィードバックを受けていきます。日々のミーティングでは今何をしているか、どこに問題があると思っているかなどをメンターと共有し、方針や解決策を練っていきます。
また実際にシナリオ通りに進められるのか、デモをおこないました。申請者となりうる方々や承認者となる方々に協力いただいて、実装前・実装後に複数回おこない、改善すべき点を洗い出していきます。
印象深かったのは、ヌーラバーのサービスに対する指摘内容の濃さです。ユーザーがそれを触ったときにどう感じるか、通知一つとってもどういう内容がいいか、サービスに対する手触りに対して厳しい目を持っていて、非常に勉強になる時間でした。
Eringi-chan誕生
さて、ここまでで稟議システムの設計・実装を進めてきましたが、「ヌーラボらしい」という点はまだクリアできていませんでした。稟議システムと言われると「堅苦しいもの」ととらえられがちなので、「ゆるく、とっつきやすいもの」としてやっていきたい。喧々諤々とミーティングを行なった結果、京都オフィスのデザイナーUGによりEringi-chanが誕生します。
Eringi-chanの誕生により、「とっつきやすさ」と「ゆるさ」が備わりググッと親しみやすさが増しました。
そして実運用へ
開発自体は11月頭で一旦区切りとなりましたが、そこからテスト等を経てEringiは年始より実際の運用に入っています。一部バグ等もありましたがすでに300件以上もの稟議申請が承認完了となっています。ヌーラバーからは「気持ちよく使えてる」「りんりんしてるのがかわいい」などご好評をいただいてるようです。
実運用に入ってからいくつか改善点も見つかっているので、これで終わりではありませんが、ひとまず着地できたといったところでしょうか。
おわりに
ヌーラボに入って研修とは言えど初仕事、ヌーラボにおけるチームでの仕事やサービスとして何を大切にしているかなど、会社の文化をしっかり体に染み込ませることができたと感じています。
Eringiは今日も元気にりんりんしています。
