使う側の視点と作る側の視点

新年、明けましておめでとうございます。

2013年の最初の記事に何を書こうかなあと考えている。

組織にいるときは「自分が組織を通じて社会に何を貢献できるのか」を、プライベートな立場では「個人としての自分が社会に何を貢献できるのか」についていつも考えるようにしている。

その中で、新人技術者の教育を始めるに際して、いつも話している事柄があるので、読者の皆さんにも役立つかもしれないと考え、これを紹介しようと思う。

技術者には使う側と作る側の両方の視点が必要

今の時代、社会人になる前にもの作りに触れる機会はかなり減ってしまったと思う。社会が成熟するにつれて、生活の中で不便と感じることを解決するデバイスが次々と供給され、不便がどんどん駆逐されている。

企業が次々と不便を便利に変える商品を投入していったことで、エンジニア予備軍となる若い人たちが、自分のアイディアで不便を便利に変えるくふうの機会が減ってしまった。

だから、多くの若い人たちは使う側の視点しか持たないようになり、かつ、もの=デバイスを使うことは楽しい=FUN という感覚が支配するようになった。

この流れは「当たり前にできていること」に対する関心を薄れさせ、「当たり前にできていること」の裏側にある仕組み、工夫に対する感動やそれを作った人への畏敬の念を忘れさせてしまう。

すべてのエンジニアがみんながそうなってしまったら、日本も終わりだなと思う一方で、そういう環境が若いエンジニアを変質させていることを認識して、じゃあどうすればいいのかを考えるのが我々の仕事だと思う。

だから自分は、冒頭の図を新人技術者たちに示して、これまでは使う側の視点しか持っていなかったかもしれないが、これからは作る側の視点を持ち、それまで自分たちが知らなかった「当たり前にできていることの仕組み」に感動できるようになりなさい、と諭している。

今やTOYOTA だって「FUN TO DRIVE, AGAIN.」なのだ。車は移動の手段ではなく、運転を楽しもうと言っている。

このスローガンは日本がいい意味でも悪い意味でも成熟してしまっていることをよく表していると思う。

こういう世の中で、もの作りをする技術者に不足しがちなのは「要求を実現するために必要な技術に対する飢え」だと感じる。何か足らないこと、不便に感じていることを自分が実現してやるというモチベーションが下がっている。

ある意味それは当然である。ユーザーが解決して欲しい問題はほとんど先人が商品化してしまっているからだ。先人が強いモチベーションで作った商品にちょっとした機能を付け加えたり、改変したりする仕事しかなかったら「よし、やったるぜ」という気持ちにはなれないだろう。

だからこそ、先人の技術者たちは商品を通じて社会やユーザーに何を貢献しようとしたのか、何が貢献できているのか、どんな工夫が貢献に結びついているのかを、新人技術者たちに説明する義務がある。

新人技術者は残念ながら商品を自分の手でゼロから作り上げる機会はほとんどないかもしれないが、商品開発の歴史や課程を知ることによって、貢献の疑似体験をするとよい。

自分が作った製品ではなくても、お客さんから「役に立っている」とか「これが便利だ」と言われれば自分のことのようにうれしいだろう。そして、「ここが良くない」とか「こうなると良い」といった意見を聞いたときに、作る側の視点で製品の中身（アーキテクチャ）が分かっていれば、「こうすれば解決できる」という感覚が思い浮かぶはずだ。

新人技術者の人たちには、いざというときに問題解決の方法が思い浮かぶようになって欲しいと思うし、そうなるためにはどんな技術を身につけなければいけないかを常に考えるようにして欲しい。

エンジニアが社会に貢献できるようになるためには、使う側の視点と作る側の視点を持ち、当たり前にできていることの裏側を理解し、それを自在に操れるような技術を習得することが必要なのだ。

P.S.

ここまでの記事を読み返して、新人向けにはよくても指導者向けにはちょっと掘り下げが浅いと感じたので追伸を書こうと思う。

百万行を超えるソフトウェアシステムが珍しくない昨今、新人の技術者に対して、ただ単にソフトウェアシステムのアーキテクチャを理解できるようになれというのは、あまりにも不親切なアドバイスだと思った。

現代のソフトウェアエンジニアはもしかしたら、好むと好まざるとに関わらず、システム全体の構成を設計するごくわずかなアーキテクトになる者と、システムの一部の開発を担当するか、変更要求に応じた設計をする者や、テストを専門に行うテスターなどに分業せざるを得ないのかもしれない。

皆がアーキテクトになれればハッピーかもしれないが実際には組織の中で実力でその地位を奪い取る競争をしなければならないだろう。

今の世の中それはしようがないとして、こんな時代にソフトウェアエンジニアはどこにモチベーションの源泉を求めればよいのだろうか。

それは、ソフトウェアシステム全体の中で自分がやっている仕事がどんなユーザー要求に貢献しているのかを理解し、システムの一部であっても自分が顧客要求を満たす価値を生み出していることに満足を感じることが大事なのだと考える。その貢献度が自分の成長とともに大きくなっていけば高いモチベーションを維持することができる。

そう考えると最初に必要なのはシステムの要求仕様を完全に理解することである。新人技術者は自分が担当する製品やシステムの要求仕様書を理解し、分からない言葉がない状態に早くなることをまず目指す。

そのためには要求仕様書の完成度が高くないといけないし、要求仕様に設計仕様やアーキテクチャの記述が含まれているとよくない。優れた要求仕様書はユーザーが理解できる言葉で記述されている。そして、どうすれば要求が実現できたのかを判定する判定基準が明確になっている。先人は、優れた要求仕様書を後の世代のために残すことが求められている。

そして、要求仕様が理解できるようになったら、次に若いエンジニアはアーキテクチャ設計書を読む。アーキテクチャ設計を理解するにはそれなりのスキルが必要だが、アーキテクトになりたいのなら要求仕様とアーキテクチャ設計の結びつきを理解できるようにならなければダメだ。要求仕様とアーキテクチャがばらばらであることに気がついたら、アーキテクトにのし上がれるチャンスがある。要求仕様とアーキテクチャが綺麗に整合するような設計ができるようになれば、アーキテクトとして認められる。そこまで到達しなくても、要求仕様とアーキテクチャの関係性に何らかの違和感を感じることができるようになれば、アーキテクトになれる可能性はある。

そのためにも、先人は現行システムのアーキテクチャが分かるような情報を残さなければいけない。言わずもがな、アーキテクチャ設計を説明する資料がないようでは、100万行を超えるソフトウェアシステムを維持し続けることはできないし、新人技術者に指導するのも無理だ。口づてで伝えられるような情報量ではないし、ソースコードでは階層的に理解を進めることができない。

現代の新人エンジニアを本気で組織的に育てようとするのなら、先人の技術者たちがソフトウェアシステムの上流工程のドキュメントをしっかり作り込まないといけないということである。

ベテランのエンジニアもこれまでの実績にあぐらをかいていたのでは、行く先が危ういのである。