どういう人がITエンジニアに向くか？
ITエンジニアに限らず、エンジニアという職は時に過酷だと思うときがあります。
それは、機械にしろソフトウエアにしろ、100%期待通りに動かなければ完成とは言えないからです。そして、100%に仕上げる道のりが決して楽ではないからです。
プログラムであれば実質的にバグがゼロでないといけません。
※「実質的に」と付けているのは、バグがゼロの状態にすることはとても難しいですが、仮にバグをすべて修正できなくても、めったに起きないなど現状の使い方では「実質」問題がないと判断しバグが残るけどよしとすることがありますので、その状態のことを言っています。
バグの原因を追いかけて、確実にそのバグだけを修正する必要があります。
直し方によっては、そのバグは直るけれども、別のバグを誘発することもあるからです。
プログラムを例にしましたが、ITエンジニアが仕事で対象にするものの多くは、「バグがゼロ」を目指さなければいけません。
そのためには、仕様書を間違いなく書き、隅から隅までプログラムし、緻密にテストし、問題があれば緻密にその問題を解消していくことが欠かせません。
そういうことをいとわない人、つまり、問題を理詰めで考えられるタイプの人が向いています。
少し具体例で作業を見ていきましょう。
理詰めで考えるとは？
理詰めで考える能力というのはどういうことでしょうか？
ITエンジニアの仕事の中で、例えば計画を立てることが求められたとき、「だいたいこのぐらいでできそう」という感覚で計画を出すことがありがちです。
計画のレベルによっては、そのざっくり感が重要な場面もありますが、より詳細な計画を耐えてるためには、作業に分解して正当な理由のある計画を立てないといけません。
仕様を理解するのに何日、仕様書を書くのに何日、設計に何日、コーディングとデバッグに何日、といった具合です。
僕の経験でも、ざっくりと出した計画はだいたい遅れます。自分が「このくらいでできるだろう」と思った期間はほぼ100％外れてました。
なぜかというと、作業を積み上げて書いていないからです。
それぞれの工程の日数を出すにも、こういうドキュメントをこのくらいの量を書かないといけないからどのくらいかかりそうだ、という積み上げで出す必要があります。
ところがそれができないのです。なぜでしょうか？
自分のスピードがわかっていない
見積がざっくりでいつも遅れる人は、何が原因かというと「自分の仕事の速度をわかっていない」からです。
コーディングスピードだとか、仕様書を書くスピードなど、1日にどのくらいの量を書けるか？をベースにして見積をしないといけないのですが、そもそも自分がどのくらいのスピードで仕事ができるかをわかっていないのです。
かくいう僕もそんなこと全くわかっていませんでした。
ざっくり「2週間かな」と出して、大幅遅れもいいところでした。
まずは自分の純粋な速度を知る必要があります。
仕様書を書くスピードやプログラミングするスピードです。
1時間当たりあるいは1日あたりどのくらい書けるかというような基準です。
ところが、自分のスピードというのは、単純に「自分の作業速度」にはなりません。
なぜなら、会社にいれば他の仕事も入ってきて、1日のすべての時間をその仕事に使えるわけではないからです。
そういった、週に固定で行われる会議などの時間を差し引き、1日辺りどのくらいのスピードで仕事をこなしているかが重要です。
最初は難しくても、2回3回繰り返すと、だいたいこのくらいで終わらせられるな、というのがわかってきます。
そうすると「だいたい2週間」という見積の精度も確からしくなってくるというものです。
そんなことを自然と考えてできるようになる必要があります。
バグの原因を突き詰める
なかなか直らないバグがあったのに「特に何もしていないけれど出なくなった」という状態が起きることがあります。
担当者としては、難しいバグが1つ発生しなくなったので単純に「うれしい」気持ちではあるのですが、これは多くの場合ぬか喜びとなります。
というのは、バグはあるときでなくなっても、全く別のタイミングで再度発生するようになることがあるからです。
たとえ、発生しなくなった場合でも、発生するバージョンに戻して発生の原因を突き止めておくことが、その後の再発を予防する上で欠かせません。
市場に出そうとする前の最終テストや市場に出てからお客さんが利用しているときに起きると問題はとても大きくなってしまいます。
ですので、こういうバグが起きたときに「ラッキー」と思わず、原因を探る地道さが必要です。
仕様書の機能をもれなく書く
ITエンジニアが関わる仕様書とは、相当に精密さが求められます。
UIの動作を記述するのであれば、絵で描くUIのパーツを正しく存在させないといけませんし、このボタンを押したらどうなるということを正確に書かなければいけないのが仕様書です。
仕様書を見た人から、
「仕様書に書いてある取り消しボタンってどこにありますか？」と聞かれ、
「取り消しボタンは機能の名前がキャンセルに変わったんだよ、わかるよね？」
と言い返す仕様書作成担当者。
確かに「取り消し」が「キャンセル」になっても想像はできますね。
だけど、「プロパティ」が「詳細」という名称になっている場合など、簡単には同じ機能のボタンとは言えませんね。
あるいは、「キャンセル」ボタンを押したときの動作として「本当にキャンセルしますか？」と確認する仕様になったのだとすれば、それを正しく反映する必要があります。
仕様書は例に過ぎませんが、「正しく書く」「変わったら反映する」という地味な作業をきちんとできることが必要になります。
能力は上げられる
上に書いたようなことができなければITエンジニアになれないのかというとそういうわけではありません。
僕だって最初はできなかったけれど、少しずつできるようになっていったのです。
最初はボロボロで見積とは名ばかりでしたし、仕様書も間違いだらけであちこちから指摘されていたのです。思い出しても恥ずかしい･･･
ITエンジニアでなくても、それが経理であろうと営業であろうと、最初はできないことがあっても徐々にできるようになっていきます。
その仕事に向くか向かないかはその職種ごとにやるべき仕事を喜んでやれるかということになります。
外に出て知らない会社に営業に行くのがいやな人が営業になれないように、毎日パソコンに向かって黙々と作業するなんてできない人であれば、ITエンジニアは難しいかもしれません。
ITエンジニアの仕事を喜んでやれるか？、その基準で判断してみください。