1 minute read

大前提

私の働く環境は一昔前で言うところの特定派遣のエンジニアです。
正社員で会社に入り、その入社した会社から別の会社へ派遣されます。
打ち合わせという名前の面談を行って行く感じになります。

なぜこれを書くか?

できなくはないが、新人っぽい人に色々質問されたので、答えていったわけだが、エンジニアである以上気にし続けるといいことがあるよという話をしました。
こういう話は新人のときは知っておくとためになるかもと思い、書くことにしました。

気にしておくこと

仕事をする上で大事なことをとりあえず列挙する。
- 公式およびローカルのドキュメントをしっかり見ろ - 何がわからないかわからないという状態にならないように立ち回れ - そこになにかの意図や理由があるものだと思え - データや処理においてフローをしっかり考え、意識しろ - スケジュールは少し余裕に見積もれ - パソコンのスペックはとても大事 - 自分で作成するドキュメントは相手に見せるものではなく相手を説得するもの - 対応する際は原因と理由を知ってからやれ - 見積もりを出す際は1つでもクリアできる実績ありきでやるべきである - 検証を行う際は少なくとも2つ以上実装や案をだしてから判断しろ - ドキュメントがバラバラにあることにより思考がまとまらないときはエクセルに全部コピーアンドペーストして思考をまとめろ - 勉強のためにプログラムを学ぶときはできるだけ思想が似ていない言語を学べ - なにかを評価する場合は絶対評価と相対評価があるが、多くの場合は相対評価の方が有用だったりする

とりあえず列挙しているが、下記で説明していく。

公式およびローカルのドキュメントをしっかり見ろ

社会に出るとこれができていないやつが多すぎる。
ちなみに発言馬鹿っぽいけどこれをしっかりやるやつは発言に騙されるな。優秀だったりするぞ。
そもそもサラッとドキュメントを見ました、説明も聞きましたという状況下で何がわからないのかわからないのは論外。
そうならないためにせめてローカル化で運用されるドキュメントを理解するべき。
そのため自分でドキュメントを書く場合には5年後の自分が見て意味不明にならないレベル感で書くことを心がけると後々幸せになれるかもしれない。

何がわからないかわからないという状態にならないように立ち回れ

意外とこれになる人が多い。
これの問題は2つあり、具体的な作業、確認、調査についてのイメージができていないか、相手が根本的に説明が抜けている場合が多い。
第三者が聞いて、説明は上から下までしっかりやっているのにどうすればいいのかわからないのは、論外だと思うべし。
そうならないために下調べや、わからない部分を先に抽出しておいたり、作るフローを意識して置かなければならない。
これには想像力と立ち回りだけで回避可能なはずなので、そういった対応を心がけよう。
技術レベルが上がれば上がるほど妄想力が強化されるはずだ。

そこになにかの意図や理由があるものだと思え

よほどの馬鹿が作ったものでなければ、だいたいコードやドキュメントで理由のないものは存在しない。
昔コーディングが変なやつに、世の中のすべてに意味と意図があるから、ムダや無意味なものはないものとして捉えろって説明したことがある。
この説明をした人は次の新人にも似たことを言ってて笑った記憶がある。
新人のときは手の付け所から不明なものだが、やることとできることを1つづつ増やしていけばよく、何かの意図や意思を感じ取れさえすれば、そこに意味があるのでだいたいの対応ができるようになる。
ただし、ときどき思惑がないことをするやつがいるので、そういったやつには近づかないか、後々面倒になる可能性がある。 なのでその情報をメモしておくと「未来の自分が」救われることがある。

データや処理のフローをしっかり考え、意識しろ

世の中にはフローを考慮しない人がいる。
よくある話だが、子機能を作り込んでいった結果、その機能への遷移する動線が存在しないなんてことが起きたりする。
そのため、データだったり処理だったりのフローはとても大事で、ドキュメント関連を見る場合でも重宝したりする。
処理フローの意識ができない人は必ずどこかで破綻したものを作ってしまう。
そのためフローはとても大事だから意識続ける必要がある。

スケジュールは少し余裕に見積もれ

