やってしまった！クライアントも気を付けたい仕様変更や無茶なスケジュールでのトラブル事例

IT業界に問わずですが、どのような仕事をしていてもトラブルが発生するものです。

しかし、プログラム開発というのはクライアント側にはっきりと目に見えるわけではないので、その大変さや時間のかかり具合がクライアント側で把握できずにプログラマーが地獄のような生活をするハメになることも珍しくありません。

今回は仕様変更や、無茶なスケジュールなど、あるあるなトラブル事例について実際に起こった出来事を紹介していきたいと思います。

とあるアミューズメント関係(ゲームセンター)のソフト開発を行ったエンジニアからお話を聞きました。

企画がそもそも定まらない。仕様変更が何回も…

アミューズメント系のソフト開発で問題だと思ったことは、企画自体が定まらない点です。

クライアントからはあいまいなイメージだけが伝えられており、こちらでほとんど要件定義から考えるという何を頼りに始めたらいいかすらわからない状態でした。

最初はその要件定義、企画で良いという話であったとしても、実際にテスターとなるプレイヤーの感想や筐体のデモ機を実際にゲームセンターに配置して反響を見た結果、大きなテコ入れが上の方で行われ、また最初の要件定義や企画から練り直すということが度々起きていました。

私はプログラマーという役職でそのプロジェクトに配属されたのですが、実装・テスト以外にも企画からデモの運用・フィードバックまで様々な仕事を任されました。

もちろん、一人で全部作ったわけではありませんが、それぞれに機能の開発を任され、その機能に関しては企画からデモの反響のチェックまですべてやっていました。

２回・３回と企画の修正、修正というよりも大幅な変更が起こり、結果的に予算やスケジュールに間に合わせるために、休日もなく毎日会社に泊まりながら開発を行うようになりました。

結果的に最後のリリース日までにできる限りの改善を行い、何とか納品することができましたが、企画が定まってすらいないものの開発をする場合は、クライアントがやり直しを指示してきた場合スケジュールと予算の見直しをしてもらう約束をしてもらわないと結局無茶な開発スケジュールに陥ってしまうと思いました。

無茶なスケジュールの仕事は能率を下げ、健康を害する

アミューズメント系のソフト開発では、前述のとおり、ころころと変わるゴールに向かって振り回され、納期が迫ってくると会社に寝泊まりするのが当たり前になっていました。

しかし、当然ながらそのような暮らしを続けていると、肉体的にも精神的にも弱ってきます。

今振り返ると能率はかなり落ちていたのではないかと思います。ひどいときは文字を文字として認識することもできない状態になりながらパソコンと向かいあっていました。

流石にそのときは早めに仮眠室にいって寝かせてもらいましたが、それでも通常の思考能力には回復しない状態でコーヒーやカフェイン系のものを無理やり頑張っていました。今思うと異常な状態だったのですが、当時は若く経験がなかったため、それが当たり前という思い込んでいました。

まだ若さでガムシャラになんとかなると思い込んで頑張っていましたが、それが失敗だったと思います。

周囲もそのように仕事をしていたので、疑う余地すら持っていませんでした。

しかし、その結果、無理をしているのが常態化しており、チーム全体の能率は大幅に下がっていた気がします。

例えそのときは大丈夫でも無理をしたつけは年を取ると必ず体に出てきてキャリアプランを傷つけます。

それにそのような無茶な仕事を続けていたためか２、３人が仕事をやめたり、休職したりして、その人たちの引継ぎや、新しく補充された人員への教育などさらにコストがかかりました。

この点からも、とにかくできるまで仕事をするというのは結果的に業務の効率が著しく落ちるということを組織全体が認識し、最低限の休日や帰宅は強制的に上から行わせるような仕組みがないといけないと思いました。

大きな会社ではノー残業デーなどがありますが、形骸化している場合も多いので、もっと休むことの意義をみんなが考えないといけないと思います。

特許に関する問題も浮上…

前述のプロジェクトでは、無理なスケジュールなどから辞めていく人もいて、そのたびに人員が補充されました。

そのような出入りの多いプロジェクトで、以前に勤めていた人が特許の問題を上の人達と話していたことが話題になったことがあります。

私は詳しくは知らないのですが、以前にこのプロジェクトで作った自分の企画やプログラムの特許料のようなものの請求をしに来たようです。

結局、その人の話はどうなったのかあいまいなままでしたが、それぞれがユニークな機能を開発することも多いアミューズメント系などの開発では、特許に関してあらかじめ取り決めをしておく必要があると思いました。

まとめ

私が経験してきたアミューズメント系の仕事は、企画から丸投げで仕様変更が当たり前のものでした。当然、スケジュールや予算は足りなくなってきて、現場は無理を強いられます。

その結果、リリースはできましたが、品質が良いかどうかはわかりませんし、作業の能率は落ちていたことは確かです。また、健康を害して辞めてしまうケースもあり、そうするとまた新たな人員を育てるコストもかかります。

そうならないためにも、仕様変更が起きる場合はそれ相応のスケジュールと予算の確保をすることが必要だと思いました。

また、その現場で発明された機能や仕組みを特許としてどのように扱うかなどをあらかじめ契約しておかないと後々面倒なことになるということもうっすらとですが知りました。

この背景からクライアント・エンジニアが気を付けなければいけないこと

まずエンジニア。

できないことをできないと伝えることは間違っていない。ということです。

そしてクライアント。

変更・追加になれば当然追加の金額はかかる。そして当然時間もかかる。

この記事を書いている私もエンジニアなので、こういったことはないわけではないのですが、正直な話

できるけれども、その納期では到底難しいものを作ると、いくら優秀な人を集めてもいいものが出来上がる可能性は低いです。

なのでまず大事なのは、クライアント側が完成形(目的)をある程度想像できる。そして制作会社が提示する期間に対して無理に縮めようとしない。

PM・SEがしっかりと要件定義・設計を行ってから構築を始めるということが大事です。