新しい会社に入って1週間がたった。
今日は入社してあっしが何をやったかアウトプットしておく。
何をしたかを語る前に、ひとつ言っておきたいことがある。
今日は新しい会社に入った人に役に立つ内容にしようと思っているが、
- 新卒入社
- 中途入社
ではやることが変わってくる。
新卒の場合、会社が新人研修を行う。
それは会社が「こうであってほしい」という人物に仕立て上げるイベントだ。
その研修の内容は会社によって大きく違う。
この研修は入社して数週間から数か月続く。
新卒は最初、ひたすらそれをこなしていくだけでいい。
ネットでは、その研修に耐えられなくてもう辞めた人もいるようだが。
あっしの場合は中途なので、新人研修はない。
その会社で働くための基本的な説明はあるが、それ以上はない。
いまの会社も最初の説明は1日ぐらいで終わり、2日目からは開発チームに配属された。
しかし、具体的な指示もないまま1週間が過ぎた。
完全に、放置状態だった。
中途の場合、放置状態だからと言って指示を待っているのはナンセンスである。
中途社員は即戦力を見込まれて雇われている。
すぐ戦力になれるように、自ら率先してそこに向かっていくように動くべきなのだ。
あっしはSIer時代にも放置状態を何度か経験している。
プロジェクトが進行中のときに、新メンバが入ってきたときのフォローの工数は大抵考慮されていない。
考慮されていない以上、構っていると自分のスケジュールが遅れるので、構ってられないのだ。
それでも若い時は、若者に指示を出したがるおせっかいなおじさんエンジニアがいろいろと絡んできて、聞いてもないことまで教えてくれたりしたが、こっちもおじさんになってくると本当に話しかけられなくなる。
だから、放置状態には慣れている。
そのときにいろいろと考えて、やるべきことを見つけていった。
そのおかげで、いまは指示がなくても動けるようになった。
今日はそれを紹介するので、ぜひ参考にしてほしい。
ドキュメントを読み漁る
会社や現場には、これまで積み上げてきた情報資産がある。
それはファイルサーバやクラウド上に蓄積されている。
これを見られる権限は与えられるはずなので、まずはこれを読み漁ろう。
そこであっしは以下のようなものを見るようにしている。
- 組織図、体制図（メンバの名前、役割、上下関係がわかる）
- プロジェクト概要（案件、業務内容の詳細がわかる）
- スケジュール（誰がいつ何をしているかがわかる）
- 成果物（機能一覧、画面一覧、設計図、テスト仕様書）
もし見る権限がない場合は、「ドキュメントを見たいんですが」と最初に言おう。
これが見られるようになるだけで、暇な状況は解消されるはずだ。
業務ツールに触りまくる
いまやメールだけでなく、仕事にはさまざまなITツールが導入されている。
snsであったり、メッセージツールであったり、プロジェクト管理ツールであったり。
ちなみに前職では以下のようなツールを利用していた。
- G Suite（旧google apps）
- salesforce（chatter）
- hipchat
- backlog
- cacoo
これらをいかに使いこなすかも重要になってくる。
はじめて触るものがあれば、どんな機能があるか自分で触って確かめてみよう。
ツールをすでに知っていた場合、実はこれが結構なアドバンテージになる。
以前使っていた時の使い方や運用を新しい現場で教えたり提案することもできるからだ。
あっしも上の半分ぐらい、いまの会社とかぶっているので、運用をチェックしているところだ。
体制を把握する
自分が所属する組織の体制を把握しよう。
これは先に述べた体制図を確認するのが1番いい。
何人ぐらいの組織で、自分がどの位置にいるかを把握できる。
他にもいくつかポイントがある。
まず、自分の仕事の最高責任者は把握しておくべきだ。
会社だと社長、プロジェクトだとプロジェクトマネージャーになる。
その人が指し示す方向に向かって進んでいかねばならない。
それに賛同できなければ、割り切るか、辞めるしかない。
あとは、縦のつながりと横のつながり。
縦とは、自分の直属の上司とそのまた上司、以下同分。
トップまでのルートをざっと確認する。
その線に乗っている人は、自分のことをどうこうできる権限を持っていることを理解しておこう。
横のつながりとは、同僚や仕事仲間をさす。
仕事をすれば自然とわかってくるものだが、事前に知っているにこしたことはない。
同じ立場の人とは、今後いろいろなシーンで重要になってくる。
仕事が始まってなくても、1回はちょっとした会話をして、なじんでおきたいところだ。
あと、自分とは直接関係ない人もざっと確認しよう。
今後自分がその現場でうまくやっていくためには、関係ない人といかにつながりを持つかがとても重要だと考えている。
その理由は、過去に述べているのでここでは省略する。
メンバの役割を把握する
これも体制図である程度確認できるが、明文化されてないものもある。
「これはあいつがやること」となんとなく決まっているものもあるので、人の説明の中で意識して聞いておくようにしよう。
ここでのポイントは、役割と実態は大抵ずれる、ということだ。
役割を担っていてもできてない人はいるし、役割を担っていなくてもやる人もいる。
ここに新参者が飛躍するポイントがある。
役割を担っている人がやらないと、仕事がまわらない。
それで困っている人が、代わりにしかたなくなる、ということが起こる。
それが、役割を担っていなくてもやる人だ。
それは本来、あるべき姿ではない。
役割を担っている人が、責任を持ってやるべきだ。
しかし、その役割が明文化されてない場合、現場レベルで決まった役割を担っている可能性がある。
上に認識されてない役割だと、やるモチベーションがあがらない。
それをやっても認められないからむなしい、と思ってしまうのである。
役割を担っている人がやらないのは、こういう可能性がある。
自分が放置状態になっていたら、そういう浮いている仕事を探そう。
そして自信のあるところから巻き取っていってみよう。
きっと「どうぞどうぞ」ということになる。
巻き取るだけでも、主体的なところをアピールできる。
ただ、そういう作業をやっているということは責任者にはちゃんと伝えておこう。
そうしないと、いずれ自分自身がやっててむなしいと思う日が来る。
自分という会社の人的リソースをそこに割いていることを、会社にわかってもらった上でやることが大事だ。
メンバのスケジュールを確認する
最近はメンバの予定をカレンダー機能で管理することが一般的になった。
誰が何をやっているかは、そこでおおよそ確認できる。
まずはオフィシャルな予定を一通り把握しよう。
特に定例MTGは、確実にメンバの予定に組み込まれている。
自分が参加するものだけでなく、メンバのMTG予定も確認しておこう。
スケジュールの名前には、「●●会議」とか「●●プロジェクト定例MTG」とか「●●へ外出予定」とかになっていることがある。
そこからメンバがどんな立場で、どういう案件を担当していて、担当顧客が何かがわかる。
プロジェクトであれば、スケジュール表があるはずなので、それを見れば、誰が何をしているかは詳細にわかる。
基盤の構築をやっている人は、技術力のあるメンバが担当するもの。
プログラミングや単体テストを担当している人は、比較的若いメンバだったりする。
メンバの力量も、担当タスクで推測可能だ。
今日1日ですべてを書ききろうと思ったが、3000字を超えてしまった。
いったん記事をリリースして、明日続きを書くことにする。
※続きはこちら