【ITエンジニア】本に書かれていない開発現場での立ち回り方法

はじめに
本に書かれていない開発現場での立ち振舞い
1. 気をつけたいポイントとして考えられる時間は有限
本に書かれていない考えなくて良い時と考える時の使い分け方
寄付の依頼

はじめに

ITエンジニアがなぜ知識よりも経験が求められのか？

このことについて考える前に、資格が充実しており、技術の先端を行っているはずのIT業界において、もうそろそろ経験にばかり頼り焦点を当て、価値を図るのはやめても良いのではないか？

そのように思ったことをきっかけに
これまで受けてきた面談と自分が採用する場合にどの用に判断するのか？
経験の有無で何を感じてきたかを元に原因について考えてみようと思い出しました。

なぜ未だに知識の差ではなく経験、未経験で判断されるのか？

そのことを考えていて、私は、ある一つの原因に気づきました。

ITの書籍には、基本的な技術の使い方や意味が書かれていますが、

経験から得られる知識は、ほぼ「言語化」されていない。

そもそも経験を言語化するのは、難しいのだろうか？
「本からは知識が得られるが、経験は得られない。経験は、行動から生まれるのだ」
あの有名な科学者のアインシュタインもそのように言われていたようです。

だが、経験談書籍は数多く出版されているので、言語化して本になっていても良いのではないか、
私は、そのように考えます。

これから行動するため人にとって経験の話は、とても価値がある。

昨今、上司が昔話をすることは少なくなりました。自慢話をすることも減りました。その大半はもう二度と使わない経験談だったり、するので不要なのかも知れませんが、
原理原則に基づいた経験も聞けなくなるのは悲しいですね。

ここでは、不変的な知識と経験に焦点を当て、ケースも交えて私の経験談を紹介したいと思っています。居酒屋で上司話す、昔の話や豆知識程度に聞いていただければと思います。

本に書かれていない開発現場での立ち振舞い

まず、初級者が開発の現場に置いて、あなたに期待をしていることは何だと思いますか？

少なくとも開発の技術力ではないのは確かです。
期待していることは、成長やスキルアップです。早くスキルアップをして、一人前になってほしいのです。そのために上司はあなたに時間を割いて、教えるのです。まあこれは容易に想像できることなので、知っていると思います。

ここからは、本にあまり書かれていない補足情報ですが、
実は、新しく入ってきた人は、ほとんどのケースでは、どんなに経験者でも新人扱いとなります。
なぜなら、既に動いているシステムの仕様やコードを知らないからです。
なので、経験者でも１〜３ヶ月は学びの時間と思って、オンボーディングタスクが振られるものです。
その間に仕様の把握やコードの把握をするのです。

ここは伝えておきたい点は、
知らないことをそこまでネガティブに考えなくて良い。大丈夫です。
みんな最初は知らない、だから覚えれば大丈夫。
お給料をもらって学習して覚えたらいいのです。

ただし、全くの初心者と経験者の差として理解のスピードがあります。
ここはどうしても差が出てしまいますので、ご注意ください。
経験者との差が出る部分としては、例えば、予想、予測、言葉の理解あたりですね。

経験者の多くは、なんども分からない場面に遭遇しています。
そのため、これまでに何度も予想・仮説を立ててトライ＆エラーを行ってきています。
ゆえに予想の勘所が良いのです。また調べてトライしてみるということにも慣れています。

そこに差が生まれます。

これを埋めるために意識することは、早い段階から自分で考え、仮説を立てて検索して調べ立証することだと私は考えます。
いつまでも上司に答えをもらうのでなく、自分なりに考えて調べるということに慣れておくと戦力として価値が高いです。

伝えたいことは、
知らないことは誰も分からないので、その時調べて覚えればよいということと自分で考える意識です。

気をつけたいポイントとして考えられる時間は有限

時間は有限です。

いつまでも悩んで調べてよいわけではありません。
その点は、難しい判断になってくると思いますので、回避策を紹介します。

ある仕事を任され分からない場面に遭遇したとします。ここで分からない種類が２つに分けられます。

１つ目、相手の言っていること自体が分からない。

２つ目、相手の言っていることは分かるが方法が分からない。

１つ目の場合は、悩んでも答えは出ません。
上司か周りの方に自分が理解できるレベルまで話を掘り下げてもらいましょう。

２つ目の場合、こちらは方法の話なので、物によってはみんなもわかりません。
そして考えて調べて答え類の話になります。
内容を理解し方法がわからないとおもったあなたは、きっと答えが出せます。

まずは、考えて見ましょう。自分の分かる程度まで問題点を分割することをおすすめします。
一つの処理でも、インプット、アウトプット、その間の処理、DB登録等分けて考えると課題点や問題点がシンプルになります。
ちなみにこの課題点や問題点の分割という点に置いても経験で差が出る部分になります。
自分が分かる分割、他者にとってわかりやすい分割、メリットの大きい分割を意識して、何度もチャレンジすることが経験の差を生み出します。

まずは、課題点や問題点を見極め、自分が分かる分割から始めてみてください。

さて、考え始めたあなたは、
次にいつまで時間を使ってよいか不安になることでしょう。

ちなみによく１０分悩んだら聞きなさいなどという人もいますが、私は違うと思います。
きっとこれを言う人は、説明が面倒なのか、または自分が安心したいだけだと思います。
１０分なんて少し考えていたら、あっという間に経過します。

