覚ませとは？/ マイワン
[ 650] 危険な技術への盲進から目を覚ませ（1）
[引用サイト] http://jibun.atmarkit.co.jp/lskill01/rensai/uru01/uru01.html
|
最新の粋を集めたプロジェクトが、大きなトラブルで頓挫（とんざ）したり、予定より大幅に遅れることは珍しくはない。いま、ITエンジニアに求められていることは何か。ウルシステムズの漆原氏が、思いのたけを語る。 さまざまなIT技術用語があふれ、まさに群雄割拠、技術変革の面白い時代に生まれたことを私は感謝している。従来の延長ではない、という新しいチャンスに満ちており、多くのメディアも新時代到来を裏付けするかのごとく、新しい技術により「魔法のように」問題が解決することを書き連ねている。オブジェクト指向、J2EEや.NET、フレームワークとコンポーネント、RUPに代表される新しい開発方法論。さらにはUMLなど……。もちろん、このような時代の中でわれわれ自身も常に意を新たに技術の先端を追求していくことに微塵（みじん）もためらいはない。 一方で、鳴り物入りの最新技術の粋を集めたプロジェクトが、大きなトラブルで問題となるケースも少なくない。メディアは新しい技術を自慢げにお披露目しながら、一方ではひどいトラブルを面白おかしく読み上げる。 われわれのところにも先週2件、今週3件といった具合に、クライアントからそんなプロジェクトへの救援要請がくる。そのプロジェクトをよくよく調べると（大して調べなくても分かることだが）、すでに末期癌（がん）的なプロジェクトがほとんどである。 もちろん大赤字は必定、クライアントは不満のかたまり、最悪の場合は撤収・訴訟という誰も望んでいなかった結末に向かってまっしぐら。それこそ「やらなきゃよかったプロジェクト」が死屍累々と連なる。もちろん、われわれ自身も例外ではなく、手痛い目に遭いやっとの思いで仕上げたプロジェクトの経験もある。そのような経験こそが至宝であると思っている。 新しいことへのチャレンジ、特に技術サイドからの挑戦が、下手をすると手段と目的を取り違えることとなってしまい、プロジェクトの成果が技術者の単なる自己満足に終わっている例が多々ある。クライアントは納得していないし成果も出ていない。 その一方で、メディアのトークに流されたりせず、しっかりとクライアントに貢献している技術者も多い。本物を目指し着実に前進している技術者が正しく評価されないのは、社会的損失である。日本の技術の底力を信じ誇りに思っている技術者の方々と本当の議論をするために、あえてこの連載を引き受けさせていただいた。今回は、われわれが感じているさまざまな問題を提起する場としたい。 最近は特にUMLやJ2EEフレームワーク、コンポーネントブームだ。また、当然ながらトラブルが増えてくるとプロジェクトマネジメント論や開発方法論に目が向かうようになる。さらに、まだ新しい技術なので成果が出るのは先だ、とメディアは書き立てる。果たして本当なのであろうか。 そもそも技術者として、技術の効果をきちんと理解したうえで仕事をしているのだろうか？ 自らが、できもしない幻想を抱いて仕事をしていないか？ そもそもの根本は、安易に技術のよさそうな面だけを短絡的に理解しようとする怠慢からくるのではないか。メディアに左右されがちな不安定な風見鶏の技術者が多いからではないか？ だいたい、「J2EEだから再利用できる」という話が広まってきたころから話がおかしくなってきた。さまざまなツールベンダも、「J2EE準拠だから再利用できますよ」とこぞって書き立てる。確かに、クライアントが運用の保守やバージョンアップ費用に苦しめられているのは事実である。何となく解を見つけたような気がしてしまい、再利用すると安く済むので、これからはJ2EE、と短絡的に理解する。 運用保守費用を下げるには、まず高いといわれている運用保守費用の分析と解決策立案が欠かせない。その過程を全部スキップした揚げ句、「再利用するとすべてバラ色」というのはいかにも短絡的である。確かに（恐らく）クライアントへの受けはいい。 しかし蓋を開けてみると、できたのはせいぜい基本部分のボルトとナットの共通化が関の山であり、「汎用で使いやすいコンポーネント」などは、そのままではいつまで待っても出てこないことに気付く。 共通プラットフォームやフレームワーク化により開発の生産性が上がることは事実である。われわれも積極的に推進している技術である。が、再利用とそのための投資と効果については、積極的な議論を喚起したい。われわれは、しっかりした設計とそれを忠実に反映した実装そのものがクライアントにとって生産性を上げる最大のポイントと考えている。 UMLも大変なブームだ。このこと自体は素晴らしいことであり、ようやく皆で共有できる交通標識が認識できたと歓迎している。しかし憂慮しているのは、業務分析とシステム設計が混同して議論されている実態である。確かにどちらもUMLで表記できるが、手法は同一ではない。UMLで表記を統一すればすべてうまくいき、要求仕様がそのまま実装に反映されるわけでは決してない。UMLはせめて前提にした方がいい（でないと表記法をどうするかから議論しないといけない）。そのうえで業務分析をしたり、要件定義をしたりシステム設計をしたりするスキルセットは、まったく別に必要である。 UMLはシステム側から派生したツールであり、特に業務においてクライアントとごく普通に話し合えるほど一般的にはなっていない。例えば、オブジェクト指向を使って業務モデルを最適化できる、というような考えほど危険なものはない。逆に業務を知らない人や分析力がない人がいくらモデルを想像で捻出（ねんしゅつ）してもほぼ趣味の域を出ないのである。 特にオブジェクト指向設計に限らないが、往々にして技術的手段が目的化してしまうことが多い“オタッキー”な技術者には注意が必要である。設計から実装まで完了し、ビジネスの役に立って初めてプロジェクトゴールに達するのだが、手段が目的化してしまうと例えば過剰なまでにモデルにこだわり、延々と議論してプロジェクトが進まない羽目に陥る。われわれも多くのオブジェクト指向プロジェクトを経験したが、趣味でモデリングしたプロジェクトを軌道に乗せるのは至難の業である（この原稿を社内に見せたら、そんなモデルは捨てればいいので、軌道に乗せるのは簡単だ、とコメントをいただいた。ごもっともである）。 プロジェクトマネジメントや開発方法論ブームについても疑問がある。そもそもオブジェクト指向開発だからといって、どうして急に手が止まるのか。いままでやってきた何もかもが役に立たないかのように不安になるのはなぜか。素晴らしいテクノロジでプロジェクトを率いてきた中堅クラスの技術者が、J2EEやUMLになった瞬間、急に訳が分からなくなって若者に一任してしまう。結果は火を見るより明らかで、プロジェクトは大火事となる。後になって、実は開発方法論が必要だとかプロジェクトマネジメントを強化しなきゃ、とか平然といい放つ。だったら事前に手を打っておくのがプロではないか。 しっかりとプロジェクトを回すには、何より基本が大事である。もちろんやり方に個別の工夫は必要だが、これまでしっかりやってきたノウハウを全部捨てないと通用しないかのような性急な判断は危険である。自分で実践して確実に成果が出た方法論こそ信頼すべきものであり、後からとってつけたような設計方法や理想ばかりを追い求め、実際に開発で使えない机上の方法論は、戸棚に閉まっておく方が世のためであろう。だいたい方法論で開発がうまくいくようになるのであれば、世の中はもっと平和なはずだ。 技術者が幻想を抱いて自分をだましているようでは、いつまでたってもプロジェクトがうまくいくわけはない。コストと納期と品質を忘れ、自己実現に埋没し、手段を目的化するような技術者は、プロジェクトにとってのリスクそのものであるし有害である。最後はクライアントがすべてを評価する。それを覆い隠すようなメディアの不健康な煽（あお）りは、正しい技術育成の阻害要因であると感じる。 われわれもオブジェクト指向技術にほれて、クライアントに真の価値を届けようと試行錯誤している。バズワード（専門用語のような流行語）なしでしっかりと考え、きっちりと仕上げるプロフェッショナルな技術者こそが、地道にプロジェクトを支えている事実を知っている。またそのようなプロジェクトはクライアントからの評価も極めて高い。 そもそも実装力を含めて日本の技術力が他国に劣るなどと微塵も思ったことはないし、これからも優れた技術者を輩出し続けていく土壌は十分にあると信じている。一度真正面から逃げずに皆でちゃんと議論したい。その機会と議論のネタを今回から始まる連載で提供できれば望外の喜びである。 ＠IT自分戦略研究所トップ｜スキル創造研究室トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ |
マイワンのサイトです。
