さまざまな困難をどう乗り切ればいいのか
ITエンジニアとしての道を究めるには
第4回 若手エンジニアの生きる道
萩本順三（豆蔵取締役）
2004/2/10
エンジニアの仕事に熱い情熱を抱いてソフトウェア業界に飛び込んだものの、数年が過ぎるとその熱が冷め始める時期がくる。エンジニアの仕事はつまらないのではないかと思い始めた、若手エンジニアに伝えたい「エンジニア道」を紹介しよう。
■エンジニアの真の仕事とは何かを知る
自分が目指す仕事の本質を知っておくことは非常に重要なことだ。読者は「エンジニアの仕事の本質はどういうのもなのか」を考えたことがあるだろうか。ここでは、私が考えるエンジニアの仕事の本質をエンジニア道と呼ぶことにする。
エンジニア道は時代とともに微妙に変化している。以前は、自己のスキルを駆使して顧客が要求するソフトウェアを開発することが「エンジニア道」であったが、いまでは少し状況が変わってきている。それは、顧客が要求するものを正しく作るという点では同じであるが、そこに下記で示す「2つの責任」がプラスされているのだ。
- 人が理解できるソフトウェア構造を提供する責任
- ソフトウェア構造を説明する責任
以前は要求されるソフトウェアを作るスキルさえあれば優秀と見なされていた。しかし最近は、作るだけでは許されなくなった。なぜならば、コンピュータシステムの目覚しい発展によって、顧客の要求が複雑・多様化し、それに伴いソフトウェアシステムが大規模・複雑化してしまったからである。
そのようなソフトウェアシステムは決して1人では作れない。規模が大きくなり、部分に分けて作ることが必要になってきているのだ。また、顧客の要求も複雑化し、一度に要求を抽出すること自体がナンセンスとなり、ソフトウェアを段階的に構築する技法（プロセス）が要求されるようになってきた。
そうした中、エンジニア同士の間で「構造の共有化」や「顧客との意思統一」が要求されるようになり、次第にエンジニアの価値は単にソフトウェアを作るだけではなくなってきた。人が理解できるソフトウェアの構造を提供できる能力と、それを説明できる能力が必要とされるようになってきたのである。
このような時代に適したオブジェクト指向言語としてJavaや.NETが生まれ、ソフトウェアの構造を説明する標準言語としてUMLが誕生したのである。では、こうした変化についてもう少し細かく説明することにしよう。
（1）ソフトウェアは1人で理解し、作るものではない
現在のソフトウェアの開発環境は、1人で理解して作るようなものではない。細部の作り込みを複数人で共有の情報にしながら開発を進めていかなければならない。若手エンジニアは、このことを知っておく必要があるだろう。
というのは、誰でも入社して3〜5年後にはプログラムを組めるようになる。その間に最初は優秀と思われていたエンジニアが伸び悩んだり、優秀ではないと思われていた人がぐんぐん力を伸ばしていくこともある。入社後3〜5年目はエンジニアにとって転機を迎えやすい時期といえるだろう。
ソフトウェアは自分1人で作るものではなく、「人が理解できるソフトウェア構造を提供する責任」と「ソフトウェア構造を説明する責任」があるということを意識して訓練している人は成長していくのではないだろうか。なぜなら、自分で作ったプログラムを人に説明することは、単にプログラムを組むだけでは身に付かない能力を持つことができるからである。では、どうやって、そのような能力を意識しながら訓練すればよいのだろうか？
（2）オブジェクト指向技術の使い方
私がオブジェクト指向技術の本質的な効果をようやく理解できたのは、オブジェクト指向言語を使いだして2、3年後のことである。当時私が使用していたオブジェクト指向言語はC++やObjectiveCであった。プログラミング技術におけるオブジェクト指向の効果は、半年もしないうちに実感できた。
しかし、それはソフトウェアを1人で理解して作るためのテクニックとしてオブジェクト指向言語の効果を実感していただけのことである。オブジェクト指向環境での開発を続けていると、それまでよりもスムーズにソフトウェアの構造をチーム内で理解し共有できるようになった。ソフトウェアの全体構造はシンプルなイメージで共有し、細部はオブジェクトに隠ぺいすることができるようになったからである。
これは、プログラミング技術による効果よりも、数十倍重要だと直感した。このとき、ようやくオブジェクト指向技術の本質的な効果を理解したのである。その効果は、Javaであっても.NETであっても変わらないものだ。
（3）オブジェクト指向技術の真の効果はエンジニア道そのもの
オブジェクト指向技術の本質的な効果は、開発者間でソフトウェアの構造を共有できることだ。（前述した2つの責任を考慮すれば）オブジェクト指向技術を身に付けることは、エンジニア道そのものといえる。このとき、エンジニアという仕事の難しさが理解できた。難しさとは、「ソフトウェアを通して展開される仮想世界に、何らかの構造を作り出し、人が理解しやすいように見せる」ことである。
そもそもエンジニアの仕事の難しさとは何たるかを理解しない限り、オブジェクト指向技術の価値も理解できない。まして、Javaや.NET、UMLの正しい使い方も理解できないだろう。それらは、「ソフトウェアを通して展開される仮想世界に、何らかの構造を作り出し、人が理解しやすいように見せる」というエンジニア道を支援するために最も使いやすい道具なのだ。
エンジニアという仕事の難しさを意識していれば、Javaや.NET、UMLを使いこなしているうちに、エンジニアにとって重要なスキルとなる「人が理解できるソフトウェア構造を提供する責任」と「ソフトウェア構造を説明する責任」を次第に身に付けることができるだろう。
（4）オブジェクト指向だけにこだわるな！
ここまで説明したように、オブジェクト指向は、エンジニア道を支援するために最も使いやすい道具なのである。道具はあくまで道具であり目的を達成するための手段である。エンジニア道を究めるには、オブジェクト指向を究める一方で、オブジェクト指向の考えを超える必要もある。また、ほかの手段を身に付ける必要もあるだろう。オブジェクト指向だけが最適解を持つものではないということも忘れてはならない。
■実装（プログラミング）を忘れるな
あまり開発経験がないにもかかわらず、若手エンジニアにプロジェクトマネジメントを任せる企業が増えているようだが、私は反対だ。人はマネジメントできても、技術のマネジメントができないからである。
技術のマネジメントとはどういうことなのか。簡単にいえば、開発で使用するソフトウェア技術、開発手法やツールなどの長所・短所を見抜いてその組み合わせを考え、メンバーの開発工数などを見積もることである。人のマネジメントしかできない社員を集めていたら、徐々に技術のない会社になってしまうだろう。
しかし、運悪くマネージャにアサインされた場合はどうすればいいのか。そのときは、実装を趣味として、また将来役立つスキルを身に付けるつもりでやり続ければいいのである。さまざまな技術を自分で体験して評価する。ソフトウェアの価値と利用法を確認するのだ。この作業を放棄したら中身のないエンジニアで終わってしまう。放棄せずに継続できれば、技術をマネジメントできるマネージャ、つまり技術の価値と使い方が分かるマネージャに近づくことができるだろう。
■プログラミング上達法
新人時代にプログラム開発を繰り返し行うことができるなら、それはいまの時代、とても運のいい方だ。まずは、一流のプログラマを目指すのがよいだろう。その際プログラミング能力はどうすれば上達するのだろうか。私のプログラミング能力は決して一流といえないが、自己体験からプログラミング上達法について説明したい。
（1）プログラムの制御をとらえる前に、プログラムの構造をイメージせよ
新米プログラマのころ、よくミスをした。自分でいうのも何だが、使えないプログラマだったと思う。執念深くプログラムの制御構造にこだわる割にはバグが多かった。頭の中では、ロジックの組み合わせが整理されていなかった。
もともと意味のない暗記が苦手だったために、ロジックの組み合わせを頭の中で整理できずに苦労していたものだ。プログラミングがある程度上達したころには、プログラムの構造をイメージでとらえていた。それはオブジェクト指向言語を使う前、C言語やアセンブラを中心に開発していたころである。多少プログラミングが上達してからは、データ構造に深く興味を持ち、どう設計すればいいのかにこだわりを持つようになった。そのデータ構造にアクセスする関数を明確にした。データ構造を取り巻く関数グループを頭の中にイメージとして焼き付けたのである。
オブジェクト指向言語を使うようになってから、このイメージはさらに強まることになった。現在では、プログラムを考えるとき、何らかの意味を持つオブジェクトらを頭の中に鮮明に焼き付けている。そのオブジェクト同士の間を、何らかのサービスを実現するため、メッセージが飛び交うというのが私のプログラムのイメージである。
実際のデータや制御処理は、意味を持つオブジェクトの中に隠ぺいされ、必要なときだけ、オブジェクトの名前により連想されるのである。この方法で頭にイメージしたプログラムは、非常にシンプルであり、プログラムの実現すべき全体構造は意味のある概念（オブジェクト）の構造に細分化されており、その世界は非常に安定している。なぜなら、プログラムの実現すべき要件を、人が理解しやすい「意味のある概念の組み合わせ」で表現しており、それを頭の中で仮想的な現実として認めることができるからである。
皆さんも、プログラムの制御にとらわれずに、プログラムの構造をイメージする訓練をしてみてはどうだろうか。そのための方法としては、下記のことを実践すれば効果が上がるだろう。
- パソコンのキーボードから離れて、頭の中だけでプログラムをイメージする
- 帰りの電車の中、お風呂の中などで、常にプログラムをオブジェクトの集まりとしてイメージし、その中をどのようにメッセージが流れるか考える
- 頭の中でUMLを書き、それを実装し、動かす。UMLを清書するのは、ある程度ソフトウェア構造がしっかりしてきてからでいい。それまでは、UMLをイメージし実装して、改善するプロセスをできるだけ多く繰り返す。UMLで設計する際には、検証された設計を行うという意識を持つ
- オブジェクトの名前は非常に重要。最も分かりやすい名前を付ける
- 最もシンプルでかつ要求を満たすオブジェクト構造を作れるようにする
（2）プログラムとテストプログラムを同時に作成する
プログラムをオブジェクトのイメージでばかり考えていると、目的を見失ってしまうこともある。目的とは、このプログラムは何をすべきかということ。それを忘れないためにも、必ずプログラムを作る際に、テストプログラムも同時に作り、テストを繰り返すことが重要である。
（3）プログラムを書く際に、何通りかの書き方を考える
（4）プログラムを書く際に、何通りかの書き方を考え、その長所・短所を比較し、最も適した方法を選ぶように心掛ける。これはかなり時間がかかるように思えるが、習慣付ければ上達する
■情熱を継続させることが一流エンジニアへの道
一流のエンジニアと接する機会が多いが、彼らには共通の特徴がある。単に頭が良いということではない。情熱を継続させるテクニックを持っていることだ。たとえスキル不足であっても人の2倍、3倍の期間、情熱を持ち続けて仕事に取り組めば一流になれる。そうした経験を経て、一流のエンジニアになれるのではないだろうか。
では、彼らはどうやって長い間、情熱を持ち続けることができるのだろうか。個人差はあるかもしれないが、現在の仕事を達成するという目標よりも、「1ランク上の目標」を夢に抱いている人が多い。そして、その目標は世間のレベルとそれほどズレておらず、しっかりと現状を踏まえたうえで決められたものである。
そのような一流のエンジニアは、現在の仕事を語るときも1ランク上の目標を語るときも、非常に生き生きとしている。皆さんも、日々の業務に目標を持つことも重要であるが、1ランク上の目標を夢として抱いてみてはいかがだろうか。また、自分戦略の一環としてその情熱を継続させるテクニックを考えることも、日々の勉強と同じくらい大切であることを知ってほしい。
■エンジニアの究極の価値
今回は、伸び悩む若手技術者に「エンジニア道」を伝えるために私見を述べてきた。エンジニア道とは、「ソフトウェアを通して展開される仮想世界に、何らかの構造を作り出し、人が理解しやすいように見せる」ことと、前段で説明したが、それではエンジニアの究極の価値とは何か。
エンジニアの究極の価値とは、「仮想世界を視覚化するテクニックを身に付けていること」だと思う。このテクニックはソフトウェア開発以外にも応用が利くものだ。例えば業務の視覚化（ビジネスモデリング）もそうだ。これからのビジネスは、存在しないものをあたかも存在していたかのように視覚化する（見せ掛ける）技術が必要とされる。そのテクニックを持つ人材の価値は必ず高まるだろう。
そう考えると、エンジニアは時代の先端を突っ走っているのである。その意味においても、エンジニアは社会的な責任を負っているのである。エンジニアの仕事は、コンピュータから飛び出て人間の思考に深く関係する重要な役目を担っている。そう考えることは、自分自身の情熱を継続させために効果的な思考法の1つなのである。
|
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
