この記事はエイチームブライズ/エイチームコネクト/エイチーム引越し侍 Advent Calendar 2018 11日目の記事です。本日はエイチーム引越し侍中途2年目エンジニア加藤が担当します。
この記事で伝えたいこと
本日書こうと思う記事は、去年のアドベントカレンダーで書いた記事「爆速エンジニアの勧め～まずは導入～」もそうだったんですが、技術的な記事というよりかは、技術は得意で仕事もこなしているのに評価されないと思っているエンジニアだったり、そういうエンジニアを教育していこうと思っている新米リーダー、マネージャーだったりする人に向けて何かの役に立てればと書きます！※以下いろんな案件を混ぜ込んだりフィクションもあります。ご了承ください。
以下本記事の目次です。
目次
相手の真に実現したい課題を考えろ！
エラーが発生した時のインパクトを考えろ！
個人情報漏洩のリスクを考えろ！
問題が発生時の心構え
段取り力を磨け！
工数見積もりの精度を上げろ！
チームで仕事をする上での基礎の基礎
相手の真に実現したい課題を考えろ！
弊社では新卒や中途での入社者に対して「作業者にしない」ように教育することをグループ全体で意識しています。
要は誰でも単純にできることを仕事として振って新卒から考える喜びを奪わないようにするということなのですが、よく僕は若手エンジニアに対して「今作業者になっちゃってるよ」と伝えます。
どういうときに伝えるのか
1つ実例をつらつらと書きますが、
新卒が営業の方から依頼された仕事が以下のようなものでした。
「業者さんが料金を入力するときにカンマを入れると料金が消えるからカンマを消してほしい」
なるほど10,000円と入力すると、DBのインサート時にint型に暗黙的に10000と変換されずにnullになってしまうとかそういうことでしょうね。
そこで若手エンジニアが提案したソリューションがこちら
「DBのインサート時にカンマが入っていたら除去してインサートするようにしますね！」
さてここで立ち止まって考えてほしいのですが、
営業の方や業者さんが真に解決したい課題とはなんだったのでしょうか？
そこでコーチング的に行った会話を以下に載せます。
加藤「業者さんが真に解決したい課題ってカンマを取り除きたいだけなのかな？」
新卒「カンマ以外も入ってきたらってことですか？？？」
加藤「うん、それもそうだろうね。」
新卒「じゃあ半角数字以外が入ってきたら取り除きますね！」
加藤「それで業者さんの望みはすべて叶うかな？」
新卒「う～ん」
とまぁこんな会話を続けてきましたが、皆さんは真に解決したい課題って何だったと思いますか？
ぶっちゃけ正解というものはないのですが、僕は
「業者さんが入力したいと思った料金を正確に入れられること」
だと考えました。
もちろんこの課題をかなえるために、
「入力されたときに自動で入力フォームに適切な位置でカンマをインサートするようにして」
とか工数をかけてでも作りこみなさいと言うわけじゃないんです。
真に解決したい課題が決まったらあとはコストパフォーマンスだと思います。
最終的に話し合った結果新卒が出してくれたソリューションが
「全角の数字を半角に変換し、半角数字以外を取り除く処理をjsでchangeイベント時に行う」でした。
おいおいバックエンド側の処理は書かないのかよと思う方もいらっしゃるかと思いますが、
業者管理画面の適正上悪意を持って料金を入力する人もいないと思いますし、最悪そんな方がいらっしゃっても結果料金がうまく入らないだけという自分の首を絞めるだけなので僕はいったんそれでよしとしました。
なので依頼された仕様をただ忠実に作るだけだと作業者になってしまうよ、「相手が期待した以上の機能」を「サクッと」作れて「おっ」と思われるエンジニアを目指して欲しいなと思います。
エラーが発生した時のインパクトを考えろ！
これも実例をつらつらと書いていきます。
弊社のコールセンター業務の一部を行ってくださっている提携会社様があるのですが、そこのコールシステムと弊社のシステムでAPI連携を行うことになりました。
そこでAPIの仕様書をせっせと作ってくれた若手エンジニアがいたのですが、その仕様をかいつまんで簡単に説明すると
「弊社のバリデートでエラーが生じた場合はエラーメッセージとエラーコードを返します。」
「エラーが発生した場合は御社システムでエラーメッセージに従って再度入力しなおしてください」
一見仕様としてはそれっぽいものになっていますがエラーの中には「未知のエラー」というものがありました。
以下またそのときにしたコーチング的な会話です。
加藤「この未知のエラーってなに？」
若手「仕様詰める段階で想定できていないエラーです！」
加藤「例えばどんなのがある？」
若手「例えばウチのシステムが重くなっていてDBにインサートできないときとか」
加藤「なるほどね、もしそんな状態になってしまったらどうなるのかな？」
若手「提携先で情報が登録できなくなりますね…」
加藤「そうなってしまった場合のインパクトってどうなるんだろ」
という感じです。
僕がここで言いたいのは
「それが発生した時って最悪いくらの損失になるの？」ということです。
売り上げ利益が下がることや工数が無駄にかかってしまうこと、今回の場合ですと取引先の信用を失ってしまうことにもなりかねないですよね。
よくエラー処理とか書いて満足するケースもあったりすると思いますが、そのエラーが起きてしまったときのフローやインパクトをしっかりとイメージして設計をして欲しいなぁと思うわけです。
個人情報漏洩のリスクを考えろ！
これも実例を交えて
よくどこかのサイトに登録しようとするとメール認証から始まって、メールに登録するためのURLが届いて、そのURLから登録みたいなケースって多いと思うんです。
弊社の新規サービスである生活に寄り添ったサービスを提供するファインドプロ～あなたの街のプロ探し～ではある程度の個人情報を入力してくれたユーザにマイページを作ってもらうのですが、もし万が一、その登録するURLがアタックされたらというのを考えてみます。以下コーチング的会話です。
若手「登録するための認証キーが長すぎてSMSとかで使えないんで短縮URL使おうと思います！」
加藤「なるほど、ちなみに短縮URLって何桁か知ってる？」
若手「え、知らないです調べてみます！あ、キーの部分は6桁ですね！」
加藤「なるほどするとアルファベットと数字でざっと62文字くらいか、62^6で600億通りくらいか、もしこのURLにアタックされたときに運悪く個人情報が開示されてしまうケースってないかな？」
若手「可能性としてはなくないと思います！」
加藤「そしたら短縮URLを使ってリスクを上げるっていうのはあまり良くないかもしれないね、現にGoogleとかだとこのURLにアタックされているという情報もあるし」
若手「そうですね…！わかりました！短縮URL使うのやめます！」
とまぁ上場企業のグループ会社なので個人情報に関してはこれくらいシビアであるべきだと思いますし、何よりまず個人情報漏洩のリスクに対して考える癖をつけて欲しいなぁと思うわけです。
問題が発生時の心構え
これはよくある話かなぁと思うので例えばの話をしようかと思います。
例えば1つのサーバーがなぜか突発的に応答不能になってアラートが飛んできて、そのサーバーを切り離して対応したら他にも応答不能になったサーバーがあとから出てきたりとか。
ある不具合が発生して修正対応したら実は他にも影響が出ていたのに修正しきれてなかったとか。
こんな時に自分がある大手自動車系の当時部長クラスだった人がマネージャーとしての心構えとして教えてくださった話を書こうと思います。
部長「もし君が1万円を駐車場で見つけたとしたらマネージャーの立場で考えて何をしたらいいと思う？」
加藤「えぇと…1万を拾って警察に届けますね、それももし誰か見ててもネコババしたと思われないようにできる限り生身で持っていくかもしれません。」
この時は地位のある人がネコババなんてしたらいけないだろうなと思ってこう答えたのですが、その部長はにやっとして続けました。
部長「それではマネージャーとしては務まらんな」
加藤「えぇっではどうしたらよかったのですか？」
部長「いいかい、まず1万円が落ちているのを確認したらすぐに足で踏みつけて飛ばないようにして、自分の財布に入れて、そしたら他にも1万円が落ちていないか探すんだ。」
と冗談交じりに話してくれましたが、そのとき得た教訓は、問題が発生したら火急的速やかに飛び火しないように対処して(足で踏みつけるのが最短)、同じような問題(1万円)が落ちていないかちゃんと確認する。というようなことでした。
不具合が発生したときこそ、目の前の事象だけじゃなく、他にも同じような現象が起きていないかを考えられるように視野が広くなって欲しいなぁと思うわけです。
段取り力を磨け！
これもあるあるなので、例えばの話から
去年の記事では調整力と書きましたが、今年になってこの段取り力という言葉がすべてを内包している気がしてよく使っています。
僕が思う段取り力とは、
他者と同じ意識でゴールを握れるか
└握れていないと出戻りが発生する
ゴールまでの道筋が見えるか
└見えていないと想定外なことが多くなる
他者を意識してどの作業順で行うのが早いかを見極められるか
└自分のタスクが終わったら他者に依頼する場合そっちを優先でやるべき
他者に依頼するときに期限を握れるか
└やってほしいだけじゃいつできるかわかんないよ！
進捗に対して遅れてそうな時に適切なアラートが出せるか
└アラートが遅すぎるとなんでこういう状態になるまで黙っていたんだとなってしまいがち
変化に対して適切に対応できるか
└仕様は変わりがち、再度しっかり段取りできるか
などなど簡単に書きましたが、なんか段取り力だけで記事が書けそうなのでまた詳しく書きたいと思います！
工数見積もりの精度を上げろ！
工数見積もりって皆さんどのようにしていますか？
肌感でやって見積もりがあっているなら問題ないと思うのですが、いつも見積もりよりもオーバーしてしまったり、少ない時間でできてしまっているのは少し問題ですね。
工数見積もりの精度を上げるためのPDCAって皆さん行っているでしょうか？
経験のあるエンジニアが肌感で工数を出せるのは仕様から機能実装までをイメージできていて、そのためにかかる工数が意外と細部にわたってすぐ計算できているからなんです。
それをマネして肌感だけでやっているうちはPDCAも回せずに、毎回ブレブレの工数を出すことになるでしょう。
なので工数見積もりをするときには工数がイメージできるまで仕様を細分化することをお勧めします。
細分化することで、Checkの時に自分がどういう処理を実装するのが思ったより得意なのか、苦手なのかや、
仕様が定まっていないことに気づいたり、想定外の仕様が来た時に経験として積みやすくなります。
工数見積もりは特に1人1人の経験によるものになりがちですが、弊社ではペア見積もりなんかもしてみたりしています。是非若手エンジニアはベテランエンジニアがどのように見積もりをしているのかを学んでみるのもいいと思います。
チームで仕事をする上での基礎の基礎
最近これがやっぱり一番初めに身に着ける能力だなと痛感するのが、やっぱりホウレンソウです。
エンジニアは割と内向的な人が多かったりするので難しいかもしれませんが、社会人として認められるために誰もが通る道だと思っています。
仕事ができる人の特徴として、形は変われどいつまでたってもちゃんとホウレンソウをしているイメージが僕の中であります。
ホウレンソウはチームのリーダーやマネージャーに若手エンジニアが成長したことをアピールする良い機会だとも思います。
そんなことが？と思っている若手エンジニアこそ是非意識していってもらえるといいかなと思います。
まとめ
いかがでしたでしょうか。
今日書いたことはなるほど！と思ってもすぐに意識できたり実践できる人は少ないんじゃないかなぁと思います。
みなさんも一人前になった！と認められるまでこの記事をストックして定期的に見ることをお勧めします ﾁﾗｯﾁﾗｯ
エイチームブライズ/エイチームコネクト/エイチーム引越し侍 Advent Calendar 2018 明日は@kekiさんが担当です。お楽しみに！
追伸
株式会社エイチーム引越し侍では、一緒にサイト改善をしてくれるWebエンジニアを募集しています。エイチームグループのエンジニアとして働きたい！という方は是非、以下のリンクから応募してください。
皆様からのご応募、お待ちしております！！