読者です 読者をやめる 読者になる 読者になる

give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

ソフトウェア開発プロセス残酷物語

開発プロセス

昔々、あるところにジェイソンという、大変真面目な開発者がおりました。


彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。
情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。
ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。


このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。
しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませんでした。
彼の手がけたシステムは他にも数多くありました。
ジェイソンや彼の同僚たちはシステムの開発には全く関わっていないにも関わらず、エセーグルの遺していった負の遺産の面倒を見続けなければなりませんでした。


ジェイソンは考えました。


「これ以上負の遺産が作られることは許されない。そもそもこの会社にはまともな開発プロセスが存在しない。だからエセーグルはドキュメントもロクに作らず、自分の好きなようにシステムを作ってしまった。」


「こうした状況をなくすためには、しっかりとした開発プロセスを作るべきだ。最低限必要なドキュメントを定義し、それらを作成することを義務づけるべきだ。加えて、開発を進める前に関係者を集めてレビューを行う必要もあるだろう。みんなでレビューをして合意を取りながら開発を進めれば、あのようなとんでもないシステムが作られることは防げるに違いない。」


そしてジェイソンは自ら社内の開発プロセスを作成することを提案しました。
この提案は上司にも快く受け入れられ、ジェイソンには開発プロセスを作成するための十分な時間が与えられました。


ジェイソンは意気揚々と開発プロセスの作成に着手しました。
勤勉だった彼はソフトウェア工学や開発プロセスに関する書物もたくさん読んでいました。
いきなりアジャイル開発を採用することには少々不安があり、かといって厳格なウォーターフォールが生み出す弊害も十分に理解していたので、彼はUP/RUPをベースとした独自のスパイラル型開発プロセスを考案しました。


要件定義と大まかな開発計画は最初の段階で立てるものの、設計と実装とリリース、および細かいスケジュールの見直しにはイテレーション型を採用する、というのがプロセスの骨子でした。


また、各フェーズの終わりにはゲートレビューを設けました。
たとえば設計フェーズでは関係者全員の合意がない限り、次の実装フェーズには進めないという仕組みです。


その他にも、彼がこれまでに見てきたような「負の遺産」の増殖を食い止めるための工夫や仕掛けをプロセスのあちこちに埋め込みました。


賢明なジェイソンは開発プロセスがもたらす弊害もよくわかっていました。


One size fits all、つまりひとつのプロセスが全てのプロジェクトに適用できるということはあり得ません。
開発プロセスはあくまでひとつの標準モデルであり、プロジェクトの規模や内容によってはテーラリング(カスタマイズ)しても構わない、と定めました。


また、プロセスは形骸化しやすく、すぐ誰も使わなくなることもありがちなので、きちんとプロセスが運用されていることをチェックするために、定期的なレビューミーティングも開くことにしました。
プロセスに問題があればフィードバックを受け付けて、改訂できるようにしておきました。


彼はこの開発プロセスがみんなを幸せにすると信じて疑いませんでした。
これ以上、自分のように他人の尻拭いをさせられる開発者を作り出したくなかったのです。
開発プロセスの設計や文書化は非常に困難な作業でしたが、ジェイソンは数ヶ月かけてプロセスを作り上げました。
そして、上司や部長の承認も無事に得られて、いよいよその開発プロセスが適用される日がやってきました。


プロセスは文書化されていましたが、文書だけでは伝わりにくい部分も多いので、約70名ほどいる情報システム部員の前で、ジェイソンは自らこれから適用される開発プロセスの説明をしました。
プロセスそのものの説明だけでなく、開発プロセスの目的や背景も説明しました。
また、ウォーターフォールではなくスパイラル型で開発することを重視していること、プロジェクトの性質に合わせてプロセスをテーラリングできること、しっくりこない部分があればフィードバックを受け付けて改訂できることもきちんと丁寧に説明しました。


さて、それから数年の月日が経ちました。
ジェイソンは開発プロセスを運用してみて気付いたことがいくつかありました。
良いところもいくつかあったように思いますし、実際「プロセスができてよかった」と現場の開発者から感謝されたこともありました。


しかし、今のジェイソンの頭に思い浮かぶのは、このようなネガティブな感想ばかりでした。


「誰からもスパイラル型のプロセスだと思われていない。実際の運用ではプロジェクト規模の大小に関わらず、開発プロセスがイテレーションを一度しかしない、単なるウォーターフォールとして扱われている。」


「現場の開発者に『とりあえずプロセスに従ってればOK』的な思考停止ムードが広がってしまった。標準プロセスが実作業のたたき台になって現場で活用されることを望んでいたが、そうはならなかった。」