ある程度経験を積むとスケジュールを考察や調べるすることでおおよその時間的な見積もりを出すことが仕事柄増える。
ところが、なぜかこの見積もりをギリギリに設定する人がいる。
大体それをやる人は仕事ができないか、仕事はできるが残業しまくるかになる。
理由はシンプルに見積もりを出した時間で終わらなかったり、見積もった作業以上にやる必要があるからそうなる。
解決方法はかんたんで、見積もりを出したあといくつかの余分な仕事や作業を考慮して数日増やせば良い。
これをするだけで、スケジュールが伸び、働き方改革に引っかかることもなくなる。
残業をしなくて良くなり、上司の依頼や要望による追加の仕事分やスケジュールの短期化依頼がある場合のみの残業となる。
仕事は人生ではないので、こうあるべきだと思う。

パソコンのスペックはとても大事

さまざまな現場を経験した結果、パソコンのスペックに注視しない人が一定数いる。
仕事なのだから決まったスペックでなければならないとか、仕事ができるやつは道具の良し悪しは関係ないみたいに思っているやつが多い。
そしてこれがすごく問題に思う。
開発環境なのに低性能でディスプレイが低性能だったりメモリやCPUが悪かったりするとそれだけで試行回数が減ってしまう。
もちろんハイエンドが良いがここで言うハイエンドは最高性能を指すわけではなく、メモリは少なくとも潤沢であれなどのそういう意味である。
大手系に行くと5年前はもっと性能が低かったから今の人は恵まれているみたいな言い回しをしてるやつがいるが、そもそもの話では今も昔も結局恵まれていない人ばっかなわけだ。
世の中の必要なスペックなどは都度都度変わるのだから、やりたいことを十二分に満たせる環境を少なくとも用意するべきではなかろうか。

自分で作成するドキュメントは相手に見せるものではなく相手を説得するもの

よくパワーポイントの資料でこれをやりましただけを報告する資料にする人がいる。
その人が優秀かはおいておき、これは大体の場合突っ込まれてこじれることがある。
パワーポイントだけでなくオフィス系の資料を自分用なのか相手にも見せるようなのかでそのあたりの扱いは大きく変わってくる。
自分用の場合は報告ではなく情報の列挙で良いが、他人に見せる場合はその相手にまとまった情報を見せることと現状の目的通り進んでいるのかがわかるようにするとより良い資料になる。
だからこそ一言で言い表すと相手を説得するドキュメントにするべしということになる。
私の場合は自分用にまとめていた資料があり、自分用に列挙しているだけなので情報が何1つまとまっていないので見せられないです。といってまとめるのを待ってもらおうとしたことがあるが、その時まとまっていなくても良いのでその資料で説明してくださいと言われたが、その時はなぜか意味がわからないなど言われたことがある。
つまりは自分用のを安易に見せてしまったことによる大失敗である。
上司などはこういったことをおうおうにするものなので、そういったことをされる可能性があるのだと思って挑むべきである。

対応する際は原因と理由を知ってからやれ

上司とは身勝手なものである。
そのため、部下はいつも対応する原因と理由を知った上でさまざまな調査や作業を行わなければならない。
社会人になると最初は作業を振られることが多くなると思うが、その作業を言われるままだけ行っているとある程度期間が経つと言われたことしかできないと言われるようになる。
この事象が起きるのは単純に情報連携不足によるところなわけだが、部下は知らないことを聞くことはできないし、上司は知ってて当然だと思って行動するので収集がつかなくなる。
上司の意図ではこういう場合はこういう作業を行い、こういった問題はこれくらいのスケジュール感で対応できるかを検討して相談を行ったのちに実作業を行ってほしいなどの思惑がある。
ところがだいたいの上司は作業内容くらいしか部下に伝えないので、部下側からなぜやるのかなどを聞いて、さらに相談などを部下から行わなければならない。
上司にそれを行ったところでだいたいが忙しいからなどを言い訳にするので、こういった問題は部下側がある程度想定して行えることが最良であり、それが自然とできる人間が優秀と言われるようになる。
そもそもこういったことを学校でちゃんとやれよという話なのだが、大体はこういったことを学ぶのは社会でもみくしゃにされてからである。
だからこそ優秀だろうと優秀でなかろうが人材不足になるのだが・・・。
さらに厄介なのがこういったことはアルバイトや色々遊びまくっている、いわゆる学校目線では優秀ではない人間側にできることが多いので遊び人風の人間のほうが重宝されたりする。
ついでに補足すると、学校目線で優秀な人間たちのなかでさらに優秀な一握りの人間は勝手にそのあたりを行えたりするので厄介なのである。

