システム構築をけっこうな数やっております。新人で右も左もわからない頃から先輩の仕事を見て見様見まねで色々な現場を経験してきました。30年もずっとよくやってきたなぁと我ながら思っています。
そんな僕がエンジニアとして技術力の向上は普通に右肩上がりだったと思います。パッケージを扱っていたので業務の知識も同じように向上していきました。（マネージャーとしての能力はまったく向上しませんでした）
ただ、組織として動くサラリーマンとしては、お客様からの予想外の要求に対しては「持ち帰って相談して回答します」と言う回答しか出来なかったんです。
これ自体は誤りではありません。プロジェクトのスコープを変更するような要求を勝手に許諾すると構築工数が増えるので当初の予算を超える可能性が出てくるからです。勿論、スコープ変更は必要に応じて発生するのですが大前提は『再見積もり』と言う工程を挟みます。簡単に言うと「作業増えるからもっとお金ちょうだい」と言うのを両者で合意さえとれれば作業してもOKというもの。
これを再見積もりをしないでスコープを変更すると、まぁ赤字になりますし炎上します。上司やプロジェクトメンバーからは「何勝手に決めるんだ！」と怒られます。いい事なしです。
なので基本的にエンジニアはお客様からの追加要求に対しては”持ち帰り”という工程をとります。
ただしこれは通常のプロジェクトの場合。
トラブルプロジェクトに関しては、途中から参画すると「どこまでがOKでどこまでが再見積もりの対象なのだ？」という場面が多々あります。
作業をお願いしているパートナーさんも「わかりません」の一点張り。お客様もそればかりの回答だとただでさえ炎上しているのにさらに関係が悪くなります。
ある程度プロジェクトの全体像が見えた時、プロパーとして「もう、ええわ。俺が決める」という場面が出てきます。勿論スコープを大きく離れるか？どちらに非があるか？をちゃんと鑑みた上です。その決意・決断には覚悟が伴います。言うだけならただの迷惑なエンジニアです。有言実行。言ったからには自分が先頭になり”やり切る”。
ー みんなうだうだして曖昧な回答で済ませている。そのため進捗はどんどんと遅れていくので本番までの作業がどんどん増える。そんなに難しい作業では無いと思うのでやってしまった方が結果良いと判断するが誰も手を挙げない。
そんな時に「わかりました！その方向で進めます。でもお客様の協力も必要なのでよろしくお願いいたします」という発言をします。
この決意と覚悟を”自分ごと”で判断したとき、ITエンジニアとして飛躍的に成長すると思っています。ブレイクスルーという奴です。
この発言後は顧客との折衝やプロジェクトメンバーへの指示出し、技術的問題の解決もしくは解決のための方法を説明して依頼などとんでもないタスクが増えます。会議のファシリテートなど全部自分が主体。でも、もうダラダラやっていくとロスコストも増えるし予定納期も遅れる。そちらの道を選んでも大変な事しかありません。でも”自分ごと”なので自分のやり方で進める事が出来るのでとても良い経験になるんですよ。
このブレイクスルーを経験し実力が伴っていると主導権がこちらに移ります。
よくエンジニアやプログラマはコミュニケーション能力は特になくても良いと言う意見を聞きます。それは対象プログラム本数が少ない場合のプログラマーなら通用するかもしれませんが、顧客向けシステム構築となるとコミュニケーション能力が物を言う世界になると思っています。お客様と直接会話する立場の場合は特に、です。
リモート越しにお客様の声色を判断して一旦謝りながら進めるべきか、強気に出るべきか？ここは営業さんに任せる事が出来ないです。営業さんは細かい技術問題の解決方法がわからないので……これは営業さんを責めている訳ではありません。営業さんには営業さんの苦しみがあるので。
このブレイクスルーを経験すると社内でも「あの人に任せると何とかしてくれる」という箔がつきます。僕もここ数年は火消しばかりしているのですが、火消しで入ったプロジェクトの人と飲みに行ったりすると「波秋さんが入ってから一気に色んな事が回り始めるようになりました！」という嬉しい評価を貰う事が多くなりました。
別に昇給に繋がる訳じゃないのは悲しいですがエンジニア冥利につきるというものです。
ただ、このスキルが増えるとスーパー火消し要員として毎回炎上プロジェクトを渡り歩く事になるので、早めに仕事の進め方、火の消し方を後輩や周りの人に教えるようにしましょうね。
