新しい現場への異動と初期の立ち回り
こんにちは、シニアソフトウェア エンジニアのリドルです。
こんにちは、リドルソフトウェア エンジニアのひびのです。
このポッドキャストでは、僕たち2人で IT業界のさまざまなリアルを
届けていこうという意思の番組です。
今日のテーマが、新しい現場に入って 最初にやること、いえい。
いえい。
新しい現場、それこそ、これリドルさんには この前、なんか雑談程度に話したんだけど、
別に転職したわけじゃないんですけど、
いわゆる社内転職部署を断して、 いろんな部署支援署に行って、
新しい支援の部署に入って、
リドルさんにさっきそれを話してほしいって 言われたので、話しようかなと思います。
そう。だから別の部署に行ったから、
その時にどういうキャッチアップをしたいとか、 どういうコミュニケーションをしてるんだろうみたいな。
はい。
じゃあ早速、どんなところに入って、 どれくらいの人がいる部署なのか教えてほしいです。
どんなところに入って、これ詳細はすごく言えないんですけど、
グループ会社の一つで、多分社員規模で言うと200人くらい。
まあまあでかいところで。
エンジニアリングのチームも多分、 合計で30人くらいはいるのかな。
もっといるかもしれない。
っていうところで、まあ行ってみたら、
僕はその中でも割とエンジニア人が関わるプロジェクトを手伝ってくれと言われて参画しました。
っていうところが。
このプロジェクトは大体その、よく関わる人数でいいですか?
あ、でも本当にほぼ全員22から32ね。
まあまあね。
まあとはいえ、なんかその規模なので、
なんか僕が入ってから途中で、やっぱり一人一人の進捗が追いづらいから、
チームを4つに分割して、
まあその、大体1チーム5、6人のところで進捗を生み出していこうみたいな感じにも。
で、実際に密に関わる人数で言うと、そこまでは大きくないみたいなところを進めた。
なるほど。
ちなみになんかそのポジションとしてはどういうポジションとしていったんですか?
いや、これは早い。
なんか最初はサーバーエンジニア、ウェブフロントエンジニアとして、
まあその頭数の人として入ってきて、
でまああと僕はその前に支援してた部署で、
あのいわゆるLLMを積極的に、
まあプロダクトに組み込みもしたんですけど、
あのLLMを使って定常業務をより回しやすくしようねみたいなところにも協力していて、
まあできれば現状整備されていない開発の効率化みたいなところもやってくれるみたいな、
まあひとふわっとした方だった記憶がありますね。
それは1メンバーとして入った、そこからって感じなんですか?
はい、1メンバーとして、うん、本当にそうです。
人間関係の構築と業務上のコミュニケーション
他の部署というよりかは他の会社に行くっていう結構な移動具合じゃないですか。
そうすると人間関係の構築とかも結構一からだと思うと、そのあたりは苦労しなかったですか?
人間関係のことか、うーん、それで言うと、
苦労してないやつやん。
いや、でもなんと言うか、どうだろうな、
僕のスタンスとしては、みんなと仲良くなれればそれは理想ではあると思うんですけど、
基本スタンスとしてまず仕事をしに行ったので、
仕事をしに行って、それで一応僕のことをオンボーディにしてくれるマネージの方とかがいるので、
その人越しに何人か、徐々に話したことの人を広げていっている状況ですね。
じゃあ何か特別なことをしたっていうよりかは、仕事上で会話必要なときにどんどん増やしててって感じで、
例えば一緒にご飯を食べに行ったりとか、そういうわけじゃないですか。
そうなんですよね。まあ言ってみたら、それこそ僕の会社って、
なんだろう、ハイブリッドというか、割とオフィスに毎日のように来てる人は毎日来てるし、
ほぼリモートの人はほぼリモートみたいなじゃないですか。
そういう中で、何回かはランチモールに行ったけど、結局メンバー固定されてきちゃいます。
そこからランチ越しに広げられる交流の輪っていう一通りも、何というかできるところまで何回かで達しちゃったなというところもあり。
なるほど。じゃあ一緒に最初は行って、そこである程度は親密になったというか、やったってことですね。
結構ですよね。親密になったっていうとなかなか表現が難しいですけど、
基本スタンスとして、もちろん親密になるは最初に大事だと思うんですけど、
何というか、業務上必要なコミュニケーションはできるべきかなって。
それで言ってみたら、自分のタスクの中でのステークホルダーが必ずないですか。
このタスクをやるときはこの人から次QAサインを確認したりとか、
そうやってステークホルダーを見つけて、自分からメールをして、必要なら必要なコミュニケーションを取っていくことで、
割と現状、プロジェクトに入っていいかいつくらいですけど馴染んできたなっていう感じ。
技術的なキャッチアップとAIの活用
いいですね。ちなみにプロジェクトの中での立ち振る舞いは分かりましたと。
どっちかというと、技術者として今あるものをいろいろ変化させたりとか、新しく作ったりするというところがあると思うんですけど、
そのあたりのキャッチアップはどうですか。
これは、そうだな。なかなか説明しがたいな。ちょっと特殊なんですけど、
今、会社の中で重要だって言われてるプロジェクトがあって、それに探しました。
そのプロジェクトっていうのがちょっと特殊で、
普通に企画が上がっていく施策と開発として進めるようなものとは全く別軸で動いてるんですよ。
それこそどちらかというと、その会社にある定業業務をキャッチアップする。
あとは周辺の技術を広く浅くキャッチアップするというよりは、
基本的に必要な部分だけ深くキャッチアップするところが求められていたので、それを実践してましたね。
最初に本当にざっくりとしたインフラの構成図を読ませてもらったりとか、
あとはもうグッドファーストイシューをいただいてガシガシ手を動かすことでキャッチアップするとか、
自分は元からそのスタイルが一番慣れてるので、そうやってやってましたね。
平野さんは最近結構AI使ってますけど、そのキャッチアップ期間だったりとか調査するタイミングではAI結構使いました?
もうバリバリ使いましたね。それでいうと、その会社で扱ってるプログラミング言語が僕がほとんど触ったことない言語なんですよ。
それもあって、コードはほぼ手で触ることがなくて、AIに任せるコーディングにでは。
で、そうだな。そうだ、AI関連で言うと、さっき乗務の中にAIをインテグレーションしてほしいみたいなふわっとしたような話をしたじゃないですか。
その僕が関わっているプロジェクトで実際に触るシステムが、なんというか、ローカルで動作確認する環境が最初ない状態だったんです。
そうなんですね。それ大変ですね。
とはいえ、昨今、例えば僕らのコンピューターに入ってるクロードコードなりコパイロットなりを使うには、
手元で動作確認する環境を作るAIがコードを改変して、それの挙動を見る。
その中で言われるAI自身が変更をして、自分で新たに起こった問題について直すみたいなフィードバックの仕組みを作れるのが理想だと僕は思っているし、
多分ウェブ上でもだいたいそういう意見が大多数だと思うんですよ。
そうですね。
なので、もちろんメンバーとしてガシガシ手を動かすに並行して、手元で動作確認できるDocker環境を整備しました。
AIで?
はい。そこはAIの力がいっぱいで。
あとそれから、もう一つちょっと特殊なのが、その環境って、その会社のシステムって、
じゃあそのDocker環境をGitHubにコミットすれば全員使えるようになるってわけでもなくて、
そうなんですか?
何と言えば、大量にある似たような開発環境に横展開しなきゃいけないっていう感じ。
なるほど。
僕がやったアプローチとして、もう一つは一回まず動かすDocker環境を作るはそうなんですけど、
そのDocker環境をみんなの開発環境にコマンド一発で展開するシェルスクリプト作ったりとか、
あとはまあ、
なんか、うん?
まあちょっとここなんか結構ぼやかして言ってるんで、
分かりました。
理解しがたいかもしれないんです。それぞれ似たような違うシステムがたくさんある状態ですね。
同じチームの人がそれぞれ別の違うシステムを担当してるから、
バラバラになってる。
エンジニアが30人関わっている、その対象になるシステムのバリエーションがとんでもなく多いっていうのが。
なんかてっきりひみのさん、さっき4人ぐらいのチームに分けてやってましたから、
てっきりその新しいもののチームでやってて、
そこで新しいものについては一個開発環境があれば、
ここ足りるのかなと思うんですけど、
そうじゃなくてもっと広い範囲にコンテナを使ってもらおうっていうことなんですね。
まあもっと広い範囲にコンテナを使う、
あとそれから細かいところで言うと、
そこからいわゆるAWS上にあるステージングDBアクセスし、
しっかりデータを取ってこれるところまでの手順書を書いたりとか、
あと環境下によって微妙にサイがドキュメント通りにやっても動かないようなところは、
もはやAIにこうやって指示するとうまく直してくれるよみたいなプロンクトレイを書いたりとか、
そういうみんなの手元でAIが最大現実力を発揮できるようにする環境制限に注力したりだとか。
いいですね。
ちなみになんですけど、そのAIもともとその現場でも使ってたんですよね。
そうですね。もちろん使われてましたが、
そういういわゆる特殊な理由がまあまあいくつかある状況で、
なかなかAI、僕の目から見ると、
昨今のコーディングエージェントの実力を最大限発揮するのが難しい環境だったっていうのはあります。
じゃあそれを整えていってって感じなんですね。
整えていきました。
AIを活用したナレッジ共有と効率化
あともう一つは、細かいところで言うと、
そのプログラミング言語に精通したベテランエンジニアの方がやっぱりそのチームの複数名いるわけで、
困ったことがあるとスラップにあげるとその人たちが助けてくれるんですけど、
一方で過去に話されてたことをみんな忘れてたりとか、
あとは
ありがちですね。
そうですね。一方で過去に話されてた対処法って割と横にたくさんあるシステムのどれにも適用できるナレッジと一緒なんですよ。
なのでやったこととして、そのスラップで議論された内容をNotion AIに精査させて、
NotionにIPS集みたいなドキュメントを一つ作らせます。
で、それをNotion APIでGitHubにマークダウンファイルとコミットさせます。
で、それをいわゆるスキルズコマンドみたいなやつで手元に持ってこれるようにして、
AIがこれまでに基本されていた内容を踏まえて変更を行えるようにしたりとか。
いいですね。整えてますね。
なんというか、そういうAIを少しずつみんなの手元でさらに賢く動かせるようにする草の根活動みたいなところを給与しましたね。
それってあれですか。先にチーム全体に対してAIの活用環境をこういうふうに整えていきたいみたいな話をしてから、
そういうふうに取り組んだ感じなんですか?
そうですね。もちろん僕から本当に最初それに取り組んだタイミングの出来事で言うと、
スラック上にもっとこうした方がより動きやすくなるのになぁみたいなことを書いたんですよ。
そうしたらオンボーディングしてくださってたので、
じゃあそれやってくれるならやってみてよみたいな感じで頼んでくれた。
よっしゃじゃあ2日で作りますって言って、2日で作って展開したっていう感じですね。
仮にそのタスクをひびのさんが独力でやったらどれくらいかかるんだろうな。
それで言うと本当に、でもなんか例えばAIを使ったときにその動作確認環境で出たエラーログを
コピー&ペーストして元で直してさらにコミックしてプッシュしてみたいなのを何回かやらなきゃいけないんで、
いわゆるAIが手元でやるフィードバックループに自分も大部分参加することになるような感じで、
だいぶ非効率になりますねやっぱり。
まあそうですよね。最近なんか昔の人のよくあるエラーメッセージちゃんと読めん。
すぐグーって答えを貼り付けるんじゃないみたいなやつあり。
最近もうなんかエラーメッセージ貼り付けちゃう。
なかったらAIがいつの間にか解決してくれるから。
そうですね。
もうあんまり読まなくなってる。
いや本当に賢くなりました。AI素晴らしいですね。
いやでも考える力が持ってかれてる気がする。
まあ確かに、でも一方でその作業としてって思ったのは細かいエラーメッセージを読んでどうすればいいを判断できるのは一番いいんですけど、
なんというかそれよりはもっと抽象的な、そのAIがやる解決方法が本当に適切なのかとか、
それで本当に他の懸念ないんだっけとか、こう判断するのがむしろ今人間がやるべき仕事だと思うし、
今後もある、次回将来、今後数年くらいはまだそういう状況が続くんじゃないかなとはなんとなく思いますね。
確かにそういう判断って実際に運用したりとか失敗しないと詰めないから。
そうですね。僕もエンジニアとして4,5年やってきたからその嗅覚とかなんとなくこうした方がいいとか、
あと一般的なシステム全体の構成がこうだからこうした方がいいとかわかるけど、今会社に入ってくる人大変でしょうね。
新しい現場でのアピールと質問の仕方
そうですね。ただそんな感じで最初に期待された分野で、前回の職場で、職場ってか現場で培ったAI系のところを新しい現場に適用して、
まず自分の居場所というか、こういう人ですよみたいな、やれますよ自分はみたいなのをずっと宣伝していたというか、
アピールしていたというような感じですね。見え方としては。
あとなんかプロジェクトに新しく入ったばっかりの立場って本当に何と言うか、初歩的な質問めちゃめちゃしやすい立場だなとは思いますね。
まあ確かにね。
ここどうなってるんですか。なんか、あの、まあもちろんすぐ聞くの、なんか自分から、自分で全く調べずに聞くのは良くないけど、ここどうなってるんですか。
ここ、ここまで確認したんですけどわからなかったレースくらいまで書けばみんな結構心よく答えてくれるじゃないですか。
そうですね。
まあそういう意味では新しい現場に入ってやること、とにかく質問投げるじゃないですか。
逆になんか気をつけてたこと他にあります?
初期の行動原則とプルリクエストの質
気をつけてたことか。
マイナスを減らすって意味ですね。さっきのすぐに質問を投げるんじゃなくて、ある程度自分なりに考えていくからと思うんですけど。
それで言うと、その僕が新しくドッカードにしてみんなで使えるようにしませんかって提案したのが、入って1週間、月曜日に現場に入って金曜日に提案したんですよ。
はいはい。
で、なんかそれが採用されちゃって、僕が音頭取らなきゃいけなくなったから、なんというかスラックでガンガンアクティブにするように、そこからアクティブに発言するようになったんですけど、
なんというかそれまではやっぱり新しい現場なんで、まずタスクをなんというか黙々とこなして、みんなから信頼を得るところが大切だなって思って、
割と素直に意見せずになんか最初の1週間はやろうとしてましたね。
借りてきた猫冗談ね。
それは注意してたことですか?あんまりこう言わずに。
なんか非効率だと思ったことでも、一旦教えてもらった手順に従ってやってみるとかは本当に最初は意識してました。
まあそれによってやっぱり見えてきた問題の解決策っていうのが、そのさっき話してた件だった。
それはそれで一番最初に意識しても良かったというのがありますね。
なんかよくあるやつでちょっと別なんですけど、最初に作るプルリクエストの質をちょっと気をつけないといけないな。
まあ確かに。
特に気にしなかったですか?
そうですね。最初に作るプルリクか。ちょっとそれはノーコメントにさせてください。
というのも、すごく作業環境としても作業としてもまあまあ独自なので、これ以上言うと知り合いが聞いたらあれやんけって思うかもしれないんで。
OKっす。
まとめとAIによるソースコードリーディング
まあまあまあ。
はい。じゃあまとめ。
まとめると、ひみのさんが最近違う職場に移動しました。そこでまあ最初に猫をかぶってましたと。
まあ最初に猫をかぶるっていうか、やっぱりでも最初になんというか、正論を押し付けずにまずはその環境の流れで一回やってみるは本当に大事なんじゃないですかね。
それは向こうの心情的にも。
確かにね。
あとは信頼者として問題を改めて見つけるか。まずそれは大事。
環境構築とか苦労しなかったですか?
環境構築は、これもノーコメントにされたから全然苦労はしませんでした。
むしろドッカー環境の構築はまあまあ苦労はしましたけど、でも蓋で終わったっていう感じで力を借りて。
いえいえ、さまざまですね。
あのね、昨今なら手元のコーディングAIがGitHubの一周全部読んでくれるじゃないですか。
過去のプルリクエスト。なんかそういう意味では割とAIとの対話でなんか解決することも結構あるんじゃないですかね。
確かにソースコードリーディングとか特に県庁ですね。
特に知らない言語だと特に。
いやわかりますよ。本当になんか。
そうか、それで言うとまだ全然2、3年前くらいなら新しいプロジェクトに入ったらとりあえずまずアーキテクチャーなんとなく理解して、その後詳細なソースコード読んでとか最初にやろうとしてましたけど、
今回のプロジェクトとか1年前に入ったプロジェクトの時点でももうそれ全くやってなかったしね。AIに聞けばわかるし。
そうですよね。しかもなんか古いドキュメントに当たっちゃう可能性も考えると最新のリポジトリ見てね、AIに解釈させるのは屈辱ですもんね。
そうなんです。いい意味でドキュメントに頼らずというか行動性としてのわかりやすいフォーマットで出してくれるようになったのは、
てかですね、だいたいこういう現場のドキュメントって何ていうか更新されないまま置いてあってみんなを混乱させるものになりがちじゃないですか。
まあじゃあそんな感じで、最初はおとなしくして問題点とか見つけだし、1週間後ぐらいから自分の得意分野を絡めてパフォーマンスを張っていくと、
新しい現場での立ち回り方と今後の展望
周りとの信頼とかわかっていくということですね。ありがとうございます。
だと思います。
うまく立ち回りましたね。
まあまあそうなのかな。そうだといいですね。
素晴らしい素晴らしい。じゃあ次どうした時も頑張ってください。
まあそうですね、僕は今の会社では色々なところに派遣されて成果を出して帰っていく便利な立場なので、この経験を生かして次も次の現場があったら頑張れるといいですね。
じゃあこのポーズキャストを聞いてくれる方はひめのさんをね、いろんな現場に招集してあげてください。影持ちOKです。
これなんか僕らの会社の人もまあまあそこそこ聞いてますもんね。
ひめのさん招集してください。よろしくお願いします。
まあ興味があれば僕の状況の人をDMしてあげてください。
僕のスラックのプロフィール見て、ちょっと下にスクロールしたら誰のグループか出てくるんで。
このポッドキャストはハッシュタグリアリティで皆様からの感想やコメント募集しております。またチャンネルの概要欄にありますGoogleフォームのリンクからもご投稿可能です。ありがとうございました。
ありがとうございました。