やりがいと達成感。これらは同じような意味合いで使われることも多いが、微妙に違う。やりがいは日々の進捗の中で感じ続けるものだが、達成感はある到達点において瞬間的に感じるものだ。
喩えて言えば、バスケットボールの練習中に上手くなっている感覚を抱く日々に感じるのがやりがいで、強豪校に試合で勝った瞬間に感じるもの、それが達成感だ。あるいは単純に、小さな達成感がやりがいであるという考え方もあるだろう。いずれにせよ、私はこれらを別物として考えている。
システム開発においても、同様である。日々の業務の中で起こる問題やそれに対する対策を考え、対処していく、それはそれでやりがいのあることだ。別にそこについては否定しない。しかし、達成感を感じるのは、システムをお客さんに提供できた瞬間だろう。
ただ、システム開発をやっている会社の人達のうち、どれだけの人がこの「達成感」を感じることができるのだろうか、などと最近は考える。
近年となってはもう標準でもないのかもしれないが、システム開発の進め方のモデルにウォータフォールモデルというものがある。簡単に言えば、まず設計して、その通りに作って、ちゃんと動くか試験する、という風に工程を区切って進めるシステム開発の方法論である。
ウォーターフォールモデルでは、序盤と終盤ではほとんど労働力が不要なのに対し、中盤のプログラミング工程では大量の要員が必要になることが多い。なぜそうなのかというと、設計を十分に固めていれば、後のプログラミングはほとんど単純作業であり、要員を増やすほど、期間短縮に貢献しやすいからである。
そして、これが何を意味するかというと、プログラミング部分だけを担当し、プログラミングが終わればプロジェクトを去っていく人間が沢山いるということである。他の工程でも問題が深刻化すればテストだけ支援に来る人もいる。
彼らには自分に与えられた業務範囲を全うすることしか出来ない。そこに達成感はあるのだろうか、と私は思う。もちろん、プログラミングだけが好きだからそれでいい、という人ももしかしたらいるのかもしれない。
でも本当のプログラマーなら、自分がプログラミングしたものがちゃんと動作して、他の人にもちゃんと使える状態になっていることを見届けたいものではないだろうか。少なくとも私は自分で設計した部分はちゃんとプログラミングされていて、ちゃんと動作していることを確認したい。私の場合、会社でプログラミングは出来ないんだけど。
で、これは私がそうしたい、というのもあるし、そうあるべき、という気持ちもある。そもそも、プログラミングだけしてどっか行く人とか、テストだけしてどっか行く人って、結局のところ、自分の誤りに気づけないし、最後の最後に責任感を持てない。例外もあるんだろうけど、私が少ない経験で見てきた人はだいたいそう。
無理もない。そもそも設計が本当に正しかったかどうかなんて試験をするまでわからないのである。設計だけが完了した時点で、これは完璧な設計ですなんて言えっこない。プログラミングも同じ。完璧なコードを書いたぜ、なんて思ってたって、試験してみりゃバグが見つかる可能性はある。
逆に言えば、どんな適当にプログラミングしたって、単体テストレベルでバグが出ない品質ならOKとしちゃうことだってできる。後続の試験やる人達は困るけど、別に自分が去っていくなら責任を問われることもない。
だから基本的には後工程に残る人が損をする。でも、まぁテストしかしない人も、そもそも設計とかコーディングが悪いとか言って、自分たちのテストが上手く進められない言い訳に使ったりもする。実際、設計自体が間違っていたら、完璧にテストをこなしたってシステム自体は間違いということになる。
そして、テストだけしにきた人がその責任を感じることはない。たとえ、この設計で本当に良いのか？と疑問に思ったとしてもそれは自分の範疇ではない、となるわけだ。つまり彼らの仕事はシステム開発の支援ではなく、ただテストをすることなのだ。
と、こんな風に中途半端にプロジェクトに参加する人がいると、他の工程を担当した人に責任を転嫁するのが容易い。本質的に、プロジェクトの成功自体をゴールに設定できない構造なのである。事実最後まで見届けることはできないのだから。
こういうのってめちゃくちゃ虚しい。これは全部、やりがいはあっても達成感がないことに起因しているのだと思う。ちゃんとやればやりがいはある、でも自分がちゃんとやってもやらなくても達成感はあんまりないのだ。だから投げやりにもなる。至極当然の真理だ。
