⇧ 力業の感が過ぎる気がしますな...
数としては膨大ですが、原子核一つひとつは極微小で、860億個すべてを足し合わせても質量はおよそ29ピコグラム、これは人間の髪の毛1本（約0.1ミリグラム）の300万分の1程度にすぎません。
⇧ そもそも、
- 金原子核
- 金
って同じと考えて良いのかが疑問だ...
理系は門外漢なのだが、
⇧ 上図が正しいとすると、
- 金原子核
- 金
は別物であるという気がするので、
『鉛を金に換えることに成功』
というタイトルは語弊があるような気がしてならないのよね...
アジャイル開発のスクラムで「透明性」の話があるが結局WBSでタスク（作業）を管理する形になるのか
前回、
⇧「アジャイル開発」の「スクラム」において「タスク（作業）」の詳細化どうするんだっけという話をしましたと。
で、日本語版の「スクラムガイド」を改めて確認してみたのだが、
⇧ とあり、「スクラム」の思想の柱となるのが、
- 透明性
- 検査
- 適応
というものらしいのだが、「透明性」については、
透明性
創発的なプロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒える必要がある。
スクラムにおける重要な意思決定は、3 つの正式な作成物を認知する状態に基づいている。
透明性の低い作成物は、価値を低下させ、リスクを⾼める意思決定につながる可能性がある。
透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
⇧ とありますと。
であるのだが、「タスク（作業）」の詳細化について言及している情報が見当たらないのよね...
そもそも「スクラムガイド」に記載の、
- 作業を実行する人
- 作業を受け取る人
が誰のことを指しているのかが皆目見当が付かないのだが（文学じゃないんだから抽象的な表現は止めて欲しい）...
で、ネットの情報を漁っていたところ、「課題管理」や「プロジェクト管理」などで利用されるツールである「JIRA」で、
⇧ という記事が公開されていた。
「WBS（Work Breakdown Structure ）」はというと、
どのレベルまで展開するかはプロジェクトの全メンバーが作業内容を「具体的に○○をする」と理解出来るレベルまでに分解するのが理想であるが、最低でも作業担当者とプロジェクト管理者の理解が得られるレベルまでは必要である。
⇧ というような感じ。
「タスク（作業）」の抜け漏れが無いかを「視える化」するという側面が大きいような気がしている。
「ウォーターフォール開発」とかだと、「WBS（Work Breakdown Structure ）」は、「タスク（作業）」の全量を把握するのにメジャーな手法だと思われる。
とりあえず、「スクラムガイド」における「透明性」の説明にあった、
『創発的なプロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒える必要がある。』
を実現できれば良いのだが、「JIRA」の答えは「WBS（Work Breakdown Structure）」ということになるらしい。
まぁ、それ以外の回答が見付けられないだけで、「WBS（Work Breakdown Structure）」以外の「タスク（作業）」の管理について「JIRA」の解があるのかもしれないが...
話を「JIRA」が公開したらしい「WBS ガントチャート for JIRA」に戻すと、「JIRA」としては「かんばんボード」の機能があり、大体の状況は「かんばんボード」の機能で把握することができるので「ガントチャート」の機能は不要な気がするのよね...
ちなみに、「かんばんボード」はというと、Wikipediaの情報が正しいとすると、
A kanban board is one of the tools that can be used to implement kanban to manage work at a personal or organizational level.
Kanban boards visually depict work at various stages of a process using cards to represent work items and columns to represent each stage of the process. Cards are moved from left to right to show progress and to help coordinate teams performing the work. A kanban board may be divided into horizontal "swimlanes" representing different kinds of work or different teams performing the work.
⇧ まさかの英語でも「Kanban board」と呼ぶらしい。
Simple boards have columns for "waiting", "in progress", and "completed" or "to-do", "doing", and "done". Complex kanban boards can be created that subdivide "in progress" work into multiple columns to visualise the flow of work across a whole value stream map.
According to the Project Management Institute, a kanban board is a "visualization tool that shows work in progress to help identify bottlenecks and overcommitments, thereby allowing the team to optimize the workflow."
⇧ とあり、「チケット」レベルの「タスク（作業）」の状況は把握できますと。
ちなみに、「チケット駆動開発（TiDD：Ticket-Driven Development）」なるものがあるらしく、
チケット駆動開発 (ticket-driven development; TiDD) とは、 プログラム 開発手法の一種で、作業をタスクに分割しBTS（Bug Tracking System／ バグ管理システム ）のチケットに割り当てて管理を行う開発スタイル。細かな修正作業の多い従来開発の中で生まれたが、アジャイル開発との親和性が高いことから、エクストリーム・プログラミングをはじめとするアジャイル開発でも実践されている。
はじまり
チケット駆動開発が提案された2007年ころはソフトウェア開発環境が充実し、Subversion、trac、ウィキを活用したプロジェクト運営が注目されていた。
そのような中で、たくさんの細かな修正を効率よく行う方法として「チケット駆動開発」が現場から生まれた。
⇧ とありますと。
で、「ソフトウェア開発」する場合、大抵は何某かの「プロジェクト管理ツール」を利用しているとは思うのだが、「Atlassian」社製のツールで「JIRA」というものがあるのだが、
⇧ 何やら、
- Jira
- Jira Align
- Jira Service Management
3種類ほどありますと。
で、「JIRA」のドキュメントを見ると、
⇧ という感じで、「チケット」という概念は出てこない。
そして、何やら、
⇧ 上図のような分類になるようだ。
次に「Jira Service Management」の方のドキュメントを見ると、「チケット管理ソフトウェア」と言っていている...
⇧「作業タイプ」が「JIRA」と同じ感じになるのか、全く別物になるのかも皆目見当が付かないのだが...
そもそも、「JIRA」と「Jira Service Management」の違いが分からんのだが、
Jira is intended for project management and task management, Jira Service Management for service management like IT Helpdesk, HR Onboarding/Off-boarding etc. Both are similar, the main difference is that for JSM only agents need a license, customers can access and submit requests via a portal. In Jira anyone that need access to a project would need a license.
Also check out this blog post for a comparison of the two.
⇧「Atlassian」のコミュニティの情報で、外部のサイトのブログが紹介されており、
⇧ ということらしい。
というか、「Atlassian」の公式が違いについて整理した情報を公開して欲しいのだが...
非常にややこしいのだが、「JIRA」の1つの「タスク」が、「チケット駆動開発（TiDD：Ticket-Driven Development）」における1つの「チケット」と見なせそうだ。
話が脱線しまくったのが、前回の話でも触れたのだが、「スクラム」においては、「プロダクトバックログアイテム（PBI：Product Backlog Item）」が、「チケット駆動開発（TiDD：Ticket-Driven Development）」における「チケット」と粒度が同じと見なせそうだ。
とりあえず、「ソフトウェア開発」を、
で行うと仮定して、「JIRA」を利用した場合、「かんばんボード」とかの概念も入ってきたりするのだが、
| No | 文脈 | オブジェクト |
|---|---|---|
| 1 | スクラム | プロダクトバックログアイテム（PBI：Product Backlog Item） |
| 2 | JIRA | タスク ※1 |
| 3 | チケット駆動開発（TiDD：Ticket-Driven Development） | チケット |
※1 本ブログの内で出てくる「タスク（作業）」とは別物である。
⇧ 各々の文脈に登場するものを仮に「オブジェクト」とした場合、「オブジェクト」の粒度が同じになると思われる。
各々の「オブジェクト」が持つ情報の数は異なるだろうが、「オブジェクト」という単位でみた場合は、いずれも1つの「オブジェクト」と言えるので粒度は合うはず。
その前提で、「スクラムガイド」に記載のあるように、
1 スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。
スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。
プロダクトバックログアイテムがより⼩さく詳細になるように、分割および定義をする活動である。
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
⇧「プロダクトバックログアイテム（PBI：Product Backlog Item）」については、全てが 綺麗に小さな粒度に分割できるわけではないので、「チケット」を起票した段階での「タスク（作業）」の粒度だと大雑把過ぎてしまうので、「開発者（Developer）」が作業する際に（「チケット」が割り当てられるということ）、「チケット」を起票した時点の「タスク（作業）」について詳細化する作業が必要になって来るのだが、そのあたりの話について「スクラムガイド」では指標を示してくれていない...
繰り返しになるが、「スクラムガイド」で「スクラム」の重要な思想っぽい3つの柱の内の1つである「透明性」についての説明で、
『創発的なプロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒える必要がある。』
と謳うのであれば、詳細化した「タスク（作業）」をどう管理すべきなのかについて、具体的な指標を示して欲しいのよね...
「スクラム」における詳細化した「タスク（作業）」の「視える化」について、どうすれば良いのかしらね...
一応、「独立行政法人情報処理推進機構（じょうほうしょりすいしんきこう、英: Information-technology Promotion Agency, Japan、略称: IPA）」が公開している「アジャイル開発の進め方」の資料によると、
■2024年5月版
スプリングプランニング
スプリントプランニングは、スプリント（直近の1反復）の開始に先立って行われる。
プロダクトバックログから今回のスプリントで扱うスプリントバックログを抜き出して決定する。
プロダクトオーナーが優先順位にしたがって、今回扱うプロダクトバックログア
イテムを選び出し、スクラムチーム全体でそれらを合意する。
それらを開発者が見積もり、前回のスプリントで測定された開発実績に照らして、優先順位の上からどこまでを今回のスプリントに入れるかを決める。
さらに、その後、開発者が計画を詳細化し、タスクにまで分割する。
通常、タスクは時間単位（2~8時間程度）で見積もられる。
スプリントプランニングは、そのスプリントで達成すべきスプリントゴールをチームで合意する。
https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065606.pdf
■2020年2月版
スプリントプランニング
スプリントプランニングは、スプリント（直近の1反復）の開始に先立って行わ
れるミーティングをいう。
プロダクトバックログから今回のスプリントで扱うスプリントバックログを抜き出して決定する。
プロダクトオーナーが順位にしたがって、今回扱うバックログを選び出し、スクラムチーム全体でそれらを理解する。
それらを開発チームが見積もり、前回のスプリントで測定された開発実績に照らし
て、順位の上からどこまでを今回のスプリントに入れるかを決める。
さらに、その後、開発チームが計画を詳細化し、タスクにまで分割する。
通常、タスクは時間単位（2~8時間程度）で見積もられる。1つのタスクは1人に割り当てられる。
https://www.ipa.go.jp/digital/hjuojm000000gwoo-att/000065606.pdf
スプリントプランニングは、直近のスプリントでやるべきタスクを単に並べるだけ
ではなく、ユーザー視点の意味を意識しながら（適切な境界で適切な粒度
で）実現のためのタスクを切り出すことが必要となる。
そのスプリントのゴールを意識しながら、そのストーリーを実現するためのユーザー観点と開発者観点の両方でのアクションの切り出しが必要となる。
その際、それを支えるアーキテクチャを構想し、ストーリーの各ステップの具体的なアルゴリズムやデータ構造、インターフェース、実装技術を想定して作業時間の見積りを行う（あくまで仮説ベース。技術的に不確かな要素があれば、その調査タスクを別途切り出して追加する）。
その切り出しの単位は同時に他のタスクとの接続性やテストしやすさを考慮したものにする必要がある。
つまり、計画しながら設計と見積りと自主的な要員アサインとを同時にやっており、総合的な判断作業といえる。
https://www.ipa.go.jp/digital/hjuojm000000gwoo-att/000065606.pdf
⇧「開発者（Developer）」が「タスク（作業）」を詳細化するようなのだが、詳細化した「タスク（作業）」をどう管理するのかの言及が無いという...
くどいようだが、再三の繰り返しにはなるが、「スクラムガイド」で「スクラム」の重要な思想っぽい3つの柱の内の1つである「透明性」についての説明で、
『創発的なプロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒える必要がある。』
とあるのに、どう管理するかについては言及していない意味が分からないのだが...
とりあえず、
独立行政法人情報処理推進機構（じょうほうしょりすいしんきこう、英: Information-technology Promotion Agency, Japan、略称: IPA）は、日本のIT国家戦略を技術面・人材面から支えるために設立された独立行政法人（中期目標管理法人）。所管官庁は経済産業省。
⇧ と謳うのであれば、「模範」となる実用的な情報を公開して欲しい気はする...
何と言うか、「有言実行」ができていないのよね...
う～む、結局、「アジャイル開発」の「スクラム」で「タスク（作業）」を管理するのはどうするのが良いんですかね？
いずれにしろ、
- プロダクトバックログアイテム（PBI：Product Backlog Item）
- チケット
- 詳細化したタスク（作業）
の情報が集約されているべきだとは思いますが...
つまり、「チケット」を起点に、他の情報に辿り着ける形になっているべきだとは思われますが（個人的見解）...
最終的には、
- チケット
- プロダクトバックログアイテム（PBI：Product Backlog Item）
- 詳細化したタスク（作業）
のような感じで、「チケット」を確認すれば、担当する「プロダクトバックログアイテム（PBI：Product Backlog Item）」に関連する全ての情報のが確認できるような状態が良いような気はする。
まぁ、
指示的な部分を削減
スクラムガイドは時間が経つにつれて少し指⽰的なものになっていた。
2020 年版では、指⽰的な表現を削除または緩和して、スクラムを最⼩限かつ⼗分なフレームワークに戻すことを⽬的としている。
たとえば、デイリースクラムの質問の削除、PBI（プロダクトバックログアイテム）
の属性に関する記述の緩和、スプリントバックログにあるレトロスペクティブのアイテムに関する記述の緩和、スプリントの中⽌のセクションの削減などを実施した。
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
⇧ そもそも、「プロダクトバックログアイテム（PBI：Product Backlog Item）」の属性が何なのかが分からないですし、属性の全量についても分からんので、雰囲気で「スクラム」っぽいことをせざるを得ないのだが...
何と言うか、「プロダクトバックログアイテム（PBI：Product Backlog Item）」について、
- そもそも属性って何？
- 削減された属性は何？
- 残っている属性は何？
という状態であるからして、推測で作業するしかなく、『当たるも八卦当たらぬも八卦』ではないが、正しい「スクラム」が実践できているどうかは完全に「運任せ」という状況なのよね...
とりあえず、
スクラムは「経験主義」と「リーン思考」に基づいている。
経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。
リーン思考では、ムダを省き、本質に集中する。
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
⇧「経験」を重視という割には、必ずしも正しい「経験」を積み上げられるような仕組みになっていないのが、誠に残念過ぎるのだが...
所謂、「ガチャ」が過ぎるんよね...
良くも悪くも「武道」や「芸事」の「守破離」という概念は、「お手本」となる「雛形」があることから、「経験」を積み上げる仕組みとしては良くできている気はする。
『日本のIT国家戦略を技術面・人材面から支えるために設立された独立行政法人（中期目標管理法人）』と謳うからには、「アジャイル開発」の「スクラム」においても「模範」となる情報（中途半端な形の情報を公開するのではなく）を、「独立行政法人情報処理推進機構（じょうほうしょりすいしんきこう、英: Information-technology Promotion Agency, Japan、略称: IPA）」に公開してもらいたいところですな。
まぁ、言い方が悪いですが、
計算機科学において、Garbage In, Garbage Out（ガービッジ・イン、ガービッジ・アウト／ガベージ・イン、ガベージ・アウト）、略してGIGOとは、欠陥のある、または無意味な（garbage）入力データは無意味な出力を生み出すという概念である。直訳は「ゴミを入力するとゴミが出力される」。すなわち、「『無意味なデータ』をコンピュータに入力すると『無意味な結果』が返される」という意味である。Rubbish in, rubbish out (RIRO)とも表現される。
⇧ のような状況と言っても過言では無いので、「スクラム」を実施するモチベーションは上がらないよね...
とりあえず、
スクラムはシンプルである。
まずはそのままの状態で試してほしい。
そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を⽣み出すかどうかを判断してほしい。
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
⇧ とあるのが腹立たしい。
『スクラムはシンプルである。まずはそのままの状態で試してほしい。』
とあるが、どのように（How）すれば良いのかについて皆目見当が付かないのだが...
「フランツ・カフカ」の文学で表現されている「不条理」を彷彿とさせてくれますな...
不毛にも程があるのだが...
兎にも角にも、「スクラム」は様々な要素についてファジー過ぎるので、結果として「暗黙知」が多過ぎることになるのよな...
「スクラムチーム」内で、「認識齟齬」を抑制するために用語の定義や、ルールを整理するしか無さそうということですかね...
う～む、『我々は雰囲気で開発している』からの脱却は未だ遠い...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
