前の記事の続きになります。入社してから6年ほど、自信は打ち崩され仕事の面でも大きな成果が出せず、評価は並といった状態が続いた。チームとしては技術力が高く会社への貢献度合いもある程度あるものの、自分は何もできていないという思いが強まっていた。
新しいHadoopクラスタの構築は先輩方の努力のおかげでなんとかリリースでき、運用フェーズとなってしばらくして、利用者が増えてきたことによる運用コストがチームの課題となっていた。以前自分はHadoopクラスタを利用する立場であり、利用者側の状況もある程度想像がつくだろうということで、運用コスト削減を目的としたチームを組み、自分がそのリーダーという立場になった。率先してリーダーになったというわけではなく、立場を変えることでなにか成長のきっかけが得られないかという試験的な面と、もしもうまくいくならチームとしても嬉しいし、うまくいかなくてもさほどダメージはないといった、わりと消極的な背景から与えられた環境であった。それでも、自分が不甲斐ない働きをすれば自分のチームに配属された人にも悪影響が出てしまうので、やれることをやろうと意気込んで取り組んだ。
6～8年目、リーダーという立場によって今まで経験したことのないタイプの業務を経験した。特にメンバーとのコミュニケーションに関する業務、キャリアについて一緒に考えたり、成長のポイントはなにかを相談したり、今までプロダクトを対象に観察していたが今度はこれが人になった。これが自分はうまくできなかった。チームと言っても用意された人員は自分を含めても3, 4人、決してメンバーが多いわけではない。ひとり若手がいて、他は自分よりも年配のシニアエンジニア。若手とのコミュニケーションでは、仕事へのモチベーションを上げてもらうことに苦労した。コーディングをたくさんして開発がしたいと本人は思っているが、配属されたのはHadoopクラスタという大きな箱の構築と運用がメインのチーム。運用コスト削減のためにツール開発はあるものの、それは若手のモチベーションを大きく引き上げるような仕事ではなかった。程なくしてこの若手は、担当したツールをリリースした後、よりコアな社内ツールの開発をするチームへと自ら志願して異動となった。仕事を通してなにか成長の手助けができたのか今でも疑問が残り、申し訳ないという気持ちもある。
年配のエンジニアのうちひとりは、そもそも運用コスト改善のチームへの配属が、自身のスキルセットに対してあっていないと考えており、この配属に対して不満を示していた。運用コスト改善は主としてツール開発をすることになるのだが、この人のスキルセットは運用に関するスキルが広く、そして深い。異動をしてもらった理由のひとつに開発をしてもらうことでさらにスキルセットを充実させ多様なキャリアを目指せるようにしようという狙いであったが、本人にとってはこれが余計なお世話だった。スタートから関係性が良好ではない状態で「コミュニケーションにおいて、伝え方などを改善するとより評価が上がるのではないか」といった提案をしたときに「コミュニケーションにおいて私に課題があるならもうやりとりはしなくてもよい」と突っぱねられ、しばらくは最低限の業務連絡以外のやり取りを拒まれる状態となってしまった。他の年配のエンジニアの方も、自分より十分にスキルがあるものの、昇給昇進などに興味を示していない人たちだったため、最終的には業務連絡以外の人事的な相談というのは実施しない状態となった。あまりチームとして良い状態とは言えなかったものの、技術の高い人達が集まってはいたので、自分がタスクの細分化とその計画をしっかりと用意すれば、タスクを期限内に消化するということはできていた。アウトプットが出ているだけに「まぁキャリアやモチベーションは本人に委ねなければならない部分もあるか」と割り切った考えもするようになっていた。しかしこのチームが良いチームとも自分から言えない状態だったので、ある程度区切りが良いところでチームを解散することを上司に提案し、自分は再度役職のない状態に戻った。Hadoopクラスタの運用業務を中心とした仕事にしばらくは没頭し、他人の将来を考える必要がないことに少し安堵していたと思う。自分は他人への興味関心が低いのだとこの期間を通して実感した。
8～9年目、上司からこんな2択が投げ込まれた。
「今のチームで続けるか、隣のデータ可視化チームにヘルプとして移るか、どっちがいい？」
隣のチームではGoogleAnalyticsのようなものを内製で用意し、自社の様々なウェブページからログをHadoopクラスタに集め、集計、可視化するといったことをしていた。入社時に自分が配属されたチームと似たようなことをしているが、使用しているソフトウェアなど環境はだいぶ異なるものだった。このチームの特に集計部分の人員が足りておらず運用がきちんとできていないということだった。上司には「どっちでもいいですよ」と回答していた。今のチームで大きな貢献はできないかもしれないが、ベースの技術力が高いチームなので、しがみつき続けることで個人として成長は可能だろうと思っていた。一方で仮にヘルプに入る場合、触れたことのないソフトウェアの知識を得ることができるため、Hadoopに偏ったスキルセットをより広いものにできるかもしれないという期待もあった。どちらも悪くはないだろうと考えてはいたものの、明確にこちらが良いと言えるほどの差はなかった。というよりは自信がないことでどっちに転んでもそこそこの成果しか出せそうにないだろうな、と消極的に考えていた。
隣のチームへの異動が決まった。このチームにとっては待望の助っ人がきてくれたという嬉しさがあったようで、かなり丁寧にもてなされた。この期待が自信のない自分にとっては逆に怖かった。期待を裏切れないというプレッシャーがのしかかってきていた。問題の集計部分について、チームの人にレクチャーを受けながら状態を調べていったところ、とにかくやばかった。使われているソフトウェア(Apache Druid)は本来想定されていない使われ方をしており、ソフトウェアに適さないサーバの選出、集計において必要になるCPU・メモリ・ディスクは無駄に消費されてコストが掛かっている。想像以上にやばかった。とんでもないチームに入ってしまったと後悔した。しかもこれがすでに定常稼働して社内向けとはいえサービスを提供しているというのだから驚愕だった。一回停止して設計からやり直したい、設計した人を殴りたいと思った。データプラットフォームと言われるようなデータを毎日変わらず提供し続ける環境を、動かし続けながら、設計段階で見落とした問題解消のために改善しようと思ったとき、設計時よりも十倍、あるいは十数倍のコストがかかると言われている。まさにそのコストがかかる作業をやらなければならないのだ。こうなった要因として見えてきたのは、設計者が Apache Druid というソフトウェアを使用することを重視して物事を進めたということ。手段が目的となって進められたせいで、本来実現したいことはいびつな形で、かなりコストがかかる状態でなされていた。エンジニアにはこういった事はよくあって、興味のあるツールを知ると使いたくなる傾向があり、他の手段をきちんと検討しない手抜きの設計によって運用のフェーズで多くの人を困らせることになる。チーム内でこれをきちんと指摘する人がいればよかったのだが、設計段階で指摘を受けたという話は聞かれなかったので、チームに対する不信感が芽生え始めていた。
チームの異動に際して、自分には以下の3つのミッションが課せられていた
- 集計環境の改善
- 集計にかかるコストの削減
- 他チームとの関係改善
集計環境の改善、コストの削減は、すでにあるものを動かし続けながらひとつずつ直してくという作業になるのだが、最後の「他チームとの関係改善」というのがまた面倒なものだった。当時集計について担当していた人が、Hadoopクラスタを運用するチーム(自分がもともといたチーム)やプロダクトの関わるチームとのやりとりにおいて、自身のやりたいことが通らない場合に態度が悪くなり、チームとしての印象を悪くしてしまっているという問題があった。これを当の本人はあまり自覚しておらず、なまじ知識や技術があるために同じチームのメンバーは指摘がしづらい(なにか言っても持論を展開して面倒になるので避ける)という状態だった。他チームとの集計に関するコミュニケーションの窓口としてこの人が立ってしまうと関係が改善されないので、代わりに自分が担当するということになった。さらには、問題となっている人にきちんと発言できるのが社歴やスキル的にも自分のみなので、他チームとの関係悪化の要因があなたの話し方にある、というのをどこかで伝えて自覚さなければならなかった(自分がいつまでも窓口になるわけにはいかないため)。これはさすがに上司がやれよと思ったが、理詰めで話してくる相手に対して辛抱強く耐えるコミュニケーションを上司が得意としないため、自分がやらざるを得なかった。
環境の改善、コストの削減、やり始めてみると新しいソフトウェアについての知識を得ることが楽しく、物量はあったもののその分やりがいを感じられるものではあった。集計という大きなしくみ全体を自分に丸投げされたものの、逆に自分のペースでことを運べることができ、同じチームの他のメンバーの作業の影響も受けにくいものだったので、周りを気にする必要もなかった。集計の問題の人物とときおり考え方の違いで議論することはあったが、以前のように泣くほどヒートアップすることはなく、むしろ向こうが「好きにすればいいんじゃないですかね」と話を打ち切るので、言われたとおり好きにやらせてもらった。この人の設計ミスやつたないコミュニケーションの尻拭いを自分がさせられていると考えると気分は良くなかったが、自分のやったことで確実に環境が良くなっていくというのは楽しかった。他チームとの関係改善については、今まで業務で関わった人が多いこともあり、窓口が自分となったときに過去の経緯を聞きつつ「あの人の言うことはさておき実際はこうしたほうがいいよね」というやりとりでだいたいは解消された。問題の人物には「途中で議論を投げ出すと関係性は悪いままだ」ということを議論を投げ出すたびに言い続けたところ、相手の意見を聞く姿勢が少し出てきたように思う。1年ほどかけて Apache Druid を含む使用しているソフトウェアのバージョンアップや集計コストを大幅に削減でき、運用の体制も整い始め、上司からも信頼を得られて昇給もあってと、異動前に想像していたよりは良い状態に持っていくことができ、少し気持ちも上向きになっていた。
9～10年目、上司とチーム体制が突然変わった。以前記事でも書いたが、自称スクラムマスターと新リーダーによってもたらされたチームの変化は、自分にとっては理不尽かつ負担が大きいものであり、チーム内不和を生む要因となった。集計の運用体制を1年かけて作ってきたにもかかわらず、チームのあり方を変えられたことにより、運用体制も一度白紙に戻され、結果としてこの期間の集計に関する運用はほとんど自分が手を動かすことになった。みんなで開発も運用もできるようになろう、と掲げられて体制が変わったのだが、そもそもみんなが運用できる準備ができておらず、準備のための時間もほぼ取られることはなかった。この体制変更はさすがにマズいだろと指摘し代替案の提案もしたが、検討しますと言われただけで行動に移されたことはなかった。他のメンバーはこの状態に対して声を上げることはなく、自分ひとりが騒いでいるような構図となってしまい、チーム内で孤立した。転職を本気で考えた。新しい環境に対して一定の知識を身につけた自分にとって、このチームに居続けることはもはやメリットはなかった。
チームに対しての不信感が高まっているとき、会社内で人員募集の知らせを見つけた。業務内容はAWSを使用したクラウドベースのデータプラットフォームの構築・運用といったもので、自分のデータプラットフォームに関するスキルセットと重なるものがあった。これまで実機(オンプレミス)をベースとした環境での業務経験が多い一方で、世の中ではクラウドベース、サーバレスの環境開発が増えてきているので、どこかでこういった環境を対象とした業務を経験しておきたいと考えていた。まさに自身の成長という点においても、この人員募集の内容はとても魅力的だった。すぐに応募を投げてた。1人しか募集していないというのが不安ではあったものの、こういう人材が世の中に少ないということも知っていたので、たぶんいけるんじゃないかなぁとだいぶ楽観視していた。めちゃくちゃ偉い人との面談で少しやらかしたかなと感じる点はあったものの無事通過。募集がかかってから1ヶ月かからずチームの異動が決定するという異例の早さだった。良縁というのを実感したように思った。異動した後どうなるか次第な部分はまだあるけれど、つらいチームを抜けられる、新しい挑戦ができるということが自身のモチベーションを引き上げた。
そして現在、自分は無事にチーム異動を果たし、新しい環境での仕事ができるようにたくさんの資料を読み進めている最中となる。今これを書いている日が異動して初日なのでまだまだこれからといった状況。前のチームはヘルプで入ったという形だったので、自分ごととしてとらえきれなかったという気持ちも正直あったが今回は違う。上司に当たる人も今回はその名が業界で広く知られている実績をのこし、行動指針について明確な価値基準を明示している人。以前のチームの上司やスクラムマスターのようなことにはならないだろう。チームへの不安を抱くことなく新しいことを学びながらプロダクトの成長に貢献することに没頭できると信じたい。
長々と3パートに分けて振り返ってみたが、気持ちの浮き沈みが激しく、特に下がるときは急降下していっているなと改めて確認した。主たる原因が環境によるものならまぁ仕方ないとも思えるが、リーダーになったときや成果が思うように出せていない時期とかはまだなにかやりようがあったのではないかと思い返すことが何度もある。自信がなくなったのと同時にどこかで、自分にはできないだろうと無理をしないような振る舞いを続けていたものと感じる。仕事に対して真剣に向き合わない結果、良い循環が生まれず気持ちもなかなか上向きにならなかったのだろう。これを繰り返さないためにも、新しい環境では常に考えることを止めず、自分のできる精一杯を出し続けるようにしていきたい。
これを書く当初、データエンジニアとして長くやってきて、データを扱う環境がこうなったよね、みたいな話になるかなと思ったが気持ちの面を思い返すばかりだった。改めてデータ周り、特に大規模なデータを対象にした集計環境について振り返ってみると、最初に属していたチームで実施していた集計と、ヘルプで入ったところで実施していた集計は、使用しているソフトウェアが違うだけでほとんど同じような集計を実施しているというのが個人的には印象深かった。ヘルプで入ったところの集計をみたときに、この集計の問題点は5年以上前に自分が設計したときに抱えた問題点とほぼ同じであることがわかり、同時にソフトウェアがいくら高度なものになったと言ってもみんな同じような課題にぶつかるのかと、集計を担当する部門の進歩の無さに落胆したものだった。データの利活用については会社として早い段階で取り組んではいたものの、おそらく設計当初、集計環境について構築や運用を長く経験した人はこのチームにいなかったのだろう。データの集計を長期に渡り構築・運用することは、精神的にもかなり負担がかかる。自分もHadoopのチームに移ったひとつの要因がこの精神的負担だった。扱うデータは大きくなるが、必要なコストは下げなければならない。運用フェーズに新しく入ってくる人にとってはトラブル対応が主な仕事となってしまい、何かを作りたいというエンジニアが残り続けることはほとんどない。業務委託や契約社員のような外部の人を雇う形でつなぎとめることはできるが、いずれソフトウェアが古くなってきたときに対応ができず、止めざるを得ないだろう。データエンジニアとして長期役割を担える人はとても貴重だと思う。だからこそ自分に当初ヘルプが投げられ、新しいチームでも人が必要になったのかもしれない。この領域で頑張り続けることが自分のデータエンジニアとしての差別化できる可能性なのかもしれない。
ここまですべて読んでくれた人がどれだけいるだろうか。自分の振り返りが主目的なので、読まれることをあまり想定せずに書いており読みにくい部分もあったろうと思う。それでもここまで読んでくれた人にはただただ感謝しかない。こういう10年をみんなはどのように感じるのか聞いてみたい気持ちもあるので、もし筆者と話す機会がある人は、率直な感想を聞かせてもらえると嬉しい。いろんな考え方を知ることで、今後の10年を少しでも良いものにしていきたい。