突然変わる要件に振り回され、曖昧な仕様に頭を抱え、終電にすら間に合わず、今日も徹夜で仕事・・・エンジニアの方ならそんな経験を誰もが一度はすることでしょう。作業が予定通り終わらずにプロジェクトが炎上する、いわゆる”デスマーチ”の原因とはなんなのでしょうか？ここではエンジニアの多くが頭を悩ませる、デスマーチの原因とその対処法について考えてみたいと思います。
曖昧な要件定義がデスマーチを招く
既に開発が進んでいるのに、要件の大幅な変更が入ってしまうという体験をした人は多いのではないでしょうか。しかも要件の変更が一度ではなく、何度も繰り返しておこる場合、プロジェクト提案者の意見がしっかりと汲み取れていない事が原因です。
要件定義を作成する場合には、口頭でのやりとりだけではなく、議事録という形でメールや文章などの形に残す必要があります。しっかりとした意思の疎通とエビデンスを残す事で、当初の予定から変更になった事を証明できる状態にしておきます。その証拠を根拠に、クライアントへの納期変更を交渉することによってデスマーチを回避することができるのです。
複雑な仕様を回避してデスマーチをなくす
バグが見つかって修正したら、別の場所でバグが発生してしまったということもよくあること。これは、開発担当者それぞれバラバラに仕様定義から開発までを任せた場合に発生する可能性が高い現象です。
全体を把握しないで作成された仕様が互いに干渉しあって矛盾点がうまれ、バグがバグを呼ぶ複雑怪奇な作りとなってしまうのです。そうならないように、仕様の定義はなるべく少数で、かつ、互いの意思疎通をしながら行うべきなのです。
突然の要件変更から仕様を変える必要が出た場合にも、開発担当者全員にしっかりと伝達し仕様矛盾がおこらないように心がけましょう。
エンジニア・コンサルタントの高単価案件は、アサインナビがご紹介しています。
デスマーチをなくすには、余裕のない納期は避けよう
「自分の実力を100％発揮し続けた場合に到達できる数値」をそのまま納期に設定してしまうということはとても危険です。特に経験の少ないエンジニアに、納期予定を提出させる場合には注意する必要があるでしょう。
前述のとおり、要件の変更や仕様の変更がいつ発生するかわからない状況に陥る可能性や、開発作業員が体調を崩す可能性などを考慮してバッファーを持たせるように心がけるべきです。
つまりプロジェクトを炎上させることなく成功に導くためには、余裕をもったスケジュール作成というものが必須となります。クライアントの予算などの影響で、納期を短く切られてしまう場合もあるかもしれませんが、妥当な納期をしっかり伝えて交渉するようにしましょう。
デスマーチをなくすには、意思疎通が重要！
無駄なデスマーチに巻き込まれないためにも、明確な進捗状況の報告は必要不可欠です。開発途中での仕様矛盾や、コア部分のバグFIXは、発見が早ければ早いほど傷が浅くて済むものです。これらの不安要素に最後まで気が付かなかったとき、納期直前に最初から作り直さなければならなくなるという最悪のデスマーチに発展してしまうのです。
中でも開発者同士によるソースレビューは、見逃していたバグや仕様漏れなどに気が付くことのできる貴重な機会となるでしょう。
現場のエンジニアが協力しあって、最悪の事態を回避する努力をすることが必要なのです。
エンジニア・コンサルタントの高単価案件は、アサインナビがご紹介しています。
最後に
プロジェクト全体から考えたとき、一人一人のエンジニアが自分だけでできる事は限られています。大勢のエンジニアの力が合わさることで、大きなプロジェクトを達成することができるのです。
コミュニケーションが苦手と言われがちなエンジニアではありますが、お互いに切磋琢磨することで技術力も向上し、快適な仕事環境を作ることができるとすれば、作業効率だけでなく、現場の空気感なども大切にする必要があると言えるでしょう。
エンジニア・コンサルタントの高単価案件は、アサインナビがご紹介しています。
invalid URL
