ソフト開発未来会議 サイト公開記念 キックオフ座談会
未来会議はなにを目指すのか?未来会議コアメンバーが熱く語るこれからのITの行方
萩本順三 氏 萩本順三 氏 萩本順三 氏 萩本順三 氏
株式会社 匠Lab
代表取締役
萩本順三 氏
ライター
(元 @IT発行人)
新野淳一 氏
株式会社アークウェイ 代表取締役
森屋英治 氏
聞き手
株式会社デジタルアドバンテージ
代表取締役
小川誉久
(@IT/Windows Server Insider編集長)

 

← 前のページへ 01 02 03 次のページへ →
  • ■開発チームが抱える問題点
  • ―― エンド ユーザーと開発を担当するエンジニアが分断されており、コミュニケーションに問題があること、エンド ユーザー側に最適化を阻害する要因があることも分かりました。開発者側には問題はないのでしょうか。
  • 森屋氏: 現場でコーディングを担当するプログラマーと、上流でシステム設計を担当する SE がチームを構成して開発するケースが多いのですが、プログラマーの立場が非常に弱く、彼らの実情が SE に理解されていないという問題があります。以前、現場のプログラマーを上流設計チームに入れてみて、会議で意見を聞いたことがあるんですが、ほとんどの場合「自分はここで意見してもいいのか?」という反応をします。つまり、現場のプログラマーは、これまで SE の意見を聞く一方で、いわれたものを作るだけ、自分から発言したことがなかったのです。
  • ―― 逆に、現場プログラマーをチームに入れたときの SE の反応はどうでしたか?
  • 森屋氏: 実装で何が難しいのか、難易度がどの程度なのかが初めて分かったといっていましたね。それまでは実装の苦労などあまり気にせず、プログラマーに開発を指示するだけだったのです。SE が実装を理解して設計すると、無理なく実現可能な設計になって、開発効率も向上します。
  • ―― 日本は開発チームのマネジメントがへただとよく聞きます。
  • 森屋氏: よくいわれることですが、年功序列の日本では、適正ではなく年齢でプロジェクト マネージャになってしまうという問題があります。アメリカでは、60 歳を越えても現場でコーディングしている人がいる。一定の年齢になったから管理職であるプロジェクト マネージャになるという発想は間違いです。
  • 萩本氏: 日本では、プロジェクト マネージャが人の管理しかしておらず、技術のマネジメントをしていません。技術をマネージするという感覚を持つプロジェクト マネージャが少なすぎます。
  • 新野氏: 「何をどれだけ作ったか」ということより、「安い外注に仕事を出して、どれだけコストを絞ったか」ばかりが評価されてしまう現実があります。これでは技術のマネジメントに注意が向かないのも当然です。
  • ―― ソフトウェア開発者の技術力という意味ではどうでしょうか。
  • 森屋氏: ゼロからスクラッチで開発する力はどんどん失われています。利用できるソフトウェア パッケージの質と量がともに向上して、全体としてのソフトウェア開発生産性は上がりましたが、パッケージが台頭しすぎて、それを使うだけになってしまっています。スクラッチ開発とパッケージ利用では、同じプログラミングでも求められる技術レベルがあまりに違います。
  • メインフレームからの移行などでは、バグのない完成されたシステムを移行し、そこに機能追加することになりますが、これにはほとんど試行錯誤の余地がなく、スクラッチ力を磨きにくくなっているという事情もあります。
  • ■IT エンジニアこそがビジネスをリードできる
  • ―― 現在の情報システム開発の問題点は分かりました。それでは、それらの問題を解決した情報システム開発の「あるべき姿」はどのようなものでしょうか。
  • 萩本氏: これまで議論してきたとおり、根本的な問題は、要求開発 (システム開発の前段階) に IT エンジニアが参加していないということです。要求開発がきちんとしていないのに、それを元に開発しているからおかしくなる。IT エンジニアが要求開発の現場、つまりビジネスの現場にも積極的に参加して、発言しリードすることが重要です。
  • ―― 個人的な印象として、IT エンジニアはコミュニケーションを苦手とする人が少なくないように思います。ビジネスの現場に積極参加して発言するという必要性は分かりますが、うまくいくでしょうか。
  • 萩本氏: そういう消極的な発想ではなく、IT エンジニアこそがビジネスの現場を変えられると自負してもらいたいです。ソフトウェアの価値は、できるだけ複雑さを省いたシンプルなモデルを考えて、無駄のないコードを設計することでしょう。またソフト開発では、目に見えないものと格闘しながら、さまざまなチャートなどを考案し、「見える化」する努力を重ねてきました。こうしたことから、私は、IT エンジニアこそが、複雑化するビジネスを見える化し、きちんとマネジメントしなければならない時代の最先端を走れるような潜在能力を培っていると思うのです。これまでソフト開発で培ってきた方法論をビジネスに応用して、ビジネスの見える化を進めて複雑さや無駄を省いたシンプルなモデルを構築できれば、おのずとビジネスの選択と集中が図れるようになるはずです。
  • ■「How の突き上げ」によるビジネス戦略とIT戦略の融合
  • ―― IT エンジニアがビジネス領域に入っていったとして、具体的にはどんな役割を果たせばよいのでしょうか。
  • 萩本氏: 「要求仕様」などというと、最初から「要求」があるように思えてしまいますが、実際には経営者も、現場の業務担当者も何を要求すればいいか分かっていません。大事なのは、ビジネスをどうするのかという“目的 = What ”だけでなく、いま何ができるのかという“手段 = How ”をビジネス戦略立案に加えていくことです。現状は What は考えるが、How を考えていません。IT エンジニアの役割は、IT で何ができるのかという How をビジネスに提案し、ビジネス戦略と IT 戦略を融合していくことです。いまのビジネスは「How のチューニングだ」といっても過言ではありません。現在はソフトウェア開発サイクルだけに適用されている反復型開発(アジャイル型開発)をビジネス戦略立案のレベルに適用し、IT 戦略も含んだ最適なビジネス戦略を立案することが必要です。こうした目的と手段の連鎖の中で、手段を手探りしながら最善手を選ぶ。この一連の作業で必要なものが「要求」という形式に見えるだけだと思います。
  • ―― ビジネス領域に入った IT エンジニアが、トップダウン的に情報システムを開発するということでしょうか。
  • 萩本氏: いえ、本来はトップダウンとボトムアップが必要ですが、この話だけでいうと上から下ではなく、下が最初です。ただし下だけで進むのではなく、どうしてそうするのか、上に対して根拠付けする必要があります。これを私は「How の突き上げ」と呼んでいます。
  • ―― 日本は製造業が強く、例えばボトムアップ的に生産効率の改善を進め、それがシステムに発展したトヨタの「カンバン方式」などが有名です。これと同じように、現場のプログラマーから情報システムを変えていくということでしょうか。
  • 新野氏: トヨタのカンバン方式は、完全なボトムアップで完成されたものではないと思います。各工程が、それぞれ自分の都合のいいように最適化しても、それが全体最適になるとは限りません。大きな方向性としてのアーキテクチャはある程度トップダウン的に提示し、その中で各工程がアジャイル的に改善しながら、各工程の最適化を進めるという形式でしょう。このように全体的なアーキテクチャ設計にはトップダウンが必要ですが、現場の改善は、見える化を進めて全員で情報を共有し、ボトムアップで無駄を組織的に排除することが重要だと思います。
  • ■破壊して再構築できる力を持つ
  • ―― まずは全体的なアーキテクチャを設計するアーキテクトの存在が不可欠ですね。しかし日本ではなかなか優れたアーキテクトが育たないといわれます。
  • 萩本氏: アーキテクトというだけでなく、本質的には、クリエイティブなエンジニアが少ない、育ちにくい環境だという点が問題です。私はこの原因は、日本では「壊して作る」文化が根付いていないことにあると考えています。
  • 例えば、オブジェクト指向プログラミングは普及したのですが、日本では構造主義に走ったり、ルール主導に陥ったりするエンジニアが多いのです。「これはこういうものだ」という構造やルールが決まると、それに従うことばかりで自分で考えなくなる。すると知識的には空洞化が進みます。その構造やルールが永遠ならそれでいいかもしれませんが、ソフトウェアは未熟ですから、数年ごとにパラダイム転換が繰り返されます。するとそれまでの構造やルールはいったん破壊されます。破壊の後には再構築が必要なのですが、日本の IT 業界人はこれが苦手な人が多いのです。習うことは得意でも、自分で新しい考え方を産み出すのは弱いのです。やはりこれからは、破壊と再構築の双方ができないと、クリエイティブなエンジニアとはいえないでしょう。
  • パターンとかフレームワームの活用も同様です。極端な話をすれば、既成のパターンの背景に何があるのか、パターンがどうやって作られるかを知らないうちは、パターンは使うべきではないというのが持論です。
  • アーキテクトはクリエイティブでなければなりません。

 

← 前のページへ 01 02 03 次のページへ →