emahiro/b.log

Drastically Repeat Yourself !!!!

環境を変えた時に先にしておくといいことをまとめてみた

最初に

※ これは個人的な経験をもとにして記載しました。

Summary

転職したり、異動したりで新しい環境に所属することはエンジニアに取って珍しい話ではありませんが、新しい環境に行った時に先んじて理解しておいた方が良いと思われることをまとめて見ました。

環境編

  1. チュートリアルを読む
  2. トイレの位置を把握する
  3. 勤怠ルールを確認する
  4. New Commer 専用のチャット部屋を作る

エンジニアリング編

  • デプロイルールを覚える
  • デプロイをする

環境編

チュートリアルを読む

ある職場はいい職場だと思います。
異動直後、入社直後のチュートリアルがあると、教えてもらう側も教える側もコスト少なく、必要な情報を伝えることが出来ますし、例えば入っておくべきメーリスや、最低限のslackのチャンネルなどNewCommerが自律的にセットアップできるような仕組みはあるとすごくよいと思いました。

もしない場合は、すぐに作ったほうが良いと思います。

  • エンジニア向け
  • ビジネス向け

など色々種類はあると思いますが、業種分あるのがおそらく理想なのだと思います。

自分もそうですが、NewCommerのころの最初の1ヶ月位は結構緊張して、生産性が上がってこないので、極力、気を使うことを減らしてあげて

トイレの位置を把握する

重要です。できれば個室の個数も数えておくと良いと思います。
入りたてのころはこういう些細なところで体力消耗するので当日に調べておく、できればピークタイムを最初の一週間くらいで覚えておくと良いと思います。

喫煙者の方は喫煙所のある階、及び喫煙ルールとかも調べておくと良いと思います。近頃は禁煙の流れなので、電子タバコしか吸えなかったりとか細かいルールがあると思うので調べておくと良いかもしれません。

勤怠ルールを確認する

重要です。いくら自由な職場だったとしても最低限のルールはあるものだと思うので、そのルールは予め確認しておくといいと思います。
勤怠は同じ会社でもチームによって違ったり、職種によって異なったり、勤怠連絡の仕方とかもメールなのかチャットなのか色々ルールがあると思うので、当たり前ですが入社当日に知っておくべきだと思います。

※ NewCommer向けチュートリアルに書いて有るべきですね。

New Commer 専用のチャット部屋を作る

※ これは実際に運用されているのを見てすごく良い仕組みだと実感しています。こういうことに気づける人材になりたいです。

初日からチャットであれこれ話せる人は(いるかもしれませんが、)まれな人材だと思います。
New Commerである以上、最初の数日は同僚の顔と名前も一致しないし、ましてチャットで話されている内容なんて、まず事業も環境も知らないのにわかるわけがないと思っています。

しかも、雑談チャットとかでもいきなり自分から声をかけるのは難しいと思います。周りは気軽に聞いてねー!みたいなことを言っても、僕もそうですが、初心者がいきなり気軽に話しかけに行けるわけがありません。
結構ストレスです。

なので、予め歓迎用チャンネルとか作って、部署の人、業務で関わる人は先に入っておく。そして、New Commerはそこで色んなことをつぶやきベースで聞いてみて、部署の人はそのつぶやきを拾ってあげる。そういう流れにすると、馴染みやすくなるのではないかなと思います。自己紹介なんかもそこですると良いかなと思いました。

チャットは例え部署のprivateな雑談チャットだとしても、公共の場です。公共の場でいきなり自分の発言をするのは負荷がかかります。そのため、ある程度NewCommerのpersonalな環境を用意してあげて、ゆるふわに色んなことを話せる場を作る、そうするとチャットでの発言がしやすくなって、ひいては仕事の話もしやすくなるのではないかなと思います。

ちなみに、チャンネル名は welcome-XXXX とか tutrial-XXXX とかが良いのではないかなーと思います。対外的にもわかりやすいですし。
※ これは入社時点で予め作ってあるとすごく良いですね。

