はじめに
「ITエンジニア」にも色々いますが、特に大手企業から受託してシステム・インテグレーションを行っている人々のことを想定しています。あまり関係ないかもしれません。
私が思うITエンジニアに求められる姿勢、または能力には3つのものがあると思います。
- 自社の課題と、顧客企業の課題を捉え、または捉えようとし、それを解決し、または解決しようとする姿勢、能力
- 常に身の回りに疑問を持ち続け、それを解決し、または解決しようとする姿勢、能力
- 言語を正しく運用する能力
ここでは、個々に対して私見を整理したいと思います。
自社の課題と、顧客企業の課題を捉え、または捉えようとし、それを解決し、または解決しようとする姿勢、能力
顧客がIT投資の意思決定を行う背景には、大なり小なり課題があります。何の課題もないところに投資を行う必要はないということです。そして顧客は、課題を解決してくれる（と期待する）ベンダーにシステム開発を委託します。委託された側は、顧客の課題を、自らが持つアセットを使って解決しようとします1。これらの流れが途中で断ち切られると、IT投資は必ず失敗に終わります。
ここで、以下のような疑問が出てきます。
- 顧客はベンダーに課題を正確に伝えてくるでしょうか。
- ベンダーは、「他社」のビジネスと課題を正確に理解できるでしょうか。
- 自社が持つアセットと自社の課題（不十分なところ）を正確に理解しているでしょうか。
- 顧客と自社のそれぞれが持つ課題は、現場とマネジメントで一致しているでしょうか。
まず、顧客がベンダーに課題を正確に伝えてくることは稀だと思います。それは、顧客自身が正確に認識していないこともあれば、ベンダーからすれば他社のビジネスにおける課題なわけで、言葉の使い方、ニュアンスや温度感などを取り違えるなんていうことはザラでもあるからです。ゆえに、顧客とベンダーは、様々な技法を用いて、ビジネスと課題を共通認識のもとに捉えていくことが求められます。技法には「ドメイン駆動設計」のようなものがあれば、「デザイン思考」といったものもあるかもしれません。いずれにしても、双方向の取り組みが必要になるということです。
そして、ビジネスと課題を共通認識のものにできたら、ベンダーは課題を解決、または整理しなければなりません。ここでは解決すると決めた課題について書きます。業界には課題を解決するための技術が多くあり、その技術は更に「基本」と「応用」に分解できます。応用部分に対して、各社が持ち合わせているアセットやその深度は多種多様で、強みもあれば、弱みもあります。そして多くの場合、顧客の課題を解決するのは「応用の技術」です。したがって、自社の何が強みで、何が弱みなのか。それに対してどのように対応しようとしているのか。これが自社の課題であり、顧客と対峙するときには、常に正しく認識しておくことが重要です2。これは何も強みを活かして対応しましょうということではありません。強みを活かすことも大事ですが、顧客からの求めによっては、弱みを課題として認識して対処する必要があるということです。
常に身の回りに疑問を持ち続け、いくつかを課題と捉え、それを解決し、または解決しようとする姿勢、能力
1つ目の話は、いわばトップダウンの考え方です。ビジネスを理解し、課題を抽出し、自社の課題を踏まえて顧客課題の解決を目指す、という3段階の流れです。ここでは、ボトムアップの考え方を書きたいと思います。
先に「基本」と「応用」という言葉を使いました。「基本」とは、長きにわたって変わらないもので、常に立ち戻ることができる地点のことを意図して書いています。これに対して「応用」とは、基本を土台と捉え、その土台の上に成り立つ概念を意図して書いています。あるいは、応用が土台となり、その土台の上に成り立つ概念でもあります。例えば、何かをしようとした時に、ある方法よりも正確に行える方法、効率が良い方法、安全性が高い方法などを意図しています。
まず、何においても「基本と応用の技術」を習得・研鑽することが肝要で、どちらかといえば基本に注力することが大事です。この理由は2つあります。まず、基本に注力すべき理由ですが、基本は応用の土台であり、不安定な土台のうえに物は載らない、あるいは載ったとしても不安定であり、もっと言えば載った状態の再現性が低いからです。次に、技術の習得と研鑽が肝要であるとする理由ですが、人は知らないことに対して疑問を持つことができないからです。人が疑問を持つのは、自分が知っている道理に沿って物事が進まないときです。人は何かを知り、そこから外れたものに対して疑問を持ち、その疑問の一部は、自分に不足している基本や応用の技術で塗り替えられ、そうでないものはやがて課題に置き換わっていきます。課題とは何かを達成するための障壁です。だから、「基本と応用の技術」の習得・研鑽は重要なのです。
私の仕事はチームで仕事をするので、ここで「チーム」という言葉を考えたいと思います。そもそもチームとは個人の集団であって、チームを組む理由（意味）は（1）個人ではなし得ないことをやり遂げること、または、（2）そのやり遂げる結果が、個々の成果の総和を超えること、にあると考えます。特に（2）を目指すなら、そこに集まる個人によってチームとしての「基本と応用の技術」の幅が広げられ、かつ深くなっている状態でなければなりません3。さらに、その多様性を発信し、また個々人が受け入れることができる土壌も必要です。”Diversity and Inclusion”（多様性の受け入れ）の意味の1つはこれにあるのではないでしょうか。
その中で、個人が持つ「基本と応用の技術」の範囲で、常に身の回りに疑問を持ち続けることが大切です。具体的には、「自分と周りが正しい4ことをしているか」を問い続けることです。断面はいくつかあるでしょう。ビジネス理解、課題抽出、設計、実装、テスト。アーキテクチャ。マネジメント。もっと広くは組織。それぞれに対し、「基本と応用の技術」を当てはめたときに、個人が疑問を生み出すことができ、その一部を個人またはチームの課題と捉えられるかどうかが、チームとしての成果を生み出せるか否かに関わり、ひいては顧客の課題を解決できるかどうかにも関わるのだと思います。
言語を正しく運用する能力
最後は、「言語」の話です。
私の仕事の成果は、すべて「言語」で成り立っています。言葉には2つあり、1つは日本語や英語といった人間同士が使う言語（これを便宜上、会話言語とします）、もう1つはサーバやネットワーク等のインフラ、およびそれらの上で動作する各種ソフトウェアを開発または統合し、動作させるために必要な言語（あるいはパラメータ類）です。
それを生産するプロセスは大きく3つに分けられると思います。1つ目は顧客のビジネスや課題を、会話言語を用いて言語化して共通認識の下に置くこと、2つ目は、その課題を解決するための方法を「基本と応用の技術」を用いて考えること、３つ目は、考えた解決策をコンピュータ等が理解できる形に変換することです。これらのすべてで言語が使われ、そして最終的に変換するということは、変換元となるものの解釈を誤ってはならないですし、変換も正確に行われなければなりません。それぞれの対象に適した言語を適切に運用しなければならないのです。
よりよい（より伝わり易い）言い回しがないか、よりよい実装の仕方はないかを常に自分に問いながら、言語を正しく運用していきたいものです。
まとめ
勘違いしないで頂きたいのは、あくまで上記は私見であり、また、自分が出来ていると思っているものでもないということです。また、人によって置かれた状況が異なるため、ITエンジニアに求められるものも人それぞれ、またはその時々によって変わるものと思います。
ただ、現時点でITエンジニアに求められるものは、ここに書いた3つのことに帰結するのではと私は思っていますし、少なくとも2023年においても私とチームの課題でもあると思っていますので、ここに書いたことを念頭に置きながら仕事をしていきたいと考えています。
では、よいお年を。