SEワンタンの独学備忘録

独学した内容や資格試験に対する取り組みの備忘録

【読書会】(システムアーキテクト試験対策)システム設計のセオリー

システム設計についての本。
読もうと思ったきっかけはシステムアーキテクト試験の論文対策のため。直接的な課題解決方法というよりは言葉のつなぎや一般論として使う程度か。
または論文ネタを考えるネタ。

なので主な目的としてはシステムアーキテクト試験の論文対策として、気になった言葉や考え方、共感できた部分などを備忘録として残します。
文体については適宜修正を加えています。また、目についたところは現場でも適用できそうな考え方や方法もちょくちょくひろっています。

書籍紹介

システム設計のセオリー

システム設計のセオリー --ユーザー要求を正しく実装へつなぐ

システム設計のセオリー --ユーザー要求を正しく実装へつなぐ

個人的な全体の感想。
すっごい技とか最新技術が書いてあるわけではないので、現場経験がある人が見るならすごく目新しいことはほとんどないかもしれない。
体系的な知識として、そのプロセスがある意味や必要な理由を理解し人に説明するときなどにはよいかも。
現場で慣例的に行っていたことあるいはその逆を見返す機会にもなる。

「設計」に関する本ってまともに読んだことなかったからそれだけでも結構面白い。

同じようなシステムアーキテクチャの本もあって気にはなったけどちょっと時間が足りなそうだから今年の試験までには見れないなぁ。

目に止まった部分の抜粋

情報システムの使命

設計の目指すべきもの=「情報システムの価値を最大化する」ことである。

情報システムはビジネスの目的を実現するための手段であり、それを構築するのがシステム開発、そしてその工程の一つが設計工程である。
情報システムの価値は運用によって初めてもたらせるが、設計工程はその価値を仕込み最大化することが目標となる。

★システム価値を最大化するために行った工夫は?

情報システムと設計

設計ドキュメントの役割は「工程間のコミュニケーションを円滑にする」こと

設計ドキュメントは次の設計工程や実装工程へのインプットとなる。
システム開発では関係者の人数が増加するとコミュニケーションコストがべき乗に増加していくが、設計ドキュメントはこの課題解決に役立つツールでなくてはならない。

★参画メンバが異なる工程間での円滑なコミュニケーションのために行った工夫はあるか?

手戻りの原因
・情報システムが組み込むべき業務設計のイメージを、ユーザと開発者が共有していない。
・データの不備、同音異義語や別名の洗い出し、用語統一、コード設計等のデータ整備が不十分。

一旦、作り終えた設計情報やプログラムを作り直すのには、多大なコストと労力が伴う。
これらの不備を残したままにすると、開発システムと実際のビジネスとの乖離が大きく、結局使えないシステムとなってしまう。
⇒早期に大枠のイメージを共有し詳細を埋めていく。
⇒ビジネス用語やエンティティの属性名等の用語集を作成する。

実践的にほんとにしっかりとやらないとこれだけでは厳しそう。

★設計工程に起因して大きな手戻りが発生した経験は?どうすれば防げたか?


エンタープライズ系システム→ライフサイクルが長く、安定性や信頼性が求められる
コンシューマ向けシステム →最新技術をスピーディに取り込みアジリティが求められる

システム形態 想定ユーザ 使用動機 ユーザ数 優先事項
エンタープライズ系システム 社内外の特定業務担当者 業務ルール 信頼性
コンシューマ向けシステム 不特定多数の一般顧客 顧客の任意 俊敏性

コンシューマ向けシステムは使用を拒否されるとビジネスの損失に直結する。エンタープライズ系システムはある意味使用せざるおえない。
対象ユーザによるシステム特性の違いは意識する必要はある、が、近年では境界があいまいになりつつある。

エンタープライズ系システムを題材にするときは安定性や信頼性を重視する理由を示すべき。

★重点項目として安定性(信頼性)を挙げた具体的な理由は?


論理設計のはじめに

経営からの要求を把握する。
要求の発生源を明確にする。

要求を把握、整理する際には、経営からの要求を最優先とする。現場をないがしろにするわけではないがトップダウンの意思を尊重する。
経営上の要求でないものについては、発生部門を明確にし、経営課題の解決につながるものを優先とする。

優先順位の理由付けに使う。

★対象システムにおける最優先要求事項(システム化の目的)は?

要求ランク付けの考慮点
・経営及びビジネスに与える影響の大きさ
・緊急度
・課題解決に要する規模

切り捨てる理由は必要。

★ビジネス要件により優先した要件の具体的なビジネス影響は?

要件を要求に紐づける

開発範囲を定める際に、どの要求がどのシステム要件で実現できるのか明確に分かるようにする。

トレーサビリティマトリクス。要件整理時の小さな工夫として。

ユーザビリティは非機能要件の大きな要素。

同じような画面であっても外回りの営業と社内の管理部門でも求める使い勝手は大きく変わってくる。
その違いがその案件の特徴的な要求、あるいは設計時に配慮した点になりうる。

★非機能要件として挙がった代表的なユーザビリティ要件は?そのシステムの特徴は?

システムアーキテクチャの検討にはシステムの実現方法とシステム形態を決定する。
・クラウドORオンプレ
・スクラッチORパッケージ
など

