エンジニアとしてステップアップする為に心掛ける３つのコト

エンジニアとして働き始めて暫く経つと「もっと成長するためにはどうすればいいだろう？」という漠然とした疑問を抱いたことがあるのではないでしょうか？ その中で多くの方が「技術力を磨く」ことを手段として掲げ、勉強会や自宅での学習などを通して日々努力されていることと思います。これは技術職である以上避けて通れないことですし、こうした努力を続けることはとても良いことです。

では、技術力さえ身につければあなたが思い描く「なりたいエンジニア像」になれるのでしょうか？

私はこれまで事業会社のIT部門、ITコンサルティングファーム、IT系ベンチャー企業でエンジニア、ディレクター、マネージャー、PMOなど様々な立場で経験を積み重ねてきました。この記事では私の経験を踏まえて「こういう事も心掛けると、より仕事の幅が広がるかもしれない」というポイントを数ある中から３つに絞ってご紹介します。

はじめに

当然ながら記載するのはあくまでも私なりの考えであり「すべてのエンジニアがこうすべきだ」と強く主張するつもりはありません。

「エンジニア」といっても職種は多岐にわたり、立場や組織体制によっても求められる能力は様々ですし、あなたが描くキャリアプランによっても伸ばすべき能力の優先順位は変わってきます。あくまで「こういう考え方もあるんだな」と参考程度にしていただければ幸いです。

ポイント１： 目的・背景を捉える

開発業務にせよ運用業務にせよ、エンジニアが何かを依頼される際は「○○のiOSアプリを作って欲しい」や「△△作業をやってほしい」といった言われ方をすることが多いと思います。

では、相手の依頼内容は果たして本当に適切なものなのでしょうか？

依頼主は大抵の場合、あなたよりも「現場から遠い」「技術知識が乏しい」のいずれか(あるいは双方)でしょう。具体的には、以下のような関係が想定されます。

• 事業会社の「ビジネス部門」と「システム部門」という関係。
• 「クライアント企業」と「開発会社」という関係。
• 職場の「上司や他チームの人間」と「あなた」という関係。

こうした立場の人達が必ずしも適切な依頼をしてくる保証はどこにもありません。

「アプリを作って欲しい」という依頼であっても、実はウェブサイトを開発したほうが適切なケースだってありますよね。それどころか、何かを開発するまでもなく業務プロセスやルールを見直すだけで解決できるような課題もあります。

さて、「本当にやるべきこと」を導くためには「目的・背景」を理解する必要があります。そして「目的・背景」を探るためには「依頼内容に対して“なぜ”を繰り返し続ける」必要があります。いわゆる「なぜなぜ分析」ですね。

「なぜなぜ分析」は誰もが耳にしたことのある言葉かと思いますが、実行できている人はかなり限られています。できていると思っていても、実はどこかでロジックが飛んでいたり、根源(目的・背景)までたどり着いていないケースをよく目にします。

それどころか「手段」を「目的」として堂々と謳ってしまっている発言やドキュメント（要求仕様書）が世の中に溢れています。そう、依頼主でさえ「目的」をきちんと論理的に説明できないことが往々にしてあるのです。

論理的に物事を捉える能力を身につける為にエンジニアの方もロジカルシンキングの本を一冊は読むべきだと私は思っています。これは依頼内容を理解するためだけでなく、あなたが上司や周りの人に対してなにか物事を説明し、理解してもらう際にも役立つスキルです。

個人的にはこの二冊がオススメです。

1分で話せ 世界のトップが絶賛した大事なことだけシンプルに伝える技術

問題解決――あらゆる課題を突破する ビジネスパーソン必須の仕事術

なぜなぜ分析で「手段」から「目的」への深掘り（あるいは仮定）が一旦できたら今度はそれを逆順で追ってみましょう。

「●●●という目的がある」だから「△△△が必要だ」だから「◆◆◆という手段を取る」・・・と言ったように順接の言葉で繋げてみるのです。

一連の繋がりに違和感や"スキ"があれば、「どこかでロジックが飛んでいる」あるいは「手段が目的の実現に適していない」のいずれかの要因が考えられます。

