→見積もり・発注

→ドキュメント作成

→詳細設計

→アルゴリズム、数学etc

→ビジネスプロセス管理

サブトピック †

↑

一般 †

↑

アーキテクチャ †

アーキテクチャって何？という素朴な疑問にはなかなか答えづらいが、一般的には、設計時の大きな方向性や方針を意味する。要件は実現しようとする機能の内容に重点を置くが、アーキテクチャは機能の実現方式に重点がおかれる。

↑

クリーンアーキテクチャ †

↑

要件定義 †

  • ユーザーニーズを基にシステムを作るな 2010.11.21
    • ユーザーニーズは偶然により決定される
    • ユーザーニーズはシステム要件に変換する段階で矮小化される
    • ユーザーニーズはユーザーすら分からない
    • ユーザーニーズ半減・半増の法則
    • ユーザーニーズはシステムを納入したときに明確になる
  • 業務機能の洗い出しと業務フローの作成を同時に実施してはいけない 2010.8.31
    • ユーザーは業務機能のレベルやサイズを意識せずに回答するので、ITエンジニアにとって業務の理解や整理が難しくなるからである。
    • ユーザーに業務フローをヒアリングしながら、業務機能のレベルやサイズをそろえるのは難しい。そこでユーザーへのヒアリングは、業務機能を洗い出すためと、業務機能間の関連やフローを確認するためという目的別に分けて行う。
  • 失敗しない要件定義、3つのポイント 2010.5.18
    • 要件定義がうまくいかないパターンとして、
      • なかなか要件定義が終わらない
      • 後工程で要件の抜けが見つかる
      • 何でも要件に盛り込んでしまい、プロジェクトの工数などに無理が生じる
    • という3つのケースを挙げる
    • 要件定義プロセスに、一般的なプロジェクトマネジメント手法は通用しないと理解しておくこと。要件定義は「管理対象と作業内容そのものを決める」プロセス。ゆえに一般的なマネジメント手法のような定量的な管理だけでは、内容的に不十分なまま作業を終えることになりかねない。
  • 要件定義書レビューの一般的観点
    • 項目に漏れがないか
    • 機能要件、非機能要件の過不足
    • 役割、責任の分担（例：データ移行は誰がやるか）
    • しないと決めたことを明記しているか
    • 文体、用語の統一
  • 検討項目管理票
    • 意外と作らないことがあるが、要件定義作業中に検討した各要件ごとに、どういう議論を経てどういう結論になったかを記録しておくため、検討項目管理票は重要。最終的な要件定義書に検討中の経緯や、要件から外された項目については文書に書かれていないことが多いが、何らかのかたちとして残すべき
  • 要件定義の勘どころ 2010.2.7
    • 要件定義は詳細なシステムの機能を決めるための入力情報となります。そのためにはWhatとWhyが記述されていること
    • このシステムの目的（価値）は？
    • どのような責務を持つ人に使われるのか？
    • どのような外部システムとかかわるのか？
    • システムはどのような使われ方をするのか？　
    • システムとの接点は？
    • その時の入出力情報は？
    • システムに必要な機能は？
    • その機能が使用するデータは？
  • 要件定義をロジカルシンキングで解析する 2009.5.2
    • 要望を単なる箇条書きの仕様と見なすのではなく、構造化された一つのモデルとして提示する能力が必要になってくる。
    • 今までUML、DOAなど色んなモデリング手法を学習してきたが、要件定義では、結局、ロジカルシンキングを中心として論理で整理するのがBetterな気がしている。
    • 仕様とは一つの仮説であり、一つの論理的なモデル。
    • 要望をロジックツリーで整理して、問題と解決策へ昇華できれば、解決策を仕様に落としてしまえばいい。
  • 顧客の膨らむ要望にいかに対処すべきか 2008.9.4
    • 要件定義とは以下を実行することである。 
        1. 顧客のあいまいな要求を把握
  2. 本プロジェクトでやれることを決定
  3. システムの機能要件・非機能要件への落とし込み
  4. 要件定義書（仕様書）の作成と合意
    • 追加要求は、顧客の要求の絞り込みを十分に行っていないために発生する
    • 追加要求をできるだけ減らすには、要件定義プロセスの最初の段階において「やる」「やらない」「後でやる」をしっかりと決めなければならない
    • 「やる」ことが決まれば、次は「顧客に機能を捨てさせる」ことを考えさせる。たいていの顧客は「機能はあればあるほどよい」と思うことが多く、システムは「結果として役に立たない機能が満載」になる可能性が高い
    • 「このサブシステムにはこの帳票が本当に必要か」と、問題を一段高いところから眺めることで、「実は、ほかの帳票で代用可能だ」「ほかの帳票と比べて、優先度が低いので後回しにしよう」など、顧客に冷静に判断してもらうことが可能になります。
      • 【疑問】そもそも最初の段階で上がってきてない要件は捨てさせることもできないが？
    • いま議論している対象の重要度はどのくらいか」を判断するための枠組みとして、1・5・10ルールというものがある。10以上なら必要になる
    • 変更管理で最も大切なのは、「変更要求の評価」と「変更要求の認可」です。すなわち「この変更は重大な変更なのか」「この変更は誰が許可するのか」を判断できるようにしっかりと手順にしておくことです
  • 要件定義の遅れ 2008.9.2
    • 前回の反省を生かして「利用部門の要件確定を待っていても仕方がない」と，システム利用部門の担当者から積極的に要件を引き出すことにした。
    • この際に大きな武器になったのが，Excelの表だ。あらかじめ「業務要件とシステムとの関係」を示した表を作っておき，利用部門との打ち合わせで決まったことやこれから検討すべきことを書いておくことにした
    • さらに「なぜその機能を採用しないのか」といった，要件の背景や経緯も，利用部門の担当者に聞き，書き留めておくことにした
  • 業務フロー図の書き方 2008.7.14
  • 過剰な要求を絞りこむ知恵 2008.7.3
    • 業務内容分析シートで業務にかかる標準時間や難易度を整理し，最終的には「労力」と「効果」を評価する
    • 要求を業務フロー図とヒモ付けて眺めてみる→浮いた要求がないかと考えてみる。
    • 洗い出した要求を「内部統制に関連するもの」「効率化に寄与するもの」「情報系システムに関係するもの」「業務改革に寄与するもの」――などのテーマに分けてみる。一つの要求が複数のテーマに重複していても構わない。そのテーマ単位で優先度を考える
    • 処理の発生頻度を聞く。処理の頻度が高ければ通常処理と判断し，その要求はシステム化した方がよい。逆に低ければ運用でカバーしてもらう
    • 要求をシステム仕様に取り入れるデメリットを問いかける。システムに実装する要求が増えると，一般にスケジュールは長くなり，コストはかさむ。できればシステム企画の段階で，スケジュール遅延の許容範囲を合意しておきたい。2次開発や3次開発に先送りするなどの交渉があり得る。
  • 見積りマニュアル策定、要件定義書の標準化 2008.5.15
    • 精度向上のための施策には大きく分けて「標準化」「個人の知識・経験の向上」「経験者のレビュー」の3つがある。どの施策が最も効果的かは、その組織が現在直面している課題によって異なる。自社の状況に応じて、上記3つの施策のバランスを調整して実行すること重要である。
  • 仕様はどうして決まらないのか？ 2008.3.27
    • （1）業務オーナーを決めろ
    • （2）ステークホルダーの整理
    • （3）whatとhowの分離
      • 本当に＜何をすべきか＞というwhatにフォーカスすることが重要
  • オフショアのERPコンサルタントvs．日本人プロジェクトメンバー 2008.2.22
    • 「欧米ではERPの標準機能を使うのが常識」「日本ではアドオンを多く実現することが常識」といえましょう。
    • ERP がパッケージソフトであることを考えると、テスト済みのERP標準機能を使った方が低コスト、高品質を実現できるという意味で、欧米の常識の方が技術的な視点からは優れているといえるかもしれません。ただ、日本のお客さまが欲しているのはアドオンによる高機能のシステムであるわけですから、このような、いわゆる「べき論」を日本において論じても意味がないことが多いのです。
    • 良しあしの議論は置いておくとして、「欧米と日本とでは常識が異なる」と私は理解しています。
  • キミの設計にトレーサビリティはあるか 2008.2.14
  • IT戦略は情シスが立案するもの 2008.2.12
  • 性能要件はユーザーが決めると思ってはいけない 2008.2.6
    • 性能要件はアプリケーション処理方式が固まらない限り，定義できない。最初からユーザーが「はい，これが要件です」とポンと出せるものではないのである。業務パターンや処理方式が現行システムと全く同じシステムを構築する場合は性能要件を早々に決めてしまうことも可能だが，実際の案件でそんなことは滅多にない。前提とするミドルウエアなどのアーキテクチャが変われば，現行システムではいくつかに分かれている処理が一つになったり，その逆になるケースが必ずある。要件定義フェーズでのヒアリングはあくまで「現行システムにおける参考値」もしくは「ユーザーの要望」以外の何者でもない。
  • 課題山積みの要求仕様確定 2007.12.3
    • 顧客との仕様確定過程で、見積もりや契約の前提条件が崩れそうになったら、すぐ実態を上申しなければならない。特に仕様が増えても納期の変更ができず、予算の追加も認められず、そのまま進めば大赤字、大事件につながることが懸念されたら、契約自体の見直しも必要になるので、すぐ幹部に知らせ今後の対策をどうするか一緒に議論すべきである。顧客との交渉のレベルを上げることも必要になろう。要は手遅れにならぬことである。
  • 定まらない要件、ユーザーからの無茶な要求
  • ヒアリングの実践ノウハウ
    • ヒアリングは司会と書記でペアを組んで行う
    • キーパーソンを把握しシステム化の目的を明確にする
    • 経営トップから各現場の社員に周知徹底してもらう
    • 「現状の業務の大まかな流れ」や「現状の業務で感じている問題」などの基本的な質問を書いたアンケート用紙を回答例付きで作成し，事前にユーザー企業に配って回答してもらうのも，問題点や要求の分析に役立つ。この方法は，会議の議論をスムーズにする利点もある。アンケートに回答することで，ユーザー企業の担当者が自分の考えを整理でき，問題意識を持って会議に臨めるからだ。
    • 聞くべき項目をリスト化しておくこと
    • FURPS＋
      • Functionarity:機能要求
      • Usability:使いやすさ
      • Reliability:信頼性
      • Perfomance:性能
      • Supportability:保守性
      • Plus:その他（開発環境、コンポーネント、ネットワーク、ハード、法律etcの制約)
    • キーパーソンが参加する全体会議は，ユーザー企業内ではなく，なるべく研修所やホテルの会議室などに場所を移して実施する。
    • ユーザー企業の現場担当者との個別ミーティングでは，上司と部下は別々にヒアリングする
    • だらだらを防ぐ
      • ヒアリングの場では，冒頭で「この会議は何のために行うのか」，「何を決めるのか」を明確に宣言する。
      • 終了時間までにまとまらなければ，再び集まってもらうことになると警告を発しておく。
      • 出席者もなるべく少人数に絞り込む。
    • ER図やDFD，UML図，業務フロー図を作ってユーザに確認してもらう
      • なるべくユーザーと議論しながらその場で図を作成すること
      • できる限り詳しく図の意味をユーザーに説明すること。
      • ミーティングで図の意味を説明したり，図をユーザーに確認してもらう際に分かりやすい説明用の文章を付ける，など
  • DOA
  • 要求定義の基本を知る
    • あらゆる要求定義に共通する「4つの必須スキル」がある。それは，
      • （1）ヒアリング技法
      • （2）業種・業務知識
      • （3）要求定義の方法論
      • （4）要求をモデル化するための図法――の4つだ。
    • 要求定義を成功させるためには，まずこの4つの必須スキルを身に付けて地道に実践するしかない。
