サーバーサイドエンジニアの小久保(@yhei_hei)です。
弊社で運営しているBtoB SaaSのクロスオーダーは、要件に応じて簡単な設定を行い、個社ごとのカスタマイズを行うことができます。
このカスタマイズ作業。
簡単とは言え、エンジニアによる設計やテストが必要な作業でした。
そのため以前は社員エンジニア(3人)が機能開発の合間で対応しておりました。
が、契約社数が増える速度が日に日に増しており、社員のリソースが追いつかなくなる懸念がありました。
よってこのタイミングで早期に外注化させ、スケールさせるよう舵取りを行いました。
もちろん品質を落とさずに、です。
今回は、エンジニアタスクを外注化する際にやったこと・注意したことを紹介します。
なぜこの作業が必要か？ から入る
業務に入っていただく前に、会社概要・製品の説明、なぜこの作業が必要かを丁寧に説明しました。
外注なんだし、やることだけ説明すればいいんじゃないの？ と思われる方もいるかもしれません。
もちろんそれでも良いのですが、早期に独り立ちしていただくためには、よしなにやるための前提知識が重要です。
例えば下記のように作業説明をしたとします。
非常にシンプルです。
が、この説明の場合、背景情報が全くないため、想像力が働きません。
ユーザーの業務フローを自分で推測しながら進める必要があり、たくさんの疑問が出てきます。
またこの状況では言われた通りやるしかなくなり、万が一要件自体に不備があった場合、バグを流出させてしまう可能性があります。
では、下記のような説明を追加するとどうでしょうか？
- 飲食店から卸に注文が入ると、卸の注文一覧に注文が表示される
- 卸は注文一覧から、任意の注文を「注文確定」し、「受注CSV」を出力する
- 卸は、各卸で持っている「基幹システム」に「受注CSV」をインポートする
- インポートした情報は、「ピッキングの情報」として使われたり、「売り上げ計上」等に使われる
- そのための「受注CSV」の設定が必要
これを聞いたエンジニアはこう思います。
ははあ、なるほど？
もし受注CSVに金額が含まれる場合、切り捨てなのか四捨五入なのか。
そもそもどのタイミングで端数処理をするのかを聞く必要があるな。
いや、基幹システム側で計算するものだろうから、うちは普通に出力すればいいのか？
であれば、Decimal使いつつ、小数点第二位あたりで端数処理をして〜。。。などなど
経験のあるエンジニアであればこのたった4文があるだけで色々な想像を働かせることができます。
逆にこの4文がないと、背景知識の不足から質問が増えたり、要件自体がおかしかったときに指摘ができずバグの温床になります。
そのため、既存資料や実際の画面を見せつつ丁寧に「なぜやるか？」を説明しました。
誰でもやれるマニュアルを作る
今後人数が増えていくことが予想されたため、マニュアルを作りました。
マニュアルの目的は下記
- 品質のムラがないかつ高品質を目指す。一定のスキルがあれば誰がやっても同じ結果になるようにする
- 自明な部分はあらかじめ説明し、社員エンジニア/業務委託者のコミュニケーションコストを最小にする
とにかく品質を落とさず、コミュニケーションコストをけずることを意識しました。
マニュアルに書いたこと
マニュアルに書いたことは下記です。
- 依頼発生から成果物提出、完了までの流れ
- サンプルタスクの作業手順
依頼発生から成果物提出、完了までの流れ
まず念頭に置いておくのは、業務委託される側は何をしたらこの作業が終わりなのかを非常に気にします。
依頼がふわっとしていて、やってもやっても何らかの戻し、追加作業が発生する。
このような依頼をした場合、業務委託側は内心「二度と御社と仕事しません」と思っている可能性大です。
見積もった以上の工数がかかり業務委託側が干上がってしまうからです。
継続依頼なんてとても望めません。
そのため、
依頼はどのように発生するか。
期限はどのように決められるか。
レビューの手順は？ レビュー時に求められる成果物は？
などの情報をあらかじめまとめ、マニュアルを見れば作業完了までの道のりが分かるように記載しました。
なぜ小久保がここまでこだわったか。
それは小久保もまた業務委託エンジニア経験があるかつSIerとして発注する立場も経験しているからです。
この辺りの発注側のお作法を適当にすると、余計な工数がかかり自分の首も業務委託者の首も締めることになります。
雑談：
小久保が某大手Webメディアでライター業務をやっていた際。依頼開始から完了までの流れや執筆のレギュレーションが全てマニュアル化されていて感動したことがあります。コミュニケーションコストはほぼかかっておらず、直接業務の説明を受けたことは一度もありません。結果、ライター50人弱を数人の編集で回すことができていました。
スケールさせたいなら、マニュアルは必須ですね。
サンプルタスクの作業手順
逐一詳細な機能説明をするよりは、過去タスクをどのように作業したかのデモがあると理解が早いです。
実画面のキャプチャを使いつつ、どの資料を見てどのように考え、どのように作業をしたかをまとめました。
ペアプロのような体験をドキュメント上で行い、解像度を高めていただくイメージです。
質問があればすぐにマニュアルに追加していく
以上のことを書いたものの、やはり運用してみて後からうまくいかないことが腐る程出てきます。
業務委託の方から出てくる疑問を、すぐにマニュアルに追記していきました。
PDCAを高速で回して、マニュアル側をブラッシュアップしていきます。
まとめ
マニュアル中心で運用を回してみて3ヶ月。
ひとまず設計作業や要件確認のタスクを含め、ほぼ全てを業務委託の方に移譲することができました。
社員の作業はレビューぐらいです。
また成果物にディシジョンテーブルを定めて、しっかりテストしてもらうようにしたため品質も以前に比べてアップしたと考えています。
テスト内容で要件が網羅できているかは明確なので、細かなミスも防ぐことができています。
秘訣は下記です。
- オンボーディング で背景情報をしっかり伝え、仕様の理解を助けること。想像力豊かによしなにやれる状況を作ること
- マニュアルで作業内容や成果物を明確にし、品質を安定させること
この2点に尽きます。
エンジニアタスクを外注化する際はぜひ参考にしてみてください〜！
クロスマートが気になってきた方はこちら
クロスマートでは絶賛エンジニア募集中です。
このお話を読んでちょっとでも気になった方がいたら
「話を聞きに行きたい」を押してみてください！
