Eyes, JAPAN Blog > エンジニアとしてステップアップする為に心掛ける3つのコト

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

藤沼

エンジニアとして働き始めて暫く経つと「もっと成長するためにはどうすればいいだろう?」という漠然とした疑問を抱いたことがあるのではないでしょうか?

その中で多くの方が「技術力を磨く」ことを手段として掲げ、勉強会や自宅での学習などを通して日々努力されていることと思います。これは技術職である以上避けて通れないことです。

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

この記事では「こういう事も心掛けてみると、より成長の幅が広がるかも」というTipsをご紹介します。

はじめに

あくまでも私なりの考えであり「すべてのエンジニアがこうすべきだ」と主張する気はありません。「エンジニア」といっても職種は多岐にわたり、立場や組織体制によっても求められる能力は様々ですし、あなたが描くキャリアプランによっても伸ばすべき能力の優先順位は変わってきます。あくまで「こういう考え方もあるんだな」と参考程度にしていただければ幸いです。
Tipsはかなりの数があるのですが、今回は私が特に大切だと思う3つのTipsをご紹介します。

Tips1: 目的・背景を捉える

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

では、相手の依頼内容は果たして本当に適切なものなのでしょうか?依頼主は大抵の場合、あなたよりも「現場から遠い」「技術知識が乏しい」のいずれか(あるいは双方)でしょう。事業会社のシステム部門に対するビジネス部門であったり、開発会社に対するクライアント企業であったり。職場の他チームの人間や上司ということもあるでしょう。

そういった立場の人達が必ずしも適切な依頼をしてくれるとは限りません。もしかしたらアプリではなくウェブサイトを開発したほうが適切かもしれません。場合によっては業務プロセスを見直すだけで開発レスで解決できるような課題もあります。

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

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

分析の手順の説明や例は割愛しますが、エンジニアの方もロジカルシンキングの本を一冊は読むと良いでしょう。個人的には英治出版の「問題解決 – あらゆる課題を突破するビジネスパーソン必須の仕事術」がおすすめです。

更にもう1ステップ。なぜなぜ分析を終えたらそれを逆順で追ってみましょう。
「●●●という目的がある」だから「△△△したい」だから「◆◆◆したい」・・・という風に“だから”で繋げて振り返ってみるのです。一連の繋がりが論理的でなければ、依頼されている手段は適切ではない可能性が非常に高いです。

その後、全体を俯瞰してあなたなりの手段を考えましょう。その際も“なぜ”、“だから”でロジックを確認しましょう。

非常に基本的なことではありますが、「目的・背景の理解」が業務において最も大事なことだと私は思っています。

Tips2: 立場を気にしすぎない

システム関連の業務は「発注側」「受注側」という立場が明確に分かれやすいですが、その立場を必要以上に意識してしまい、意見を自分の中に留めてしまう方をたまに見かけます。前述の話にも関連しますが、依頼主の発言内容を鵜呑みにしていては「あるべき姿」を目指せない事も往々にしてあります。

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

慣れてきたら“防御線”を捨てて、自信を持って発言しましょう。といっても対立関係を煽るのは望ましくないです。自分サイドの意見を主張しつつも全体を俯瞰して落とし所を探り、さり気なくその場を取り纏めているような立場に自分を持っていけるのが理想だと個人的には思っています。無論、このレベルに達するには相手の性格や、所属する組織の文化なども理解している必要がありますので容易なことではありません。私も勉強中です。

Tips3: 証跡・記録を関係者が理解できる形で残す

日々の業務に追われるとどうしても目の前のタスクをこなすことに意識が行ってしまいます。その積み重ねの結果、新規参入者が既存仕様を理解する術が「現物を触る」「ソースを解読する」しかなかったり、1年後には自分自身でさえも「どうやってこの作業をやったのか分からない」「どういう経緯でこの仕様に至ったのか分からない」「バグなのか仕様なのか分からない」なんて事が起きている現場もあるのではないでしょうか?

全ての物事をドキュメント化する必要はありませんが、「業務を回す上で必要な情報は特定の個人に依存しない形で共有されるべき」です。開発手法としてアジャイルやDevOpsを用いている場合も同様だと私は思っています。

ずっと同じ仕事を同じ人がし続ける事は稀です。想定外の事情で仕事を休む事もあるかもしれません。であれば、初めからいつか他人と共有することを見据えてある程度は初めから作っておくほうが効率的でしょう。

こうした文化が根づいていないと痛い目を見るケースとしては、トラブル発生時です。「現場には行ってみたものの、担当者が居ないとわからない。」「共有ドキュメント上にメモ書きを見つけたけど、意味がわからない。」という事態に陥り、その間もトラブルが継続してしまうという最悪のケースです。

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

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

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

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

最後に

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

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

  • このエントリーをはてなブックマークに追加

コメントは受け付けていません。