職場変わるってよ - 新卒からの5年間を振り返る -
この 7 月で新卒から 5 年と 3 ヶ月お世話になった職場が変わるということで振り返っていきたいと思います。自分なりに色々な課題に向かいあって学びを得て成長できたので、その学びを発信することで読んでくれた誰かに少しでも刺さったらいいなぁと思って書きます。
筆者の概要
- 新卒から社内データ分析基盤の開発・運用に携わる
- 所属するチームのメンバー数は 15 名程度
- クラウド(AWS/Google Cloud)を中心に業務に携わり、DevOps や Observability やアジャイル開発もかじる
- Google Cloud は自身の技術軸でもあり、社外コミュニティに参加したり、社内コミュニティを立ち上げたりと今後も関わっていきたい
自分ならではの価値ってなんだろう？
大きな節目ごとにまとめていこうと思いますが、まずは自身が入社からずっと向き合ってきた課題について書こうと思います。
格好良く書きましたが、モチベーションとしては「いかに目立つか、どうやって他人との差分を出すか」をずっと考えていました。入社から優秀な同期や素晴らしい先輩方がいる中で自分自身が目立つためにはどうしたらいいか、これの 1 つのアプローチが「自分ならではの価値を発揮する」でした。
言葉で言うのは簡単ですが、実践するのはすごく大変で。ちょっと形になってもすぐに追いつかれたり追い越されたり、自分のポジションやスキルに満足し続ける時間は長くなかったように感じます。
それでも、この課題と向き合い続けたからこそこれから書くような経験ができて学びを得られたのだと思います。（調べてみると、これから書くようなスキルはテクニカルスキルに対してヒューマンスキルやコンセプチュアルスキルと呼ぶみたいです。ヒューマンスキルは聞き覚えありますが、コンセプチュアルスキルは初めて聞きました。ニュアンスはこちらが近そうです）
振り返り①：課題の背景を理解する
資料レビューでダメだしの日々
入社してから 3 年くらいは技術課題を解いてスキルアップすることに集中していました。特に既存のデータ分析基盤に BigQuery を中心に Google Cloud で構築した基盤を導入する取り組みに力を入れてました。
2 年目ごろから管理職向けに案件を説明する役目を若手社員がやるという施策が始まりました。自分も例に漏れなく上記の案件の説明を定期的にいれることとなりました。
この案件説明では当然資料を作成するのですが、ここで問題が。資料を作れど何度も上長のレビューでダメ出しをくらいました。そして何度もこの言葉を言われました。
上長：「やってることはわかった、結局それでどうしたいのかが伝わらない」
気がつけば言われたことしかやっていなかった
改めて自分の資料を読み返した時に、とにかく自分がやったことだけをまとめていて、そこには 「なぜこの取り組みが必要なのか」「取り組みの結果、誰がどう嬉しいのか」 と言う情報が一切ありませんでした。
なぜかと考えた時に、上長から「こういった技術課題を解いて」と言われてただやるだけになっていたのが原因だと感じました。つまり、言われたことをただやるだけで 「どういう経緯があって、その中で何が必要だからこの課題を解かなければいけないのか、それによって誰がどう嬉しいのか」 といった 課題の背景 を全く理解せずに取り組んでいました。
当時は課題渡す時に一緒に言ってくれればええやん、と思っていましたが得てしてこういった情報は省かれがちですよね(笑)でも、こういった情報を把握しているか理解しているかによって、課題へのアプローチが変わってきたり、より説得力のある説明できたりと アクションの精度が高まる と思っています。
この経験から何かしら取り組む時は、「誰かに説明だったり提案するときにストーリーだてて伝えられるか」 を重要視するようになりました。そうすることで「あれ、これってやる意味あるんだっけ」といったふわふわすることがなくなったり、 取り組みのやる意義を精査できた ので、自分の自信にも繋がりました。
言われてみれば当たり前ですが、当時はなかなか言語化できなかったり実践できなかったりで苦しみました（理解できているようで詰められると答えられない的な）。各々の立場やフェーズによってどれくらい背景を理解した上で取り組むかは変わってくるとは思いますが。
振り返り②：あるべき姿をとにかく考える
いきなりチームリーダーに任命
チームに所属し続けて 4 年目、15 人規模のチームのリーダーにいきなり任命されました。チームの構成的に中堅どころがいなかったので 4 年も所属し続けるとチームでそこそこの立ち位置になってました。
任命された当初は「チームリーダーと言われたが何すればええねん」って思いが強く、あまりアクションを起こせていませんでした。一方で打ち合わせ等では「彼が新たなチームリーダーです」と紹介されることも増えて、何もできていないのに肩書きだけ広まることにプレッシャーを感じる日々でした。（新たなとはいうものの前任者はいませんでしたが。）
この時期、他支社から異動してきたかなり経験積んだ先輩がチームにジョインしていました。その先輩に何もできていない不甲斐なさやチームがどこに向かっていけばわからん的なことをよく愚痴っていたところ、こんなことを言われました。
先輩：「わからないなら筆者くんが考えて導けばいいじゃん、筆者くんの立場だからこそできることがあるはず」
正解がない時代だからこそ「あるべき姿」を想像する
最初はこの言葉の意味がよくわかっていませんでした、「そんなん上の人の仕事じゃん」と正直思っていました。
しかし、ある取り組みがきっかけでこの考えは変わりました。それは複数のチームをまとめるリーダーが開催するようになった 「組織をよくするために個々がどう進化するべきか」 を考えるという取り組みです。
ここではそのリーダーが考える組織のあるべき姿を参加者で議論したり、「成人発達理論」「New Type」「NORULES」「だから僕たちは組織を変えていける」「Team Topologies」など組織論やカルチャーに関する書籍から得られた学びを共有してもらったりと今まで考えなかった観点での学びがたくさんあるものとなっていました。
その中で 「十数年前と比較して今は正解がない時代、だからこそ個々が正解だと思うあるべき姿を追求してアクションを起こしていかなけばイノベーションは生まれない」 といった話がありました。
その話を聞いてから 「誰か」 がやってくれるの待つのではなく、気になったり違うと思ったことには「自分」が あるべき姿を考えてアクションしなければいけないんだ というマインド（いわゆる当事者意識ですかね）になりました。その時に上述した言葉の意味が 「不満があるなら自分で変えていけばいい、年次も重ねて管理職と現場の間に立てるからこそやれることがある」 なのかなとふと解釈しました。本当のところはわかりませんが（笑）
そこからは何がチームにとってあるべき姿なのかを考えるようになりました。例えば、チームの取り組みについてやりっぱなしにせず結果共有して何を継続して何を次に活かすかを議論する だとか システム的に失敗があれば担当者を責めるのではなく、失敗を詳細にしてチームで何が原因でどう改善するかを考えて再発防止する だとかチームレベルで 「振り返りを徹底する文化」 を浸透させる必要を感じ発信を継続しました。他から見たらどうかわりませんが、個人的にはよりチームらしくなってそれぞれの取り組みでアクションと振り返りのサイクルがぐるぐる回って加速したように感じています。
振り返り③：いかにスケールさせるか
1人では限界があった
5 年目になったころ上述の観点でものごとを考えられるようになったことでそれまでのとにかく技術力を伸ばして成長する！とはまた別の成長を感じられていました。例えば、チームをリードするような話し合いを何回も開催して自分たちはチームとしてどこに向かっていけばいいかを考える機会を作ったりもしました。
ただ、こういった話し合いは得てして意見が出づらいものですよね。活発な議論というには程遠い話し合いが続きました。やっていることは間違っていないと思いつつ、チームとしてもっと考える雰囲気をつくりたいと思っていました。
チームの方針を考えながら、「どうやったら活発な議論ができるか」も考えるようになりました。行き着いた結論はこんな感じでした。
筆者：「自分だけが頑張っていてもダメだ、もっと日頃からチームのことを自分事として捉えてもらえるようにコミュニケーションを取らなければ」
自分事として捉えてもらう仕組み/仕掛けづくり
自分が思う組織におけるスケールは、特定の物事が属人化（その人だけが何もかも頑張っているだけの状態）せずに関係者が自主性を持って取り組んでいる状態をイメージしています。
上述の考えになってからはいくつか日頃からの取り組みを変えてみました。簡単なところではチームメンバーとの何気ない会話の中で「将来的にチームがこんな状態になると良いと思っているけど、どう思う？」と投げかけるようにしました。すると、打ち合わせの場では出てこない各自の考えが簡単に出てくるようになりました。雑談くらいの空気感でラフに聞いた方が話がしやすいんだなと改めて実感しました。
各自がどう考えているかがなんとなくわかってきたので、次は明示的に役割を与えることもしてみました。これは自分が思い返してみた時に、「チームリーダー」という役割を与えられたからこそ「チームのあるべき姿を考える」というアクションを取っていたからです。人間、役割を与えられるとそれっぽく振る舞おうとするですかね（笑） 例えば、チームの方針をブレイクダウンするといくつかフォーカスすべきトピックが出てきたりします。そのトピックごとにリードするメンバーを任命することで、そのメンバーに責任感を持ってもらう = 自分事として捉えてもらう形をとりました。個人的には自分事として捉えて考えてくれるメンバーが増えたとともに、自分自身が頑張りすぎなくよくなったのでアプローチを変えて良かったなと感じています。
あとはツール的な面で、打ち合わせ中に極力顔出しをする、話し合い中や後に議論内容を見れるようにチームメンバーの共有場所に置くドキュメントをわかりやすくまとめる、 言葉を発することに抵抗があるメンバーを考慮して Jamboard（電子ホワイトボード的なツールで複数人同時に付箋にコメント書いたり閲覧して共有できる） をベースに議論を進めてみたりしました。特に Jamboard は付箋にコメントを書くのがワークっぽくて、発言を促すよりも圧倒的に意見が集まるようになりました。また、出してもらった付箋を見て気になるところは記載したメンバーに補足をしゃべってもらったりとリードしている自分以外のメンバーが話す機会を作ることにも注力しました。
こうした地道な仕組み/仕掛け作りを継続した結果、数ヶ月後には活発な議論と言ってもいいくらいに濃密な時間になることが増えました。（やはり毎回そういった時間にするのは難しく、自分が準備不足な時は反省が残る回もありました(笑)）
根底には心理的安全性
こういった自分事として捉えるというマインドには 「心理的安全性」 が不可欠であるとも思いました。上記で例として挙げたチームの方針を考える話し合いはもろに直結していますが、開発の現場でも同じだと思っています。
Google のソフトウェアエンジニアリングでも似たような記述があります。
ソフトウェアエンジニアリングの根本には人間がいるため、組織の成功は組織が擁する人々への育成と人々への投資にかかっている
組織の文化をどう醸成するかや開発手法をどするかは手段である。何事の根本には人間がいるからこそ、その点にフォーカスすることが重要なのかなと。この人間同士の関係性における望ましい状態の 1 つとして「心理的安全性が高い」ということが重要と考えています。
上述した話に戻ると、打ち合わせを始めた頃に活発な議論ができなかった要因の 1 つは心理的安全性が低かったのもあると考えました。そもそもある程度の人数がいる場で発言しにくい、意見を言ったら非難されるのではないかという考えを持っていたメンバーも多かったと思いますし、これは心理的安全性の低さも起因しているものだったのかなと。
だからこそ、まずは「心理的安全性」という考えが重要であることを認識してもらうことは 1 つ良くなったきっかけだと思いました。これを展開したのは自分ではなく、「組織をよくするために個々がどう進化するべきか」 を考える場でリーダーがキーワードとして出ていたのでありがたかったです。
また、自分が変えたアプローチである「日頃のコミュニケーション」「明示的な役割の割り当て」「打ち合わせ中に顔出し」といった内容は地味ではあるけど心理的安全性を高める行動でもあったと思います。あとは話合いの中で 「正解はない」 というワードもよく出していました。これは何か質問すると誰しもが「正解」を考えてしまって、その「正解」が出ないと言葉に詰まってしまうと現象をよく見かけたからです。（自分もそういった節はありました）心理的安全性の文脈でも率直であることが重要とありますし、思ったことを率直に言って欲しいというメッセージ を出すようにしていました。（ただ、率直に言いすぎて人の意見を否定するようなケースは避けるようにもしてましたが（笑））
こういった取り組みを通して、チームがよりチームらしく成長している様を感じれたのは非常に良い経験となりました。
まとめ
長々と自身の振り返りの学びをまとめてみました。この記事の最初を「自分ならではの価値ってなんだろう？」で始めたのはエンジニアとしてのテクニカルなスキル以外にも上述したヒューマンスキルやコンセプチュアスキルを持ち合わせていることも個人的には人の差別化にあたると考えているからです。こう言った内容を評価してもらえるかは環境次第だとは思いますが、自分は成長をできた部分でもありますし評価してもらえてありがたかったなと。
上述した内容はどれも経験がないと実感しづらいものかもしれませんが、1 つでも「確かにこういう考え重要かもな」と思ってもらえれば幸いです。また、伸び悩んでいるエンジニアの方にもテクニカルなスキルだけが全てでないと伝わるといいなと思っています。ポジションによって求められるスキルは違いますし、スキルの掛け合わせで発揮できる価値も変わってくると思うので。
ここまで読んでくださった方に感謝しています。
ありがとうございました。
さいごに
AWS と Google Cloud で構築したデータ基盤の開発・運用に携わっているデータエンジニアです。5 年くらい携わっていて、この業務がきっかけで Google Cloud が好きになりました。
Google Cloud 関連の情報を発信をしています。
Discussion