見積もりを出す際は1つでもクリアできる実績ありきでやるべきである

意外と多いのが、ある問題があり、それについて調べた結果できると解説していたWEBページを見ただけでできると思いこみ、作業のスケジュールを出す人がいる。
これが結構問題になることがある点に注意が必要だ。
なにが問題になるかというと、バージョンや環境が異なる場合、さらには使用しているライブラリやフレームワークが異なることにより使えない場合がある。
それだけではなくフレームワーク内でも、小規模向けと大規模向けで異なる記述方法を採用していたりして、そのまま転用できないことが世の中には多々存在する。
そのため実際に自分の環境下で行えるのか、行うためにはどういった作業が必要なのかを一度実施してみて、その作業により見積もりを出すべきである。

検証を行う際は少なくとも2つ以上実装や案をだしてから判断しろ

前項と少しかぶるが、調査依頼を受けて実際に調査を行い、さらには実験を行わなければならないことが出てくる。
このときに1つの案だけだと、想像していない問題にたいしてツッコミを受けると対処しきれないことが出てくる。
これに対応するため、2つ以上の対応案や実験を行い、それらを主観と相対的視点において評価を行った上で発表やレビュー依頼を受けたほうが良い。
そうすると1つ目がだめでも2つ目が、2つ目がだめでも2つ目をもとに1つ目のアイデアを入れた対応が行えるなどが起きることがある。
なので、なにかを調べたりする場合、1つだけではなく2つ以上の案を出せるような調べ方をすることが好ましい。

ドキュメントがバラバラにあることにより思考がまとまらないときはエクセルに全部コピーアンドペーストして思考をまとめろ

現場に入ると、インターフェイスはここ、マニュアルはここ、API定義書はここ、旧仕様はここ、新アルゴリズムはここ、DB仕様はここのように見なければならないドキュメントがバラバラに配置されていることがある。
この場合ディスプレイがいくら広くても4つ以上の資料を併用することは殆ほとんどの場合できない。
なぜなら大体の人間はそこまで頭がよくないからである。(ときどきそれを平然と行う人がいるが。)

なので、そういった場合はスクリーンショットレベルでもよいので、1つのエクセルなどに全列挙すると意外と頭の整理ができたりするので、オススメだ。

勉強のためにプログラムを学ぶときはできるだけ思想が似ていない言語を学べ

よくスキルアップのためといいつつ、関連するプログラミング言語を学ぼうとする人がいる。
たとえばPerlを行ったあとにPHPや、JavaScriptのあとにTypeScriptなどがそれにあたる。
PHPをやったのであれば、JavaScriptやC#のような使い所が異なる言語を学んだほうが多くの場合、より良い経験になることがあるので、もし何かの言語を学ぼうと思っているときには注意すると短い時間でよりよい経験になると思う。

## なにかを評価する場合は絶対評価と相対評価があるが、多くの場合は相対評価の方が有用だったりする 処理時間やアルゴリズムのなどにおいて、何かを評価しなければならないことが一定数出てきたりする。
その場合、絶対評価と相対評価があることを知っておくと判断しやすいことがある。
絶対評価はある条件を満たしている限り一定の水準を担保するという評価軸がある場合に用いられるが、これには論理的な穴を見落とすある場合が多いので気をつけよう。
相対評価は逆に今まではこれだったが、新しいものはこの程度早くなるなど、旧モデルやプロトタイプを引き合いにだして評価することを指す。
これの良いところは、前のものがとても悪い場合であってもそこを解決できるといえるし、悪くなかったとしても性能が上がっているような表し方ができるからだ。

色々書いてみて

本書は社会人に出る人、出た人、出られないひとなどいると思うがそういった人に向けたメモ書きである。
1%でも良いものだと判断できればシェアなどをして上司や部下に説明にでも使ってみてほしい。
そのうち追記するかもしれないし、追加を別のページで作るかもしれない。

comments powered by Disqus