↑

基本設計 †

  • 基本設計は大雑把な設計、詳細設計は細かい設計だと思っている人がいるが、それは誤り
  • 基本設計は、システムを外から見たときどういう動きをするか（＝外部設計、What）を決めるもの。詳細設計は基本設計で決められた動きをどうやって実現するか（＝内部設計、How）を決めるもの、と考えるとよい。基本⇔詳細という言葉に惑わされず、外部から見たときの動きについての話なのであれば、どんなに細かいことでも基本設計に書く。
  • 機能要件設計書だけで20種類 2009.1.8
    • 基本設計は大きく分けて三つのプロセスを踏む。いずれの設計も入力情報となるのは要件定義で作成した成果物である。
      • 「機能要件設計」どのような機能をアプリケーションに求めるかを設計する。その際「画面」「業務プロセス」「データ」という三つの切り口に分ける。
      • 「システム方式設計」システム方式設計では、性能や信頼性などの非機能要件を整理する。それを踏まえて、ハードウエアやソフトウエアなどの構造や実装方式を練る。
      • 「アプリケーション方式設計」アプリケーション方式設計では、非機能要件を考慮しつつ、機能要件設計で明確にした機能（画面、業務プロセス、データ）を適切なサイズのモジュールに割り当てる。
    • 基本設計で作成する設計書の一覧(日立システム開発方法論「HIPACE」を基に作成)
  • システムのリプレース案件が最も危険な理由 2008.2.24
    • 運用していくうちに、バグフィックスや機能追加で、恐竜のように馬鹿でかくなった中身は、最新のオブジェクト指向言語で、同じようにたくさんのバグフィックスを重ねて積み上げたものに変わる。 同じソースコードの断片は一つもないはず。
    • プログラムの保守性や移植性、再利用性が、どの時代になっても、言語がいくら発展しても難しいこと。
    • 特に再利用性は、そのライブラリの粒度に大きく依存する。
    • 再利用できる程度は、フレームワーク程度ぐらいで、昔から夢想するビジネスオブジェクトレベルまでなかなか辿り着けない。
