このシリーズは転職の記録ですが、この記事だけは転職の話ではありません。
客先常駐の開発現場で、技術以外にやっていたことの話です。
転職活動の記録だけ読みたい方は、この記事は飛ばしてもらって大丈夫です。
ただ、私がコンサル寄りの仕事を選んだ理由にもつながっているので、残しておきます。
チームの雰囲気が重いと感じている人
技術で突き抜けられないと思っているSE
客先常駐でどう立ち回るか迷っている人
参画したときのチームは、とにかく静かだった
今の会社はSESなので、客先に常駐して働きます。
初めてその現場に入った日、島全体がシーンと静まり返っていました。
でも、仕事の話は笑顔でしていた
ただ、よく見ていると少し違和感がありました。
仕事の話をするときは、みんな笑顔で喋っているのです。
つまり、仲が悪いわけではないんですよね。
前の転職では社風や雰囲気を重視して会社を選びました。
なので、雰囲気って変えられるものなのかな、というのは前から気になっていたんですよね。
雰囲気がそうさせているだけかもしれないと思いました。
こっちからボールを投げてみることにした
試しに私から話を振ってみると、笑顔で答えてくれます。
向こうからも、いろんなことを聞いてくれるようになりました。
なので、ボールを投げる数を増やして、どんな反応が返ってくるか見てみようと思いました。
これが最初にやったことです。
見積もりが甘くて、全員が月40時間以上の残業になった
最初に入った開発プロジェクトは、正直に言うと見積もりがかなり甘いものでした。
開発期間は半年ほどでした。
稼働が始まって1カ月目から、開発メンバー3名全員が40時間以上残業していました。
一番多いときで、私は月75時間ほどです。
他の方も60時間から70時間くらいでした。
そりゃあ、チーム全体の雰囲気もかなり重くなっていきます。
やったこと① ハッピーターンを配った
雑談から会話を盛り上げて、少しでも明るい雰囲気にできたらと思って始めました。
やり方は単純です。
週に2回ほど「ハッピーですか？」と聞いて回ります。
「ハッピーでない」と返ってきたら「ハッピーになれ」と言ってハッピーターンを渡します。
「ハッピー」と返ってきたら「もっとハッピーになれ」と言って渡します。
ハッピーターンを選んだ理由は語呂だけ
なぜハッピーターンなのかというと、単純に語呂が良かったからです。
分解するとハッピー＋ターンで、ハッピーに転換する、という意味になります。
あとは、渡し方を想像すると単純に面白かったからです。
本当に、それだけの理由なんです。
先にキャラを作っておいたのが大きい
これ、いきなりやってたら確実に引かれてたと思うんですよね。
私は案件に参画した時点から、冗談を言ったり、少しおかしなことを言ったりしていました。
意識的に自分のキャラ付けをしていたのです。
そのおかげか、最初に渡したときも「少し驚いて、少し笑う」くらいの反応で済みました。
1年で5回だけにした
やったのは、1年いた中で5回ほどです。
毎日お菓子を配っていると、ありがたみも意味もなくなってきます。
なので、雰囲気が重くなってきたタイミングを見てやるようにしていました。
ちなみにお菓子代は自腹です。
自分を助けるという意味でも、自腹で買うのは悪くないと思っています。
「ハッピーじゃないです(泣)」から始まった
一番最初に渡したときは、みんなかなり忙しくてしんどい状態でした。
PLからは「ハッピーじゃないです(泣)」という回答が返ってきました。
まあ、その通りだろうなと思いました…
ただ、翌月に同じことをしたときは違いました。
少しずつ雰囲気も明るくなり始めていて、「ハッピーです」と言ってもらえたのです。
そのうち、お互いにお菓子を渡し合うことが増えていきました。
やったこと② ホワイトボードで書き出した
私は社会人8年目くらいから、小型のホワイトボードを持ち歩いています。
きっかけはコンサル会社の人たち
1社目のとき、事業会社のIT企画部に常駐していました。
そこでシステムの入れ替えを手伝ってくれていたのが、あるコンサルティング会社の人たちでした。
その方たちがホワイトボードを使っているのを、よく見ていたのです。
10歳上の先輩に説明が伝わらなかった
もう一つきっかけがあります。
現場に10歳ほど年上の先輩が入ってきたとき、説明がなかなか理解してもらえませんでした。
口で言うだけだと、どうしても限界があるんですよね。
構造的に理解してもらえるようにと思って使い出したら、これがかなり便利でした。
それ以来、持ち歩くようにしています。
会議が空中戦になりかけたとき
開発が遅れて、メンバー3人とチームリーダーで会議室に集まったことがありました。
議論が空中戦になりかけている気がしたので、後ろにあった大きなホワイトボードを使いました。
まず、各々が持っている開発のタスクを人別に書き出していきます。
リーダーは、優先順位をつけて潰せるものから効率的に潰したいと思っていたようでした。
なので「では、優先順位はどれですか？」と聞きながら進めました。
優先順位が高いものから番号を振って、赤・青・緑のペンで色をつけていきます。
終わったあと、リーダーからは「ありがとうございます、助かります」と言ってもらえました。
やったこと③ 口頭で終わらせずエクセルに残した
口頭だけだと、体感で2割は認識がずれる
詳細設計から結合テストの間は、口頭中心の連絡がとても多くなります。
その結果、伝え漏れや認識の齟齬が起きます。
体感ですが、不具合の2割くらいは認識のずれが原因だったと思っています。
「通勤時間は必ず入る」と聞いていたのに、空白で来た
分かりやすい例があります。
グループ会社のシステムが出力する、通勤経路の申請ファイルを取り込む開発をしていました。
自転車通勤の交通費申請について、通勤時間は確実に入ってくると聞いていました。
なので、駐輪場代を取り込むかどうかは「通勤時間があるかないか」で判定する作りにしていました。
ところが、実際に流してみると違いました。
ユーザー側にも認識違いがあり、通勤時間が空白や0で来るパターンもあったのです。
結果、判定の条件を作り直すことになりました。
通勤時間の有無だけで見るのをやめて、申請額と他の3区分を合わせた4つを統合して判定する形に変えました。
誰かが嘘をついたわけではありません。
「確実に入る」という言葉の理解が、聞いた側と話した側でずれていただけなんですよね。
離任した案件から「2日以内に直して」と来たこともある
もう一つあります。
すでに離任した案件でインシデントが起き、それが私の担当していたプログラムでした。
2日以内に直すよう依頼が来ました。
正直、抜けた案件の依頼が来ることには少し不満もありました。
ただ、原因をたどると当時の修正依頼が不明瞭で、私の確認が甘かったのです。
どちらが悪いという話ではなく、口頭で終わらせたことが原因なんですよね。
結合テストの不具合をエクセルにまとめた
そこで、システムテストの調査からはドキュメントに残すようにしました。
まとめたのは、結合テストのフェーズで出てきた不具合です。
自分たちが開発した処理を流したあと、後続の給与計算の処理でエラーになるものでした。
ある程度分かっていないと理解が難しい内容だったので、自分が理解するためにもエクセルにしました。
リーダーがそれを持ってユーザーに説明に行った
結果として、そのドキュメントをリーダーがユーザーへの説明に使ってくれました。
これは作ってよかったなと思いましたね。
その後、仕様に関する会話も終盤には練度が上がりました。
不要な改修を避けられたり、根本解決に近い修正案が出るようになった気がします。
もちろん、滑ったこともある
冗談が変な空気になった
病院に行くために早く帰る日がありました。
その理由を説明したときに、こう言ってしまいました。
「ほら、僕って頭おかしいじゃないですか。なので頭が痛かったり耳鳴りがするので病院に行ってきます」
これは、しっかり変な空気になりました…
首を突っ込みすぎて止められた
参画した序盤のことです。
他のメンバーが行き詰まっていることや、保守案件の障害にも首を突っ込んでいました。
どんな内容なのか、どこが問題なのかという話をしに行っていたのです。
当時は自分の案件もかなり忙しい時期でした。
なので、リーダーから「今は自分のやるべきことに集中してもらった方がいいです」と言われました。
おっしゃる通りですよね(笑)
やることをやったうえでやらないと、ただ邪魔をしているだけなんですよね…
まとめ：これはコンサルのスキルではないと思う
正直に言うと、私は今でもこれをコンサルっぽいことだとは思っていないんですよね。
ただ、物事を構造的にとらえて整理して、分かるように伝えることは、他の業界の仕事でも使えるものだと思っています。
特に、人を引っ張る立場や案件を進めていく立場になると必要になってくると思います。
メンバーを一つの方向に向かせる、同じ視点にさせる、という意味でです。
技術で突き抜けられなくても、現場でやれることはあります。
AIが進んでいく中では、むしろこちら側の方が残るのではないかとも思っています。
そしてこういう話は、転職の面接でも何度も聞かれました。
派手なことは一つもしていませんが、同じように静かな現場にいる方の参考になれば嬉しいです。
