embrace the conflict -- 葛藤を楽しもう

はじめに

この文章は、 2003年の新入社員に「今後の技術動向とそれにそなえるために」というテーマで話したことからできたものです。 その時話した内容の中には重要な視点が含まれているような気がして、 整理しなおして文章にしてみようと思いました。

まとめながら、何を言いたかったのか自分で考え直してみた所、 「葛藤」という言葉がキーコンセプトとして浮かびあがってきました。

概略

葛藤の時代

これまでの20年とこれからの10年

私がこの業界で仕事をはじめて今年でちょうど20年になります。 この20年の間にコンピュータの世界は大きく変わりました。 20年前には、コンピュータで業務システムを提供するベンダーは、 ハードウエアもOSもデータベース等のミドルウエアも全部、自社開発していました。 もちろん、アプリケーションも自社開発ならそれらの構成要素をまとめあげるシステムエンジニアもベンダーの社員でした。 それが、今ではこれらは全て、別のベンダーが手がけるようになっています。

また、20年前にはパソコンは個人が趣味で使うもので業務用のシステムのパーツとはみなされていませんでした。 もちろんインターネットもアメリカのごく一部の研究者が使うもので、 そんな名前を聞いたことがあるコンピュータ技術者はほとんどいませんでした。 しかし、今ではネットとパソコンに関係のない業務システムはほとんどないと思います。

ですから、これから技術者として歩みはじめるみなさんに何か話すとしたら、 「これからこの業界では大きな変化があります」と言っておけばまず間違いはありません。 この20年に起きた変化と同等の、あるいはそれ以上の変化があるのは確実です。

私も実際に「変化」というテーマで話をまとめようとしました。 20年後は想像もできませんが、10年くらいのレンジなら想像がつく所もあります。 10年後に、みなさんが技術者としてどのように仕事をしているのか、 なるべく具体的にイメージしようとしてみました。

そうしたら、イメージが明確になるにつれて「変化」という切り口では、何か足りないものがあるように私は感じました。 もちろんこれからもこれまでと同様に大きな「変化」があるのは確かだし、 どのような「変化」が起こるのかもある程度予想がつきます。 でも、「変化」をメインテーマとしてお話しするのは、何が違う気がしました。

それが何なのかしばらく考えてようやくconflict(葛藤)というキーワードが浮かびました。 ですから、今日はこのconflictということをテーマにお話したいと思います。

変化と葛藤

私が変化という言葉で満足できないのは、 変化という言葉が「全員が同時に変わる」ということを暗黙に意味しているからです。 例えば、明治維新と太平洋戦争の後、日本は非常に大きな変化をくぐりぬけています。 価値観も社会のシステムも180度転換しました。 でも、これは日本人全てが一斉に経験した変化です。 みんなそろって、進む方向を変えてしまいました。

近くはバブルの時にも同じことが起きたし、 我々の業界で言えば、ベンダーが自社開発をしなくなったのも大きな変化ですが、 日本の各メーカーが自社の顧客に提供するシステムで、 WindowsやOracle等の重要な構成要素に他社の技術を使用するようになったのも ほぼ同じ時期です。

このような動きは急激に起きますが、 起きてしまうとそれが当然のことになっていまい、 昔のやり方はなかったかのように忘れられてしまいます。

これから起きる変化は、このようには進まないと私は予想しています。 つまり、これまでの違うある特定の価値観が主流になって、 みんながその価値観や考え方にのっかって一斉に仕事の方法を変える、 というようなものではないと思います。

そうではなくて、これから起きることはひとことで言えば「価値観の衝突」です。 つまり、大半の人々が同じ価値観に添って仕事をすることはなくなり、 同じ業界の中に複数の価値観が同時に存在するようになると思います。 そして、価値観と価値観が衝突して混乱を起こすことも多くなるような気がします。

例えば、オープンソースソフトウエアが業務システムで使えるかどうかというテーマで、 「使える」という人と「使えない」という人が両方いて、 業界全体としての見解がなかなか収束しないというような状況です。 こういうことがいろいろな形で起きると私は予想しています。

なぜ葛藤が起きるのか

