はじめに

この記事はラクスアドベントカレンダーの10日目の記事です。
おととしぶりの参戦ですが、相変わらず技術的なことは書きませんと先に言っておきます。
ほんとーーーーーに技術的なことは書きません。
そういうのが読みたい方は別日程を楽しみにしておいていただければ…()

今年は私にとって激動の一年になりました。
チームが課になり、リーダーの異動で実質リーダーになり、かと思えば課が吸収されチームに戻り、リーダーが板につき始め…

新卒4年目となる私ですが、一気に働く環境の変わる一年になりました。
(実際は肩書が変わっているだけで業務内容自体には大きな変化はなかったですが…)

と、こんな感じで組織の大きな変動に流されてきたのですが、以前から意識してやってきたことが成果として表れてきたのでおさらいがてら文章化して常に忘れず心に留めておこうかと…
本や上長や先輩から教えてもらったことを噛み砕いて書いているだけですがあしからず。
あと、書きあげてから気づいたんですが、オフショアのエッセンスがかなり薄い。マジでちょっとしか書いてない。タイトル釣りじゃん。
一緒に働いているメンバーがベトナム人2名であることを前提に読むと何となくオフショアだからこそ活きたのかなと見れる可能性があります。(精一杯の予防線)

弊社のオフショアチームについて

2年前と体制も変わってきたので参考までに。
現在は国内にBrSEとしてベトナム人メンバーが2人、ベトナムの拠点にPL・PM含めてPGが9人、QAメンバーが5人の大所帯になっています。(他商材にもそれぞれメンバーがいるのでベトナム拠点にはもっと人数がいます。)
稼働や生産工数の管理から、案件の供給、レビュー、受入のテスト、案件についての質問や相談の対応などをしています。
私含め3人で14人のベトナム拠点のメンバーと仕事をしている形です。

この記事を読んでほしい人

若手(5年目以内くらい)でリーダー業務をする人
オフショア管理をする人
正直あれよこれよとリーダーになったけれどプログラミングに自信のない人

やってみたこと

今の世の中、コロナ禍だとか、さとり世代だとか、どんどん人との縁が緩やかになっているように感じます。
とはいえ一緒にする仕事のメンバー、嫌でも関わっていくことになります。
よく友人の話なんかを聞いているとこんなことをよく聞きます。

でかいミスをした人がいたけど、うまいこと隠してて後からばれてお客さんに謝罪に行くことになった。
先輩/後輩のしりぬぐいで当分残業だ。
上司から無理難題振られたけど普通に無理だろ～残業ラッシュだわ。

よくある居酒屋で垂れる愚痴だと思います。
どんな会社でも一定数こういう話はありますよね。
とは言え、どれも上手くやっていればつぶしていけることではないのか…とも思ったり。
ここからはそのために実践したことについて書きます。

ミスを隠させない

ミスと言っても色々とありますよね。
納期の遅れ、判断ミスによる手戻り、純粋な作業のミス。
一緒にやっている作業であればすぐ気づけるものの、いくつもの作業を並行でやっていたら見落とすと思います。
それを常に落とさないためにどうすればいいのか。
簡単です。
報告させるんです。

それが簡単じゃないんだろうって話なんですが。

じゃあどうやってそれを簡単にするのか。
「何かあってもすぐ報告してね、怒らないからね。」
言うのは簡単です。言う側は。でも報告をすべき言われた側はどうでしょう。
正直難しくないですか。報告って。
しなきゃいけないときはもちろんするけど、どうしても自分で突っ張ってどうにかしようとしちゃうんじゃないですか？
思い当たる節のあった人はたくさんいるはず。（なんなら私も苦手です。）

じゃあ逆になんで報告しにくかったのか、考えてみてください。
「話しかけにくい雰囲気があった」「怒られるんじゃないか不安だった」「このミスで仕事減らされたらどうしよう」
いくつかあると思います。
でもやっぱり年の差や歴の違いで生じるのって「話しかけにくい雰囲気があった」なんじゃないでしょうか。

報告しやすい環境づくり

私は普段まじめな顔しているつもりがムスッとしていしまいます。
そういう人ってめちゃくちゃ話しかけにくいですよね。

向こうから話しかけにくいならこっちから話しかければいいじゃん！

ただこれだけなんです。
普段から息抜きがてらプライベートの話や時事ネタ、社内での話とかをして話しかけやすい雰囲気を作ります。
最近報告が少ない案件なんかは今どんな感じなん？と言ってこっちから気にかけます。
これを毎日続けてください。報告するのは義務だ、自分はフラットに全部見なきゃいけないんだみたいなのはナンセンス。
報告させる習慣をつけるんです。本人たちにはこの人なら言っても怒らない、言わない方が怒られそうという雰囲気をつけましょう。

これを続けた結果、この前メンバーに「やっぱ最初は私怖かった？」と聞いたら「怖かったです！！」と言われましたが、ちゃんと今は怖くないとフォローももらいましたｗ

これは国内のメンバーだけでなく、海外拠点のメンバーにも同じです。
プロフェッショナルな堅気の風土の国ならなおさら気をつけてみてください。
チャットにハートのスタンプでリアクションしたり、MTGの始まる前は日本の季節や天気、イベントの話をしたり、案件が完了したら盛大に感謝したり。
そうすることで「この人は良く反応してくれるし、話しかけやすいな」という風潮を意識的に作っていくことで、風通しがよく進捗が把握しやすい報告の多い組織になると思います。

