→ /yunoha-pub/JIS X 0166:2021
規格名称 : システム及びソフトウェア技術-ライフサイクルプロセス-要求エンジニアリング
対応国際規格 : ISO/IEC/IEEE 29148:2018 (IDT)
関連
JIS X 0166
→ /yunoha-pub/JIS X 0166:2021
規格名称 : システム及びソフトウェア技術-ライフサイクルプロセス-要求エンジニアリング
対応国際規格 : ISO/IEC/IEEE 29148:2018 (IDT)
関連
JIS X 0166
関連
IT 運用
システム運用
運用プロセス
運用設計
en : system
JIS X 0160:2021 での定義 : 一つ以上の明記された目的を達成するために組織された相互に作用する要素の組合せ
一般システム理論におけるシステム
内部の要素が相互に関連する、1 つのまとまりのこと
複数の要素が情報やモノ、エネルギーなどの流れでつながり、相互に作用しあい、全体として目的や機能を有する集合体
en : Business or Mission Analysis process
目的
ビジネス又はミッションにおける問題又は機会を定義する
ソリューション空間を特徴づけ、問題を解決したり機会を活かすことができるような 1 つ以上の潜在的な可能性をもつソリューションの集まりを決定する
プロセスが成功したときの状態
同義 : システムレベルの運用概念文書
OpsCon (システムレベルの運用概念) に関する文書
システムが何をするか (どのようにするかではない) と、なぜ必要かを記述する
利用者向けの文書
システムの特性を利用者の視点から記述する
en : Stakeholder Needs and Requirements Definition process
JIS X 0160 での訳 : 利害関係者ニーズ及び利害関係者要件 (要求事項) 定義プロセス
JIS X 0160 で定義されているソフトウェアライフサイクルプロセスのひとつ
取得者の業務要件と、取得者がシステムに求める要件 (機能要件、非機能要件) を明確にすることを求めている
en : concept of operations
略 : ConOps
JIS X 0166:2021 の定義 : 運用又は一連の運用に関する組織の前提条件又は意図を、言葉及び図で、全体像として記述するもの
en : system requirements specification
略 : SyRS
JIS X 0166:2021 の定義 : システム及びその運用環境並びに外部インターフェイスに対する要件を構造化した集合
企画プロセスの中のプロセスのひとつ
『SEC BOOKS 共通フレーム 2013』 より
経営上のニーズの実現や課題解決のために、経営環境を踏まえて、新たな業務の全体像とそれぞ実現するためのシステム化構想及び推進体制を立案する
アクティビティとしては、準備、立案、承認、がある
ISO/IEC 29148 の A.2.5 「Concepts for the proposed system」 を参考にすると良い
en : requirements engineering
同義 : 要求工学
JIS X 0166:2021 より
多分野の協働を必要とする工学で、取得者の領域と供給者の領域とを仲介し、対象とするシステム、ソフトウェア又はサービスが満たすようにする要件を確立し、保守するための工学
要求に関するプロセスとしては以下がある
規格名称 : Systems and software engineering — Life cycle processes — Requirements engineering
https://www.iso.org/standard/72089.html
ISO/IEC/IEEE 29148 の 2018 年の版
対応する JIS は JIS X 0166:2021
規格名称 : システム及びソフトウェア技術-ライフサイクルプロセス-要求エンジニアリング
要求エンジニアリングについての日本産業規格
内容は https://www.jisc.go.jp/app/jis/general/GnrJISSearch.html にて 「X0166」 で検索して閲覧できる
版
JIS X 0166:2021
en : stakeholder requirements specification
略 : StRS
JIS X 0166:2021 の定義 : 利害関係者、及び利害関係者と外部環境との関係についての要件を構造化した集合
en : software requirements specification
略 : SRS
同義 : ソフトウェア要求仕様書
JIS X 0166:2021 の定義 : ソフトウェア及びその外部インターフェイスへの必要不可欠な要件を構造化した集合
機能、性能、設計の制約、及び属性
en : business requirements specification
略 : BRS
同義 : ビジネス要求仕様、ビジネス要求事項仕様、ビジネス要求記述書
JIS X 0166:2021 の定義 : ビジネス又はミッション、及びその外部環境との関係についての要件を構造化した集合
すなわち、ビジネス要件 (= ビジネス要求) に関する仕様
en : Conway's Law
Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
Melvin Conway が 1968 年に 「How Do Committees Invent?」 という記事で発表した法則
i コンピテンシ ディクショナリ より
以下のようなことを行う
システム運用設計
IT サービス設計
Web サイト運用設計
ホケットによるもの
今井・秋田版
言語の本質的特徴
1. 意味を伝える
2. 変化する
共通フレーム 2013 においては、JIS X 0160:2021 の利害関係者ニーズ及び利害関係者要件定義プロセスを単に要件定義プロセスとしている
いわゆる業務要件定義を行うプロセス
関連
利害関係者要件
『SEC BOOKS 共通フレーム 2013』 より
複数のコンポーネントやサブシステムからなるプロダクトの要求を表す (ISO/IEC/IEEE 29148:2011 (E))
システムというのはソフトウェア以外のハードウェアなども含んでおり、人やプロセスもシステムの一部
ユーザーインターフェイスの分析と設計の中の作業のひとつ
システムのエンドユーザーのプロファイルに焦点を当てる
スキルレベルや業務の理解、新しいシステムに対する受容力などを記録
ユーザーのカテゴリごとに要求が導かれる
本質的には、ユーザーの種類ごとのシステム知覚を理解する取り組み
識別された利害関係者のニーズ、欲求、要望、期待及び識別された制約条件を記述するもの
文章又は形式的表現によるモデルを使用して表現する
システムの目的及び振る舞いに焦点を当てる
関連
利害関係者ニーズ及び利害関係者要件定義プロセス
en : software system
JIS X 0160:2021 の定義 : 利害関係者にとって、ソフトウェアが最も重要であるシステム
一般的に、ソフトウェアシステムは、ハードウェア、ソフトウェア、人員及び手作業で構成される
ソフトウェア開発の成果物
3 つの重要な特性 (1)
組織が学習できない 7 つの要因
1. 私の仕事は○○だから : 事業全体のことを考えられない
2. 悪いのはあちら : 他責にする
3. 先制攻撃の幻想 : 難しい問題に直面したときに積極的に敵に攻撃する (が、実際には敵はおらず、問題を引き起こしているのは自分自身を含めたシステム)
4. 出来事への執着 : 売上や予算削減、競合他社の新製品などの短期的な出来事を重視し、その背後の長期的なパターンを無視する
en : Theory of Constraints / 略 : ToC / 同義 : 制約条件の理論
TOC (Theory Of Constraints : 「制約理論」 または 「制約条件の理論」) は、「どんなシステムであれ、常に、ごく少数 (たぶん唯一) の要素または因子によって、そのパフォーマンスが制限されている」 という仮定から出発した包括的な経営改善の哲学であり手法です。
相手への気づかいに基づく感情の状態だと考えられやすい
思いやりは、行動に作用するシステムに対する気づきの度合いに基づくものでもある
参考文献
学習する組織 ―― システム思考で未来を創造する
en : General systems theory
1940 年代の後半に作られた
第 1 期のシステム理論とされる
世界のほとんどの現象は、要素間の関係性の網としてみなせる、という考えに基づく
複数の学問分野を一つの共通言語で形式化することを最終ゴールとしているっぽい
en : System Thinking / Systems thinking
複雑なシステムの根底にある構造を見抜き、問題解決を単純化するという考え方
多様な分野にまたがる一連の一般原則
以下に端を発する独自のツールと手法でもある
サイバネティクスのフィードバック
社会をシステムの観点から読み解こうとする理論
制御の学をルーツに、20 世紀半ばから発展
統計熱力学を下敷きにしている
コミュニケーション一元論を用いて、コミュニケーション以外のものを要素としないシステムのダイナミズムを記述する
従来の上部構造と下部構造の二元論とは区別される
モダンからポストモダンへの変化
生活世界がシステムに置き換わるプロセスの当初は、システムを使うのは生活世界を生きる我々がより便利で豊かになるため、と自己理解できる
システムが一定程度広がり、生活世界が空洞化 → もはや我々がシステムを使っていると言えない
我々や生活世界というイメージも、システムの構築物だと理解するしかない
変化のまとめ
生活世界でまかなわれていた便益をシステムに置き換える合理化過程
途上が近代過渡期 (モダン)
完遂した段階が近代成熟期 (ポストモダン)
あえて生活世界を保全しているといえるようになるのが再帰的近代
選択対象としての生活世界なので、厳密にはシステムの中に含まれる
アメリカの国内外で疑惑と論争の種を撒き散らし続ける
それでもフィールグッド・ステイトを目指す以外に選択肢はない
民主制の危機を招来する
プラットフォームの保全に関わる危機
1. 国民の便益増大が国家の権益拡大になる
システムの全域化による生活世界の空洞化
ウェーバーは、生活世界がシステムに置き換えられる動きを近代化や形式合理化と呼ぶ
モダンからポストモダンへの変化という逆説
生活世界の空洞化が起こった経緯
生活世界の空洞化 = システムの全域化は、郊外化の動きと並行
ローマ帝国が 2000 年も続いた理由
優れたシステム
徹底した合理主義
多様性 (ダイバーシティ)
キリスト教が国教になるまで、異なる宗教や文化に寛容だった
IT バリューストリームのサブセット
開始 : バリューストリームに属するエンジニア (QA なども含む) が変更を VCS にチェックインしたとき
終了 : その変更が本番環境での稼働に成功し、顧客に価値を提供して役に立つフィードバックや遠隔測定データを生成したときに終わる
第 1 フェーズである設計と開発はリーン製品開発とよく似ている
可変性と不確実性が高く、高度な創造性と再現できないような作業を必要とすることが多い
『The DevOps ハンドブック 理論・原則・実践のすべて』 より
バリューストリームの全てのステージで、右から左にコンスタントにフィードバックを返せるようにすること
複雑なシステム (複雑系?) の特徴
システム全体を把握して全ての部品がどのように関連しているか誰にも理解できない
同じことを 2 度しても、必ずしも同じ結果にはならない
『The DevOps ハンドブック 理論・原則・実践のすべて』 より
顧客にすばやく価値を届けるために、開発から運用への作業の流れを早くスムースにする
作業を可視化し、バッチサイズを縮小し、作業のインターバルを短縮し、品質を組み込んで下流に不良品が流れないようにする
やるべきこと
作業の可視化
https://dora.dev/
ソフトウェアのデプロイと運用パフォーマンスを促進する機能を理解することを目的としたプログラム
DORA は、チームがこれらの機能を適用できるように支援し、組織のパフォーマンスの向上につなげる
委託者から所有分離された資産を、受託者が管理・運用して、その利益を受益者に還元する仕組み
中世の英国に起源がある
登場人物
委託者 : もともとの資産の所有者
受託者 : トラストされた財産の所有者
https://tatsu-zine.com/books/continuous-delivery
著 : Jez Humble、David Farley
訳 : 和智右桂、髙木正弘
序文
サイクルタイムはどんなプロジェクトにとっても欠くことができない指標
投資家から資金を募り、株式や債券などに投資・運用する商品
ビジネスコンセプト : 構想立案時やシステム化企画時に検討され、要件定義開始時に提示されていることが多い
ビジネスコンセプト確認ドキュメント
ステークホルダー (利害関係者)
ステークホルダー関連図
ステークホルダー一覧
企画プロセスの中のプロセスのひとつ
『SEC BOOKS 共通フレーム 2013』 より
システム化構想を実現するために、運用や効果等の実現性を考慮したシステム化計画とプロジェクト計画を具体化し、利害関係者の合意を得ることが目的
アクティビティとしては、準備、立案、承認、がある
サービスマネジメントに対するシステム管理者 (systems administrator or sysadmin) アプローチ
既存のソフトウェアコンポーネントを組み立て、それらが協働するようデプロイしてサービスとして展開
システムの複雑さやトラフィック量の増加に伴い、システム管理者チームは成長して対応していく
システム管理者の役割に求められるスキルセットは開発者のそれとは著しく異なる
開発者とシステム管理者は 「開発 (development)」 と 「運用 (operations or ops)」 に分けられる
オンコールシフトの量と質
量 : オンコール業務に費やした時間の割合で計算
最低でも 50 % はエンジニアリングに充てて、25 % 以下をオンコールに、残り (25 % 程度?) を通常の運用に
常に 2 人のオンコールエンジニアがいるとすると、単一サイトで最低 8 人の SRE エンジニアが必要
デュアルサイトだと、各 6 人ずつが妥当
運用および保守のしやすさについての非機能要求のカテゴリ
保守性と運用性を合わせたもの、という理解でよいのかな
最近だと持続可能性というような表現もあったりするっぽいが、それに近い?
参考文献
システムを作らせる技術
利用者用文書に従って、意図する環境でシステムを運用するタスク、およびそのタスクのみからなるアクティビティのこと
参考文献
SEC BOOKS 共通フレーム 2013
IT システムの運用
運用自動化の仕組みのこと
リソースの柔軟性とアプリケーションの再利用性を管理する技術
クラウドのリソースの抽象化
背景
ユーザーの要求やサービスの仕様が常に変化する環境においてはアプリケーションのポータビリティが必要
プライベートクラウドとかパブリッククラウドといった場所に依存しないように
from リーンソフトウェア開発と組織改革
複雑性 : ソフトウェアは人が生み出す構造物の中でも複雑
実際に使われるよりも多くの機能が実装される。 ポリシー的に、スコープを縮める決定がなされづらい
顧客はプロセスの自動化を望むが、自動化よりも単純化がまずは重要
→ とにかく単純であることを重視
https://www.spec.org/
Standard Performance Evaluation Corporation の略
設立当初は System Performance Evaluation Cooperative という名称だったっぽい
最新世代のコンピューティングシステムについて、性能とエネルギー効率を評価できる、標準のベンチマークとツールを制定、整備、奨励するための組織
O : 組織 (Organization)
B : ビジネス
A : アーキテクチャ
P : プロセス
ほとんどの企業は OBAP モデル
組織の IT 部門が組織の事業目標をどのようにサポートするか
▲ 『ITIL 4 の教本』 より
関連
DX を考える際に考慮すべき 3 つの戦略
デジタル戦略と IT 戦略を立案する
組織が将来どうなりたいかという明確に定義された願望
関連
ビジョンや目標の関係
参考文献
ITIL 4 の教本
組織を方向付け、コントロールするための仕組み
目標を確実に達成するようコントロールする
3 つの主要活動
評価 (Evaluate)
方向付け (Direct)
事業体の目標の達成に向けてガバナンス主体が定めた方向性と整合するようにアクティビティを、計画、構築、実行し、モニターすること (COBIT 5 日本語版)
組織を指揮し、管理するための調整された活動 (JIS Q 9000)
関連
ガバナンスとマネジメントの関係
CDS は Create, Deliver and Support のこと
サービスを創り、提供し、サポートすること
サービスマネジメントの 4 つの側面のうち、下記のものについて具体的な実践
バリューストリームとプロセス (サービスマネジメントの 4 つの側面)
パートナとサプライヤ (サービスマネジメントの 4 つの側面)
知識集約的な世界で、対人関係の不安を最小限に抑えて、チームや組織のパフォーマンスを最大にできる組織のこと
参考文献
恐れのない組織
#組織
https://twitter.com/songmu/status/1625767100102094850?t=37dmEoDgmh664da2ZTzL8Q&s=19
en : Building shared vision?
達成すべき将来のイメージを組織で共有すること
共有ビジョンとは 「私たちは何を創造したいのか?」 に対する答え
学習する組織にとって不可欠
共有ビジョンがあるからこそ、学習の焦点が絞られ、学習のエネルギーが生まれる
#BCG
TOPPOINT 2022 年 2 月号の紹介
コロナ禍により、今後数年の経営環境に大きく影響を与える方向性
ニューノーマル時代の到来
経済活動の前提の地殻変動的揺らぎ
原著 : THINK AGAIN
著 : アダム・グラント
訳 : 楠木建
TOPPOINT 2022 年 7 月号での紹介
変化の激しい時代には、「考える・学ぶ」 能力よりも、知識をリセットして学びなおす 「再考する」 能力の方が重要
リクルートにて創業期から実践されている
組織の中で人間が人間としての自由度を拡大させるという理念
単なるお題目や経営ロマンシズムで終わっては意味がない
企業における働く人々の自己実現、そして豊かな人生の実現自体がゴール
経営リアリズム、人間を人間としてあるがままに捉えるという現実認識が出発点
Norbert Wiener (ノーバート・ウィーナー) が 1948 年に書いた 『サイバネティックス ― 動物と機械における制御と通信』 に由来する
組織をセンサー機構として活用するもの
ゴールを持ち、フィードバックの仕組みにより環境と相互作用する制御系の研究
研究自体の目的は、そのような制御系のプロセス (実行 (環境への影響を持つ)、センシング (環境の反応の確認)、評価 (ゴールと現在の状態の比較) の繰り返しを含む) を理解すること
en : service catalogue
組織がその顧客に提供するサービスについての文書化した情報 (JIS Q 20000-1:2020 より)
サービス、その意図した効果、サービス間の依存関係を説明するための情報を含める必要がある
アプリケーションやサービスに対するさまざまな業務要求を定義した、機能のテンプレートセット (『Kubernetes 実践ガイド』 より)
参考文献
価値を認める (appreciative) 探求 (inquiry) という名のとおり、組織の問題ではなく強みに注目した組織開発の手法
ポジティブコア (人や組織に活力を与えているもの) を見出し、それが発揮できる未来を探求する
基本的な進め方 : 4D サイクル
例
ディスカバリー (強みの発見)
同義 : ビジネスアナリシス
ビジネスアナリシスとは、組織をとりまく状況 (Context) において、ニーズ (Needs) を定義し、すべてのステークホルダー (Stakeholders) に価値 (Value) を提供するソリューション (Solutions) を推奨することによって、変革 (Changes) を可能にするためのプラクティス
▲ 『ソフトウェア要求 第 3 版』 で紹介されている BABOK バージョン 3 のドラフトより
一般的マネジメントプラクティス (ITIL 4) のひとつ、要員 (原文では workforce、労働力といえる) とタレント (コンピテンシーともいえる) の管理について。
事業達成目標の達成を支援するため、適切なスキルとナレッジを備えた優れた人材を組織内の適切な役割に確保すること
組織ベロシティを確立するうえで欠かせない
必要なコンピテンシーを備えた適切な人材を的確なタイミングに配置し、必要なサービスを提供するためにも必要