Lead Sheet

大学時代、クラシックギターをやっていた。

部活の顧問に、クラシックギターのプロがいた。コンサートを開き、レッスンをする。ギター一本で食っている本物のプロだった。なぜか目をかけてもらっていて、レッスンが終わったあと楽器を片付けながら、いろいろな話を聞かせてもらった。

苦労話のひとつにこんなのがあった。クラシック一本でプロになった人だ。あるとき仕事で、コードでの伴奏を頼まれた。やったことがなかった。「そんなことも知らないんですか」と言われたのが、プロとしてショックだった。家に帰って必死で覚えた。

先生が知らなかったことに驚いたわけじゃない。自分の失敗を、学生にこうして話してくれること。そっちのほうが意外だった。だから妙に記憶に残った。

学生時代で先生との縁はいったん切れた。IT業界に入り、15年ほど自分の会社をやった。そこから大手にPMとして転職した。受託の現場から、エンタープライズの世界に。

面食らった。

「これは機能要件ですか、非機能要件ですか」「設計ですか、実装ですか」「PMOからの依頼で、ステコミに上げる必要があります」。打ち合わせで飛び交う言葉。文脈から推測はついた。ただ、こんなに切り分けて喋るのか、と文化の違いに驚いた。

それまでの現場では、要件と設計と実装の間に隙間はなかった。設計は開発者の裁量であり、現実との折り合いの結果として生まれるものだった。ドキュメントは後追いで書いた。非機能要件という呼び方もしなかった。性能や運用はインフラの人と一緒に詰めるもので、開発者の領域と明確な境目はなかった。

非機能ってなんだよ、と思った。

そう思ったところで、先生の話を思い出した。

これで飯を食っている。だったら知らなければならない。

覚えるべきは、言葉そのものではない。言葉の裏にある、世界の切り分け方だ。要件を機能と非機能に分ける発想自体が、わたしの育った現場にはなかった。先生もたぶん、コード表記を覚えたのではない。譜面のとおり弾く世界と、コードを渡されて音を組み立てる世界。その間にある発想の違いを、必死で埋めたのだ。

PMBOKやITILの本も、それなりに買った。怠惰なたちで、読み飛ばしたきり中身は思い出せない。同じ言葉が同じ場面で何度も使われるのを聞いているうちに、その言葉が前提にしている世界の切り分け方が、少しずつ自分にも入ってきた。何を議論しているのか、どこで意見が割れているのか、誰が責任を負っているのか。霧の向こうにあった会話が、急に景色になった。

先生は、しばらく前に亡くなった。

訃報を聞いてから、墓参りに行こうと思って、まだ行けていない。コードを必死で覚えた話を思い出すたびに、行かなければと思う。