コミュニケーションは仕事の基本なので、そのコミュニケーションの最初の一歩をどれだけ後押ししてあげられるかがその人が馴染める初速につながっていくと思います。
これによりコミュニケーションが円滑に進み、仕事のスピードに繋がり、ひいては事業スピードに繋がっていくと思うので、この仕組みは本当に良い仕組みだなと思っています。

エンジニア編

エンジニアとしては

  • 開発環境構築
  • システムの理解

など最初にやるべきことはある程度決まっています。

その中で個人的に、ある程度慣れないとやらないことだけど、先にしておくと実はコスパが良いのではないかと思ったのがデプロイ です。

デプロイを先に理解する意図

開発者たるもの、作った機能のコードを書くことだけが仕事ではありません。
リリースして事業に貢献する ことが仕事だと思っています。

そのためリリースをするためのデプロイ権限をエンジニアは持たないといけないと思います。
しかしJOIN当初は当たり前ですが、デプロイ権限はなく、権限を持つ人に依頼することになるのが一般的だと思います。

デプロイ権限を持たないデメリット

リリースが自分以外の誰かに依存してしまうことで幾つか弊害があると感じます。 - リリースするだけなのに、その「誰か」のスケジュールを確認しなければ行けない - 何かバグがあった場合にも切り戻しも依頼しないといけない - つまり、自分以外の誰かに依頼する以上、案件を全て自分でハンドリング出来ない。

デプロイ権限があることのメリット

誰かに依存することがありません。

  • スピード感持ってリリースできる
  • 案件への責任感が生まれる
  • もし仮に問題があっても、実装者である自身が気付けるので、切り戻しが早く行える。

そして何より、自分から進んで案件を拾いにいけると思います。
書いたコードが実際に自分の手で世の中に届けることができる権限を先に渡しておくことで、ずっとスピード感持って開発をしていけるような気がしています。

デプロイを標準化する

デプロイ手順を簡略化、べき等化しておくことは、チームの責任だと思います。
ちょっとしたデプロイでさえ秘伝のタレ化していたり、細かな手順を踏まないと行けなかったりというだけで、開発のモチベーションが削がれます。
誰がしても同じようにデプロイ出来る仕組みを作っておくことは、受け入れチームの責務だと思います。
ある程度揃えておきましょう。

また、権限を取るためのチェック項目や、デプロイ手順もドキュメントにまとめておくと良いと思います。  

デプロイて権限管理等が悉皆されていると後回しになりがちなことだと思います。
ただ、これを早い段階で誰かに依存せずにNewCommer1人で出来るようにしておけば開発がより早く進むと考えています。

デプロイするにあたって

デプロイルールを覚える

Documentや権限付与のための簡単なチェックシートがあるといいですね。
読み終えたら自動的に権限付与、くらい裁量があるとことがスムーズに運ぶと思います。

デプロイする

簡単なチケット等の実装をして、見守られつつも早い段階でデプロイまでしておくと良いかと思います。
最初のデプロイは、冷や汗もんですよね。

僕は異動3ヶ月目くらいでようやくもらってその前後で生産性や仕事へ意識が変わった実感があったので、これは先に経験しておくとよかったなぁと後悔したところだったので記載しました。

まとめ

僕は特にそうですが、新しい環境ってめちゃめちゃ緊張します。
一緒に働く人の顔と名前も定かでない状態でいきなり100%のパフォーマンスは出せません。
NewCommerにできるだけ早く100%の力を出させてあげる、そのための小さな障害やストレスになりそうなものは予め軽減しておくことは会社、受け入れるチームの責任であると思っています。

めんどくさがらずにチュートリアルも歓迎チャンネルも用意しておくときっとNewCommerが馴染むまでの時間を軽減できます。
そしてそれがそのまま事業スピードにつながると思うので、こういうちょっとした気遣いやオーバーヘッドかもしれないことをこなしておくといいです。
最後にトータルで見たときに結果を実感するようなものなので、最初は腰が重いかもですが、ある・なしで本当に異なるなーという実感があります。

個人でもwelcomeチャンネルで即レスしたり、新しく入った方が早く環境に馴染める努力はしていきたい所存です。