サウスポーなエンジニアの独り言サウスポーなエンジニアの独り言サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。2017年10月15日Tweet外部設計や内部設計なんかの色々なレビューをしているうちにふと思ったことです。レビューやインスペクションは画面単位(もしくは単機能を構成する複数画面)で行うことが多くなります。そこではある要求仕様が、その該当画面(とそこで定義されている機能)で過不足なく満たされているかを焦点にレビューします。上記の焦点の結果、「システム全体を通じて」複数の機能の観点からが漏れがちになることが時々あります。...「A画面では要求仕様書の要望の**という点を考慮して設計している」ということがレビューされ、OKが出たとします。B画面では同じ要望を「別の観点」で考慮した設計になっていることがあります。この結果、単機能レベルでの単体テストは順調にクリアされても、いざ結合テスト時にインターフェース不備によるバグが多く発生することになります。#要求仕様管理がキッチリ出来ていればこういう漏れは防げるように思いますが...それはそう簡単では無く...。原因の1つにA画面で検討した仕様/内容/問題点に対する同じ視点(=同じ要求仕様からの視点)でB画面を検討しないこと、もしくは検討した結果、2つの結論が異なってしまうことがあります。その仕様が、どの要求仕様に対するものか分かる...フェーズを縦断したラインでのトレースはできることが多いです。規模の開発プロセスでは各フェーズにおけるインプットとアウトプットが明確に定義されていることが大半です(現場でそれが実践されているかはまた別として...)。情報の伝達や管理ノウハウは色々情報があります。それこそ本やWebで山程見つかります。横の連携はかなり泥臭い方法で今もしているような気がします。プロジェクトがうまく行かなくなる要因の1つに、この横の連携の破綻があるのでは?と考えています。実際、下流工程になれば一気に人が増えることが多く、横の連携で要求仕様や設計に対し共通した認識が持てているかがポイントだと思います。明確な答えが出ているわけ色々なプロジェクトで遭遇している実装フェーズなどにおける仕様ズレによる手戻り防止のきっかけになればと思っています。※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。コメントをキャンセルメールアドレスが公開されることはありません。*ウェブサイト関連記事もっと会議の時間を有効に使いませんか?今回は、ある会議に出ていて「もう少し効率良く時間を使えるなぁ」と思ったことを書きます。出席者は地理的に離れている複数チームです。...変更履歴を論理的に見ておかしいと思わないのは...仕事での行動基準...うまく言えないのですが「これを気をつけて欲しいなぁ」的な内容...を考えることがありました。...勝手に親近感Twitterや社内SNSなどで、「実際に会った」ことも「直接話した」こともない...けれど、その考え方やアクション、マインドにすごく共感したりする方々がいます。...会議での「KY読めよ」な空気がキライ議論が活発な会議で、費用対効果が出ているような会議ならそんなことはないのですが...。ようなアンケートに答えたことが1回はあると思います。...PREV「名前」で呼んでいますか?NEXT新規開発と保守開発に求められる要素の違いギルドワークスの現場コーチ。「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。様々な規模のSIerでのシステム開発を経て今に至る。DevLOVE関西を主催。(14)サウスポーなエンジニアの独り言サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。