ベテランエンジニアが語る! 20代、30代で身に着けておくべき基本

キャリア・人材

技術解説

連載 [第8回] :

時代や環境に左右されない、ITエンジニアの生き方・働き方・学び方

2021年4月15日(木)

松川秀毅

はじめに

仕事の向き不向きに関して、個人の性格によるものが大きいと言われていますが、持って生まれた性格を抜きにして「特性」や「○○力」を身に着けておけば、「様々な企業から重宝される人物像」に近づくことができます。

今回は、20代、30代のエンジニアが身に着けておくべき、基本的な知識を紹介します。なお、今回の内容は起業・独立しているエンジニアではなく、企業に属するエンジニアを対象としています。

仕事をする上で切っても切れない関係にある言葉として、「ミッション」と「モチベーション」があります。ここでは、それぞれを下記のように分類してみます。

ミッション＝「与えられた仕事」＝「受動的」
「モチベーション」＝「自分が掲げた目的」＝「能動的」

企業に属する場合は「ミッションに対してどのようにアプローチしていくか」が重要となります。また、仕事をする上で「PDCA(計画(Plan)→実務(Do)→確認(Check)→対処(Action)」のサイクルを回すことは大切です。ここでは、まずPDCAの1つひとつの項目ごとにポイントを解説していきます。

PDCAにおける
各アプローチのポイント

(1)計画(Plan)

会社から依頼されたミッションは、積極的に受けるようにしましょう。ただし、すぐに受けるのではなく、まずは「自分でできるか」を検討した上で、保持している技術や知見、期限などを鑑み、自分に不足している部分を明確にします。

社内で不足部分をどうすれば解消できるかを相談することで、ミッションを進めるうえで周りからアドバイスや協力を得られるかもしれません。

また、業務の依頼に対する回答として、どのような計画にするのかを記載します。

算出方法

現在のミッションがどのくらいの期間で依頼されているものかを確認します。例えば、1日8時間で5日間の場合は、

8(時間) × 5(日) ＝ 40(時間)

となります。次に、依頼されようとしているミッションがどのくらいの時間がかかるのかを算出します。算出するために必要なものは、依頼された情報や個人的な知見、技術です。

＜情報＞

インプットされた情報が豊富でアウトプットも明確
インプットされた情報が豊富だがアウトプットが不明確
インプットされた情報が乏しくアウトプットが明確
インプットされた情報が乏しくアウトプットも不明確

＜個人的な知見、技術＞

熟知している
経験あり
知見あり
聞いたことがない
最新技術

基準値

一般的に、依頼内容に対して妥当な依頼期間だと判断できれば、目安となる基準値(係数)を期間に掛けます(※下図の係数はあくまでも個人的な見解なため、ご参考まで)。

例えば、依頼内容を「熟知」しており、依頼された情報が「インプットされた情報が豊富でアウトプットも明確」な上、依頼期間が2週間の際は、5日間でミッション完了の予定となります。

2週間(8時間×10日＝80時間) × 係数0.5 ＝ 40時間

組み立て

依頼期間が現在のミッションに重なるような場合は、1日あたりに実施する時間を算出します。1日の作業時間を最大12時間とすると、

現在のミッションに利用する時間：1日(8時間)
新たに依頼されたミッションに利用する時間：半日(4時間)
12時間－ 8時間＝ 4時間

新たに依頼されたミッションの期限が2週間とすると、

40時間 / 4時間 ＝ 10(日) ＝ 2週間

上記を踏まえ、依頼者に「現在のタスクを継続しながらですと、新規タスクは1日最大4時間しか割けないので、2週間掛かります」と返答します。

仮に、依頼自体が「インプットされた情報が乏しくアウトプットも不明確」で、依頼されたエンジニアは依頼内容を「熟知」しており、依頼期間が2週間の場合は、5日間でミッション完了の予定となります。

2週間 (8時間 × 10日＝ 80時間) × 係数1.0 ＝ 80時間
80時間 / 4時間 ＝ 20(日) ＝ 4週間

上記を踏まえ、依頼者に「現在のタスクを継続しながらですと、新規タスクには1日最大4時間しか割けないので、4週間は掛かります。2週間で仕上げるには、同レベル(同じスキルを持つ)の人材が2名必要となります」と返答します。

(2)実施(Do)

いよいよ依頼を受け、ミッションを開始します。設計書の作成やプログラムを組んでいきましょう。注意点は、常に「アウトプットをイメージしながら」行うように心掛けることです。

進捗

プロジェクトの一員として進捗報告の場があると思いますが、「嘘をつかないこと」を大前提に報告を行います。スケジュールが遅延している場合は「順調です」と報告せず、アラートを上げましょう。1つの嘘がプロジェクトに大きく影響する可能性があります。

進捗報告は依頼者の意図との食い違いを調整する場でもありますが、会話が長引きそうな場合は他の進捗の報告に影響が出るので、改めて打ち合わせの時間を設けることをお勧めします。この調整報告は期限の長短に関係なく、都度実施することが望ましいです。

＜短期間で依頼された場合＞
要求されるアウトプットに沿わなくても、比較的短時間で修復可能ですが、期限を過ぎることに変わりはありません。

＜長期間で依頼された場合＞
もし期間の後半になって食い違いが発覚するとリカバリーが長期間に及ぶ恐れがあるので、発覚する時期とリカバリー期間は比例することを頭に入れておく必要があります。

証跡

進捗や打ち合わせの際に、メモレベルで良いので会話の内容を記録し、メールやストレージ上で共有することを習慣付けましょう。自己の振り返りやトラブルが発生してしまったときの対応にも役立ちます。

品質

設計書に設計範囲外の項目が追加されていたり、組んだプログラムが仕様通りに動作しなかったりすることを極力避けるため、自己レビューを実施することで品質を維持します。

＜自己レビューの観点＞

イメージ通りのアウトプットになっているか
今までの打ち合わせで上がった課題が取り込まれているか(解消されている)
記載した内容やロジックに納得(腹落ち)しているか
※文書の体裁やコーディングルールに従っているかの確認は基本中の基本なため割愛

生産性

自己レビューにより品質が向上するため、レビューまでの生産性は落ちることもありますが、トータルで見るとレビュー時の指摘が減り、結果的に生産性向上(工数減)が見込まれます。

(3)確認(Check)

レビューの際に心掛けることは、レビューイ(ミッションを依頼された側)が主体性を持ち、レビュアー(ミッションの依頼者)に敬意を表しながら、レビュー対象の資料やソースコードの説明を実施することです。レビューの前に自己レビューをしているので、自信を持ってレビューに臨みましょう。

対面レビューの流れ

レビュアーはレビューの目的を把握しているため、レビューイは資料や概要および内容を順番に説明します。レビュアーからの指摘については積極的に自分の意見を述べ、結果としてレビュアーの指摘が正しく、レビューイが納得した場合は指摘事項をメモしておきます。

査読レビューの流れ

レビュアーはレビューの目的を把握しているため、レビューイは査読レビューを依頼するツール(メールやチャットなど)を使用して概要を説明します。依頼するツールにストレージ上に置いたレビュー対象のファイルやソースコードを展開し、同時にレビュー指摘を記載するファイルも展開しておきます。また、ツールにはレビューを実施いただく最終期限を明記した上で送信しましょう。

＜査読レビュー依頼事項＞

レビュー対象の場所
レビュー指摘を記載するファイルの場所
レビューを頂く最終期限

(4)対処(Action)

レビューが完了したら、レビュー指摘を管理するファイルに指摘事項のメモを転記し、指摘事項の修正を行い、再度レビューを開催します。対面レビューの場合は、修正箇所および修正に伴って変更が発生した箇所の説明を行います。査読レビューの場合は、レビュー指摘を管理するファイルに、対処した結果を記載の上、再度レビューを依頼します。

以降、レビュー毎に確認(Check)→対処(Action)を繰り返し行います。

ベテランエンジニアが語る!
20代、30代で実践すべき10のこと

ここまでは基本的なことを解説してきましたが、上司も部下もいない企業へ常駐担当として1人で配属される方は、以降の①～⑧までは企業に所属するエンジニアとして必見です。また、⑨は実践向け、⑩は将来の展望に向けた内容となっています。

①社風に馴染む(規律性・社交性)

多少は性格が出ますが、社会的に浸透している「挨拶」は大切です。元気に明るく、挨拶しましょう。

②謙虚な姿勢(相手にとって社交性・感受性が上がる)

性別や年齢に関係なく、相手のことを「さん」付けで呼びましょう。また、「承知いたしました」「おっしゃるとおりです」「伺います」といった丁寧な言葉は聞いた相手も気持ちの良いものです。

③相手の話をさえぎらない(傾聴力)

相手が話し終わるまで、とにかく待ちましょう。そして、相手の話を理解しましょう。最近は、テレワークでオンラインの会話で双方のタイミングが合わずになかなか苦労しています。

④こだわりは捨てる(柔軟性)

年齢を重ねれば重ねるほど、余計なこだわりが出てきます。例えば、各企業で標準化されているツールは様々なので、それらにすぐに馴れないとコミュニケーションが取りづらくなります。若い頃の経験で、上司が慣れ親しんだツールがなく苦情を言っていましたが、耳に入った企業の方としてはあまり気持ちの良いものではありません。まずは、それぞれのツールや環境に馴れましょう。

⑤誤っている場合は指摘する(積極性)

愚痴は言わずに我慢しますが、間違いは間違いなので指摘しましょう。特に技術関連の誤解をそのまま進めてしまうと、後続タスクに影響を及ぼします。大勢の前での指摘は避け、後から本人に助言する形で伝えましょう。

⑥怖がらなくても大丈夫(実行力・主体性)

知見ゼロの依頼でも「やれるだろう」精神で挑めるかどうかが非常に大切です。もしわからないことがあれば、周りの方に聞いたり、インターネットの情報などを調べてみましょう。

⑦メールの最後に一言を(気配り)

依頼するメールの最後に「よろしくお願いいたします」と記載して終わることが多いですが、「クッション言葉」も付け加えてみましょう。以下のような文章が、クッション言葉としてよく利用されます。

「お忙しい(ご多忙の)ところ申し訳ございませんが」
「ご足労お掛け致しますが」
「度々の依頼で申し訳ございませんが」

⑧清潔感をキープ

相手に与える印象として、清潔感を保つことは重要です。清潔にしていると、相手の「感受性」「社交性」が向上し、「良い関係が気付けるはず」と思ってもらえるチャンスが広がります。

⑨IT業界で今何が起こっているのか

様々なIT業界の動向や障害について最新情報を得るように努めましょう。特に障害に関しては「対岸の火事」とは思わず、我が身と照らし合わせることで、今後の対策に多少なりとも得られる情報があれば良いと思っています。

⑩IT業界での立ち位置

IT業界で求められている人材のスキルをウォッチし、現在の自分の立ち位置を把握することで、業界のニーズにおける視野が広がり、将来展望の選択肢が増えます。日本ではプロジェクトマネージャのニーズが高く、ここ数年、日本政府によるデジタルトランスフォーメーション(DX)政策により、クラウド基盤、IoT、AI、コンテナの技術者はもちろんのこと、データサイエンティストなどのニーズも顕著に伸びています。