入社3年目である企業の基幹システム（会計システム）のリプレースに関わることになった。メンバーはプロマネ1名、デザイン1名、バックエンド2名、フロントエンド2名の計6名。みな同じ会社のメンバーで、要件定義から運用まで一貫して行うことになった。私はバックエンド担当。
結論から言うと、進め方や要件定義のやり方に間違っていたのではないかと思う。もちろん、良いところもたくさんあったと思う。スケジュールは遅れ気味ではあるが、悪くないペースで進めることはできている。だが、システムの完成形というか、しっかりと動作しているシステムを自分の中でイメージすることができていない。というのも、初期の想定と比べて現行システムが非常に複雑でなおかつ、様々な機能要望も来ているからだ。機能要望については私自身がシステムの拡張性は事前に今後実装されうる機能を知っていれば担保できると考えていたため、お客さんからこんな機能は必要かヒヤリングをしていたら結構要望が出てきた。これを考慮しながら開発するのが想像以上に大変だった。
進め方にも改善の余地があったのではないかと思う。基幹システムの開発だったため、よく聞くウォーターフォールモデルに従って進めてきた。だが、進め方は沿ってはいたが、必要なアウトプットが足らなかったのではないかと思う。要件定義書や設計書を作成しはしたが、それは振り返ってみるとただ機能をまとめた文書に過ぎず、モジュールの入出力、フロントとバックでやり取りするデータなど、インターフェースについては何も記載していなかった。なので、いざ開発してみようとすると連携のところでごたごたや手戻りが生じた。開発とはそのようなものだと言われれば、そうだと思うがもう少し効率的にやることはできたと思う。そもそもウォーターフォールモデルはマンパワーで効力を発揮するものと思っているので、少人数開発ではあまりメリットはないのではないかと思う。前のフェーズには戻らないのでスケジュールは立てやすいのかなと思った。
「前のフェーズに戻らない」と記載したが、これも少し問題がある。実際にやってみて「前のフェーズに戻らない」のは実際のところ不可能ではないかと思う。なぜなら、人間の思いは時間がたてば変化するし、極端にいえばさっき話していたことを覆すことだってある。システム開発が完了するまで同じような思いを持ち続ける人は少ないのではないだろうか。さっさと試作品を開発して順次見せながら開発していくので効率的にもシステム的にもよいのではないかと思う。そのほうがフィードバックをもらいながらイメージに合った機能を開発することができると思う。最後までイメージの中でヒヤリングをしてもお客さんのイメージと自分たちのイメージがあっているのかはシステムが完成してみないとわからない。完成した後、思っていたのと違ってましたとなるのは避けたい。
このプロトタイプを見せるという点でも思ったことがある。
続きはまた今後、気が向いたときにでも。。。