渡辺幸三「業務システムのための上流工程入門」\1300－、日本実業出版社です。
★SE＆プログラム必読とありますので、経理の方には縁遠い本かもしれませんが、
私にとってはカバーしておくべき分野でありますので、お付き合い願います。
◆「上流工程」はプロジェクト管理や実装技術に先行する問題
もくじ
第1章：上流工程の困難
第2章：上流工程の進め方
第3章：基本設計入門
第4章：モデリングパターンと用例
◆ボトルネックは「分析・設計・検収」
◎一般に、プログラマに十分な能力があれば、「ユーザー＝プログラマ」の場合に、使いやすいプログラムが高い生産性で産み出されるものです。しかし、ほとんどのユーザーにとって「細かいレベルで決定されるべき個々の仕様が、システムの使い勝手に大きく関係している」という事実が、そもそも想像を絶することであり、ユーザーが意欲にあふれているとしても、仕様決定の重要性はなかなか理解してもらえない。
◎「ユーザー＝組織」であるようなシステム開発プロジェクトにおけるボトルネックは、
「ユーザーのかかえている問題を明らかにして＜分析＞、適切な業務プロセスやコンピューターシステムの仕様を考案して＜設計＞、その妥当性をユーザーに納得してもらうこと＜検収＞」です。
上流工程 │ 分 析
│ ↓
│ 設 計
│ ↓
│ 検 収
────────────↓─────────
実 装
◆システム開発のフェーズ分け
【上流工程】
◎要件定義：新システムにおいて実装されるべき仕組みや性能がまとめられる。要望事項が箇条書きでまとめられる。
◎現状分析：データ量や業務の流れなどの現行システムの有り様が調査される。
◎基本設計：要件定義の内容を実現するための「システムの論理的な形」を決める。「詳細設計」に取り掛かれるような成果物、つまり「基本設計書」が用意される。
【下流工程】
◎詳細設計：基本設計の内容が詳細化されて、「仕様書（詳細設計書）」が作られる。
◎構築・テスト：プログラミングを意味する。この後、「単体テスト」が実施され、「システムテスト」によって、関係するプログラムのまとまり単位で「通し」テストを行う。
◎広義の構築：「データ移行」や「ユーザー教育」の手順も含まれます。
◆将来の開発体制
◎「詳細設計」と「プログラムミング」が統合されると考えられている。プログラマが基本設計の内容を規定の様式にしたがって詳細化するだけで、コードをほとんど意識することなしにシステムが出来上がる体制が将来的には実現される。
◎システム開発のボトルネックは上流工程にある
◎実装技術が発展しても上流工程の助けにはならない
◎上流工程の専門化が求められている
◆基本設計のための図法（「手書き図面」の重要性）
◎文字どおり「手書き」での図面起こしから設計は始まる。この工程では失敗を繰り返すことが重要です。少なくとも上流工程の初期段階では失敗を恐れずどんどん手書きしましょう。
◎論理の一貫性があること（工学的厳密さのため）
◎より単純な文法でより複雑な内容を盛り込めること（ユーザーにとってのわかりやすさのため）
◎対象分野の特性に適合していること（暗黙知的要件の収集効率を高めるため）
◆現状分析の進め方
１、新旧要素の付き合わせ
２、「塗り残し」の評価
３、基本設計の調整
◎現行システムは「発想の源」ではなく「品質の検証材料」のためにある
◆とりまとめレビュー
◎パネルや帳票、つまり「ユーザーの目に触れる部分」をリアルにまとめて示すのが効果的。ポイントは「ユーザーインターフェイスのリアルさ」です。さらに重要なパネルに付いては、ボタンなどのコントロールを使って実際に動作可能なモックアップ（ハリボテ）を作ることがお勧め。
◆「他人からとやかく言われてナンボ」のテクニカルビュー
◎これには、ユーザーにみてもらう「ユーザーレビュー」と「プロジェクトに関係ない他の技術者」にみてもらう「テクニカルビュー」の２つの段階がある。
１、他人の仕事について積極的にとやかく言うこと
２、選択肢を挙げて妥当性を問うこと
３、「ユーザーが望んだから」とは言わないこと
＊あくまでも「工学的妥当性」が問題にされるべきで、ユーザーを言い訳にしてはいけない。
◆ユーザーレビューと検収
◎参加者全員に操作してもらい、あらためて改善点を確認する。最後に、修正課題を反映させた資料の提出日と、ユーザーがそれらを確認・捺印して返却すべき日付を明確にします。
このときに、確認が遅れたら遅れただけ完成が遅れることと、捺印したら基本的に仕様変更は認められないことも強調しておきます。
◆消えゆく「管理帳票印刷プログラム」
◎最近は基幹システム側では基本的な集計を行うだけにして、こまごまとした印刷用プログラムをあえて用意しない設計スタイルが主流になりつつあります。基本的なデータ収集や集計についてはホスト側でやって、照会や分析・検討についてはユーザー自身にクライアント上の表計算ソフトを使ってやってもらおうと考えるのが合理的です。このような分業スタイルはEUC（End User Computing)と呼ばれて一般的になりつつあります。実績情報を分析・検討する役目を負う事務担当者には、表計算ソフトや個人用データベースソフトの利用技術がかつての「そろばん」のような基本的素養として求められる時代になりつつあります。
業務システムのための上流工程入門―要件定義から分析・設計まで
後半は具体的技術論に入り、かなり難しく理解できない部分もありました。
私の仕事は、会計パッケージシステムの開発・販売・サポートなので、この本のようなゼロからの開発という仕事は、
実際にはありません。しかしながら、多くの中堅企業様では、いわゆる基幹系と呼ばれる受発注・在庫管理・生産管理
などのシステムについて、上記のような工程で自社開発するケースが多く、そうしたシステムと会計の連携が
ますます増えていく中、勉強していおく必要がると思い、取り上げました。
本日は、この辺で。