2019年7月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

最近のコメント

最近のトラックバック

無料ブログはココログ

« 住宅用火災報知器の更新時期と動作テストについて | トップページ | 詳細設計書が役立たずになる理由や解決策について »

2019年6月 3日 (月)

会社標準の開発プロセス(ウォーターフォールモデル)に関する、あるユーザー側の評価と私見

今、勤務している会社はウォーターフォールが大好きです。
ウォーターフォールを必要としないような、小規模開発などについても、ウォータフォールに沿った手順を踏まされます。
では、ウォーターフォールで上手くできているかというと、決してそういう訳ではないのですが...

先日、システムを導入した会社の担当者(システム担当でなく、業務担当)と話をする機会があり、そのとき、ウォーターフォールに関する進め方についての、ユーザー側の意見を訊きました。

前提

  1. 弊社開発のパッケージソフトの導入で、パッケージ部分の導入については、ほぼパッケージ通り(一部カスタマイズあり)
  2. 小規模なサブシステムを機能を新規で追加する(マスター・帳票含めて10画面程度)
  3. ユーザー側は、システム担当1名、業務担当1名という状態で、とてもドキュメントの確認に手が回らない状態
  4. 会社の方針で、標準に定められているウォーターフォールで勧めろとの指示(パッケージ導入とカスタマイズ部分を同時に導入しろとのこと)

これに対する意見

  1. 要件を出してくださいと言われても、いざ動かしてみないと分からない箇所や見落としがあるので、要件定義・基本設計で仕様凍結をしてしまうのは、問題がある
  2. バインダーに挟まれた大量の紙資料をもらっても、システムの動くイメージまではどうしてもできなかった。
  3. 動かせる部分は、早く操作して、業務との乖離を確認したかった。(多少の設定ミスのバグなどは気にしないとのこと)

開発担当者だった私の意見としては、さっさとパッケージのパラメータ設定してパッケージのままで動かしてしまい、パッケージのカスタマイズ部分と小規模なサブシステムを反復的に開発した方が良かったと思っていましたが、会社の方針でダメだったと伝えました。

そうしたら、担当者からは「そうして進めてもらえれば、良かったかもしれない」との意見でした。

開発プロセスの標準化も結構ですが、あくまでも「標準」であって、絶対では無いと思うのです。標準通りに進めることが「お客さんのため」ではなく、開発側の都合(ISO9000の審査のためなのか、いちいち考えるのが面倒と思っているかは分かりませんが)だと思っています。

プロジェクトでは開発側、ユーザ側、双方が使える資源(費用、人手、時間、技術レベル等)の中で、どのような手段をもって実現していくかを考えて行かないといけないかと考えています。標準の開発プロセスに無理に合わせるのではなく、プロジェクトによってカスタマイズないしは、従わないという選択肢もあっていいのではないかと思います。

それに、管理者は「会社の決まりだから従え」というのではなく、「自分の頭」で考えてもらいたいものだと思います。

« 住宅用火災報知器の更新時期と動作テストについて | トップページ | 詳細設計書が役立たずになる理由や解決策について »

システム開発」カテゴリの記事

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

« 住宅用火災報知器の更新時期と動作テストについて | トップページ | 詳細設計書が役立たずになる理由や解決策について »