はじめに
大学生として就職活動をする中で、僕はシステム開発業界に電撃的な恋をした。これからこの世の中を変えていくのは、きっとこの業界だ！そんな熱い志を胸に、僕はシステム開発業界に飛び込んだ。
それが20世紀が終わろうとしていた頃のこと。もう、25年もの年月がたった。僕は今、PRIME ORDERという小さいけれど、愛してやまないシステム開発集団に身をおいている。
PRIME ORDERとはなんなのか。どこへむかっているのか。
これまでの僕らの25年の足跡を旅路になぞらえて、書きつづってみたい。
すばらしき景色
大学を卒業して飛び込んだこの世界は、僕が恋して期待していた通りのすばらしい景色が広がっていた。
知識経験豊富で、尊敬できる先輩エンジニア達。
高性能なコンピューターやはじめて見る画期的な機械、便利なソフトウェアの数々に囲まれる日々。当時の僕にはワクワクしかなかった。
なにより、システムを設計し、開発し、できあがったものをテストするという行為。
ゼロから価値を生み出す、最高にクリエイティブな体験だった。
・・・はずなのに。
そんな最高の景色はいつまでも続かなかった。
気づくと見たくない景色にたくさん出会うようになってきた。
その度に、僕は何度もこの業界を嫌いになった。
無駄の山
最初に立ちふさがった、見たくなかった景色は「無駄の山」。
当時の僕の役割名は、システムエンジニア。ソフトウェアの仕様をまとめ、設計書を書くのが主な仕事だった。実際にプログラムコードを書く人はプログラマと呼ばれていた。僕らシステムエンジニアは、プログラマの作業が終わり、テスターと呼ばれる人たちがテストが完了するまで家に帰れなかった。その間、別に何かの作業があるわけでもない。プログラマやテスターを見張り、クライアントからの電話を取りそこねないように、そこにいつづけるだけの仕事。
なんの役にも立たない書類を書くために残業をさせられたこともあった。上司には、大切なのは内容じゃない、ページ数の多さだぞ、と念を押された。
論理的にアプローチして、合理性を生み出す・・・・そんな仕事だと思っていたのに、なんと無駄の多いことか。
若かった僕は、そんな不合理な残業を嫌い、上司の目を盗んで逃げ帰ったりした。
敵対の谷
その次に見えてきた景色は、「敵対の谷」。
開発チームとクライアントの間には、それはもうはっきりとした敵対関係があった。
開発チームの誰もが（リーダーですら）、自分たちをあごで使うクライアントの悪口を言っている。そうすることで、チームの一体感が生まれていることに気づき、最初はなるほどと感心した。だけど、なんだかどこかに違和感がある。
それに社内が一枚岩なのかといえば、決してそんなことはなかった。営業チームと開発チームの間にも明らかな敵対関係があった。
無理な納期でシステム開発の仕事を取ってくる営業チームに、できるわけないと文句を言う開発チーム。
頭を下げて取った仕事に理屈をこねて文句やわがままを言う開発チームに、憤る営業チーム。
若かったから、僕もそのケンカに参加することもあった。
でも、ケンカは疲れる。そのうち嫌気がさしてきた。
虚実の霧
いくつもの「無駄の山」と「敵対の谷」を歩き続けるうち、僕は気がついた。
この業界では日々のあらゆるところに、”嘘”や”隠し事”がある。
いうなれば「虚実の霧」だ。濃い霧が立ち込めていて、僕の視界はどんどん見通しがきかなくなっていった。
開発がありえないくらい遅れているのに、”順調です”とクライアントに嘘の報告をする光景をあたりまえのように目にした。今朝のシステム障害の原因は人為的なミスだったのに、コンピューターの不調のせいだったという嘘の報告書を目にすることも日常茶飯事だった。
先輩たちは、「嘘も方便」とか「伝える表現の工夫」だとか、「作文能力」なんて言ってた。僕もその片棒をかつぐ羽目になったけど、不思議と後ろめたさを感じていなかった。
濃い霧の中で、何が正しいのかわからなくなっていたのだと思う。
混濁の川
そういえば、耳をすませばいつも、川の存在を感じた。川と聞くと、涼しげで爽やかなイメージを持つかもしれない。けど、僕がシステム開発の現場で見ていたのはそういう静かできれいな川じゃなかった。はげしく濁った激流の、「混濁の川」だった。
システム開発は、その工程をいくつかのステップに分けるのが常識とされていた。ざっくりいうとこんな感じ。
・要件定義・・・クライアントがほしいものを、詳細に言語化する
・基本設計・・・画面や印刷物など、ユーザーが実際に目にしたり触れたりするものを設計する
・詳細設計・・・画面の裏側で動く処理やデータのしまい方など、ユーザーには見えないけれど機能を成立させるための細かい仕様を設計する
・実装・・・詳細設計どおりに動作するプログラムを書く
・単体テスト・・・実装されたプログラム処理が詳細設計どおりに動いているかどうかを確かめる
・結合テスト・・・実装された機能が基本設計どおりに成立しているかどうかを確かめる
・受入検査・・・完成したシステムが要件定義を満たしているかどうかを確かめる
こういう工程のうち、上の方にあるものを上流工程と言って、下の方にあるものは下流工程と呼ぶ。
それぞれの工程ごとに担当者を割り当てて進めていく。
たとえば要件定義には要件定義の専門家、基本設計には基本設計の専門家。
もちろん、実装の専門家、各テストの専門家もいた。
ここが特徴的なんだけど、上流工程は絶対の存在で、上流工程で決めたことを下流工程で勝手に変えるのはご法度。だから、上流ほど自由でクリエイティブで、下流になるほど決定事項の中で手を動かすだけのシンプルな作業になっていく。
こうした開発の進め方にはちゃんと名前がついていて、ウォーターフォール型のシステム開発と呼ばれていた。かなり昔からある考え方で、今でもこのやり方はシステム開発業界に深く根付いている。
でも、もし上流工程の専門家がポンコツで、まったく不要な要件を定義していたら？誰もがケチをつけたくなるような、いけてない仕様を設計していたら？
そうだとしても、下流工程ではおりてきた書類通りに実装をしないといけない。それが、この国のシステム開発業界での絶対ルールだった。
実装の担当者は、実装するときにはじめて設計書を見る。その人が、「これ、使いづらくないですか？」とか「これ、処理もっと工夫できますよ」「この設計通りだとスケジュール間に合いません」「この機能、そもそもいらなくないですか」とか言ったとしても、ぜんぶ黙殺されてしまう。黙殺というか、逆ギレされて怒られることだってあった。
上流工程は絶対だから。
下流工程を担当する人たちは、従いたくない、けれども逆らってはいけない「混濁の川」に、ただ飲み込まれるしかなかった。
（本当はもっと良いシステムにできるのに・・・）
そんな僕の熱い想いは、やらされ感しかない下流仕事の濁流に溺れるうちに、次第に熱を失ってしまった。