業務設計論はそのうち。
まずは開発における設計について。
* 概要 [#d4af1309]
とりあえず、大別する。
-共通
--機能要求から最終Outputの逆引き
必要なプロセス、SAPの機能制約、現状のデザインが源泉の前提条件を洗い出す。
ここが曖昧だったり不充分だったりすると、後々に禍根を残すことになる。
--ボトムの定義
すべての要求を完全に満たせればよいのだが、スケジュールや要員のスキルセットを鑑みると、必ずしもその限りではなく、また最終的には必要であっても''ある時系列においてはその限りではない''ということも多い。
更に''「齧りかけの状態で、人に見せられる仕上がりでない」ではできない話が、「○○の部分は実装できていないが、第一版は上がっている」という状態ならば、それはそれでできる話もある''ということもある。
そのため、まずはボトムを定義し、第一版の照準をそこに合わせるのが肝要かと思う。
-[[拡張>SAPの拡張手段]]系
当然、まずは機能検証から入る。
通常はドキュメント作成から入るものだが、この分野については、''やりたいことが、この[[BADI>SAPの拡張手段/BAdI]]なり[[Exit>SAPの拡張手段#b1976726]]で実現できるか、対象やタイミングや揃っているか、やってみないと分からない''ためである。
他社事例や過去の経験からほぼほぼ間違いないと思っても、その顧客ではマッピングも違えば考慮事項も違うため、まずは動かす・試すことが大事かなと。
当然ながら、設計書の目的は証拠残しだけになってしまったりするが、だからと言って軽んじてはいけない。
-[[フォーム>アドオン/フォーム]]を含む[[レポート>アドオン/レポート]]系
--[[フォーム>アドオン/フォーム]]での注意点
特に言葉の壁がある場合に言えるが、''相手と自分で使っている同じ単語が、異なる意味の場合がある''ということがある。
これによる齟齬は中々違和感レベルから先に進まなかったり、要求確認のスピード低下したりすることを避けるため、まずは「自分たちが考える○○という帳票は、××という位置付けの機能だ」というところから入るべきかと思う。
--[[レポート>アドオン/レポート]]での注意点
法制上の要件でもない限り、色々な人の色々な思いがこもりがち。
なので、''当然だが「要求ごとに機能を分ける」という考えを徹底すべき''と考える。これは、複数の目的を充足しようと思ったら、機能が巨大化・複雑化しすぎたり、あちらを立てればこちらが立たず系の壁にぶち当たりやすいためである。
--進め方
これは、一般的なレイアウトや必要項目（なんなら他のプロジェクトの遺産）でドラフトを作成し、差分を埋めるという方法がよいかと思う。
この段階でレビューを行えば、結果を反映させた設計書の第一版を作成すれば、後は[[実装>アドオン/実装]]に落とすだけだが、この二つにおいては、アジャストという工程が待っている。
それは、あ〜・・・ここはね〜なんつって、''目に見える形になると、必ず直しが入る''からだ。
それは、あ～・・・ここはね～なんつって、''目に見える形になると、必ず直しが入る''からだ。
しかしながら、ポジティブに捉えれば、このステップごとに質を向上させていればよい話なので、''各ステップで100点満点でなくてよい''ということも言えるため、手を抜くということではないが、メリハリをつければよいかと思う。
~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)
