そんな環境だからか、仕事ができるエンジニアは例外なく段取り力が高い。デキる30代になりたい人には、必須のスキルと言えます。
しかし、言うはやすし。仕事を完全に管理し段取り良く仕事を進めることは、考える以上に難しいものです。実際20代のエンジニアを見ていても、今日割り当てられたタスクに手いっぱいになり、気付いたら明日のテストの準備がまったくできていない……など、段取り良い仕事との距離はまだまだ遠い人がいっぱい見られるようです。
30歳を過ぎるまでに確実に身に付けておきたい「段取り力」、仕事を通じてどう獲得すればよいのでしょうか。
―― 3年目までは「自分の仕事を遂行する」
3年目までに確実に身に付けたいのは「与えられた仕事を期日通りにこなす」こと。そんなの当たり前だと思われるでしょうが、期限ぎりぎりに「やっぱりできません」という報告をもらうことがしばしばあります。
与えられたスケジュールどおりに仕事をこなすために、まず何をやるべきか切り分け、スケジューリングをするところまでは、やっている人も多いでしょう。しかしここで見落としがちなのは、日常業務では急なアクシデントが発生したり、思ったより作業に時間がかかることはよくある、ということ。バッファも見積もったスケジュールを立てるとともに、毎朝そのスケジュールを確認し、予定とずれた分を調整したリカバリプランを立てるようにしましょう。
また、与えられた仕事をきっちりこなすために必要な、技術の基礎を身に付けるのもこの時期です。スケジュールを組むことで自分の仕事量を見える化し、技術の勉強をする時間を見つけ出すことも、同時に意識しましょう。
―― 4～5年目からは「プロジェクトを俯瞰して捉える」
技術の基礎も付いてきて、自分に与えられた仕事が確実にこなせるようになるのがこの時期。また、20代後半から30代にかけて、少しずつプロジェクトマネージャとしての役割を求められ始める時期でもあります。プロジェクトマネージャとしてまず問われるのは、プロジェクト全体を俯瞰したうえで、どうタスクを割り振り進めていくかという“段取り”です。与えられた仕事をしっかりこなすだけでなく、プロジェクト全体を見る視野を4～5年目からは持ち始めてください。
自分たちのチームは、プロジェクト全体のどこを任されていて、この前後にどんな作業があるのか、常に意識してみましょう。例えば、違うプロジェクトの人に仕事内容を聞いてみたり、自分で書いた設計書やWBSを先輩にレビューしてもらったりすることで、自分が今まで知らなかったプロジェクトの面が見えてくるはずです。自分たち以外のチームがやっている作業の流れが見渡せるようになると、プロジェクト内のみだけでなく、そのあとの工程に段取りがくめるようになります。
例えば自チームが開発しているシステムを、次にテストを担当するチームは、どのくらいの期間で、どんなテストを実施するのか知っていますか？ テスト期間から再調整、リリースまでの期間を考えると、自分たちはどの期限までに開発を終わらせるべきか、ざっくりスケジュールがイメージできるでしょうか。
全体の流れを知っていれば、仮に開発のスケジュールが大きく遅延したときも、どのチームとどう調整をすればよいのかなど、リカバリープランも立てやすくなります。また、次行程を意識することで、テスト運営方法が分かりやすい設計書を書き、テスト実施者が業務をスムーズに行えるようにするなど、より配慮した仕事ができるでしょう。
「段取り力」とは、見えている期限をもとに、見えているタスクの分配をするだけでなく、起こりうるトラブルや見えざるタスクを想像し、余裕ある仕事の進め方をあらかじめ決めることです。そのうえでも、開発の大きな流れを知っていることは重要になるのです。
－ 段取り力があれば、トラブルも怖くない
もちろん、当初のスケジュールではどうしようもなくなることもありますし、トラブルが起こらないプロジェクトはあり得ません。その場合も、現状をどう確認し、だれに報告し、どう対処するかという段取りをきちんと決めさえすれば、意外とトラブルが大きく発展することは少ないもの。お客様や上司が焦るのは、その段取りが見えないからでもあります。
20代前半、後半とステップアップし、自分自身にもお客様にも助けとなる「段取り力」を身に付けていきましょう。
]]>言わずもがな、使えるエンジニアになるためには勉強はマスト。ただ、エンジニア歴3年程度になると、多少仕事ができるようになることから、仕事も忙しくなり、勉強時間をとることができない……という声も聞かれます。今できている技術である程度、仕事ができることからも、新しい勉強をするよりも今の仕事を優先してしまう、という気持ちもあるようです。
ただ、このブログで言い続けているように、“今できる仕事”は、“2年後に入社する若手でもできる仕事”です。今のあなたの仕事が、2年後に入社する若手エンジニアで代替されたとき、あなたは何をやりたいのか、やれるのか。そういったキャリアを考えることが、勉強し続けるうえで重要であり、かつ、多くの若手に不足している視点だと思います。
とはいえ、がむしゃらに勉強するのも大変だしもったいない。仕事やプライベートで忙しい中でも効率的に勉強するために必要な視点について、今日は紹介します。
― “転職市場で引く手あまたなエンジニア”を目指せ
常に頭に置いてほしいのは、「転職マーケットでの自分の価値」です。転職を推奨しているわけではないので、誤解しないでください。転職市場のように、業界内の同年代のエンジニアと比較される市場においても、自分には“引く手あまた”なエンジニアとなれるか？ という視点を忘れずにいてほしいのです。
半年単位でプロジェクトを変わる他の会社との共同プロジェクトに参加するなど特殊なケースを除き、多くのエンジニアは1つのプロジェクトもしくは企業内で、1～2年単位で同じメンバー達とシステムに携わります。そうすると、自分がそこから得られる知識は、どうしても自分が所属するプロジェクトの内容や先輩エンジニアの知識に絞られてしまいます。
甲子園に例えてみましょう。自分の所属するチームが全国大会常連校の強豪で、守備も攻撃も共に強いチームで鍛えられていればよいですが、県大会でも3回戦に行けなかったり、守備は強いけど攻撃は弱いチームで育ち、攻撃はからきしだったりすると、同世代とドラフト会議に乗った時に、まったく選ばれない選手に育っている可能性があります。
10年後も活躍できるエンジニアであるために、今から、ドラフト会議で引く手あまたになれるエンジニアを目指す努力が必要になります。自社内でどれだけできるかのみにとらわれず、“エンジニア全体市場での自分の価値”に意識を向けてください。
― 自分の“キャリアステップ”、何年後までありますか？
若手のエンジニアは特に、まだ技術を学び始めたということもあり、目の前の仕事や技術をがむしゃらにしがちです。もちろんそれは大切な姿勢ですが、プロジェクトが終わった時や来季に向けた面談で「次はどんな仕事がしたい？ 」と言うと、答えに詰まったり、手にした技術でできる仕事を……と言うエンジニアが多いのは、少し残念だなと感じます。
2年後、5年後、10年後も同じ技術だけで仕事はできません。5年後にプロジェクトマネージャを目指したいのか、スペシャリスト（いるのでしょうか？ ）を目指したいのか……その像によって、次に勉強すべき技術は変わってきますし、目指す像により必要な力は変わってきます。
例えばリーダー、マネージャを目指すのであれば、どんなプロジェクトに携わってもメンバーに指示できる、広い知識が必要です。スペシャリストであれば、様々なプロジェクトに携わりながら、とことん得意な領域を見つけるのも良いでしょう。
キャリアマップを作る一方で、20代の若いうちは、まずは『石の上にも三年』をオススメしています。
まずは今学んでいる技術を極め、自分の基礎を作りましょう。自分の基礎となる技術を持つと、その周辺技術を学ぶときの習得スピードがまったく変わります。例えばJavaでのこの言語が、PHPではこれにあたるのか…など、基礎を応用することで知識の関連付けがスムーズになり、他技術であっても、理解促進が速いからです。
― 時流の流れに敏感であれ
自分の大きなキャリアマップにプラスしてほしい視点は「今の時代の波に乗る」ということです。今はどんな技術ができるエンジニアが強いのか、時代の流れに常に敏感でいましょう。まずは、時代が求める技術を認識したうえで、自身のキャリアプランと照らして勉強の優先順位を付けてほしいためです。
分かりやすい事例で言えば、言語1つとっても、Javaが過半数の主流言語で、PHPが数割、残りはまばらです。もちろん、Javaができることが市場に求められるエンジニアの必須条件と言えるでしょう。自らの強みを育てるのはそれからです。そのJavaを一通りできたうえで、PHPに手をつけるもよし、javaを極めるもよし…自身の目指すステップに歩を進めてください。
― 評価制度や国際基準を活用してプラン立てを
いきなりキャリアと言われても……という人は、ITSSのような国際基準や、各社の人事でつくる評価制度を見てみることをオススメします。例えばITSSなら、30代時点で、レベル3～4を目指すのが、一般的なエンジニアのレベル目安です。会社の人事が作る評価制度も、よく考えられていますから、エンジニアとしてレベルごとに必要な要件を明言化しています。
スキルとレベルがマップ化された評価基準を見ると、自分は現在どのグレードで、どのようなキャリアアップをしたいのかという道筋が分かりやすくなります。そのうえで、会社の推奨資格制度などを活用するのも一手でしょう。
今やっている仕事が面白い、大変、さまざまな理由で、勉強の優先順位が下がることもあります。しかし、お話したように自身のキャリアから照らして、必要な勉強を洗い出すことで、自然と、積極的に勉強できる姿勢がついてくるもの。4月から新しい年度も始まったこのタイミングで、自身のキャリアプランを今一度、見直してみてはいかがでしょうか。
ということで今回は、エンジニアに良く見る事例を見ながら、顧客との日々のやりとりがうまくいくコツを整理したいと思います。
■ケース1
仕様について顧客に確認の電話を入れたところ、当初の要件定義では出ていなかったAという機能を追加してほしいと要望があった。そこで追加開発を行い、追加開発費も請求したところ、費用発生の話は聞いていないので支払いはできないと言われ、トラブルに発展。
今回のケースは金銭トラブルに発展していますが、そこまで至らずとも、こういった顧客との“すれ違い”トラブルは意外と多いものです。こういったケースを見ると、一番共通して言えるのは、つい顧客の要望に「イエスマン」になってしまうことが多いこと。
もちろん、顧客の要望にすべて「ノー」と言えということではありません。顧客も、ほしいものを最初からすべて言葉にできているわけではありません。度重なるコミュニケーションから、新しい要望や意見が出てくるのは自然なことで、そこに可能な限り対応していくことは必要でしょう。しかしこれらにその場でイエスかノーかお答えするのは、プロジェクトマネージャですら難しいこと。このようなケースでは「一度確認します」と一息つくことが大切です。
■その場で判断せず「一度確認」を言える勇気を
「イエス」となぜ言ったのかという原因を聞くと「判断ができないはずのことを判断してしまった」「どう断ればよいかが分からず、断りきれなかった」といった理由が聞かれます。
「判断ができないはずのことを判断してしまう」というのは、どれくらいの費用や時間がかかり、他への影響が分からなかったりするタイミングで、見込みでOKを出してしまうということ。しかし、その後いざプロジェクトマネージャに報告したら、コストの面でNGだったことが分かった…ということが発覚する可能性もあります。「どう断ればよいかが分からず、断りきれない」というのも、検討すべき論点を整理すれば、おのずと要望を受けられるかどうか、明確な理由が出てきます。
顧客の要望にすぐ応えたいという気持ちや、その場で解決したいという意欲は分かりますが、まず「一度確認します」といってコミュニケーションを中断させる勇気を持ちましょう。そのうえで、まずはマネージャと相談（第1回を参照）して、一息ついてから顧客に返答をしましょう。一見回り道ですが、手戻りが少なく、双方ともにストレスのないコミュニケーションが取れるはずです。
■ケース2
要件定義後、何度か顧客に連絡したものの「お任せします」と任せてくれる様子だったので、開発を進め、納品のタイミングで顧客に報告。すると「思っていたものと違う」とトラブルに発展。こちらで費用負担し、作り直すことに。
顧客とのコミュニケーション不足は、システム開発においては一番の問題。エンジニアのモノづくりは、芸術家が自分の表現したいものを自分で作るのとは違い、顧客の要望を実現して、初めて価値を発揮できるものです。要件定義後はほぼ任せていただけたり、あまりエンジニアと話す機会を持たない顧客はいらっしゃいますが、それでも最終決定者は顧客。細かい疑問も自分で判断せずに、都度、確認しながら進めることが重要です。
■コミュニケーションの質を左右する“ツール”の使いこなし方
その中でぜひ身に付けてほしいのは、電話やメールの上手な使いこなし方です。このツールを場面でうまく使い分けられる人は、顧客とのコミュニケーションも円滑に行えている人が多いと感じます。
すべて履歴を残したから、とすべてメールでやりとりする人もいますし、メールをいちいち作る時間がもったいない、直接話した方がお互い言いたいことが伝わりやすいと電話を好む人もいます。どちらも一理あります。まずは特性をきちんと見極めましょう。
メールは、履歴が残ること、論点が可視化され整理できることはメリットです。一方、メールは見落される可能性もありますし、こちらの感情がうまく伝わらない書き方で、誤解を招く恐れもあります。
電話は、直接話せる分、お互いの主張が理解しやすく、話がスムーズに進みます。一方で履歴が残らないため「言った」「言わない」論争に発展しやすいことや、直接話している分、お互い気軽に「OK」を出してしまいやすく、後でトラブルになる恐れもあります。
■まず電話、メールは議事録代わりに
私はまずは電話、可能であれば直接お話することをオススメしています。メールでは強固に見えていた主張も、電話すると意外と思いつき程度で言っただけだった…ということもあります。できれば長文メールの往復にならないよう、初期のうちは電話で話し合うようにしましょう。
次に、顧客の要望や、こちらから顧客に検討してほしいことがまとまり始めたら、電話のあとにメールで簡単な議事をメモして送りましょう。特に長文でなくても、すでに電話しているので、伝わるはずです。これで、長文メールを打つ手間も省けますし、「言った」「言わない」問題も防ぐことができます。
コミュニケーションにまつわる、良く起きるトラブルやその解決ポイントについて、2回にわたりお話してきました。若いときに顧客とのコミュニケーションがトラウマになってしまったり、30代になって急に顧客との折衝が多くなり、一気に仕事が憂うつになった…という話など、コミュニケーションについての悩みは尽きない問題です。
しかしこれまで書いてきたように、顧客とのコミュニケーションは、その場での会話力よりも、事前準備や論点整理、ツールの使い分けなど、基本的なポイントを押さえることでずいぶん円滑に行えます。顧客とのコミュニケーションが得意と自負するエンジニアは、ごくわずか（若手の人は特に）。気楽に、うまくポイントを押さえたコミュニケーションで経験値をあげていくことで、あなたのエンジニアとしての強みが、また1つ増えるはずです。
しかし、このやり取りを苦手と感じているエンジニアは多いようです。場合によっては、顧客への報告が原因でトラブルに拍車がかかることも。
ということで、今回からは2回に分けて、顧客とのコミュニケーションにおける失敗と原因、その解決策についてお話します。
― うまく伝えるコツは「準備」にあり ～おしゃべりが苦手でも構わない
エンジニアに顧客とのコミュニケーションにおける悩みを聞くと、「提案の意図が伝わらない」「突っ込まれた質問に答えられない」など、いろんな声が出てきます。ではどうすべきと思うか更に聞くと、そもそもしゃべるのが苦手なので……と悩む声も。
しかしこれは大きな誤解です。「意図が伝わらない」「反論や質問への答えに詰まる」などの原因は、いかにその場の雰囲気を読んで話すかという“おしゃべり”の能力とはあまり関係ありません。これらの悩みのほとんどは、2つの“視点”を持った事前準備を行えば解決することが多いからです。
― エンジニアに足りない2つの“視点”
「失礼な、もちろん準備はして臨んでいる」と思う方もいるでしょうが、今一度、2つのポイントに基づいて、自身のコミュニケーションを見直してみましょう。
（1） 顧客視点 ～「自分が伝えたいこと」より「顧客が知りたいこと」
「顧客視点」とはよく言われる言葉ですが、この視点が欠けた報告現場に良く出くわします。
例えば提案時、あるエンジニアは、システムへ仕様する新技術のメリットを熱弁。障害報告や故障報告の際には、その原因とリカバリ策のスケジュールを報告。説明すべき事項は十分説明したとエンジニアは満足げでも、本当に顧客の知りたいことは、実は何も伝わっておらず、逆に信用を得られず事態が前に進まない……なんてこともよくある話です。
そもそも、顧客はなぜシステム導入をしたいのでしょうか？ 顧客は、サービスの質を向上させるために システムを導入します。日々のビジネスへの影響を俯瞰したうえでシステムを語るのが、顧客視点なのです。
提案時、顧客はどんな最新技術を使っているかよりも、システムの導入・進化に伴い、サービスがどれだけ効率化するか、発展するかを気にします。他社と比べてどこが優れているのかも気になるところでしょう。トラブル時は、そのトラブルによって他部署やスケジュールはもちろん、ビジネス全体にどんなインパクトがどの程度発生するか、知りたいのです。
と書いてみると「なんだそんなことか」という感じですが、エンジニアはどうしても「開発者視点」で、“システムの完成”をゴールとして話しがちです。
この視点のズレを理解し、「顧客が一番懸念していることは」「報告先の担当者が、上長に報告をあげる際、どんな情報が必要だろう」など、顧客の不安や知りたい点を押さえた情報を事前準備できれば、顧客が納得できない姿に慌てることも、質問に詰まることも、ぐっと減るはずです。
（2） リスクマネジメントの視点
開発の現場にいると、仕様の変更やスケジュールの遅れなど、トラブルへの直面が避けられないこともしばしば。
もちろん何のトラブルもなくプロジェクトが完遂されるよう、開発当初からあらゆるリスクを想定し、マネジメントすることが理想。とはいえトラブルが起きた際は、原因とリカバリ策を顧客に納得してもらえるコミュニケーションが必須となります。
ところが、慌ててトラブルの原因と対応を報告しに行ったものの、顧客に質問攻めにされ激怒されむしろ事態が悪化……というケースも目立ちます。
こういった原因の1つには、前述した「顧客視点」に立っていないゆえに、顧客が知りたい情報を提供できていないことも考えられますが、もう1つ、トラブル後の対処について、リスクマネジメント視点が足りていないことも挙げられます。
ビジネスにおいて「100％計画通りに実施できる」ことはないと考えるのが基本です（もちろん100％できるよう最大限努力はしますが……）。
ところが顧客への報告時には、多くのエンジニアがリカバリ策を「100％実施できる」前提でお話している。顧客としては、もともとうまくいくと思っていた開発にトラブルが起き、そのリカバリ策も100％うまくいくと説明されても、納得できませんよね。
ですから、リカバリ策を説明する際は、プランにリスクがいかに少ないか、またトラブルが発生しても対応可能であるのかを事前に考え、説明する必要があります。特に配慮してほしいと感じるリスクマネジメントのポイントを、2点にまとめました。
a．工数を具体的に見積もる
どれくらいのコスト（お金、人員、時間）が最大かかるのか、顧客が納得できる具体的な見積もりを出し、プランの正当性を説明できるようにしましょう。複数視点からのシミュレーションを出すのも効果的です。
b．スケジュールに余裕を持つ
私が聞いてもギリギリのスケジュール設定だなと感じるスケジュールを提案する人もいます。ですが、スケジュールは遅れこそすれ、早まらないのが常。スケジュール設定の際、遅延リスクを想定したバッファを加えた計画を立てることで、顧客からの「本当にそのスケジュールで出来るの？」という疑いはなくなります。
トラブル時は兎角焦りがちで、すぐにリカバリしたいという気持ちがはやりますが、顧客としては、確実なリカバリ策を聞きたいものです。今後のリスクも考慮したリカバリ策を提示することが、顧客からの信頼回復にもつながります。
プレゼンテーションも報告も、準備が8割。コミュニケーションでは“うまくしゃべろう”という意識が先行しがちですが、特にビジネスにおいては、必要な情報さえ用意しておければ、伝え方は二の次。2つの視点に基づいた準備で、顧客の信用をつかみましょう！
“顧客とのコミュニケーション”前半は、「しゃべる」ビジネススキルではなく「事前準備の視点」に絞ったものでしたが、後半では、日々の顧客折衝で必要となる「しゃべり」のコツをお伝えしていきたいと思います。
PMという役職柄、私は、プロジェクトメンバーから進捗やトラブルなどの報告・相談を日々受けますが、仕事のコミュニケーションの基礎である“報連相”につまずく人が、実に多いと感じます。その報告で何を伝えたいのか、上司に何をしてほしいのかなどが、まったく伝わってこないこともしばしば。
「で、何をすべきなの？」「結局何が言いたいの？」と怒られた経験がある人も少なくないのでは？
トラブルなど悪いニュースの報告は、だれもが憂鬱です。
重い気持ちを奮い立たせてせっかく報告したのに怒られてしまい、報告が怖くなって先延ばしになりがち……という人もいるかもしれません。
実は上司とのコミュニケーションは、“上司が部下の報連相に望むもの”がわかれば劇的に改善できるもの。
そこで今日は“上司に喜ばれる”上手な報連相の方法について、お話します。
― 抑えるべきポイントは、たったの3つ！
報連相で抑えるべきポイントは、たった3つ。タイミング、目的、手段です。
＜タイミング＞ 手遅れな“報告”ではなく早めの“相談”を
私が受ける報告の8割は“悪いニュース”です。プロジェクトにトラブルはつきもの。私自身、トラブルや進捗の遅れが発生することは、一定見越しています。だから、悪いニュースを報告されること自体で、怒ったりすることはありません。
ただ、対処の仕様がないほどの末期状態になってから報告されると、さすがに私も困ります。
言いづらさから報告タイミングが延び延びになって、やっと報告する勇気がわいた時には事態がどうしようもなくなっている、なんてパターン、経験ある人も多いのでは？帰り際や週末の遅い時間に報告してさっと帰る、“言い逃げ”をする人もいて（苦笑）、これもとても困ります……。
悪いニュースほど、事後の「報告」ではなく、まだ対応策を講じる余地が残されている早いタイミングで「相談」しましょう（ただの進捗や状況を共有するだけなら、「報告」もいいのですが）。
実は上司にとって、メンバーから相談を受けることは、とてもうれしいものです。メンバーでは解決できない状況を、これまでの経験やもてる人脈、スキルを駆使して打開するのがプロジェクトマネージャの務めであり、醍醐味でもあります。
ただ、トラブルが発生してしばらくたってから報告されても、私たちにも打つ手がない。もっと事前に相談して、どうやったら解決するか、上司を巻き込んで考えましょう。上司も協力を惜しまないはずです。
＜目的＞ 上司に何をしてほしいのか？を明確に
メンバーから報告を受けながら「この報告、何が言いたいんだろう？」と思うことがあります。ただ状況を知ってほしいのか、何かアクションが求められているのか。目的の見えない報連相は、その後の話も無駄が生まれるし、せっかくの時間がもったいないですよね。
まずは、上司に話しかける前に立ち止まって、その報連相の目的を考えてみましょう。
「状況を認識しておいてほしいのでお話します」「トラブルが起こっており、対応を相談させてください」「●●の作業が終わったので、報告します」など、目的を最初の一文につけるだけで、上司も自分のするべき反応を決めて話が聞けるので、すぐに次のアクションに移ることができます。
また、上司に意見をもらうときにぜひ気を付けてほしいのは、「状況＋自分の意見」をセットで持っていくこと。
自分の考えや迷っているポイントを具体的に伝えることで、上司からのフィードバックも明確になり、一段深い議論が出来ます。それに、自分はどうしたいという意見もなく、ただ上司に言われたらそれを行う“作業者”にはならないでほしい、とも思っています。よりいい仕事をするために、自分の考えを常に持ち、しっかり周りに伝えるようにしましょう。
＜手段＞ 「なんでもメールで」から脱却しよう
なんでもメールで送ってくる人がいます。すぐ隣の席からメールが来たときはさすがにビックリしました。
言いにくくかったのか、メールでびっしり経緯や状況を書いて送ってくるなんて人もいたりしましたが、私は基本的に、なんでも口頭でお話することが、コミュニケーション手段として一番と考えています。
直接話すと、声のトーンや表情などの情報量が増え、相手に真意が伝えやすいといいますが、まさにその通り。メールでの連絡は、相手に真意が誤解されて伝わる可能性が高まります。あれこれメールの言い回しを悩むのも時間がかかりますし、いいことは少ないですね。
もちろん、エビデンスを残すためにメールで送る、という場面も存在しますが、まず口頭で話し、必要な部分だけメールで議事録を送れば済むこと。上司が不在でメールで伝えざるを得ないときも、必ず後で口頭補足を心がけましょう。その場で相談の返答をもらえたり、メールで不足していた説明を補足できます。
メール偏重になる理由として「言いづらい報告だから」という理由以外にも、「上司が忙しそう」「あまり何度も報告するのも気が引ける」という声もよく聞きます。
そんな人への処方箋としては「週に一度の定例報告時間」を設定することをオススメします。週に1度、15～30分くらいで十分です。必ず上司が時間を確保できるので、その時にまとめて報連相を行えるため、その場で意見がもらえます。上司もメンバーの状況を定期的に把握できるので、お互いに良い時間となるのでは？
3つのポイントで報連相の方法をまとめてきました。なにより誤解しないでほしいのは、上司はあなたを助けるためにいる存在だということ。
あなたからの報連相に100％の完成度は求めていませんし、良い仕事の実現に協力したいと思って話を聞いています。恐れずコミュニケーションの量を増やすことで、徐々にコミュニケーションの腕もあがりますし、いい仕事の実現にもつながるはず！明日からの上司コミュニケーション、ぜひ見直してみてください。
エンジニアが20代で必ず身に付けるべきことってなんだと思いますか？ それは「ビジネススキル」。これがあるかないかで、エンジニアが30代、40代になっても“使える”エンジニアとして第一線を張れるかどうかは大きく変わります。
もちろんエンジニアにとってITスキルの習得は必須。また、普通の営業などよりお客様との接点も少ない分、ビジネススキルの習得に迫られることもありませんし、「ITスキルがあれば別にいいんじゃない？」と思う人も多いかもしれません。
しかし、私がこれまで、さまざまなプロジェクトのPMとして多くのエンジニアの方と関わる中で、いわゆる「デキる」30代エンジニアとそうでない人の決定的違いは、ビジネススキルが基礎能力としてしっかり備わっているか否か、ということだと、強く感じています。
なぜ30代までにビジネススキルを身に付けないと、その後の飛躍が難しいのか？
第1回では、エンジニアにとってのビジネススキルの必要性についてお話したいと思います。
～30代は、20代の延長線ではない！ エンジニアが直面する「壁」
最近、プロジェクトの中で多くのエンジニアと接する中で感じることは、「20代の延長」で仕事をしている30代エンジニアが多いということ。20代で得たITスキルで仕事をこなしている、そんな人が多くみられます。
確かに30代になれば、20代より早く同じ作業を処理できるようになります。でも、いくら20代がやる仕事が早く処理できても、20代ができる仕事を30代、40代の人にいつまでもお願いするPMはいません。
40代は「40代のエンジニアである」価値を持たないと、市場で生き残れないのです。ですから30代は、20代の延長線で仕事をする期間ではなく、40代で活躍するための価値を積み上げる時期。にもかかわらず、この危機感を持たずに20代、30代を過ごすエンジニアが多いように感じます。
では30代、40代と価値あるエンジニアになるために、20代では何をすべきか？
ここで、最初の話に出てきた「ビジネススキル」に戻ります。20代で、エンジニアとしての基礎を学んだあとの30代は、さまざまなプロジェクトに携わることを通して、最新のITスキル、その背景となる大きなITトレンドなどを幅広く学び、自分の強みを育てる時期。
こうやっていろんなプロジェクトにかかわる中で、どのプロジェクトでも重宝される人であることは非常に重要です。このベースになるのが「ビジネススキル」。いかに自身に求められる役割を理解し、スケジュールに落とせるか、お客様の要望を的確にヒアリングできるか、上司との「ホウ・レン・ソウ」を正しくとれるか…こういったビジネススキルが20代できちんと学べていたエンジニアは、どんなに以前と違うプロジェクトに配属されても、すぐに仕事に順応し、素晴らしいパフォーマンスを発揮します。
一方、いくらITスキルが高くても、ビジネススキルが身についていない30代では、プロジェクトの内容が変わると、とたんに順応できず、お客様やマネージャ、メンバーとうまくいかない事態に陥りがちです。結果、似たようなプロジェクト、仕事内容しか経験できず、最先端であったりトレンドとなる技術を学べるプロジェクトに配属されるチャンスも減ってくる。その結果、20代で得たスキルの延長線で食べていく30代になるしかないのです。
ITの世界は日進月歩。もちろん、20代で得た技術だけではすぐに古いエンジニアとなってしまいます。
だからこそ、どんなプロジェクトや組織にいっても通用する“仕事の方法”を知り、あらゆるプロジェクトで活躍することが必要。このキャリアの土台こそが、ビジネススキルなんです。
＜まとめ＞
●30代、40代と、エンジニアとしての価値を積むためには、さまざまなプロジェクトでの経験が必須
●基本的なビジネススキルを20代のうちに持たないと、新しいプロジェクトや組織で活躍ができず、30代まで同じ経験しかできない
●20代のうちに、仕事を進めるのに必要なビジネススキルを学び、あらゆるプロジェクトに対応できる土壌を自らに作ることが必要
とはいえ、私が身に付けてほしいと感じるビジネススキルはどれも、20代のうちに気づきさえすれば、ちょっと仕事への視点ややり方を変えれば身に付けられること。大切なことは、必要性に気づくことと、日々の仕事でのちょっとした配慮です。
では、いったいどんなビジネススキルをつけていけばいいのか？
次回から、具体例を挙げながら、エンジニアにとって必須なビジネススキルと、その習得方法についてお話ししたいと思います。