↑

要件定義と基本設計の違い †

  • 要件定義の一般的項目→要件定義書の一般的な項目 
    　・業務要件：現状、新業務フロー等
　・システム要件：インフラ系を中心にネットワークやプロダクト等
　・セキュリティー要件：セキュリティに関しての要求事項等
　・機能要件：大まかな機能や、「これを実現して欲しい」等の要求
  ・非機能要件：性能要件や障害発生時にどうなるかなど
　・運用要件：運用まわり、バックアップ、容量見積等
　・その他：ケースバイケースで他に何かあれば
　・昔はレスポンス要件等もあったがＷＥＢでは保証できない
  • 基本設計の一般的項目　乱暴に言うと、要件定義をインプットとしてシステムの外部仕様を決めるのが基本設計 
    　・システム設計：インフラ、ネットワーク、機器構成、プロダクト構成等
　・画面設計：デザイン、項目定義等
　・ＤＢ設計：論理／物理設計、ＥＲ図等
　・インターフェイス設計：他システムとの外部インターフェイス、ファイル、帳票設計等
　・処理設計：ＤＦＤ、ＩＰＯ、ＣＲＵＤ、コード設計等
　・業務・運用設計：サービススケジュール、バックアップ、リカバリー方法
　　　　　　　　　　新業務フローの詳細等
　・テスト設計：テスト方法、ツール等の設計
　・その他：補足資料他
↑

