Javaに限らず、ITエンジニアというと激務なイメージを持つ人も多いでしょう。システムの改修、更新、あるいは量産品に組み込むためのプログラムなど、決められた期間内で完了・納品させなければならないといった制約の中での納期遵守、またその納期遵守とも密接に関連する品質確保、コスト管理といった面でも厳しい仕事を要求されている印象があるかもしれません。さらに、これらは自社内では完結せずに、顧客や協力会社等と関係する部分もあり、業務を管理・遂行することで、より困難な部分もあるかと思います。
とは言え、冷静に考えれば「様々な関係者との連携の中で納期どおりに完了させる」というのはIT業界に限ったことではなく、どんな業種でもどんな仕事でも、「仕事」として成立させる以上、当たり前の前提ですよね。
エンジニアの仕事とは、上司や顧客から指示されたことに基づき黙々と作業を行うといったイメージもあるかもしれません。しかし真のエンジニアには、コミュニケーションを図ってよりよい状況を作り出すことが求められています。
たとえば、システムの専門家ではない顧客は、その狙いや指示をエンジニアに伝えることに慣れていません。したがって、エンジニア側から、その顧客に分かる言葉で確認することが重要です。その結果、顧客との共通認識をはかることで、仕事がスムーズに進み、顧客からの信頼を勝ち取ることができ、今度はこちらの要望も伝えやすくなったり、新しい仕事の依頼等も考えられます。
また、自分の部下、あるいは協力会社に対する進捗確認でも、日頃からコミュニケーションを図っておくことで、問題・課題の共有化や「悪い話」を報告しやすい環境づくりが必要でしょう。逆にこちらから上司に対する報告という部分も同様です。納期間際になって、「やはりできませんでした」ということにならないように、事前に対策が打てるようにしておくことが重要です。
Javaエンジニアとしてデスマーチになだれ込まないために必要なのは、「かもしれない運転」です。大丈夫だろう、問題ないだろう、という「だろう運転」で仕事をしていると、ほぼ必ず、予期せぬトラブルによってデスマーチに一直線です。これを回避するためには、常に最悪のパターンを想定し、最悪のケースに至った場合の対応策を事前に考える癖をつけることです。「間違えているかもしれない」、「システムダウンするかもしれない」という「かもしれない運転」によって、できる限りの事前準備が整えられます。これは、ネガティブな意味ではなく、リスク管理思考を持つという意味で非常に重要です。
何かを依頼されたときに、「できるか?できないか?」を考えるエンジニアは成長しません。 何かを依頼されたら、「どうしたらできるか?」を考える習慣をつけましょう。この習慣によって、自分自身が成長するだけでなく、自然とコミュニケーションが円滑になります。
「できるか?できないか?」でしか考えられないエンジニアに何かを依頼すると、「○○だから、できません」と、理由つきで断られるというシーンが発生します。「他の仕事があるから、できません」、「技術的に無理だから、できません」など、理由の部分は様々ですが、拒否であることには変わりません。
一方、「どうしたらできるか?」を考えるエンジニアの場合、「○○であれば、できます」という回答を得られます。「あと1日ほど時間をもらえれば、できます」、「この技術を応用すれば、同じようなことが実現できます」という、前向きな回答によって、積極的な印象を与えることができます。さらに、「どうしたらできるか?」を前提にした判断であるため、「できないものをできると言ってしまった」という最悪のパターンも避けられます。