なぜ、葛藤が起きると予測しているのか?ひとつには直観です。 10年前、インターネットというものを知った時に、 私は「この技術はコンピュータ技術者や研究者だけでなく、一般大衆の生活にも大きな変化を及ぼす」 と直観しました。 これと同じように、まず直観で「葛藤の時代」が来ることを感じます。

しいて、根拠を述べるとしたら、次の3点になるでしょう。

インターネットのインフラ化

現在、ハードディスクレコーダーという商品が発売されています。 テレビから受信した動画情報をハードディスクに記録する家電製品です。 これらは、付加機能として、ネットから番組表を取りこんだり、 録画した動画をパソコンで見ることができるようになっています。

このような製品を開発する際には、家電の考え方とパソコンの考え方を両方持つ必要があると思います。 家電は完結した一定の操作性を重視しますが、パソコンは拡張性や相互接続を重視します。 おそらく、両者の常識は葛藤を起していると思います。

また、今後、ネット上に動画のデータがたくさん提供されるようになると、 この製品はテレビと同様、ネット上の動画をいかに取りこめるかが重要になります。 そうなると、ユーザにとって最も重要な選択基準は、 細かい操作やデータ容量ではなくて、 どれだけ簡単に自分の見たい番組を探せるか?ということになると思います。 つまり、検索サービスやポータルの機能が重要になってきます。 ということは、製品そのものの機能や性能でなく、それに付随するネット上のサービスの良否が売れゆきを決めることになるでしょう。

この場合は、「物を売る」という製造業的な価値観と「番組情報を提供する」というサービス業、メディア的な価値観が葛藤を起こすでしょう。

このようにインターネットの存在を前提とすることで、 あらゆる製品、あらゆるサービスが根本から考え方を変えなくてはなりません。 それは、これまでと異なる世界との出会いに伴なって起きてきます。 インターネットにはいろいろなものを「つなぐ」という性質があるからです。

オープンソースソフトウエアの実用化

LinuxやApacheをはじめとするオープンソースソフトウエアは、 インターネットのインフラとして多くの現場で実用的に使用されています。 今後は、業務システムにおいても同様に使用されていくでしょう。

オープンソースソフトウエアは技術的な革新ではありません。 むしろ、技術的にはやや保守的で実績のある技術をベースにしているケースの方が多いと思います。 しかし、その開発形態や開発者の考え方、行動の基準はこれまでのソフトウエアと大きく違います。

ソフトウエアは、技術であると同時に文化です。 成果物を作成者と切り離して単独で取り出すことはできません。 また、静的なソースコードでなくて、動的な開発プロセスが維持されていてこそ、 安心して使用できます。 特に、OSや開発ツール等の基盤となる技術を使うためには、 特定の完成したバージョンを見ていればいいのではなくて、 開発プロセス自体に着目してこれを理解して、場合によってはそのプロセスにかかわることが必要です。

そのような意味で、 あらゆるビジネスはオープンソースとのかかわりを求められますが、 これはビジネスにとって異質の価値観をどのように自分のプロセスに取りこんで行くかという、 大きなチャレンジになるでしょう。 ここでも、大きな葛藤が起こると思います。

社会や経済の変化

ソフトウエア開発は物理学や数学と違い、人間系を含んだシステムです。 ですから、社会の動きと無関係ではいられません。 また、ビジネスの中でソフトウエア開発を行なうとしたら、 経済の動きとも無関係ではいられません。

コンピュータは一般の人々の生活の中に深く浸透していますから、 コンピュータにおける変化は人々の行動や考え方に大きな影響を及ぼします。 例えば、携帯電話のメール機能によって、若者の交友は大きな影響を受けていますが、 逆に、携帯電話のベンダーにとって若者は最も重要な顧客層で、 その行動形態は市場調査の重要なテーマだと思います。

多くの評論家が、社会や経済の価値観の変革について述べています。 ネットやコンピュータ関連製品が、人々の生活や社会のなりたちを大きく変えますが、 逆にそれによって、コンピュータシステムに求められることも大きく変化します。

この相互的な過程が振幅を大きくして、大きな葛藤となるのがこれからの10年ではないかと思います。

多様化と葛藤

このような現象を表現する時には「価値観の多様化」という言葉の方が一般的でしょう。 でも、多様化という言葉には複数の価値観が平和的に共存するイメージがあります。 ちょうど、日本の政治システムで言えば、自民党と社会党のような関係です。 互いに相手を非難していましたが、相手の考え方が存在することまでは否定していませんでした。 このような関係には「多様化」という言葉の方が適しています。