自信を持たない

正しくは自信を持ち「すぎない」ですね。
あえて強い言葉を使ってます。弱く見えてしまいますが。
一応ある程度の自信は必要です。
とはいえ、自分の判断には常に懐疑的になるのが良いと思います。
自信を持ちすぎた時に起こること…

自分の判断でOKと思ったことがNGだった。
- 事故や手戻りにつながった
その判断によって複数の人間の作業量が倍になった
たまたま見落とされてしまうと、以降ずっと同じミスをし続ける

などなど、デメリットまみれです。
若手が自分で全部決めて進められるの、魅力に感じそうになりますが危ないです。
エンジニアとして、その製品に関わる人間として、私の倍以上の歴を積んでいる人が周りにたくさんいます。

嫌な言い方をすると、そういう人をガンガン利用していきましょう。

4年目ともなると、結構知識もついてきたかなぁ〜といい気分になったりします。
が、実際には知らない観点や、誤解している部分って結構ありますよね。
責任のある立場になればなるほど、もっと詳しい人に相談・確認していきましょう。

指摘されるところがある、ダメだと突き返される、気持ち的には若干落ち込みます。
ただ、「聞くは一時の恥、聞かぬは一生の恥」とも言う通り、自信満々で通したものが「ダメですね」となる方が恥、と言うより自分へのダメージが一番大きくのしかかります。

自信をつける（判断ミスを減らす）ために

私のチームでは、受けた指摘をスプレッドシートにまとめています。
指摘を受けたフェーズ（設計書、CDR、テスト…などなど）や重要度など、絞り込みをしやすいようにまとめて、各フェーズで気をつけなければいけないことを見やすいようにしています。

(本当に簡単にメモを溜めてく程度ですが…)

これは自分自身の自信をつけるだけでなく、チームメンバーの自信アップにも有効です。
スプレッドシートで誰でも更新/確認できることで、どんどん見落とす観点が減っていく、他の人が受けた類似の指摘をクリアしてくことで、チームレベルも上がっていきます。
どうしても職人気質な人が多いと見て学べ、みたいな風潮とかエンジニアだからこのくらい知ってるでしょ、みたいなのが出てくると思いますが、システム的に解消していくのも時には必要ですよね。

目先の問題が必ずしも大きい問題ではない

さっきまでのは自分でこうやって解消できないかなと模索してやっていたものですが、これは教わったものになります。
例えば、Aさんの生産工数がなぜかBさんより少ない…歴の差かな…と思ったりすることないですか？
そういう時に工数上げてくのって、正直「数をこなして効率を上げてく」とかにすぐ行きがちですよね。
でもこれって抽象的だし長期的だし。かといって遅いことを責めることできないし。
そしたら次に明らかに効率の悪いものを絞っていくと思います。
Aさんに「最近何が手ごわかった？」って聞くと「めっちゃでかい〇〇案件が大変でした。」とか目立つものが真っ先に思い浮かぶものです。
そしたら大きい案件の時はBさんにフォロー厚めにしてもらったり、自分がフォロー入ったりすれば効率上がるはず…

ってちょっと待った！

確かに大きい案件って目立つし何とかしようと思いますよね。
でも待ってください。
バンバン大きい案件を担当できるみたいな人からすると「それ解消できれば万事解決じゃんｗｗ」と思いますが、BrSEみたいに複数の案件を同時に見る人にとってそれって効率的かというとそうでもないんです。

どうしても目先の大きいものが課題に見えてしまいがち。

データを元に課題を探す

実際Aさんの工数を多く蝕んでいたのは何だったのか。
データを見るとどうも向こうのメンバーの質問対応で、結構一緒に作業をしていたらしい。
例えばこれが1日2時間あったとしたら月の1/4は質問対応に費やしていることになります。
巨大案件1つ見るだけならいいかもしれないですが、向こうに15人もメンバーがいると、1つの巨大案件だけではどうしても案件が足りないです。
そのため、複数の案件を渡しているので、こちらで見る案件量も自然と多くなるんです。
これを半分に、1/4にと削減できればそれだけで2～3日も作業できる時間ができるんですね。
こちらはヒントを渡して向こうで倍の時間をかけて調べるとか、質問が減るように案件を渡す時点での細かな制約や条件を明確にするとか、そういうところが課題として見えてきました。

「とりあえず印象的にここで時間食ってそう」とか「時間を食うからこれが悪い、やめよう」とか、簡単に解消できそうなんでついそこからつぶしてしまおうとしてしまうところを、ちゃんと何が原因なのか、それを解消する方法は何なのかを細かく分析していくことが重要なんですね。

まだ細かいデータを取っていないので正確な比較はできていませんが、本人に自分の稼働の分析を簡単にしてもらったところ、課題をつぶせたおかげで多少なりとも効果は出ているとのことでした。
(大きく合計だけ見ただけでも、前よりも数字が上がっているのは言うまでもなく…)

最後に

相も変わらず技術に関することは一つも書けませんでした。
いつかプライベートで何かやったこと書ければいいなとは思いつつ…

またリーダー職が板についてきたとこで詳しく解説なんかを書くのもいいですね。
期待はしないでください。

最後に宣伝になりますが、みなさん面白い記事書いているのでぜひ弊社のアドベントカレンダーを見ていってください。