新人／若い人の方へメッセージを送るAdvent Calendarの記事を勝手に書こうと思ったのだけれど、時間が過ぎてしまったので、ここに置いておく。
◇ ◇ ◇
こんにちは、みなさん。
多くの方々は、初めまして、ですね。
新人の方へメッセージを…ということでしたので、空気を読まずに書くね。
いろいろなニュースやブログを読んでいると、たまに論争がある。その論争は、vi v.s. emacs、 Windows v.s. Mac OS, Java v.s. Ruby, NoSQL v.s. SQL、アジャイルv.s.ウォーターフォール…いろいろな論争がある。それぞれ主張は、適した状況下で「その通りだなぁ」と思うことが多い。その論争によってそれぞれのツールや方法論が改善したのかもしれない*1。
あるツールや方法論を究めることも大切だ。しかし、それにとらわれ、他の考えを拒絶することは大きな損失でもあるということをここではお伝えしたい（むろん拒絶することのメリットもあるw）。
- それぞれの状況が違うことを理解すること（どっちも正しいのだ）
- 幅広い観点から見極めてほしいこと（単純でわかりやすい主張は怖い）
- 学び、試し続けること
どっちも正しいのだ
私自身は、とても「よく回っている」現場にいた。そこでは、いわゆるアジャイルプロセスではなく、ビジネスからアジャイルであったため、それに対応するソフトウェアも迅速に変化していた。ドキュメントも、必要にして十分なドキュメントを書いていたし、利益を得るなどの価値も享受していた。しかしながら、ウォーターフォール型開発に移行し、ドキュメントをしっかり書くことに価値を置く文化が台頭してきた。これは、ドキュメントをしっかり書き、承認をとることによって、関係者がわかり合える、という主張だ。
ここで、注意してほしいのは、どちらも正しいのだ。監査プロセスを厳密にこなすことによって「強い」会社にもなれる。フィードバックプロセスを適切に回すことによって「強い」会社になれる。どちらもビジョンを明確に描けるし、どちらも言い分が適切なのだ。つまり、それぞれの状況が違うことを理解することが大切である。
状況が違うことを理解することは、とても大切である。たとえば、「時間」という概念を持たない人たち、もしくは時間という概念を尊重しない人もいるかもしれない。時間という概念がなければ、計画や予定という考え方がなくなるだろう。でも、計画や予定がない状況で、どのように振る舞えばよいのかを考えるとさらに深まる。たとえば、コードを書いていて無心になることはなかったであろうか。無心になっている場合の時間の進みは違うのではなかろうか。
ええ？そんなことを想定するの？と思ったあなた、ちょっと待ってほしい、日本語には未来時制がないのが通説になっているんですよ。現在完了形も明確ではないですよね？そう、日本語を母国語としている我々も、英語を母国語にしている人とは、違った時間を過ごしているのかもしれない。
では、全員、英語で考え、英語でしゃべればいいじゃないか、と思ったあなた（←こればっか）、他の人と違う発想方法や論理構造を持つことは、価値を生み出すために、とても大切なことである。他の人と同じように考えることができる人だ、ということは、それは、他の人と交換可能ということですよね？つまり、何らかの価値を生み出してもコモディティ化してしまうってことですよ*2。むろん、そんな人も社会には必要で、同じという多様性もあるので、同じことをフォローする人も大切なことだよね。ただ、ほっといても影響を与え合うので「人は同じになりやすい」傾向があることも覚えておくと何かと得。
閑話休題。で、状況が違う、多くの場合、それは無自覚であることが多い。丁寧に耳をそばだてて、謙虚に学んでいくことを大切にしたい。
幅広い視点を持った上で、ひとつだけ注意しておきたいのは「これだ！」と思ったものは徹底的に究める道を歩むことを忘れてはならない。究める過程で、ぱっと視点が広がる時がある。その視点の広がりは他の領域にも及ぶ。おそらく「軸」として機能している。
単純でわかりやすい主張は怖い
あるフレームワークや手法について信奉する人がいる。ちょっと前までは、スクラム！スクラム！スクラム！と叫んでいたかと思うと、今はリーンスタートアップ！リーンスタートアップ！とか、叫んでいる。多くの場合、その人の話している言葉は単純で強くて美しい。テレビのショッピング番組のように手軽に問題を解決しそうだ。
たしかにあいまいであやふやなことより、単純でわかりやすい主張が好まれる。たとえば、「スクラムは良い！アジャイルは良い！」とか。確かにスクラムを取り巻くエコシステムは、よくできていると思う。しかしながら、ある程度の規模を想定し、それぞれのタスクが予測可能な状況になっているなど、ある状況下でフィットするように作られているフレームワークだ。なので、どのような現場でもスクラムを導入すると、現状を改善するどころか、新たな問題を引き起こしてしまう。繰り返すけれど、スクラムは、よくできている（本音だし、こう書かないと、スクラム信者に取っ捕まって、スクラムの素晴らしさについて長時間にも渡って話を聞くはめになるからね）。しかし、ウォーターフォール型開発にも良いところがあるのだ、ポイントはどのように活用するのか、というところだ。
「お花畑にいる人たち」という言葉を聞いた。ある方法論や技術があらゆる問題を解決すると信じている人たちが、まるでお花畑にいるかのようだ。お花畑で暮らして、そのお花畑を広げる価値もあるかもしれないけどさ。
同じ話が JavaとRubyにも当てはまるだろうし、emacsとviにも、SQLとNoSQLにも当てはまる。Mac OSとWindowsにも当てはまる。テストを書く、ということも良いプラクティスである状況もたくさん想定できる（そうではない状況も想定できるw）。そして、それらの専門家になって極めることはとても大切だ。しかし、そうではないという考え方を尊重し、幅広い視点を持つことが大切なことなのだ。
単純な主張は理解しやすい。しかし、現実（今のここ）をしっかり見ることが何よりも大切なのだ。過去の知見を尊重にし、その現実にふさわしい技術や方法論を選択できる、場合によっては悩み、自ら作り出すことが大切なのだ。
受け入れて、学び、試し続けること
いつも悩むのは、エバンジェリスト（宣教師）や攻撃する人に対する対応は難しい。特に、その人たちが「合意」とか話しだすと、十中八九は自分の意見を押し通すためなんじゃないか、と心配することがあるし、経験上、多くの場面がその通りでした。できれば、ひっそりと過ごさせてほしいのだが、巻き込まれることも多い。
そもそも、コンセンサスや合意があるのか、という話もある。たとえば、自分の住んでいる谷をダムを造るために埋没するようなことを考えてみよう。人によっては社会に役立ち大金ももらえるからダムを造るべき、と考えるだろう。むろん、人によっては自然を破壊し、永続的な農業や伝統芸能を行っているため、ダムを誘致することは反対だ、というだろう。この２人が、おそらく本心で、どちらかが正しい、ということは、考えられない。積極的な反対が出なくなった時点で、どちらかを選ぶ、ということだ。つまり、本心としては平行線をたどり、いつまでも交わることがない、少ない、ということなのだ。たとえば、技術やサービスを選択し、それを「なぜ、なぜ」と繰り返し問うたとしても、そのパラダイムに立つことができる、ということがわかるだけにすぎない（多くの場合、話がうまいな、機転が利くことがわかるだけに終わる）。
丁寧に話を聞き、いったん距離を置いてもよい。ただ丁寧に聞き、噛み砕き、幅広い観点からいろいろと学び続け、試し続けるしかないのだ。
学ぶためのヒント
私の経験から「古典*3」や「抽象度の高いこと」、「根本的な技術」は、効率的で効果が得られやすいことが多かった。なぜならば、「古典」ということは曲がりなりにも時間を通じて生き残ってきている。抽象度が高いことは、自分の置かれた状況や文脈に応じて応用できる、ということだ。「根本的な技術」の例としてTCP/IPも、かれこれ1960年ごろから今でも使われている。
ただ、逆の人もいるし、私自身「最新」「具体的」「派生技術」にこだわった時期もあった。これも文脈やその人の性質、戦略次第なので、それこそ好きなように関われば良いと思う。カードを持っている、ということは何かと有利だ。
◇ ◇ ◇
これが、新人のみなさんに対するメッセージである。設定上とはいえ、なんだか上から目線で違和感があるのは、単に私の力不足である。おつきあいいただいてありがとうございました。
『西の魔女が死んだ』は良い映画でしたよ。このメッセージに関係している気がするし。