しかし、無党派VS既存政党の対立はこれよりもう一歩深いレベルでの衝突です。 自民党は比較的柔軟に政策を調整してその時々のトレンドに合わせてきた政党ですが、 無党派という言葉で代表される動きには対応に苦慮しています。 ある意味、既存の政治システム自体を否定するような要素を含んでいるからです。

価値観とは世界観ですから、「敵」あるいは「対立概念」を含んでいます。 相手の考え方に同意できないということではなくて、 相手の存在を自分の世界観に含めることが難しい、 というニュアンスを表現するためにあえて私は「葛藤」という言葉を使っています。

そのような互いに相手をつぶし合うような関係にある複数の価値観が並立する時代に、 これから我々の業界は、日本は、突入していくと私は考えているのです。

葛藤の時代にどう備えるか

戦略と枠組みを持つ

みなさんは、これから技術者としていろいろなことを覚えていかなくてはなりません。 その中にはプログラミング言語のように明確に表現されている知識もありますが、 微妙なニュアンスを含んでいて言わば「体で覚える」べきこともたくさんあります。

開発手法もウォーターフォールと呼ばれる、ドキュメントの記法や工程が明確に固定的に定義されたものから、 XPやアジャイルと呼ばれるダイナミックな手法に移行しています。 思想や目的を意識していないと、単なる手続きやきまりごととしては学習できないものになっています。

もともとコンピュータ技術者に必要とされる知識は、 量的に膨大なものでただ覚えるだけでも大変なものですが、 このような価値観の葛藤の中でこれを学習していくのは大変なことだと思います。

リーダによって全く違うことを重視していたり、 あるお客様に喜んでもらえたことが別のお客様を怒らせてしまったりします。 本によって全く逆のことを書いていて、どちらの主張が正しいのか判断がつかなかったりします。

ですから、これからの技術者には自己啓発に関して「戦略」と「枠組」が絶対的に必要だと思います。 「戦略」とは葛藤の中でどのように学習していくかの基本的な方針です。 「枠組」とは葛藤し矛盾する知識を整理するための箱を自分の中に持つと言うことです。

これから、ひとつの戦略とふたつの枠組を紹介します。 これが役に立てばもちろんうれしいですが、役に立たなかったとしたら、 それに代わる戦略と枠組をみなさん自身で探して下さい。

戦略1: T字型勉強法

T字型勉強法とは、次のふたつの方針で勉強することです。

前者がTの字の横棒で、後者が縦棒です。

もちろん、幅広いジャンルで深い知識をつけられればもうしぶんないですが、 限られた時間の中では不可能なことです。 コンピュータの技術は進歩が早いので、どんな優秀な人でも知らないことばかりです。

横棒が必要なのは、必要になった時に必要な知識を覚えたり調べたりするためです。 ソフトウエア開発は分業や専門化が進んでいないので(原理的に不可能)なので、 必要になったら、どんなことでもやらなくてはなりません。 それもシステム開発の工程の中である期間内に理解しなくてはいけない、 というケースが非常に多いです。

ですから、どんなジャンルでも全く知らない分野がないようにします。 極端に言えば、意味を知らなくても用語だけは聞いたことがあるという状態にします。 中身を知らなくても用語を聞いたことがあるのと聞いたことがないのでは、 話の瞬間的な理解が違ってきます。

そして、それだけでは薄い知識になってしまうので、 何でもいいから自身の持てる分野をひとつだけ作り、徹底的にそこを勉強するのです。 理論的な専門書も読んで、ソースを読んで理解します。

ひとつのジャンルで深いレベルまで理解しておくて、 一番いいのは自分の知らないジャンルに関して、 「どれくらい知らないか?」の見当がつくということです。 「知らない、わからない」にもレベルがあって、 あと一時間本を読めばわかる場合もあるし、 一年間大学で研究しないとわからないこともあります。

現場の業務では、「わからない」ことがあとどれくらいでわかるようになるか、 ということを予想することが必要です。 早めに見切りができれば、自分にはできなくてもプロジェクトとしては対策が打てます。 「あとちょっとでわかる、できる」と言っていて、そのままズルズルと作業をして、 期限ぎりぎりで「やっぱりできません」というのが最悪パターンで、 これと比べれば早めにギブアップしてもらう方がずっといいのです。

