JAXA(宇宙航空研究開発機構)は6月21日、昨年から今年にかけて、複数回のサイバー攻撃を受けていたことを明らかにした。情報漏えいの可能性については調査中だが、攻撃を受けたのは「ロケットや人工衛星の運用や安全保障に関わる情報とは隔離されたネットワーク」としている。
情報漏えいの可能性についてJAXAは、「現在、調査中で、セキュリティに関わる情報のため回答できない」と話す。「関係省庁や個人情報保護委員会への報告は適宜行っている。もう少しまとまった段階、然るべきタイミングで説明する機会を設けたい」。
⇧ 公表されていないだけで、サイバー攻撃、至る所で行われてるんでしょうね。
Webシステム開発におけるスコープと工程とタスクと成果物の関係が整理された資料が欲しい
Webシステム開発以外の開発についてが分からないので、何とも言えないのだけど、
- スコープ
- 工程
- タスク
- 成果物
の関係が曖昧過ぎて、カオスな状態なのをどうにかしたい、と言うか、このあたり気になって仕方ないんだが、誰も気にならないんかな?
そもそもとして、
⇧「独立行政法人情報処理推進機構(IPA:Information-technology Promotion Agency, Japan)」の公開している情報にしてからして、工程の粒度がバラバラであるし、工程に関係するタスクや成果物の全量が全く見えて来ない...
デジタル庁の公開している資料によると、
設計・開発では、様々な活動が行われます。事業者が作成するスケジュールを確認する際、まずは俯瞰的に工程の流れを押さえて、大きなそごがないかを見ていきましょう。
情報システムの設計・開発は、大まかに捉えると以下のような流れになります。
なお、工程の名称は、事業者によって呼び方が異なります。
同じ名称でも、事業者によって捉え方が異なることがあるため、注意が必要です。工程の捉え方を間違えていると、適切な時期に求めたレベルの成果物ができていなかった、というようなことが発生します。
⇧ 工程の粒度とかの基準が無いせいか、認識がバラバラで、成果物についても認識が合わないような気がするんだが...
ネット上に、これといった情報が見つからず、結局のところ、
⇧ 前に、「独立行政法人情報処理推進機構(IPA:Information-technology Promotion Agency, Japan)」の公開しているドキュメントなどを参考に、自分が整理していた情報ぐらいしか整理されているものが無いという...
とりあえず、
- 要求定義
- 要件定義
の段階で、漏れのない一覧系を作っておかないと、基本設計以降のスコープで、必要となりそうな成果物の全量を正確に把握できないことになり、WBS(Work Breakdown Structure)を作る際に、タスクの過不足が起こりがちになると。
そもそも、WBS(Work Breakdown Structure)の対象とするスコープもハッキリしないですが、基本設計以降のスコープのタスクの全量を正確に見積もるには、
- 要求定義
- 要件定義
のタスクで、網羅された一覧系のドキュメントを成果物として作っておく必要があると。
結局のところ、どんなことを実現して欲しいのかについてのドキュメント化が為されていないと、タスクに紐づく成果物の精度を上げるのは難しいと。
- 要求定義
- 要件定義
を完全に合意した上で、基本設計以降のタスクに取り組まないと、タスクを進める上で基準とすべき情報が無いに等しい状態になりますからな...
WBS(Work Breakdown Structure)についても、列の分類がハッキリしないんよな...
- 大分類(大項目)
- 中分類(中項目)
- 小分類(小項目)
みたいな列を作ってるのを見かけることがあるけど、分類の粒度についての基準が分からんのよな...
ちなみに、
⇧ 上記サイト様によりますと、7列ぐらいに分類していらっしゃる…
何はともあれ、成果物の一覧を整理して成果物の全量を把握しないと、必要なタスクの全量と工数も正確に算出できないということになりそうね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。