「こんな感じでできました。ちょっと見てもらっていいですか?」
「ようやくできたか。これはどういう構成になってる?」
「ベース部分にオープンソースのライブラリを使ってるんですが、デキがあまり良くない部分があったんで改良を加えてます。これなかなかすごいんですよ」
「えーと、そのライブラリの内容は? ライセンスは? ドキュメントは?」
「まだあんまり有名じゃないんですけど、ベータ版の段階ですから手を加えました。ちゃんと本家にフィードバックします。ライセンスは作者がいいかげんなのか何も書いてませんね。ドキュメントはソースコードそのものです(笑)」
「悪いが全部作り直してくれ。客には謝っておく。ちょっと頭を冷やしてくれ」
「え?」
このやりとりについて、どこに問題があるのか、念のために指摘しておこう。オープンソース利用時によく指摘されている「ライセンス形態が不明瞭」などという問題があるのは当然だろう。しかしそのレベル以上に根深い問題が潜んでいる。
アーキテクトを自称する者であれば、自分の趣味や研究でない限り、顧客(もしくは自社)からお金をもらって作業をする立場になる。こうした場合、作業する時間は契約内での顧客のための作業を行うことが大前提である。これはどの業種であっても変わらないルールだ。
ところが、多くの若年プログラマーは、大学からの延長ととらえているのかどうかは分からないが、作業する目的を自分の興味の赴くままに従ってしまう例が多い(特に社内外から「デキる」といわれている層によく当てはまるかもしれない)。
これはパーソナルコンピュータのプログラム作業が、個人的な興味を土台とした作業に多く立脚してきたというこれまでの経緯を考えれば致し方ないところだとは思う。現に、1980年代の国産PCブームはそうした「高い興味を持った層」によって形成されてきたことは間違いないだろう。筆者自身も、最先端のやりたいことをやって生活できるなら、なんと素晴らしいことだろう、と無邪気に考えていた。
しかし、時代は変わった。コンピュータを使うことは誰にでも当たり前になり、「PCを使いこなせる=最先端を行っている=仕事が舞い込んでくる」という楽観的な図式はもろくも崩れた。多くの企業はすでにコンピュータシステムを「もうけを出せる手段」としてしか見ておらず、システム構築そのものへの過大な期待もなくなっている。投資家の目も冷ややかになった。ITバブルを経てようやく正当な評価に落ち着いた、というのが筆者の率直な感想だが、それに伴い、以前のように最先端を理由に技術者が好きな技術を選択できる余地は少なくなっている。
例えばの話だが、ここ数年来、オープンソースの利用が、特にJava EEを中心として企業向けシステム構築の現場に浸透してきた。筆者自身もオープンソースを基本としたプロダクトの作成や企業システムへの導入、記事の執筆やオープンソースへの還元などをいくつか行ってきた。
何事も行き過ぎは別の問題を生む。最近では「オープンソースを採用しないシステムは悪の手先だ」といわんばかりのメチャクチャな論法でシステムアーキテクチャをゴリ押しする例を筆者は何度も目にしている。つまり、商用アプリケーションにお金を出して導入するのは誤りで、何が何でもオープンソースを採用すべきだ、というわけだ。ただし、お金を出す企業側の担当者の多くは、オープンソースを導入して、サポート用の有能なプログラマーに月額80万払うより、製品サポートに年額60万円払う方を選択する。その方が圧倒的に安くつく、と考えるものである(もちろん、一概にどちらが安価であるかどうかの結論を出すのは危険だし本稿の論旨でもない)。
話を元に戻すが、顧客側の悩みを解決する立場としてのITアーキテクトはまず、そうした客観的な事実を吟味すべきである。冷静に収益向上を第一として作業に当たらなければ、第一線で活躍し続けることなど夢のまた夢である。そこには、自らの個人的趣味を反映する余地はない。
顧客を「自分の技術や芸術性を実現するために出資を惜しまないパトロン」と錯覚するのは、勘違いという度合いを超えた考えだ。もし、そうしたことを望んで企業システム構築の現場に入ったのであれば、その企業も、顧客も、プロジェクトも、そして、何よりも自分自身が不幸になる。そのような人は、ITアーキテクトではなく、研究者として研究所や大学に行って堂々と没頭してほしい(決してそうした活動を否定しているわけではない点を強調しておく)。
残念ながら、ITアーキテクトとしての活動はそうした行動(ここでは仮に「アカデミズム」としておくが)とは対局にある。すなわち、現実の解決策を探求し、妥協点を探る極めて「俗物的」な活動の集大成であるといえる。初学者ならば誰でも、研究書籍に登場するようなエレガントなモデルや、オブジェクト指向の極みとなる美しい設計にあこがれを持つものだ。
しかし、現実に待ち構えているのは、単一のマシン上でエレガントに動作する書籍上の仮想世界ではなく、複雑に分散したマシン上で理解し難いほど膨れ上がったビジネスルールとパフォーマンスチューニングの塊である。そんな状況で、書籍などに書かれていた内容を素直にそのまま展開、実現しても、手痛い返り討ちに遭うだけだ。そもそも、それ以前に一般社会としての厳然たるルールが待ち構えている。特に、企業システム構築の現場で、大学の研究所よろしく自らの趣味に没頭するITアーキテクトがいた場合、プロジェクトの失敗が予期できることはもちろん、実際に失敗した場合には、背任の疑いや損害賠償請求が発生する可能性が高い。ITだけが特別扱いされるはずもない。
そこまで行かなくとも、やはりお金をもらって他人様のシステムを構築する以上、そのために自らの知恵を絞り、限られた範囲内で可能な限りそれを良くしていく、というプロセスは、明治以前から続く日本の美徳かつ強みであるとされてきたはずだ。何よりもそうした先人の足跡は、世界最強といわれる製造業の現場でいまでも息づいており、業務上交わることが多々ある筆者も驚かされ続けている。
情報サービス業やIT業界(という業態が今後続くかどうか筆者は疑念を抱いている1人だが)にしても、特定の機械上で動作するバイナリコードを作成して納入している製造業の一部だとすれば、本元である製造業の洗練された品質追求の姿勢との間には、越えられない壁が依然として存在しているように思えてならない。「市場成熟度が違い過ぎる」との関係者間のエクスキューズが顧客に通用するとも思えない。
それがたとえ、日本版SOX法などを契機に、業務コンサルティング領域に進出しようとしている業界であったとしても、だ。顧客の声に耳を傾けるという、基本かつ真摯な態度から逃げられるはずもないだろう。その業界で働くITアーキテクトであれば、このような状況と今後の自らの在り方、および倫理観について、一定の考えを持っておく必要がある、というのが筆者の持論だ。何よりITアーキテクトは現場の親分となるべき存在である。自らの行動に責任を持って仕事に携わることを肝に銘じるべきだ、と常々思っている。
ところで、冒頭のやりとりの問題としては、ほかにもさまざまな問題をはらんでいる。
例えば、メンテナンス用のドキュメントが存在しないことや、ベータ版に相当する不安定なものを採用してしまったこと、さらにそこに直接修正をしてしまい、本元のライブラリがバージョンアップしたときの乗り換えを阻害してしまっていることなどだ。
特に問題となるのは、(契約形態にもよるが)業務上の時間を利用して構築した成果物を、顧客の許諾もなしにオープンソースに提供しようとにおわせている個所だ。これまで述べてきたとおり、「誰のためにシステムを構築しているのか」という点を考えれば、これが背任行為や秘密保持契約に抵触しかねない行為であることは容易に想像できる。しかし、これを作ったプログラマー側は、「オープンソースを利用したなら、オープンソースに貢献するのは当然だ」と無邪気に考えているはずである。当然、そうした作業が見込まれるのであれば、事前に顧客とそうした打ち合わせや契約を済ませてから作業すべきだろう。
だが、この場合、最も責任があるのは、このプログラマーがオープンソースを無断で利用し、完成するまで中身をチェックしなかったITアーキテクトにある、と筆者は考える。つまり、監督責任がある、ということだ。
本来であれば、構築の方法についてアーキテクトが指示を出すか、またはプログラマーから持ち上がった相談に乗り解決策を探る必要がある。それができていないということは、日ごろからそうした場作りを行っていなかった、あるいは、チェック体制に不備があったということだろう。少なくとも第三者にはそう見える。例では最後に、作り直しを指示していることから、このプロジェクトは当初予定していた線表よりも遅延することが分かる。やはり責任はITアーキテクトにあるだろう。
自らが何を仕事として行っているか、誰のためのシステムを作っているのか。またそれをプロジェクト内にどれだけ浸透させているか。ITアーキテクトの責務は、重い。
Copyright © ITmedia, Inc. All Rights Reserved.