ひとつの分野を極めた人は、自分のわからなさについて「どれくらいわからないか」 「どうわからないか」「自分には何が足らないのか」等を比較的明解に説明できます。 これが重要なことです。

ですから、T字型を意識して、横棒を横に伸ばし縦棒を縦に伸ばす努力を同時にするという戦略は、 非常に有効なものではないかと思います。

枠組1: サラリーマンVSテクノロジスト

テクノロジストとは、高名な経済学者/経営学者であるドラッガーの言葉です。ドラッガーについては下記のURL等を参照してください。

ドラッガーは抽象的なことを言っているのではなく、 我々技術者ひとりひとりの日常の働き方が大きく変化する、変化しなくてはいけないと言っています。 また、堺屋太一や大前研一なども大枠では似たようなことを言っています。

同感できる所も多い反面、サラリーマンの実感からは非常に現実離れした考えを言っているようにも思えます。 しかし、私はオープンソースソフトウエアというものが、まさにこれらの人が言っていることを実証しているように感じます。 オープンソースという活動はリーナス・トーバルズのような特定のスターに注目が集りがちですが、 重要なのは、そういうリーダの下に無数の開発者が参加していることです。

Redhat Linuxと書かれたCDの中には、トーバルズの開発したカーネルだけでなく(実際にカーネルのコードを書いた人の数も膨大なものですが)、 大量の良質なソフトウエアが含まれています。 ある程度厳選しても数百という数の重要なソフトウエアがボランティアによって開発されているのです。

このようなものが存在することは、経済的な動機や特別な技術者の気まぐれとしては説明できません。 まさに「知的労働で生まれる成果物(知識、アイデア、情報)はそれ単体では役に立たない。自らの成果物を、他人に供給する必要がある」というドラッガーの言葉に多くのプログラマが直観で従っている結果だと思います。

一方で、これが従来のサラリーマン技術者としての価値観と葛藤を起こすことも確かです。 例えば、XPという開発手法には「週40時間労働」というプラクティクス(実践項目)があります。 XPでは、開発の工程が濃縮されていて、従来では考えられないような集中力を必要とするので、 残業することでは決して効率が上がらない、納期が早くなることはあり得ない、という主張です。

プロジェクトが遅れて取引先に迷惑をかけている状況で、これが貫きとおせるか、とおすべきなのか?

もしXPの効果がある程度実証されていたら、 技術者としては技術的な結論、つまり「週40時間をキープすることが、最も早くシステムの開発を完了する」という結論に従うべきでしょう。 しかし、日本人でサラリーマンでもある人の多くの技術者は、私もそうだと思いますが、それを貫徹することはできないでしょう。 技術者として持ってる価値観以外に重視すべき別の価値観があるからです。

ドラッガーは「所属企業への忠誠心から職業倫理への忠誠心」という表現で、 今後は、多くのテクノロジストが行動基準を変えると言っています。 そのような方向性があること、ソフトウエア開発の技術を体得する上で、それが重要であることには、私も同意しますが、 この変化が、一斉にギャップなく起こるとは私には思えません。

そこには多くの葛藤が起こるだろうと思います。

また、日本では電機メーカーがコンピュータシステムの主な提供者となっています。 ドラッガーや堺屋の言う変化は、規格大量生産から知価社会への移行に伴なって起こると言っていますが、 この矛盾を両方持っているのが、そのような提供者だと思います。

つまり、現在、サラリーマンが持っている行動基準や価値観は非合理的なものではなく、 規格大量生産を最適化するためには、最も適した文化だったと言うことです。 実際、日本はこの文化を基盤として高度経済成長を成し遂げ、世界第二の経済大国となったわけです。 ある状況においては、非常に合理的な選択だったわけです。

ですから、この葛藤は合理/非合理の対立ではなくて、 状況、環境が変化する中で、合理的な行動基準が変化しているということです。 ふたつの合理的な価値観が葛藤を起こしているわけですから、 この葛藤は深刻なものになるのではないかと思います。

キーワードとして、両者の違いをまとめておきます。

