それ本当に意味ある！？システム開発を進める上での不毛な行為

業務としてシステム開発をしていくと「それ本当に意味ある！？」とツッコミを入れたくなってしまうようなイベントが多々発生するものです。業務担当者としては「不毛だ・・」と思ってしまいがちですが、開発のルールとして定められている以上、従うしかない状況もしばしば。

今回はそんなシステム開発を進めていく上での不毛な行為について、いくつか事例を挙げながらお話していきたいと思います。

適切なバグ密度に合わせてバグ製造

システム開発のテスト工程には、適切なバグ検出数が設けられていることが多いです。これはシステムの品質を担保することが目的で、テスト対象となるプログラムのステップ数に応じて、適切なバグ検出数が決められています。バグ密度と言ったりもしますね。

テストを実施して、見つけられたバグ数が適切な水準値になれば、テスト仕様書も問題なく、しかるべき品質を確保できている、という考え方です。

ですがこのバグ密度に関しては、今の時代の開発スタイルでは、あまり意味のない数字になってきているような気もするのです。

デバッグしながら開発を進めるとバグが少なくなる

かつて汎用機が主流だった時代には、プログラムを製造して、汎用機で動かして結果が返ってくるまで、結構な時間がかかったものです。それこそ各自のクライアント機で動作を確認できるわけでもないので、処理を流すにも順番待ちが発生することだってありました。

ですが今の時代の開発はクラサバが主流で、バッチ処理だけでなく画面系の開発もあります。

そうすると製造フェーズにおいても、画面で逐一動作を確認しながらプログラミングを組んでいくことが多いのではないでしょうか。つまりデバッグしながらソースコードを書いていくことになります。

バグを潰しながら開発を行っていくと、テストフェーズでは期待値ほどのバグが検出されないこともしばしば。ボリュームの小さいプログラムであれば、バグ件数ゼロ件となることだってあります。

そうすると社内での検査を通すために、わざとバグを作って、検出して、バグ対応をして、という意味の無い行為が発生してしまいます。まさに不毛な行為ですね。

バグ検出の基準値については、いい加減現代の開発スタイルに合った水準に見直すべきでしょう。

終わらない工程会議

延々と続く工程会議。SEであれば誰しも経験したことがあるのではないでしょうか？　会議も2時間、3時間と続くと精神的にも消耗してしまいますし、多忙なSEであればあるほど「本当に必要なのか？」と思ってしまいますよね。

工程会議については、個人的には「全く意味ない」とまでは言いません。プロジェクトメンバーが集まってのミーティングには、当事者意識を高める、チームの士気を高める、結束を強くするといった効果も狙って開催することもあるからです。

ですがあまりに会議が長すぎると、メンバーの工数を奪ってしまうことや、モチベーション低下といった害も及ぼしてしまいます。単純にプロジェクトメンバー10名で2時間の会議を開くと、20時間分の工数が消耗されるわけですから。

工程会議を開催するPMとしては、チームメンバーを集めてまで共有すべき事項と、メールなどの伝達で済ましておく内容をしっかりと切り分けて、上手に会議を開催していきたいものですね。

多すぎる申請書類

これは会社の規模がでかくなればなるほど言えることだと思いますが、大手ベンダーでの開発となると、やたらめったら社内の申請書類が多くなりがち。

本番環境に変更を加えるとき、ハードディスクを社外へ持ち出すとき、仕様書のレビュー時など、上長の承認を受けるのはもちろん大事なことなのですが、ことあるごとに上長⇒課長⇒部長⇒事業部長・・・といくつも申請を回していくと、承認フローだけで膨大な時間を消費してしまいます。

事故が発生する度に増える申請書類

なぜこんなにも非効率な減少が起きてしまうのでしょうか・・？

その答えですが、なにも意味もなく申請書類、申請フローを複雑にしているわけではありません。多くの場合は何かしらの事故が発生した際に、再発防止策として社内の申請書類が用意されます。

例えば不用意に機密情報が入ったデータをハードディスクで持ち出して、紛失事故を起こしてしまえば、持ち出し許可の申請書が生まれ、上長承認が発生することになります。

本番運用にて大きなミスがあれば、手順書の承認も多くの人が回覧することになりますし、手順書とは別に環境を操作することに対しても承認フローが発生します。

こうして再発防止策として申請書類が増えていくことは、一見すると合理的に思えるものです。しかしあまりに社内の申請書類の用意で多くの時間を取られすぎると、本来の作業時間が圧迫されて準備不十分のまま本番運用を迎えて事故が起きる、という悪循環を生み出してしまうことにもつながります。本末転倒というか策士策に溺れる状態ですね。

 

おわりに

ここまで説明してきたように、組織でシステム開発を行うとなると、不毛な行為や作業が多々発生してしまうものです。

プロジェクトを動かす者としては、本当に必要なものと、形骸化した行為をしっかりと切り分けて、作業効率をいかにして高められるかを追求していきたいですね。