安直に考えて作った仕様書は失敗を招く
日々クライアントの納期に追われるエンジニアの日常は、さまざまな失敗と修正の連続で成り立っている。
どれだけ気をつけていても、煩雑な業務内容に加えてさまざまな人間が関わる上ではヒューマンエラーは避けられない。
どの業種、どの職種でも同じではあるが、どんな仕事も納期に余裕を持って終わらせたいのに、いつもギリギリになってしまうのはなぜなのか？
誰しもがそんな自問を抱えながら、仕事の効率化のためタスクに優先順位をつけてコントロールしているはずなのに、なぜか失敗してしまう。
その「なぜ？」を探るため、実際にあったエンジニアの失敗例を紹介しよう。
チームが同じ方向を向いて、同じ速度で仕事を遂行するためには、その目的、全体像、納期、進捗に関して、可能な限り全員がタイムリーに把握する必要がある。
そのためには、全体の設計の下で作成された仕様書の存在が大きい。
目的地に正確にたどり着くための地図のようなものだ。
もし、その地図に空白の部分があったらどうなるだろうか？
実際に移動している現場のスタッフは、右往左往するだろう。
よくある仕様書がまねく失敗の1つが、この仕様書を作成した人が共有を怠ったがために起こる情報の欠落だ。
特にプロジェクトの開始語に発覚すれば、そこで進捗がストップしチームにもクライアントにも多大な迷惑をかけることになる。
誰でも分かるだろうという設計者の思い込みは、現場との温度差を生むことにつながってしまうので注意が必要だ。
さらに作成中のノリで安直に思いついたレベルのアイデアを仕様書に盛り込んでしまうと、実際に作業が始まった段階でさまざまな不具合が現れることになり、思い付きだからこそ現実に即した修正が難しくなる。
また手抜きという最悪の原因も、実際には起こりがちである。
特に優先度の低いタスクに関しては、本来はすべきテストを憶測だけで省略したり作り込みが必要な部分を簡略化すると、実際にバグが起きた時にプロジェクト全体について低レベルだという評価を受けることになってしまう。
報連相を怠ったことによる失敗
チームで仕事をする以上、意思の疎通を図り、進捗具合を共有するためには報告・連絡・相談の、いわゆる報連相が重要だ。
この意義を低く見積もって必要な報連相を怠ってしまうと、しなくて済んだはずのミスを引き起こすこともある。
最もやっかいなのが、それぞれのフェイズで生じる自己解釈だ。
人間は自分の都合の良いように解釈する傾向がある。
クライアントのために行っているプロジェクトである以上、いくらプログラムが正しくとも、 クライアントの要望が盛り込まれていなければ意味がない。
常にクライアントとの報連相が密に行われていないと後で大きなギャップに気付くことになり、結局やり直す羽目になるという二度手間が生じれば時間とコストの無駄という現実的な責任が待っている。