枠組2: コンピュータの4つの文化

もっと具体的なソフトウエア開発に直結する葛藤の例として、 ある所に書いた、ソフトウエア開発の葛藤について述べた文章を引用します。

ソフトウエアは'70〜'80にかけて、互いにほとんど交流のない4つの領域に分裂して進化した。それが'90から相互に浸透しはじめ、インターネットの発展とともにこの4つの領域をしきる壁は消滅しつつある。これが、純粋な技術の問題であれば、「正しい」方法を見つけるのも混ぜ合わせることも容易だが、この4つの領域は「文化」と呼ぶのがふさわしいような、精神的なポリシーを持っていて、単純に混ざることにはならない。現実の文化と同様に、摩擦も起きているし、交流によって面白いことが起きているケースもある。

ひとつめはメインフレーム文化。規律主義。汎用機(大型コンピュータ)は非常にクリティカルな業務を多くの人間が組織として開発する。たくさん人を集めればコンピュータに向かない人も嫌いな人も混じる。従って規律に従うことと、担当分野を明確に分けることが重視される。

典型的なシステムがデータベース。はデータモデルを作成したりチューニングするには高度なノウハウが必要であるが、データの入出力はという簡易なインターフェースで行なう。管理者や設計者は高度な専門家、SQLでアプリケーションを書く人は兵隊。兵隊は高度なノウハウは不要で何か失敗しても影響が局所的ですむようになっている。

次はUNIX文化。実用主義。コンピュータのハード性能が相対的に低いので、創意工夫と積極的、意識的なトレードオフが重要。100%は求めず、職人技で80%の仕事をこなすことを重視し、20%を切り落とすセンスを追及する。

C言語はこの発想でできていて、ポインタのような有用ではあるけど使い方を間違うと悲惨な結果を産む機能がある。予約語は少ないが、学ぶことは多い。芸術と呼べるような美しいプログラムも書かれているし、誰にもデバッグできない悲惨なプログラムも多く書かれている。

次はパソコン文化。刹那主義。パソコンは一人が占有して使うことが特色で、失敗しても他人に迷惑をかけない所が他のシステムと違う。そのため、根本に「とにかく動けばよい」という発想があり、準備したり勉強したりせずに誰にでも使えることが重要とされる。

VisualBasicのように言語と処理系が一体化している開発ツールがその典型。実行性能や保守性を捨てて、短期的な生産性とわかりやすさを重視している。GUIは、(非熟練の)開発者にとってもユーザにとってもわかりやすいので重視される。

最後がこのようなハードの発達とは離れた所で発生した学者文化。理論主義。ものごとの根本を考えて、ひとつの発想でできるだけ多くの領域をカバーしようとする。実用性より整合性を重視する。

Lispという言語が典型で、最も古い言語のひとつだが、ベースとなる理論が優秀であったため長く生き残っている。そのわりにはユーザが少ない。一方で、GCとかシンボルとか高階関数のように、Java/Python/Rubyのような最新の言語にも多くの影響を与えている。

これが混合している例としてはVC++。V=Visual処理系=パソコン文化、C=C言語=UNIX文化、++=オブジェクト指向=学者文化の混合で成りたっている処理系であるが、その内部で使用されているMFCというライブラリはパソコン系の人にも学者系の人にも評判が悪い。EJBは、E=Enterprize=メインフレーム文化、J=Java=UNIX文化、B=Bean(部品化)=パソコン文化の混合である。うまく育てば、品質と生産性と柔軟性を兼ねそなえた枠組になるが、修得は難しい。

セキュリティホールという問題は、UNIX文化の実用主義、パソコン文化の刹那主義が、汎用機の領分であるクリティカルな業務に進出したことから発生した。解決されないのは技術的な問題と言うより文化的な問題ではないだろうか。

この分類は、私が個人的に考えたもので確立された一般的なものではないが、現代のソフトウエア開発にはこのような意味で複数の思想が複雑に入り混じっていることは確かである。そのため、学ぶ時にある程度意識して源流を見極めることが必要ではないかと思われる。(仕事によって重視されることが違ったり、先輩が本に書いてあるとと逆のことを言ったりするかも)

オープンソースの最も重要な意味は、違うバックグラウンドを持った人が出会い、共同作業をする場であることかもしれない。