要求開発 †

  • 観察力と推理力のプロ 2008.4.9
    • 「企業の本社や管理部門は報告書やら何やらであまり役に立っていないものがどっさりありますが，物流センターのような現場には無駄な物なんてないんですよ。どんなに旧式のプリンタであっても業務に必要だからそこに置いてあるわけで，そういう意味では紙切れ1枚にも大概役割があるんですね」
  • システム開発には広い視点で取り組め 2008.4.7
    • 利用部門が主体ということと，利用部門の言うことをなんでも聞くことは全く異なる。利用部門は新システムに対しても従来通りの機能を要求したり，自分が困っていることを解決してほしいという観点だけで要件を出すことが多い。
  • RoRで要求仕様を開発(RfS)
    • 要件定義フェーズでRfSを行うときには，もらった設計書を単にプログラム化するだけの能力しかないプログラマでは荷が重い。
    • 変化に強いスタイルで構築しなければならないため，オブジェクト指向をちゃんと理解したうえで，アジャイルの設計スキルと，きれいにコードを作成できる技術を身に付けた開発者である必要がある。そうでないと，要件定義の間に「仕様」のアプリケーションが変化に対応できなくなってしまう。また，開発しながら仕様を決めるので，要件定義のスキルも必要だ。
    • つまり，このフェーズでプログラミングを行う開発者は高度なスキルを要求される。RfSとは，上流フェーズをプログラミングを使って行うということなのだ。
  • 要求を洗い出す４つの工夫
    • 模型を作って動かす
    • 壊しては作る
    • サンプル集で動きを確認
    • UI仕様書と画面見本
  • 要求分析ツリー
  • 開発プロセスの本質・要求開発のフロントローディング開発
    • 【現状の課題】
      • 要求自体がどんどん複雑化し，とらえづらくなっています
      • 既存の人の業務をコンピュータ化するという観点だけではなく，業務をIT化することで付加価値を創出しなければならないという課題を負うことが多くなります。
      • このような要求については，要求提案当初は非常にあいまいな場合が多いのです。
      • 様々なテクノロジを組み合わせて開発した結果，はたしてビジネス要求を実現できるかのかどうか，ちょっとやってみないとわからない
    • 【対策】
      • これらのリスクをできるだけ早期にヘッジするために，反復開発やアジャイル開発
      • (1)要求を早期に検証する
      • (2)技術的リスクを早期にヘッジする
    • 【上記対策の問題点】
      • システム開発よりも前段階で，つまり企業の将来ビジネスを構想する要求開発の段階にて，両リスクをヘッジするための対策を講じる必要が出てくる
      • ビジネスとITが密接に関係するような問題領域では，ビジネス要求をITでどう表現するかによってIT化の価値が左右するため，試行錯誤しながらビジネス価値を創出するIT表現を洗練させることが重要となる。
↑

業務知識 †
トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2022-08-16 (火) 16:07:39 (3d)