キッチリソフトウェア開発

ソフトウェア開発の現場に関わっていると、いつも同じような文句を見かける。

  • 仕様書のレビューを「キッチリ」行います。
  • 工程管理を「しっかり」やるように。
  • バグの修正箇所を「確実に」確認します。

やる気の表明としては悪くない表現だれど、当然のことながら「キッチリ」「しっかり」「確実に」の定義は人によって異なる。同じグループで同じような仕事をして日頃からコミュニケーションを行っていても「キッチリ」のレベルは全然違っていたりする。誰かが「キッチリ」やった結果が、他の人には全然「キッチリ」ではなかったりする。これならアウトプットのレベルが異なってしまうのは必然の帰結だし、エンジニアリングとは程遠いのが実情だろう。

では、どうすべきか?例えば、同じ内容を客観的な「数値」として表現する形なら、だれが見ても同じレベルで理解できるかも知れない。

  • 仕様書のレビューを行い、仕様書が原因の不具合流出を10件以内に抑えます。
  • 工程管理により、作業遅延をゼロにします。
  • バグの修正箇所を、コードカバレッジ率100%の単体テストで確認します。

これで完璧とは思えないけれど、少なくとも一歩前進しているようには思える。設計の見える化を実現するためにUMLで記載するとか、確実な仕様書を作成するために形式的手法を導入するのも一つの手ではあるけれど、短期的な即効薬にはなり得ない。今日できる対策なら、仕様書やメールにて「キッチリ」などという曖昧な表現の使用を禁止することだろう。見方によっては、曖昧な表現のおかげで今まで救われていた面も有るのかも知れないが、特に大規模なソフトウェア開発において、そのような不明瞭な言い方はもう許されないと思う。

「テストやレビューをしっかりやれ」「プロジェクト・マネジメントをキッチリ徹底しろ」

今のソフトウエア開発では、誰もが品質確保の確かさを「キッチリ」としか表現できない面がある。エンジニアリングの実践に程遠いこうした現状から脱却しハードウエアと同じ地位を持つ工業製品としてソフトウェア開発を昇華させる必要がある。

特集 ソフトウエアは硬い キッチリとは何か 現状はエンジニアリング以前 解釈ミスを減らす方法論へ | 日経エレクトロニクス | 日経BP記事検索サービス