京都府警は7月4日、府警が事務局を務める中小企業向けの情報セキュリティ支援サイトが改竄（かいざん）され、アクセスしようとすると別のサイトに接続される状態になっていたことを明らかにした。不正アクセスを受けたとみられる。府警は利用者のメールアドレスなどの個人情報が流出した可能性は低いとしている。
サイトは「京都中小企業情報セキュリティ支援ネットワーク」。府警が事務局として運営に関わり、京都府内の中小企業を対象に情報セキュリティに関する情報発信などを行っていた。サイトのサーバ管理は京都市内のWeb制作会社に委託していたという。
府警サイバー対策本部は「大失態であり重く受け止めている。原因を追究するとともに再発防止に取り組む」としている。
⇧ 原因が明らかになっていないのに、『サイトのサーバ管理は京都市内のWeb制作会社に委託していたという。』って発表するのってどうなのかね...
『京都府内の中小企業を対象に情報セキュリティに関する情報発信などを行っていた。』 っていうなら、今回の事件を事例として取り上げて、対策方法を公開してくれれば良い気はするんですけどね。
情報セキュリティに関わる情報発信を行っているのなら、セキュリティのノウハウを共有してくれても良い気はしますからね...
『大失態であり重く受け止めている。』と言わざるを得ない立場だとは思うのだけど、『再発防止に取り組む』って言葉が真ならば、具体的に何がいけなかったのかと実現できる対策についてのノウハウを共有して、正しいセキュリティの情報が普及するように努めて欲しいような...
アジャイル開発とは
あくまで、ソフトウェア開発における文脈での「アジャイル開発」についての調査ということで、Wikipediaによると、
ソフトウェア工学におけるアジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、人間・迅速さ・顧客・適応性に価値を置くソフトウェア開発である。
典型的なアジャイルソフトウェア開発では、チーム主導で設計・実装・デプロイを短期間に繰り返してユーザーが得た価値を学習し適応する、すなわちトライアルアンドエラーで開発が行われる。
アジャイルソフトウェア開発を可能にする開発手法にはエクストリーム・プログラミングやスクラムなどがある。
アジャイルソフトウェア開発宣言
アジャイルソフトウェア開発宣言（英: Manifesto for Agile Software Development）は「アジャイルソフトウェア開発」という概念を提唱した文書である。
⇧ ということらしい。
「アジャイル開発」には開発手法が様々あって、
⇧ 上記サイト様の分類図がイメージし易いかと。
「アジャイルソフトウェア開発宣言（英: Manifesto for Agile Software Development）」が宣言される前後の歴史を俯瞰するに、
■1945年～
■1999年～
⇧ いろいろな概念が提唱されてきた模様。
スクラムにおける開発の全体像
「スクラム」は「アジャイル開発」の数ある中の開発手法の1つで、単に「アジャイル開発」って言うと「スクラム」の内容を語っていることが多い気がする。
というわけで、「スクラム」についてWikipediaによると、
概要
スクラムは「問題に対する解決策を列挙」「高優先度の策を一定期間でチームで実行」「結果の検査に基づく調整」「その繰り返し」を実現できる環境を生み出すシンプルなアプローチである。
歴史
1986年に野中郁次郎と竹内弘高が「新製品開発のプロセス」について日本の組織とNASAといったアメリカの組織との比較、分析を行った研究論文「The New New Product Development Game」が『ハーバード・ビジネス・レビュー』に掲載される[8][9]。その中で柔軟で自由度の高い日本発の開発手法をラグビーのスクラムに喩えて「Scrum（スクラム）」として紹介した。
野中、竹内の論文に着想を得たJeff Sutherland、John Scumniotales、Jeff McKenna が、1993年にラウンドトリップ・エンジニアリング（一種の反復型開発）を取り入れたオブジェクト指向プログラミング設計・分析ツールを構築し、実践したのがソフトウェア開発手法としてのスクラムの最初である。
⇧ とのこと。
「スクラム」で開発をするとなった場合に、
⇧「スクラムチーム」を構成するのが基本らしい。
その他、Wikipediaを読み進めていくと、「スクラム」独自の用語や概念があるのだけど、ザックリと「スクラム」における開発の全体像として、
⇧ 上図のような感じになるらしい。
「要件定義」で決まった要件を実現するためのタスクの全量が「プロダクトバックログ」で管理されると思われる。
「要求定義」や「要件定義」とかも「スクラム」で実施してるのかどうかが分からない...
アジャイルでスクラムのプロダクトバックログの進捗管理ってどうしてるんだろう
で、「プロダクトバックログ」が「スクラム」における開発のタスクの全量っぽい気がするのだけど、Wikipediaでによると、
プロダクトバックログ
プロダクトバックログ（英: Product Backlog）はプロダクトが目指す姿とそうなるための要素の一覧である。プロダクトバックログはプロダクトゴールとプロダクトバックログアイテムからなる。
⇧ とあり、
⇧ という構成らしい。
各々については、
■プロダクトゴール
プロダクトゴール
プロダクトゴールはプロダクトの将来の状態である。すなわち将来のプロダクト利用が生み出すべき価値である。ゴールは評価可能であり、全員に共有され、一度に1つのみ設定される。
■プロダクトバックログアイテム（PBI）
⇧ という説明になってますと。
で、「プロダクトバックログ」からスケジュールとかを見積もりして、1つの「スプリント」で対応が可能なものを選別して、「スプリントバックログ」としてまとめると。
「スプリントバックログ」はというと、
スプリントバックログ
スプリントバックログはスプリントの計画である。このスプリントで実現したい成果（スプリントゴール）、そのために必要なPBI、PBIを生成する手順計画からなる。スプリントバックログはデイリースクラムで進捗を検査可能な程度の詳細度が必要である。スプリントプランニングで生成され、状況の変化に応じて適応する。
⇧ とある。
とりあえず、
- プロダクトバックログ
みたいな感じで、全てのタスクが「プロダクトバックログ」に集約されていると思われるのだけど、
- プロダクトバックログ
- ...
みたいな感じで、タスクを割り振るっぽい。
で、俄然、気になってくるのが、「プロダクトバックログ」がタスクの全量になってるはずだから、その全体のスケジュール、つまり「進捗管理」をどうしているのか？
ウォーターフォールでの開発だと、
あたりで、タスクの全量が洗い出せて、俯瞰して全体のスケジュールが確認できるので、全てのタスクの「進捗管理」を行えると思いますと。
アジャイルでの「スクラム」における開発で、全てのタスクの「進捗管理」ってどうしてるのか？
「スクラム」における開発で、全体的なスケジュールの把握についての話がネット上でほとんど語られていないような気がするんですよね...
「スクラム」における開発って「納期」とかあんまり意識しなくて良いってことなんですかね？
⇧ 何となく、「スクラム」における開発でも、
で管理する感じになるんですかね？
二重管理したく無いというのはあるのだけど、タスクの全量を俯瞰するためにはExcelとかで「WBS（Work Breakdown Structure）」とか作らないといけないんかな？
悲報...
⇧「納期」について全く触れられていない...
何と言うか、
QCDFとは、品質(Quality)、価格(Cost)、納期や入手性(Delivery)、柔軟性(Flexibility)の頭文字をとったもので、製造業における開発生産業務の評価における指標のひとつである。
⇧ 重要な気がするんだけど、「スクラム」における開発は全体のスケジュールについては、意識しなくて良いのかね？
普通に考えて「納期」から逆算して考えないと、タスクのスケジュールを見積もれない気がするんだけど、アジャイル開発の「スクラム」にとって、そのあたりの考え方をどうしてるのか知りたいですな...
まぁ、何が言いたいかというと、「スクラム」における開発の流儀が不明な点の雨霰であるからして、「守破離」の「守」を実践できないんよね...
結局、正確な情報がないまま、手探りで試みるしかない状況になるから、とりあえず始めるしかなくて、誤った知識が身に付くという感じになるから、IT系の学習ってモチベーションが上がらないんよね...
努力が報われず徒労感しかない世界ですな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
