新天地へ

PRIME ORDER Journey 新天地へ

「無駄の山」「敵対の谷」「虚実の霧」「混濁の川」。

僕が恋焦がれていたシステム開発業界って、こんなところだったのか・・・。

僕はシステム開発業界にすっかり嫌気が差してしまった。

それでも仕事だからと、割り切って日々を過ごしていたのだけど、ある時こう考えた。

(大きな開発会社にいるからダメなのかもしれない。もっと小さい開発会社だったら、自由に理想を追えるかも。)

僕は1年間ほどフリーランスエンジニアをして武者修行をしたあとに、家の近所にある小さなシステム開発会社に入社した。

小さなチーム

PRIME ORDER Journey 小さなチーム

有名で大きなシステム開発会社からやってきた僕は、その小さい会社では一目置かれた。色々質問されたし、僕のやり方を見た人はたびたび感嘆の声をあげた。

「内藤君、こういうときってどうするの?」

「へぇ、そういう図表を書けるのすごいねぇ。」

「なるほど、ITの教育を受けたひとは、そうやって考えるんだ!」

社員はみんな、といっても当時は4人くらいだったけど、システム開発業界での正規の研修を受けてない人たちだった。でもその分、机上の理論よりももっと実践的なアプローチでシステムを作っていた。

一つのシステムを、たった一人か二人で全部作るようなスタイル。

今まで、10人とか、多いときは40人とかのチームでシステムを開発していた僕にとって、なんだかとてもカッコいいカウンターカルチャーとして映った。

僕はその小さな会社を、”小さくて実践的なチーム”というストロングポイントを残したまま、より洗練された理想のシステム開発会社に成長させたいと思った。

アルバイトとして門を叩いた身にしては、今思うとずいぶんとだいそれた考えだ。

でも、その時の僕は26歳。まだまだ十分若かった。

新しい発見

PRIME ORDER Journey 新しい発見

大企業で培った教科書的なIT理論と、零細企業の実践的で小さなチームのスタイル。

僕はこの掛け合わせに夢中になった。理論を抑えながらも、必要に応じて大胆かつ柔軟に対応する。例えるなら、デジタルとアナログをかけ合わせたような。そんなスタンスで、いくつものシステム開発案件に挑んだ。

小さな会社だったし、僕は器用貧乏なタイプなので、ほとんどすべての仕事を担当することになった。営業から設計、開発とテスト、インフラの構築。たくさんの案件で、すべての工程を必死にチャレンジした。そうしているうちに、すごい発見をした。

クライアントの悩みや実現したいことを聞き出したのは自分。

それを実現するシステムの設計をしたのも自分。

設計をベースにプログラミングをするのも自分。

「全部の工程を自分でやっているから、工程間の引き継ぎ漏れや認識の齟齬が生まれない!」

自分で書いたものだから当然だけど、意味のわからない要件定義書を読み解く必要がなくなった。

困っているクライアントの表情を思い出しながら書く設計書には、クライアントやユーザーへの愛をぎっしり詰めることができた。プログラムを書く段になって、設計書よりもっと合理的な処理を思いついてそのように実装しても、怒られることもない。だって、設計書を書いたのも自分なのだから。

そうして作ったシステムは、クライアントやその先にいるユーザーたちに大歓迎された。

最初に見せた仕様書と違っていても、それがより良くなっているのなら誰も文句を言ったりしない。

僕は、システム開発の”正しいカタチ”を見つけたと思った。

「そうか、全部ひとりでやればいいんだ!」

・・・こうして僕は、少しずつ間違え始めていた。

天才との出会い

PRIME ORDER Journey 天才との出会い

ともかくも、小さな会社は少しずつ成長を始めた。

仕事が増え、人を増やす必要が出てきた。

そんな中、ひとりの天才プログラマーが入社してきた。

僕自身、プログラミング技術には多少の自信はあったのだけど、彼の前では霞んだ。

必要な処理を組み立てる発想に天と地ほどの差があった。

僕はただもう、ワクワクした。

技術的課題が見つかる度に、彼が鮮やかな解決方法を示してくれる。なんという爽快感。

”全部ひとりでやればいいんだ”なんて思ったけど、技術的な課題”だけ”は彼に任せるべきだ。

このころになると、僕の中には”技術を重んじ、その使い手である技術者を大切にする”、という絶対原則が出来上がっていた。

技術者がプログラミングに集中できる環境を作り守ることが、僕の使命だと強く確信した。

小さな王国

PRIME ORDER Journey 小さな王国

僕と、天才プログラマーのガイドの下、複数の”小さくて実践的なチーム”がシステム開発にあたった。一見うまくいっているように見えた。

でも実は、”小さくて実践的なチーム”というストロングポイントには、属人性が高いという致命的弱点が隠れていた。実際にその案件を担当している人がいなくなると、にっちもさっちもいかない。その人がプロジェクトの途中で離職なんてすれば大変なことになる。

僕は、その属人性を排除することに集中した。

そうすれば、人をどんどん増やして、たくさんのシステムを安定的に開発することができると信じていた。

案件に関するあらゆる情報を統一フォーマットで一元管理するようにした。

開発の現場で手に入れた知見はナレッジデータベースで会社内で共有できるようにした。

Webアプリケーションでいつも取り組む課題や機能は、独自のフレームワークにあらかじめ搭載して効率向上とともに品質の均一化を実現した。

一つの街、いや、国を作るようなこの仕事に、僕は日々没頭した。

気づくと、数人しかいなかった社員は20人近くになっていた。

僕の名刺には、専務取締役なんて重々しい肩書もつくようになった。

それからも、大半のクライアントの窓口を僕が務めた。

大半のプロジェクトのマネジメントを僕が務めた。

このころになると、さすがに僕が実装担当となることはマンパワー的に難しかったので、専門のプログラマのみんなにお任せした。でも、クライアントが欲しいものがちゃんと伝わるよう、詳細な仕様説明書を付けて、プラモデルを作るように正確かつ簡単に取り組んでもらえるように配慮した。

チームメンバーが病欠しても、他のメンバーがカバーできるようになっていたし、クライアントの満足度もとっても高かった。

「よしよし、うまくいってるぞ!」

僕はまるで小国の王のように、少し高い場所から会社をすみずみまで見下ろして満足していた。

どうして間違っていると気づかなかったのだろう。

【PRIME ORDER Journey Vol.3】へ続く >>>