ポイント２： 立場を気にしすぎない

システム関連の業務は「発注側」「受注側」という立場が明確に分かれやすいですが、その立場を必要以上に意識してしまい、意見を自分の中に留めてしまう方をたまに見かけます。

前述のとおり依頼主の発言内容を鵜呑みにしていては「あるべき姿」を目指せない事も往々にしてあります。「お客様の言うことは絶対」ではないのです。

相手がクライアントであれ、職場の上司や先輩であれ、あなたなりの意見を発してみましょう。経験が浅い方であれば「私が間違っていたら申し訳ないですが…」と防御線を貼りつつ意見を述べるのも一つの戦術です。その発言がきっかけで、「あるべき姿」に一歩近づけるかも知れません。

慣れてきたら“防御線”を捨てて、自信を持って発言しましょう。といっても対立関係を煽るのは望ましくないです。自分サイドの意見を主張しつつも全体を俯瞰して落とし所を探り、さり気なくその場を取り纏めているような立場に自分を持っていけるのが理想だと個人的には思っています。

無論、このレベルに達するには相手の性格や、所属する組織の文化なども理解している必要がありますので容易なことではありません。私も案件ごとに常に模索しています。

ポイント３： 証跡・記録を関係者が理解できる形で残す

日々の業務に追われるとどうしても目の前のタスクをこなすことに意識が向かいがちです。その積み重ねの結果、以下のような場面に直面したことがある方も少なくないでしょう。

• 過去に実績があるはずの作業手順が分からない。
• 仕様が不明でバグなのか仕様なのかわからない。
• 仕様の調整経緯がわからない。

もちろん、全ての物事をドキュメント化する必要はありません。プロジェクトの規模や重要度によっても変わってくるでしょう。

ただ、基本的には「業務を回す上で必要な情報は特定の個人に依存しない形で共有されるべき」です。勘違いされがちですが、これは開発手法としてアジャイルやDevOpsを用いている場合も基本的に当てはまると私は思っています。（開発手法によらずプロジェクトごとに何をもって証跡・記録とするか予め決めるべき、という事。）

こうした文化が根づいていないと一番痛い目を見のはトラブル発生時です。「現場に駆けつけたものの、担当者が居ないとわからない。」「共有ドキュメント上にメモ書きを見つけたけど、意味がわからない。」という事態に陥り、その間もトラブルが継続するといった経験がある方もいらっしゃるでしょう。最悪の場合、作業ミスにより二次災害を引き起こす可能性もあります。

もう一例挙げるとすれば、仕様凍結後に発注者と受注者間で仕様の認識齟齬が発生し「なぜこういうつくりになっているんだ。バグじゃないのか。」「いえ、これは仕様です。」と揉めるケースです。仕様書ないしQA票上できちんと証跡を残していれば「誰が・いつ・どの内容で」合意したかが明らかです。

証跡・記録を残す際に私が特に意識しているのは以下の５点です。

• QA票や手順書など繰り返し使うドキュメントは雛形を決める。
• 口頭で交わしたものであれ、重要な取り決めはドキュメントに残す。
• 書いた人しか理解できないメモをそのまま引き継がずに清書する。
• フォルダやファイル名を他人が理解しやすい構造／ネーミングにする。
• 自分が作った内容を「同じチームの他の人」の目線で見返してみる。

面倒だと感じるとは思いますが、一度習慣づけてしまえばそうでもありません。 むしろ前回までの実績を使い回せますし、抜け漏れのリスクも減らせますので、長い目で見ればこうしたほうが効率的です。

最後に

「エンジニアとして」と銘打ったものの、内容としてはどれも社会人として身につけておくべきとされるビジネススキルであり、一度はどこかで耳にしたり、研修で学んだ内容ではないでしょうか？

技術的なスキルに加えて、この様なスキルも併せ持つことでより活躍の機会が広がるかと思います。少しでも参考になれば幸いです。

1分で話せ 世界のトップが絶賛した大事なことだけシンプルに伝える技術

問題解決――あらゆる課題を突破する ビジネスパーソン必須の仕事術