こんにちは、みるちゃ(@milcha_on)です！！
個人事業主としてGAS開発をしているのですが、お客さんとの認識合わせや予算内で完成させることの難しさを身をもって実感しました。
ベテランシステムエンジニアの方は何回も経験してるだろうし、何を今更感はあるかと思います。ただ、過去の失敗から学ぶこともあると思うので、駆け出しエンジニアで初案件の方などには参考になるかもしれません。
システムの開発手法には主に2種類ある
システム開発を進める際に開発手法に従って進めることが多いです。お客さんから「こういう機能欲しい！」と言われたら「承知です。（カタカタ）出来ました！」と単純に進めることはできないんですよね。
というのも本当にシンプルな機能であればそれでも問題はないかもしれませんが、機能が複雑でお客さんとの認識も合っていない状態だと完成したとしても「伝えたのと違うな〜」と思われるわけです。
お金を払ったのに伝えたものと違うものを作られた時には継続で仕事を頼んでくれることはなくなるでしょう。
お客さんとの認識合わせとプロジェクトを円滑に進めるために、2種類の開発手法を用いて開発することになります。
ウォータフォール開発
システム開発をする上で要件定義から、基本設計・詳細設計、実装、テスト、リリースまでを計画的に進めるのがウォータフォール開発手法です。
前段階の工程が終わらないと次に進めず、滝のように流れ落ちるイメージからウォーターフォールと呼ばれています。
この開発手法は基本的に後戻りできないと言われています。
「前段階が終わらないと次に進めない」と伝えた通り、お客さんが「やっぱり、これじゃなくて、こういう機能が欲しい！」と言われても、すでにテストに入っているため、要件定義から再スタートしなくてはいけません。
要件定義からやり直すとなると、その分お金や時間も掛かるので、基本的にウォーターフォール開発では後戻りができないと言われています。
ウォーターフォール手法は銀行や証券会社など大手企業で用いられることが多い印象です。高い品質が求められるシステムはこの手法が多いです。
アジャイル開発
アジャイル開発は、ウォーターフォール開発をより柔軟にした開発手法です。
ウォーターフォール開発がシステム全体を設計して行うのに対して、アジャイル開発はシステムの機能を要件定義からリリースを小さく行う手法です。
スプリントという1〜2週間程度の期間で要件定義からリリースまでのサイクルを回していきます。この短期間で機能を小さく作ってリリースしていくというのを繰り返してシステムを完成させます。
小さく開発していくため、仕様変更があっても影響が最小限に抑えられるというメリットがあります。最近は予算や時間の関係でアジャイル手法が用いられることが多いと言われています。
主に中小企業やベンチャーなどはこの手法が多い印象です。
システム開発で失敗したこと
システム開発をする上で開発手法を用いることが一般的なのが理解できたかと思います。それを踏まえた上で僕が経験した失敗談を紹介します。
失敗1：業務フローを完全理解しないまま開発
システム開発をする上で、お客さん側の現状の業務の流れを理解しなくてはいけません。
打ち合わせ時にお客さんの要求や要件などを聞いても、その場で「実現したいこと」や「この仕様にしなければいけないこと」を引き出せる訳ではありません。
お客さん側であっても業務内容の全てをその場で伝えることは難しいのです。なので大枠の内容や流れを引き出し、開発者側が理解できたら、「この場合はどうするのか？」を細かく聞き出していく必要があります。
この引き出し力が上流工程では大事だと実感しました。
ここで細部の要件などを聞き出せないと、システムが完成した時に「こういう場合はこうしたいんだけど？」と言われても「仕様にないので出来ません！」という事態になってしまいます。
失敗2：お客さんの要求が膨らむ
お客さんからすると、せっかくシステム開発を依頼するのだからよりいいものを作ってもらいたいものです。その思いが強すぎるが故に、「この機能が欲しい！」、「これはこうしたい！」という要求が膨らみます。
要件定義書を作成して合意をとっても、その後の段階で「やっぱりこっちがいい！」ということが起こります。
しかも、大規模プロジェクトなら断れるも、個人で依頼を受けているレベルの小規模なプロジェクトだと断りにくいことさえあります。
お客さんの要求を飲み続けるとその度に仕様を変更して実装しテストをしますが、最初の仕様より品質が落ちることが多々ありました。
品質が落ちればお客さんは不満を持ち、「依頼したけど、大丈夫だろうか？」という不安の気持ちを抱かざるを得ません。（システム開発って辛い。。。）
お客さんの膨れ上がる要求を飲んでずるずると開発をしていき、予算に合わない仕事をして品質が悪く怒られるという、絶対に避けたい事態です。
失敗3：仕様の理解が得られない
お客さんは技術的な話は分かりません。全くといってもいいくらいに分からない場合もあります。そのため、「ここはこの仕様でないと出来ない」ということを伝えるも理解されないことがあります。
例えば、「スプレッドシートのA列は連番でないと処理がズレてしまい、期待の結果にならない」というケースで、フィルター利用時にデータの追加順序での処理を厳守したい場合などです。
説明しても、「この部分は任意の文字を入れたい！」という無理を強いられることもあります。ここで理解してもらわないと、システム完成時に再度同じことを言われます。
失敗4：開発費用が膨れ上がるとお客さんは不満を持つ
これは、見積もり時の問題になりますが、開発費用は仕様変更やスケジュールの遅れなどで費用が膨らむことが多いです。ただし、お客さんは「見積もりの値段と違う！」と不満を持つこともあります。
実際は、システムの開発費用は見積もり時の２倍になるという話もあります。システム開発の見積もりってかなり難しく、「この内容ならこの料金です！ﾎﾟﾝｯ」と出せるほど簡単ではありません。
個人の受託などでは、自分の時給を設定して要件定義からリリースまでに何時間かかるかを逆算して見積もりを出すと思います。
仕様変更もあれば実装時のエラーで時間がかかったり、テスト時に期待値通りでなければまた実装に戻ります。このようにシステム開発は時間がかかり予測が難しいため、費用は膨れ上がります。
失敗5：仕様を譲らない
DX化したいのにクライアントが既存の仕様を変更したがらないということはよくある話だと思います。システム化する上でどうしても仕様を新システムに寄せないといけない部分は出てきます。
こういった場合、クライアントの意見のみを通すとシステムは失敗に終わる可能性が高いので、既存の仕様から移行してもらうように説得する必要があります。
お客さんとエンジニアで求めるものが違う
システム開発でのトラブルはかなり多いかと思いますが、何故このようなことが起きるのか考えました。
| 内容 | クライアント | エンジニア |
|---|---|---|
| 時間 | 早く納品してほしい | テストに時間かけたい |
| 料金 | 安く抑えたい | 工数に合う料金は欲しい |
| 品質 | 高品質がいい | 高品質で納品したい |
| 仕様 | 想像したものを実現してほしい | シンプルにしたい |
| 仕様変更 | その都度してほしい | 仕様変更したくない |
| コミュニケーション | 理想的な話をしたい | 技術的な面も理解してほしい |
| 開発への理解 | 簡単っしょ！ | 開発難しい。。。 |
こんな感じでクライアントが求めているものと、エンジニア側が求めているものには乖離があるため、如何にこの差をなくすかが開発のポイントになります。
システム開発に限らず、日本は安くて高品質なものを求める傾向にあると思います。しかも今の日本はそれが実現できてしまう・実現してしまうのが問題なのではないかと感じています。
安くて短納期となると、各工程を省略し、少人数・少機能の開発で、低品質になりますが、クライアントはこれとは真逆で、各工程をしっかり行い納期を守れる範囲の少人数で多機能・高品質を求めます。
クライアントが求めるのはブラック労働を強いる依頼なんですよね。でも、この考えは誰しもが持っているもので普通のことだと考えます。
安いおにぎりと高いおにぎりがあったとしたら、安いおにぎりを買いますが、味が不味いと猛烈に批判します。安いし、仕方ないと割り切れる人もいますが、安くて・高品質を求める人が多いと思います。
1番の問題は安くても引き受けてしまったことであって、業界全体がシステム開発は高いものと印象をつければ、それなりのフェアな料金で依頼されるのではないかと単純な考えを持ちました。
まとめ：要件定義はしっかりして無理なことは無理と言おう
システム開発をする上でクライアントとエンジニア側の認識・理解を打ち合わせを重ねて擦り合わせます。見積もりはスケジュールが押すことも考慮して高めに見積もり、出来ないことは出来ないと伝えることが大切です。
ただ、傲慢になってはいけません。スケジュール通りに進むかは経験の差が重要ですが、基本的にエンジニア側の責任です。無理なものを無理やり引き受けてしまったのもエンジニア側の責任です。
自分のようにとりあえず経験して失敗することも大事だと思います。