← 前のページへ

01 02 03

• ■コーディング経験は必要か？
• ――　再構築する力とも通じるかもしれませんが、プロジェクト マネージャなど、現場のプログラマーをリードする人に、コーディング経験は必要なのか、という議論があります。これについてどうお考えですか。
• 新野氏： 当然ながら、リーダーにはリーダーシップが求められます。プログラマーに対してリーダーシップを発揮する上で、プログラマーがどういう心理状態でプロジェクトに参加しているのかを理解できるのと、できないのでは大きな違いがあります。この意味で、ソフトウェア開発のプロジェクト リーダーには、ある程度のプログラミング経験が必要だと思います。
• 萩本氏： IT エンジニアとしてビジネス領域に参加する場合も、コーディング経験があるかどうかは大きく影響すると思います。
• ――　なるほど。しかし単純なコーディング作業は、より安価なエンジニアを外注として使うことが常識になってきており、これからプロジェクト マネージャを目指す若手が、コーディングを体験できる機会は減っていますね。
• 新野氏： 私もかつてプログラマーだったことがあるのですが、昔は何もなかったので、何でも自分で作るしかなかった。私のときと同じように、若い人が学べる環境があるかというと、それは減っていると思います。どうすればいいのか分かりませんが、あえてそういう場を用意するか、理想をいえば、教育機関にそういう場を拡充してもらうということでしょうか。4 年大学に行ったら、その後 5、6 年くらいプログラミングの勉強をするとか…。
• 森屋氏： 可能であれば、発注だけを行う会社ではなく実際に開発を行っている会社に自分から行って、そこで学ぶしかないかもしれません。
• ――　コーディング経験、実装経験が必要とのことですが、例えば現在は、アセンブリ言語プログラミングを知っている必要はないでしょうし、C 言語プログラミングでは必須だったポインタの知識も、C# や Java など現在の主流言語では不要になっています。エンジニア的な思考方法は学ぶ必要はあるとして、本当にコーディング経験は必要でしょうか？
• 萩本氏： ひと口にアーキテクトといっても、主にビジネス戦略策定に重心を置くビジネス アーキテクトと、IT に重心を置く IT アーキテクトの 2 種類があると思います。このうち前者については、コーディング経験はなくてもよいでしょう。しかし後者は、How からの IT 活用法をビジネス アーキテクトに伝えなければなりません。これにはコーディング経験も必要になるでしょう。IT アーキテクトは、使えるそれぞれの技術をプロジェクトの特性に合わせて最適にマネージしないといけませんが、そうした現場経験がないと、どこにどれだけコストをかけるべきか、コスト感覚が分からないと思います。
• 新野氏： そうですね。簡単にいえば、マネージャにも経営者の方を向いているマネージャと、エンジニアの方を向いているマネージャがあり、後者には実際のコーディング経験が必要だということだと思います。
• ■開発者としての表現能力を磨く
• ――　業務時間も長く、内容も過酷なことから、「新 3K」などと揶揄され、IT エンジニアを目指す若者は減ってきていると聞きます。こうした流れを変えるには、どうすればよいのでしょうか。
• 萩本氏： 日本のエンジニアは、自分の価値を対外的に表現する機会が乏しく、また苦手なようです。欧米のソフトウェア開発者は、プログラミングが優れているだけでなく、自分の価値を表現する能力にも長けています。まず、日本の先輩エンジニアが、こうした表現能力を身に付けることだと思います。
• ――　しかし表現能力といっても、日本のように受託中心のシステム開発では、表現したくてもユーザー企業との機密保持契約などで思うように表現できないという問題はありませんか。
• 萩本氏： 確かにそういう側面はあるでしょう。しかしこれからの SIer は、頭数で何人いるかではなく、社内にどんなコンサルタントがいるのか、どんな特徴ある情報システム開発ができるのかを会社としてもアピールしないと生き残れなくなっていくと思います。実際、私がコンサルティングを担当しているシステム インテグレーターさんは、金融関係の受託システム開発をしていますが、有名コンサルタントを多数排出して、それを企業のカラーにしていくと社長自らが宣言しています。こうしたアプローチが実際に可能なのです。
• ■まず手始めに何をすべきか
• ――　IT エンジニアがビジネス戦略に積極的に関われるようにするために、手始めに何をすればよいでしょうか。まずは経営者の視点でお願いします。
• 萩本氏： 情報部門や IT エンジニアをもっと自分の身近に置くことでしょうね。そして経営側も、もっと IT と共同でビジネスを作っていくというプロセスを検討すべきです。「IT 屋の言っていることはよく分からない」で片づけるのではなく、もっと彼らの話を理解する努力をしてもらいたいです。逆に IT エンジニアは、経営者でも分かるような見える化をして、IT の価値を目的から説明してあげてほしいと思います。
• 私は、要求開発の「コタツ モデル」を提唱しています。企業のトップと業務担当、IT エンジニアがコタツに入って話すような場を作ることから始めるのです。そしてセクショナリズムの垣根をはずし、トップと業務現場の考え方に IT を加えて、How からの突き上げで一緒に考える。これからの本当に生きたビジネス戦略は、こうでなければ作れないでしょう。いま必要なことをスピーディにやれば、戦略が腐ることはありません。
• ――　エンジニア側はどうすればよいでしょうか。
• 新野氏： 多くの開発エンジニアは、「どうして仕様がこんなにコロコロ変わるのか？」「どうしてこんなに無理な納期を設定するのか？」などの疑問を普段から抱いていると思います。こうした疑問に、自分なりに首をつっこんでみるところから始まるのではないでしょうか。これらの疑問に首をつっこむということは、エンド ユーザーがどんな状況に置かれて、何を考えているのかを知ることとほぼ等しいと思います。現業で忙しい中、口でいうほど簡単なことではないでしょうが、ビジネス領域に一歩踏み込む、エンジニアとして上の領域に踏み込むためには、このあたりをきっかけにするとよいと思います。
• ■エンジニアは楽しい
• ――　閉塞を打破して、IT エンジニアが輝く時代はやってきますか。
• 森屋氏： クラウド コンピューティングが進んで、IT エンジニアの仕事がどこかに持って行かれてしまうという危機感があるようですが、正直なところ、コモディティ (日用レベルの比較的低価値のもの) はクラウドに持って行かれてもいいと思います。これは逆に考えれば、つまらない仕事がどこかにいって、楽しいクリエイティブな仕事が残るということでしょう。ソフトウェアの価値は、創造性によって左右されるものです。こうしたキラキラした、創造性あふれる領域を技術者は常に追求してもらいたいし、ぜひここで IT エンジニアが食べていけるようになってもらいたいですね。
• 萩本氏： 「偶然からの創作」を「計画からの創作」に変えたいと思っています。キラリと光るものを、エンジニアリングの中で出していきたい。エンジニアリングや分析というと、機械的な作業に身を投じるようなイメージがありますが、つまらない機械仕事はコンピュータにまかせて、人間しかできないところをうまくエンジニアリングすることで新しいものを産み出したいと思っています。エンジニアにはこれが可能です。今回議論してきたとおり、問題は沢山ありますが、少し別の視点を持てば、チャレンジできる領域がいくらでもあるということです。エンジニアの仕事は、クリエイティブで楽しいものですし、そう思っているエンジニアたちが私の周りにはたくさんいます。
  (2008 / 11 / 14 公開)

 

← 前のページへ

01 02 03