「実際にやってみるとドキュメントの作成やゲートレビューは当初考えていたよりもはるかに大変だった。品質の向上ために導入したとはいえ、明らかに開発ペースが遅くなってしまった。自分で策定したプロセスであるにも関わらず、ドキュメント作成やゲートレビューはすっ飛ばしてプロトタイプを作成する方がはるかにマシだとまで感じた。」


「プロセスはフィードバックを受け付けて随時改訂するつもりだったが、いざ運用が始まると現場の仕事が忙しすぎて開発プロセスの保守まで手が回らず、現場から返ってきたフィードバックがそのまま放置されてしまった。」


「上層部がドキュメントフェチに目覚めてしまった。すなわち、キレイな開発ドキュメントが大量に作られることに喜びを感じるようになってしまった。もちろん、ドキュメントを書かされるのは現場の開発者であることは言うまでもない。」


「ドキュメントと同様に、上層部が部下にプロセスを厳守させることをマネージメントだと考えるようになってしまった。プロジェクトの規模や内容によってはテーラリングしてよいとあれだけ説明したにも関わらず、『どんなプロジェクトでも標準プロセスを標準プロセスの通りに厳守させること』が上層部の目的になってしまった。」


「これらの結果、開発プロセスが作られる前に比べて、はるかに開発効率が悪くなってしまった。」


ところで負の遺産を作り続けていたエセーグルはどうなったのでしょう。
エセーグルは開発プロセスに従うことで、高品質なシステムが作れるようになったのでしょうか。


いいえ、そんなことはありませんでした。


エセーグルはドキュメントを書かせても読みづらく、矛盾だらけのドキュメントを書いてきました。
コーディング規約や開発標準を用意したところで、彼はそんなこともお構いなしに自分の好きなようにコードを書き続けました。
問題点を何回指摘しても、摩訶不思議な持論を繰り返して自分の正当性を主張してきました。
結局、プロセスを導入してみても彼の作るシステムはやはり理解不能なスパゲッティコードだらけで、誰の手にも負えないような粗悪品のままでした。


ある日、ジェイソンはツイッターに流れるこんなツイートを目にしました。
ツイートの発言主は「まっつ」という呼び名で知られる、世界的に有名なプログラミング言語開発者です。








このツイートを見て、ジェイソンは何かが分かったような気がしました。


「自分は開発プロセスを作ることで、ダメエンジニアを鎖でしばって使い物にしようとしてたんじゃないか。」


「しかし、"まっつ"の言う通り、鎖でしばってもダメエンジニアは使えなかった。」


「それどころか、むしろ同僚や自分自身が鎖にしばられて、かえって組織全体の生産性を落としてしまったのではないか。」


「結局、ソフトウェア開発を成功させるための鍵は、平均以下のプログラマに立派な開発プロセスをあてがうことではなく、良いプログラマを集める、この一点に尽きるのではないか。」


そして、後悔しました。


みんなを幸せにすると信じて疑わなかった開発プロセスは、実は誰の役にも立たない鎖だったんだと。
役に立たないどころか、逆にみんなを縛り付けて苦しめてしまったんだと。


そう考えたジェイソンは、自分の作った開発プロセスを捨て去ることに決めました。


もちろん、開発プロセスは組織の中に深く組み込まれてしまっているので、ジェイソン一人の意思で簡単になくすことはできません。
しかし彼は、もうこれ以上同僚たちに開発プロセスの遵守を訴えることはありませんでした。
自分が開発プロジェクトに参加するときはドキュメントを書くことよりも、まず動くソフトウェアを早く提供することに注力しました。
機会があれば現場の開発者に自分の作った開発プロセスが間違いだったことを告白しました。


生産性を落とさず、現場の開発者全員が幸せになれて、なおかつ平均以下の開発者でも高品質なソフトウェアが開発できるようになる、そんな夢のような開発プロセスはこの世に存在するのでしょうか?


もしかしたらあるのかもしれません。
ジェイソンの開発プロセスがもたらした残念な結末は、単に彼の力量不足が原因だったのかもしれません。
しかし、ジェイソン自身はもうこれ以上、理想の開発プロセスを追い求めることはやめにしました。


それから数年後、彼はその会社を去り、新しくできたばかりの小さなベンチャー企業に移りました。


最近になって、ある人が彼に「ソフトウェア開発を成功させる一番の近道は何だと思うか?」と尋ねました。
彼は少しだけ沈黙した後、こう答えたそうです。


「少数精鋭の良いプログラマを集めることなんじゃないかな。今それを確かめてるところなんだ。」



※この物語はフィクションです。実在の人物及び団体とは一切関係ありません。