目安としては、次の報告タイミングまでにはなんらかの答えが出せるようにしておくことですね。
毎朝、毎夕、週１なのかわかりませんが、報告時に相手が納得する答えが出せないのであれば、
悩みすぎなので、報告のタイミングよりさらに前に質問をしたりアクションを取るべきです。

相手が納得する答えは、できるが一番よいですが、できないという結果を突きつけ代替え案を提示したりもします。あとは、進捗としてなんらか結果が出せて、次に進むことができることを指しています。

相手が納得しない答えは、結果として示せるものがなにも無い、何かしら判断できる材料も無い、悩んで終わりました。
これが一番良くないですし、もっと早く相談してくださいと注意を受けるでしょう。

これを回避するためのおすすめの目安を私はこのように考えています。
次に報告までの時間を1/3または1/2消費したあたりで、一度自分の進捗を確認し、報告内容の見通しが見えないようであれば、一旦悩むのを止めて、追加質問をすることをおすすめします。

経験者であれば、4/5くらいの消費まで粘る人もいると思いますが、
最初のうちは、1/3または1/2消費くらいを目安に、「このように考えていて、このように調べているのですが、なかなかわかりません。おしえてください。」みたいに質問をするのがよいでしょう。

自分の考えた内容と調べたことを添えると相手も答えやすいと思いますし、ちゃんと考えたんだなと思ってもらえると思います。何より考えることは一番大切です。

ただし、質問した後に「もうちょっと調べて見て」という回答も往々にしてあります。
このケースは、「まだ考える時間があるので調査する時間を使ってよいですよ。」の意味です。

ここが言語化されたいない非常に難しい振る舞い方の一つなのですが、
私の経験では、開発チームや開発現場によって、調査に使って良い時間にばらつきがあります。

最初は、1/3または1/2消費くらいから質問して、そこから周りに合わせて時間の感覚を調整するようしましょう。私もチームの雰囲気読みや空気読みを今でも行っています。

ちなみにIT業界に入って違和感のあったことの一つですが、検索したり調べることを「調査」と呼びます。ぜひ覚えて帰ってください。

本に書かれていない考えなくて良い時と考える時の使い分け方

あまり考えず答えをもらうことは、目標達成において素早いスピードを発揮します。
使い方や内容によっては、私も考えることを放棄し、答えをもらうこともあります。

物によっては、考えても意味が無い、考えても答えが出ないケースがあります。

私の経験から言うと、調べても出てこないようなシステムやサービス固有の概念、名称、扱い（一般的にドメイン知識と呼ぶ事が多い）の場合、考えるのをやめ質問に徹します。

理由としては、明白です。
仮に仮説が立てられても答えが自分で答えが出せないからです。

この時は、恥ずかしがらずに後ろめたさも持たずに堂々と素直に聞いてしまいましょう！

大体、資料があるので読んでくださいと言われると思います。そしたら、まずは読んでみます。
ほぼ確実に全てを理解することは、無理です。
相手も全て理解してくれるだろうとなんてこれっぽっちも思っていません。
なので、一生懸命に読み込むこともしなくてよいです。概要だけ軽く理解できれば、花丸です。

ここでの考えないメリットは、前述のように目標達成までの素早いスピードです。
逆に考えないデメリットは、知識は増えますが、経験など大した成長が得られません。

ですが、良いのです。
そこでしか使わない固有の概念に対し得る経験など、他で使えませんので未来の自分に取ってさほど必要ありません。素早い目標達成と原理原則の知識に基づき、汎用性のある経験を身につけることに徹します。その方がメリットが自分にも相手にもあります。

考えた方が良いケースとしては、ドメイン知識を除いたエンジニアとしてのシステム構築に関わる部分全般です。

常に考え仮説を立て検証を繰り返し立証する。
このプロセスは、システム開発しいては、他の専門職において不変です。

どの言語を使っても、どこで働いても通用するスキルの一つになります。
ここが経験が重要視されるところの一つとも言えるでしょう。考えるクセを付けさえすれば、
あっという間に不変のスキルを身につけることができるはずです。

ここは、小話ですが、
考える隙を与えない仕事や職種、職場、上司は、成長してやめないように、会社に依存してやめれないように原理原則に基づく不変のスキルを身につけさせないようにしている。と私は考えます。

話はずれますが、工業化に伴い設計と製造、製造も細かく細分化が行われたことは有名ですね。
人々は、労働環境が与えられ紙幣を手にし豊かさを手に入れることができました。

ですが、その細分化された労働は、効率化に伴いほとんどが流れ作業で完結できるようになっています。
そのため、ほとんどの工程を一人でこなす職人と違い、何も考えることのない作業化しました。
考えないで済むのは、とても楽なことですが、職人と違って不変のスキルを身につけることは決してありません。
これは、不変のスキルを身に着けさせずに成長を止めて確実に労働力を確保する仕組みの原型と考えています。

もちろん良い面もあります。労働者のメリットは、安定した仕事とお給料を提供してもらえるところです。考えることが苦手な人や働くことに重きを置かない人にとっては、逆に救いのような仕事とも思います。

ITエンジニアにおいては、同じような構造とそうでない構造の２つの仕事、働き方に分けることができ、更に選択の自由もあります。
同じ職種で選択の自由があるのはとてもすごいことです。

自分が得意とすること、好きな方、幸福度が高い方を選ぶと良いと思います。
すぐ聞いてくれる頼ってくれる部下は可愛いものなので、あまり考えない選択肢も全然ありと思います。

どのように働くと幸福度が高いか、なにに重きを置いているのか
それは、人それぞれなので、正解はその人の中にしかありません。