システムアーキテクチャの検討と言われた際には、ソフトウェア構成だけではなく、ハードウェア構成やネットワーク構成のことを配慮できるようにする。
代表的なパターンは制約や要件から採用、不採用の理由があがるようにする。

★システムアーキテクチャを行ったシステムの構成概要は?

データ設計のセオリー

意味がある既存コードを流用、変更する際に注意する

原則としては意味ありコード(桁で階層を表すようなコード)はすべきではないというのが筆者の考え。
意味ありコードはプログラムの処理の中で分割して使用されている可能性がある。
→そのままコード体系を継承すると旧システムの仕様を縛られてしまう可能性が高い。
コード体系を変える場合はユーザが画面上でコードの意味を使用している場合の業務影響を考慮する。

コード仕様書に記録しておきいつでも誰でも把握できる状態は必須。

★どのようなコード体系を設計したか?そのようにした理由は?

外部インタフェース設計における例外処理の早期検討

対象システムが外部システムの連携を行う場合、連携方法などの検討を行う。その中で例外発生時の対応方法を検討する。
例えば、連携ジョブのリランやログへの出力など、運用設計につながるところがある?

★外部連携処理に異常発生するケースとその対応方法は?
★検討を行った外部連携方法とそれぞれのメリット、デメリットは?

データ移行は一回しか使わない機能。しかし、データ移行の失敗は開発プロジェクトの失敗になりうる。

新システムが正常に動かなくなるという失敗のリスクが大きい割に、データ移行は成功して当たり前と思われがちで軽視されがちである。
成功して当たり前、失敗したら大問題、しかも機能としては一度しか使用されない機能とくれば開発者としてもモチベーションがあがりにくくなる。
データ移行も設計の範疇としてとらえるべき。

★データ移行の失敗例とその対策は?またデータ移行の準備に十分な工数が割かれていない場合にその重要性をどのように説くか。

データベースにビューを定義するのが有効なパターン
・プロジェクトの開発標準に定められている場合
・ある程度パターンの決まった複雑な検索や問い合わせがある場合
・セキュリティ上の観点から特定のカラムやレコードを参照禁止にする場合

プロセス設計のセオリー

ビジネスの静的側面を表すのがデータモデル、動的側面を表すのがプロセスモデル。

プロセスモデルを表すドキュメントは顧客との重要なコミュニケーションツールになりうる。
プロセスモデル(業務フロー)では以下の点に留意する。
・データではなく時系列的な業務の流れに着目する。
・起点、開始条件を明確にする。
・適切な規模で作成する。必要に応じて概略にする、サブジェクトエリア等をきる。

業務プロセスの5W2Hを明確にする。
Who,What,When,Where,Why,How,HowMany

業務プロセスの5W2Hが明確になると、統合と分割を検討することができる。
簡潔な言葉で5W2Hを明確に定義できないものについては不要な可能性も疑う。

5W2Hはよくきく言葉だが、実際にどの程度実践できているか。基本的なことだけに応用範囲は広そう。

★どのような業務プロセスの統合、分割を行ったか?なぜ必要になったか?そのようにできると判断した根拠は?

必要かどうか分からない成果物(ドキュメント)は迷ったら捨てる。

成果物のみが過剰に設定されると、成果物の作成自体が目的になってしまう可能性がある。本来の果たすべき目的から必要なものを考え直すべきである。
また、仕様変更などが発生した際には即修正すべきであるが、後から一括修正を行うという事態もよくあることで、そうすると納品目的になりドキュメントの品質が低下しがちになる。
この点からもドキュメントは即座に修正可能なボリュームに抑えるべきである。

機能設計のセオリー

バッチ処理の特性
・一定量のデータを一括で処理する。
・予め設定された一連の処理を順次実行していく。
・処理が開始されると、「正常終了」か「異常終了」の結果になる。
・バッチ処理はジョブの固まりでもあり、個々の処理単位をジョブと呼ぶ。

何が重要ってことでもない、ジョブやバッチの定義を明確にしてこちらから定義を揺らすような事態は避けたいだけ。
論文試験的な定義は、情報処理試験の午後Iからとかから解釈すればいい。

バッチ処理の実行方針
・バッチ種別
・実行時間帯(前後処理と時間的な制約)
・実行スケジュール(月次、日次、週次)
・処理件数(パフォーマンス検討)
・エラー処理方針(再実行方法、異常終了対応方法)

ここも何が特別というものではなく一般的な内容。
逆に言えば設計時に考慮して当たり前、話題にする場合はそれなりの工夫が必要。
仕様や実行条件を変更する場合にも、最初にそう定められた理由があるはずで、変更する際には各種問題がないことを確認する必要があるだろう。

CRUDマトリクスはシステムライフサイクル全般にわたって活用できる。

CRUDマトリクスは、まずは機能の更新領域が見える化できる。
仕様変更の際に影響度分析が容易になる。
保守フェーズにわたっても活用できる。

プログラム自体以外のところで保守性を考慮した点にはなるか。

★保守フェーズでも有効活用シーンは?また他にはどのような特徴を持つドキュメントが保守運用シーンで活用が見込めるか?