 |
||||||||||||||||||||
|
||||||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||||||
|
||||||||||||||||||||
| 高い精度 | ||||||||||||||||||||
|
既述の通り、精度と保守性とのバランスには意味があります。データベースなどを用いて高い保守性を実現しているとはいえ、「スペックパターン開発プロセス」のような役割分担での文書作成や保守は仕様策定者にとって、本当に辛い作業になります。 その辛さを少しでも軽減するためにも、最初から高い精度で顧客要求を理解し、ブレのないシステム設計ができなければなりません。それはさらに工程をさかのぼって、仕様策定者と顧客側担当者との初顔合わせからはじまる「顧客側の開発目的」「方針の確認」「明確化」や、繰り返し解説している「顧客業務の徹底理解」などを一体化してはじめて実現できるものとなります。 以上がドキュメントの「量産」と、そのために考慮している事柄の重点事項です。本連載は、第9回の今回で終了いたします。これまで必死に業務システム開発をやってきて、何とか結果として成果が上がるようになっていた進め方のポイントについて、自分なりにできる限り伝わるように説明しました。ありがとうございました。 疑問点については、ページ下部の記事評価欄などでご質問ください。すぐには対応できないかもしれませんが、できる限りお答えしたいと思います。また本連連載へのフィードバックでは、ご感想や激励のメッセージなどをいただきまして大変感謝しております。この場をお借りして御礼申し上げます。 本連載が業務システム開発の実務改善に少しでも役立つことを願っております。 |
||||||||||||||||||||
| 役割分担 | ||||||||||||||||||||
|
連載の最後にあたって、前回の本文中に少し書かせて頂いた「役割分担」について、非常に重要ですので少し細かく書いておきたいと思います。 役割が適切かつ明確に分かれていないと、助けているのか助けてもらっているのかすら、明確にはわかりません。何か問題があっても、人のせいにしたい気分になってしまったり、「自分の責任です」と言い出すには、どこか納得できない気分になってしまいます。逆にいえば、頑張っても自分の功績とは思ってもらえないような気分にもなるということです。 チームメンバー各人が持っている、何となく割り切れない気持ちが、もう一歩頑張れるところで頑張れなくさせたり、チーム全体として今一つ気力がでなかったりさせてしまうことになります。 このことについて、特にソフトウェア開発では作ろうとしている対象がなかなか図でも示せないような見えにくいものであるということが本質的な原因です。しかしそこを解決しようと意識するからこそ、この業界のプロフェッショナルであるということになると思っています。ですから、マネージャーはじめチームメンバー全員の責任として対処しなければなりません。 具体的には、マネージャーは次のような考え方を事前に明確にしておく必要があります。
表2：マネージャーが事前に明確にしておくべき考え方 そして、役割分担とその責任を決めたからには「マネージャーは各担当者がその責任を果たすに当たって本来必要な環境を（交渉などによって）実現する」ということがその責任範囲となります。ここでの「本来必要な環境」とは、その時のチームメンバーによって異なるものであって、マネージャー本位で考えるのではなく、議論の結果としてチームメンバーが納得の行くものとなっていなければなりません。 |
||||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
-
-
連載
