« 2022年2月 | トップページ | 2022年4月 »

2022年3月

2022/03/25

世界5大宗教入門の感想~世界の人間は宗教で生かされている

世界94カ国で学んだ元外交官が教える ビジネスエリートの必須教養 世界5大宗教入門」を読んで、ポジティブシンキングはプロテスタントの予定説から生まれているのではないかという仮説を持った。
ラフなメモ。

【1】以前、キリスト教の聖書の本を読んですごく面白くてハマった。

捏造された聖書の感想: プログラマの思索

しかし、カルヴァン派の予定説の考え方だけはよく分からなかった。
人が生まれた時点で、あなたは天国に行くのか、地獄に行くのか決まっている、と言われて、果たして人は真面目に生きるのか?と疑問に思ったから。

世界94カ国で学んだ元外交官が教える ビジネスエリートの必須教養 世界5大宗教入門」によれば、予定説の考え方は、あなたが死ぬ時に天国に行くのか、地獄に行くのか、神様が既に決めているが、今は確かに分からない。
でも、天国に行けると信じて、頑張りなさい、と励ましているのだ。

この考え方は、米国人のポジティブシンキングに似ている、という。
君には能力があると信じて頑張りなさい。
すると、本人はそれを信じて頑張ったら、実際に成果が出るようになる。
そうすれば、本人も自信がついて、さらに頑張ろうという気になる。
そういう成長のらせん構造にスムーズに乗っかかれる、と。

【2】キリスト教の聖書のおかげで、欧米人はプレゼン能力が上がっているのではないか、と言う。
実際、聖書の内容は、とてもドラマチックで、小説として読んでも面白い。
だから、他人に聖書を読み聞かせる時に、いかに人を引きつけるか、という観点で、プレゼンできる仕組みがある、という。

確かに、キリストの生涯の話は、波乱万丈でドラマティックだ。
おとぎ話や小説のように読み聞かせるテクニックが生まれる余地があったのかもしれない。

【3】「世界94カ国で学んだ元外交官が教える ビジネスエリートの必須教養 世界5大宗教入門」を読んだ後、牛尾剛さんのブログを読んで、心の拠り所に宗教を持つのは心の安定を保つための一つの手法なんだなと理解した。

生産性の向上のための孤独感の解消とエネルギー強化|牛尾 剛|note

アメリカに住んでいるとクリスチャンになるととてもいいことが多い話|牛尾 剛|note

人間は政治環境に左右されやすいので、こういう宗教のような価値観や拠り所がなければ、生きていけないのかもしれない。

| | コメント (0)

「大国政治の悲劇」の感想~現代はパワーポリティクスの歴史に戻ったみたいだ

大国政治の悲劇 | ジョン・J・ミアシャイマー, 奥山 真司を読んだ。
まさにロシア侵略のウクライナ紛争のタイミングで読むと、彼らがこの本で書いた通りに行動しているのではないか、と思った。
ラフなメモ。

【1】まず最初に断っておくと、この本は672ページという大著であり、注釈だけでも150ページもある。
論文みたいな本だ。
しかし、内容はとてもロジカルだ。
この本のプランは最初の第1章の最後に書かれている。

【2】まず、なぜ国家はパワーを求めて競争するのか、なぜ国家は覇権を求めるのか、という2つの問題を提示し、この問題が国際政治学で重要な根本問題であることを示す。

数学で言えばwell-defined、論文のお作法で言えば、justifyに相当するだろう。
つまり、この本で提示する問題の正当性を示す。

【3】次に、なぜ国家はパワーを求めて競争するのか、という問題を分析するために、2つのことを行う。
一つは、パワーを定義する。
もう一つは、国家が活動する舞台である国際システムにおいて、5つの仮定を置き、そこから国家がどのような行動を取るのか、を導き、最終的に最初の根本問題を解決する。

数学で言えば、公理系を最初に打ち立てて、そこから命題、定理、系を導くやり方に相当する。

僕はこの本を読んでいて、まるで過去に数学を研究していた時のことを思い出した。
数学のやり方はこういう社会科学、歴史学においても使えるのか、と改めてびっくりした。

この本を読んで、気づいた点はいくつかある。

【4】1つ目は、ミアシャイマーが提唱する理論「オフェンシブ・リアリズム」の結論は、国家は機会があれば覇権を求めて行動するので、世界は必ず対立し戦争が起こる。
ただし、その対立構造には、安定した二極世界、安定した多極世界、不安定な多極世界という種類がいくつかある。

【5】2つ目は、ポール・ケネディの「決定版 大国の興亡―1500年から2000年までの経済の変遷と軍事闘争〈上巻〉 | ポール ケネディ」の通り、国家の国力は、軍事力と経済力の2つであり、そのバランスが重要である、ということ。

【6】3つ目は、ハルフォード・マッキンダーが提唱した地政学の理論に似ているな、という点。

ランドパワー - Wikipedia

シーパワー - Wikipedia

オフェンシブ・リアリズムでは、覇権を求める国家はせいぜい地域覇権しか達成できない。
すると、今の世界地図から見れば、米国や英国のような海側から覇権国家を目指す国家と、ユーラシア大陸で覇権を求めるソ連、中国、ドイツ、フランスなどの国家に分別される。
基本は、大陸国家と海側国家の対決構造が必ずあるように思える。

ここで面白い点は、日本は海側国家の立場になり得たのに、実際は朝鮮半島や中国の一部を植民地化して大陸国家を目指そうとしていたことだ。
戦前の日本は、国際システム上では、当初は明治維新の後、西洋列強の植民地にならないように近代化を果たしたが、地域覇権を目指す方向に自然に活動し、最終的には、米国と戦争を起こすという自殺行為で最終的に破綻した。
「なぜ日本は無謀な戦争を決断して負けたのか」という問題は日本の歴史学でいつも問われるが、オフェンシブ・リアリズムの理論では「国際システム上では、国家は必ず覇権を求める行動を取らざるを得ないから、それから逃れることはできない」という結論になると思う。

また、ランドパワーとシーパワーの境目となる箇所がまさに紛争地になるのだろうなと思う。
だから、欧州大陸ではウクライナがNATOとロシアの中間地帯にあるし、朝鮮半島では、朝鮮半島の南部分はシーパワーである米国の影響力の配下にある、という例になるのだろうか。

【7】4つ目は、以前読んだウォルフレンの本「日本 権力構造の謎〈上〉 (ハヤカワ文庫NF) | カレル・ヴァン ウォルフレン」、ハラリの本「サピエンス全史セット【全2巻】 | ユヴァル・ノア・ハラリ」によく似ているな、と思った。

欧米人の歴史学や社会学の本はページ数が膨大で、その内容は非常にロジカルに書かれていて、自分たちの意見もはっきりしている。
しかも、その意見の正当性を示すために、大量の事例や事実を集めて補強しているし、反論されそうな内容は予め予想していてそれに対する反撃の意見と対症療法まで示している。

大国政治の悲劇 | ジョン・J・ミアシャイマー, 奥山 真司でも、米国、英国、フランス、ドイツ、ソ連、日本、イタリアの過去200年間の歴史をふりかえり、膨大な事実を自分の意見の正しさの証明に使っている。
そして、こういうオフェンシブ・リアリズムのような、普通の人間にはあまり心地よくない理論の話には反論したくなるが、それに対して、自分の意見の正当性と正しさを説明するために膨大な文章を使ってロジカルに組み立てている。

僕はこういう本は好きだ。
読むのは割としんどいけれど、メモしながら、ロジックの流れを追いかけてみると、最初の5つの仮定から定理が導かれ、最終的な結論まできちんと抑えられているのが分かる。

論文作成の技法part1~論文の構造: プログラマの思索

論文作成の技法part2~論文作成の観点: プログラマの思索

【8】大国政治の悲劇 | ジョン・J・ミアシャイマー, 奥山 真司では、最終章で「中国は平和に台頭できるか?」を設けて解説しているが、内容は悲観的だ。
まあ、オフェンシブ・リアリズムの立場ではそういう論理的な帰結になるだろうと思う。



| | コメント (0)

2022/03/24

CFD法のコツは同値分割にある #GIHOZ

ベリサーブ社のテスト勉強会で、CFD法のコツは同値分割にあると分かったのでメモ。
後半は適当な妄想なので後で消すかもしれない。

【参考】
【明日から使えるテスト技法勉強会】 #4 ~CFD法って、なに?~ - connpass

CEGTest - 原因結果グラフからテスト条件を作成するツール

CEGTestによる原因結果グラフの書き方: プログラマの思索

ソフトウェアテスト技法ドリルの感想: プログラマの思索

CFD法は原因結果グラフの別の表記法。
秋山さんの本「ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 | 秋山 浩一」にも紹介されていた。
実際はなかなか使いにくい。

テストケースやロジックそのものをANDやOR条件でつなげて原因結果グラフで書くこと自体が難しい。
そして、原因結果グラフで書いたとしても、何が嬉しいのか、分からない感覚があった。

今日の勉強会で良かった点は、テスト仕様を提示して、そこからCFD法で実際に図を描いて、そこからデシジョンテーブル、最後にテストケースを作る、という一連の流れが分かったこと。
実際は、ベリサーブ社が提供するクラウドサービス上でやっていただけ。
でも、GUIが揃っているのは便利。

CFD法のコツは、テスト仕様を同値分割の集合体と考えて、同値分割の集合でグルーピングして、同値分割のグループを原因→結果の流れで矢印を結んで、ロジックを状態遷移図のように一連の流れで示すこと。
同値分割はテスト技法の初歩で出てくる考え方だが、まさに同値関係でテスト仕様をグルーピングするのがCFD法の起点になる。

盲点になる点は、仕様を同値分割でグルーピングした時、補集合を忘れがちなことだ。
ベリサーブ社のツールでは補集合は「その他」として必ず表示されるので、漏れがなくなる。
大体のケースは、システムエラーや例外処理、異常処理のケースが多いだろう。
そういうケースを忘れないように図で示せるのは良い。

すると、CFD法は状態遷移図で表せないか?と思った。
CFD法で描いた図を見ると、同値分割の各グループを状態遷移図の「状態」と捉えることができる。
状態遷移図では、状態の入れ子構造も表現できるから、補集合も内部状態の一つとして表現できる。

そうすれば、状態遷移図を描ければ状態遷移表を自動生成するツールはastahやEnterpriseArchitectなどたくさんあるから、そこからデシジョンテーブルやテストケースを生成することができる。
つまり、状態遷移図に落とし込めれば、状態遷移表を通じてテストケースを自動生成するやり方はツールで既に実現されているし、状態遷移図は組込みソフトウェア開発者であれば見慣れた図なので、理解しやすいからだ。

ただし、このアイデアも、Q&Aで聞いた所、状態遷移図はトリガーやイベントも含む技法なので、CFD法のように原因と結果を結ぶ図とはそもそも観点が異なります、という回答があった。
確かに、全く違うのはその通り。

実際、下記の例題を考えてみよう。

(引用開始)
例題

ベリサーブショッピングモールでは、買い物金額やシネマ鑑賞に応じて、駐車場の料金を割引きするサービスを提供しています

■<駐車場割引サービスの仕様>

パターン 結果
お買い物金額2,000円以上 1時間無料
お買い物金額5,000円以上 2時間無料
お買い物金額10,000円以上 3時間無料※平日限定
シネマ鑑賞 3時間無料※鑑賞本数・上映時間に関わらず上限3時間
割引サービスの判定システムの実装を確認したところ、条件判定はシネマ鑑賞、お買い物金額、曜日の順に実施していました。
このシステムの判定結果が正しいことを確認するためのテストケースを作成してください。
(引用終了)

シネマ鑑賞、お買い物金額、曜日の3項目は、それぞれ同値分割でグルーピングできる。
具体的には、シネマ鑑賞の有無、お買い物金額は金額ごとに4パターン、曜日は平日と平日以外の2パターンに同値分割される。
そして、シネマ鑑賞、お買い物金額、曜日の3項目に対し、同値分割のグループの組み合わせを考えて、それらを原因→結果でつなげると、状態遷移図のような図でCFD法を示すことができる。

同値分割の各グループを状態と捉えて、状態遷移図で表現することは可能だろうと思った。

astahであれば、状態遷移図を描ければ状態遷移表は一発で自動生成できるから、そこからデシジョンテーブルやテストケースを作成すればいい。

状態遷移表プラグイン | astah* Plugins

状態遷移パスプラグイン | astah* プラグイン

CFD法の特徴の一つに、ループ構造がない点だ。
理由は簡単で、原因→結果の1方向しかないからだ。
この特徴を活かせば、状態遷移図や状態遷移表は非常にシンプルに描くことができるはず。

しかし、状態遷移表では前状態x後状態の表をイベントで表すから、CFD法には使えない。
状態遷移パス表なら、状態xイベントの組み合わせでパスをすべて生成するので、テスト仕様が3項目なら、入力3個と出力1個で合計4個のパターンを見なして、状態xイベントを4パターン組み合わせたもので表すことができるはず。

改めて理解できた点は、テスト仕様は同値分割で最小限のテストデータに整理できること。
そして、同値分割の組み合わせを原因と結果の組み合わせで表現する時に、原因と結果を状態に割り当てれば、状態遷移図らしきもので表現できると思う。

ちょっとこのアイデアを試してみようと思う。

| | コメント (0)

2022/03/23

テスト自動化の計画づくりにはコツがある #mabljapan

藤原さんが主催されたOL勉強会に参加した。
ラフなメモ。

【参考】
テスト自動化スタートダッシュ! テスト自動化のオンボーディングや戦略、計画づくりを考える編 - connpass

イベントレポート: テスト自動化スタートダッシュ! テスト自動化の戦略を考える編 | mabl

【1】テスト自動化をやりたい動機は色々あるが、効果を出すには、ゴール設定やスコープ設定が必要になる。
なぜなら、mablがいくら優れたテスト自動化ツールであっても、その現場の問題解決にピッタリ当てはまるとは限らないからだ。
たとえば、マニュアルテストをすべて自動化したいと思っても、実際はなかなかうまくいかない。
あるいは、テスト自動化で回帰テストを強化したり、受け入れテストを自動化したい、と思っても、効果を出すには割とギャップがある。

どうやらテスト自動化と従来のマニュアルテストの間には大きなギャップがあるらしい。
テスト自動化に合ったテストケース作成、テストシナリオ作成、テスト自動化のスコープや自動テストの粒度があるようだ。

テスト自動化の計画の話を聞くと、4つの注意点があるように思う。

【2】1つ目は、テスト自動化のゴール設定、テスト自動化で実現する品質の基準を明確に定めること。
テスト自動化で何を求めたいのか?
一口に品質向上と言っても、コストをいくら掛けてもいいわけではない。
藤原さんの言葉で腑に落ちた点は、テスト自動化をやっていると品質保証という言葉が合わない。
むしろ、どんな品質をテスト自動化で担保したいのか、を明確にすべきだ、と。

たとえば、受入テストのような手動テストを自動化したいのか、本番運用する前に品質検査するスモークテストを自動化したいのか、機能追加や機能改善してもデグレしないように回帰テストを重視したいのか、自動テストのカバレッジを上げたいのか、どれなのか、と。
あるいは、クレジット決済に関わるようなクリティカルな機能のテストは十分に自動化したいのか、本番システムの障害テストを自動化したいのか、と。

また、品質に関する基準も、マネージャや開発者、ユーザでも異なってくる。
この辺りは狩野モデルかな。
当たり前品質なのか、魅力的な品質を求めるのか。

マネージャならシナリオテストや受入テストを自動化したいだろうが、開発者なら単体テストのカバレッジを上げたり、回帰テストを強化したいだろう。
役割によって、求めたい品質は異なってくるから、そのゴールをまずは現場で合わせる必要があるわけだ。

【3】2つ目は、テスト自動化は、単体テストから受入テストまでのプラミッド型のスコープではなく、回帰テストからテストカバレッジまでの逆ピラミッドにすべきであること。
つまり、テスト自動化を導入する場合、松竹梅のレベルに合わせて、まずはテスト自動化に手を付けやすく、投資効果が大きい部分から始めて、徐々にテスト自動化の範囲を広げていくのがおすすめ。

資料のスライドでは、回帰テストの松レベルから始めて、受入テストのうち重要機能の正常ケースを網羅するスモークテストに手を付け、徐々にシナリオテストや単体テストの網羅率を広げていくような例があった。
この方法ならば、開発者も実装しやすいし、ユーザもテスト自動化の投資効果を得られやすいだろう。

【4】3つ目は、テスト自動化の実現手段は、WF型開発の各工程、アジャイル開発ならDevOpsの各プロセスによって異なること。
たとえば、単体テストならC0、C1のテストカバレッジ、結合テストなら回帰テストやCI、総合テストならシナリオテストやCD、受入テストならUIテストやスモークテストやCDなどが相当する。
つまり、テスト自動化の技術は、WF型開発の各工程、DevOpsの各プロセスによって異なる。
だから、投資効果を得たいならば、どのフェーズにテスト自動化を注力するのがよいのか、をゴール設定から見極める必要がある。

【5】4つ目は、テスト自動化を担当するロールは、現場の組織のリソースや組織構成に応じて、柔軟に対応すること。
たとえば、大規模なSaaSや大規模な基幹システムであれば、複数のチームが機能やサービス単位に分かれていて、それぞれで開発して、品質に責任を負っている。
すると、回帰テストやスモークテストを実行したい時、複数のチームをまたがってテストシナリオを作ってテスト自動化を図る必要が出てくるが、それを担当する人やチームが曖昧になりがちだ。
なぜならば、複数チームにまたがるので、その作業工数や品質について誰がその責任を負うのか、が不明確になりがちだからだ。
そこで、たとえば、複数の機能やチームを横断するテスト自動化のチームを作り、回帰テストを担当するケースもあり得ると言われた。
確かに、チーム横断、機能横断でそういうチームを作るときもあるだろう。

一方、各チームにテスト自動化の専任担当者を作った方がいい場合もあるだろうし、他方では、チーム内の各メンバーがテスト自動化のスキルを持つように能力を育成して全員が担当する、という場合もあるだろう。

やはりアジャイル開発であれば、少人数のメンバーでチームを組んで開発していきたいので、各メンバーがテスト自動化のスキルを持って実装できるのが理想だろうと思う。

【6】こういう話を聞くと、テスト自動化とは単にJUnitやSeleniumなどで実装するだけではなく、細かいの実践ノウハウが必要だと分かる。

僕は、ソフトウェア開発において、テスト自動化のスキルはシステムの品質を担保する上で重要な要素の一つであると思うので、この辺りの技術は今後もウォッチしていく。

| | コメント (0)

2022/03/21

RedmineのWikiタグでタスクリストを書けるようになった

RedmineのWikiタグでタスクリストを書けるようになったのでメモ。
これは色々使えそう。

【参考】
【毎月更新】Redmine リリース前の新機能を先行チェック!タスクリストの記法など(2022年1月コミット分) | Redmine.JP Blog

Feature #35742: Enable task list items for Common Mark text formatting - Redmine

タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine: プログラマの思索

Redmineの親子チケットの功罪: プログラマの思索

タスクリストを使いたい場面は、自分だけのタスクを分解してメモしたい時や、作業手順が決まっているルーチン作業の進捗管理に使いたい時だろう。
今からやるべきゴールがあって、それに対してどんな作業があるのか、洗い出して、それをタスクリストで順に並べて、1個ずつ消し込みながら作業を管理したい。
作業ができる人ほど、タスクリストのような地味な作業管理をきちんとやっているように思う。

しかし、Markdownでやろうとすると、箇条書きで作業手順を書いて、逐一取り消し線を引いていく、みたいな面倒な作業が多い。

そこで、タスクリストの記法を使えば簡単に、未完了の作業と消し込んだ作業を管理しやすくなる。
こんな感じで使えばいい。

* [x] Item-A
* [ ] Item-B
    * [x] Item-B-1
    * [ ] Item-B-2-a

ただし、注意点はいくつかある。
1つ目は、タスクリストのたびにコメントに履歴がたくさん残ってしまって、履歴が煩雑になってしまうこと。
だが、Redmineではチケットのコメント履歴をタブで分けてくれているので、見分けることはできるだろう。

もう一つは、タスクリストの作業状況はチケットを開かなければ分からないこと。
チケット一覧からタスクリストが見えないからだ。
消し込んだ状況と進捗率を同期する運用もあり得るが、手作業で更新するのが鬱陶しい。
よって、タスクリストを使う時はチケット一覧でタスク管理しなくていいイメージで考えた方がいいと思う。

こういうリスト、箇条書きを使った手法は、ライフハックの技法として数多く知られているので、色々試してみると経験しやすいと思う。

仕事と自分を変える 「リスト」の魔法 | 堀 正岳シンプルTODOリスト仕事術超・箇条書き―――「10倍速く、魅力的に」伝える技術 | 杉野 幹人の本が分かりやすかった。
いろいろ試してみたいと思う。

| | コメント (0)

2022/03/20

マイクロサービスはアトミックな操作で閉じるべきシステム分割論に基づいたアーキテクチャなのか

渡辺さんのブログを読んで、マイクロサービスはアトミックな操作で閉じるべきシステム分割論に基づいたアーキテクチャなのかどうか、という問題提起をしていると感じた。

アジャイルとマイクロサービスは最悪な組み合わせ - 設計者の発言

データモデリングで考えれば、サブシステム分割の単位は、CRUD操作で閉じるようにシステム分割すべき。
一方、マイクロサービスは僕の考えでは、外部インターフェイスの一つのアーキテクチャに過ぎないのに、ものすごいシステムアーキテクチャみたいな幻想があって、システム分割論と混同する開発者が多いのでは、と思う。

アジャイル開発というプロセスでは、特にスクラムでは、プロセスに特化していて、ソフトウェア技術や設計アーキテクチャの話はあえて避けていると思う。
だからこそ、スクラムという開発プロセスのフレームワークはIT業界のあらゆるプロジェクトに適用できるし、製造業など他の業界でも使われるようになった。
しかし、それですべての問題が解決できるわけではない。
実際、XPやScrumを生み出した人たちのキャリアを見ると、ソフトウェア開発の経験がとても豊富で、オブジェクト指向設計、テスト駆動開発、継続的インテグレーションなど数多くのベストプラクティスを生み出している。
彼らは技術的要素を軽視しているわけではない。

マイクロサービスはSaaSのようなWebシステムでは、外部インターフェイスの公開APIとして優れている技術と思うが、それですべての問題が解決できるわけでもないし、この辺りの技術の実装はとても難しいと個人的に思っている。
なぜなら、こちらが仕様を準備して想定しているような使い方を、外部APIを利用する人たちはしない時が多いとか、非機能要件のうち性能要件やセキュリティ要件の実現が非常にシビアだったり、割と罠が多いからだ。

この辺りの技術は色々考えてみたい。

| | コメント (0)

2022/03/19

映画「ひまわり」は名作だった

映画「ひまわり」の感想をメモ。確かに名作だった。

ウクライナで撮影された名作映画『ひまわり』全国各地で拡大上映へ|ORICON NEWS|Web東奥

【1】映画を見たきっかけは、舛添さんのツイートで気になったことだった。

舛添要一さんはTwitterを使っています 「1942年夏、ヒトラーはスターリングラードを攻略。ムッソリーニはイタリア軍15万人を派遣。独軍敗北。イタリア軍もまた大敗北し、2万5千人が戦死し、7万人が捕虜になり、祖国に帰還できたのは1万人のみ。この悲劇が伊映画『ひまわり(I Girasoli)』(1970年)の物語だ(続く)。https://t.co/iSyBhp8NPH」 / Twitter

学生時代に既に見たが、イタリア人夫婦の悲恋の物語ぐらいのイメージで、あまり心に残ってなかった。
しかし、今見直すと、映画のシーンにはたくさんの意味が込められていることが分かって、すごく引き込まれた。

自分が理解できたことをメモしておく。

【2】映画「ひまわり」の舞台は今、ウクライナでの戦争地域そのものにある。

タイトルにあるひまわり畑は、ウクライナのヘルソン州にあると言われている。
ウクライナ大使館のHPによれば、そこは今、ロシアが侵攻して激戦地になっている場所のはず。

在ウクライナ日本国大使館:エピソード集(日本語)

平和であるはずのひまわりの畑が今、まさに激戦地になっていると思うと、やりきれない気持ちになる。
だからか、今、日本でも映画「ひまわり」が注目されて、各地で上映されているらしい。

News Up 「戦争とは何か」 ウクライナ侵攻で再注目の映画「ひまわり」 | ウクライナ情勢 | NHKニュース

【3】ひまわりには本当に数多くの意味が込められていることが分かった。

まず、美しく咲き乱れるひまわり畑の下には、捕虜となったイタリア兵やロシア兵の死体が数多く埋まっているらしい。
映画では影絵のようにそのシーンが現れる。
ひまわり畑には墓碑もあって、ご覧なさい ひまわりやどの木の下にも麦畑にもイタリア兵やロシアの捕虜が埋まっています、ここから帰還したイタリア兵はいませんよ、と付添の者からも言われる。
つまり、あのきれいなひまわりは、戦争で亡くなった人たちを養分にして咲いている。
そして、そのひまわり畑でも、現に今同じような戦争が起きて、また死体が積み重なるのだろうと思うとやりきれない。

2つ目は、ひまわりは"あなただけを見つめる"という花言葉だそうだ。
「ひまわり」は女性を表していて、愛する夫(太陽)を追い続ける存在という比喩であるらしい。
つまり、ジョバンナは愛する夫アントニオの存在を異郷のロシアまで追い続けてきたというストーリーにもつながる。
しかし、ジョバンナがアントニオの居場所を見つけた時、彼は自分を凍死状態から救ってくれた若いロシア人女性と結婚して子供まで作っていた、という悲恋が待ち受けていた。

3つ目は、ひまわりはロシアの国花だそうだ。
日本なら桜に相当するだろうか。
このひまわり畑の上でロシアが戦争しているのを見ると、因縁みたいなものを感じる。

ひまわりとは関係ないが、ウクライナとロシアの戦場は、ドニエストル川やヴォルガ川付近だ。
この辺りの地域は、インドヨーロッパ語族の祖国に当たると言われている。
つまり、今の英語、フランス語、ドイツ語、イタリア語などを話すヨーロッパ人は、この地域から移動してきた祖先の子孫に当たる。
そんな祖先の故郷で今まさに戦争が起きているのを見ると、欧米人の因縁、業の深さ、原罪みたいなものがあるのかなと想像してしまう。

【4】独ソ戦の過酷さを念頭に置いて映画を見直すと、あまりにもリアルに感じる。

独ソ戦 絶滅戦争の惨禍 (岩波新書) | 大木 毅によれば、第2次世界大戦の独ソ戦は、日本人の戦争体験よりも遥かに凄絶だ。
太平洋戦争で日本人約8000万人のうち戦死者は約400万人で5%だが、ソ連側は約1.8億人のうち戦死者約3000万人で約20%近く、ドイツ側は約7000万人のうち戦死者約800万人で10%以上が死んだ。
なぜなら、独ソ戦は通常の限定戦争ではなく、絶滅戦争の性格を持っていたために、相手側の領土を奪うだけでなく、そこに住む人を徹底的に根絶やしにするほどの凄絶な戦いだったからだ。
しかし、ロシアの過酷な冬で、ナポレオンのフランス軍も、そしてドイツ軍も破れた。

ジョバンナの夫アントニオは過酷なロシア戦線に送られるが、たぶん、スターリングラード攻防戦にも関わったのでないか。
スターリングラード攻防戦はドイツ軍とソ連軍の戦いと思っていたが、スターリングラード攻防戦 - Wikipediaを読むと、イタリア軍も含まれている。
この事実は僕も知らなかった。
舛添さんのツイートが正しいならば、イタリア兵15万人が送られて、戦死者2.5万人ものぼり、祖国に帰還できたものはわずか1万名だから、90%以上のイタリア人兵士は死んだか、行方不明になったことになる。
スターリングラード攻防戦は、ドイツ軍もソ連軍も合わせて死傷者200万人を越えるひどい戦場だった歴史をふりかえると、映画の舞台の過酷さが分かる。

実際、映画のワンシーンには、雪の中の丘に突然翻る赤旗と、ソ連軍の落下傘部隊、スキー部隊、雪上車部隊による戦闘シーンが影絵のように流れる。
画面いっぱいに翻る赤旗は、配送する枢軸国の兵士に対するソ連軍の圧倒的な勢いを表し、戦場に流された多くの兵士たちの血をイメージしているらしい。

映画のシーンには、深い雪の中で敗走を続けるイタリア兵士たちが疲れ切った姿で歩き続けていて、最後には、アントニオがもう歩けず雪上に倒れて友を見送る場面がある。とてもやりきれない。

【5】映画には伏線となるシーンがたくさんばら撒かれていて、最後にその意味が分かる。

ジョバンナが持っていた、夫の写真。
彼女はこの写真を片手に、異郷のロシアで夫を探す。
しかし、彼女が夫を見つけた時、夫には、彼を凍死状態から助けて介助してくれた女性と子供まで作っていたことを知って、列車に乗って逃げる。
そこに、彼女が落としていった夫の写真の裏には、愛するジョバンナへ、アントニオより、と書かれていた。
彼は、この写真を手に取り過去を思い出すことで、イタリアの母親の死に際に会いたいという理由でイタリアに戻り、ジョバンナに会おうとするアクションのきっかけになる。

映画のクライマックスのシーンでは、いくつかのアイテムが伏線として回収される。
その点が分かると、この映画がとてもロジカルに作られているのが分かる。

アントニオから新婚旅行で贈られたイヤリング。
ジョバンナは、アントニオが来ると電話で聞いて、十数年ぶりにそのイヤリングを付ける。
一度は会うのを拒んだのに、愛する夫にきれいに見せたい、あるいは、あなたが新婚旅行で贈ってくれたイヤリングを付けているのよ、と言いたい気持ちなのか。

ジョバンナは、自分の赤ん坊の息子の名前にアントニオを付けていた。
自分が愛した男の名前を付けていたわけだ。
ジョバンナがアントニオへの愛を忘れていなかったことを暗示している。

アントニオはジョバンナに毛皮をプレゼントした。
映画のプロットポイント1のシーンでは、アントニオがロシア戦線に向かうときに、「すぐに帰ってくる。毛皮を土産に」とジョバンナに言った場面がある。
彼は、十数年ぶりにその約束を果たしたわけだ。
彼はジョバンナを愛していたからこそ約束していたことを忘れていなかったことを暗示している。

【6】この映画では列車が重要な意味を持っている。
実際、印象的なシーンには必ず列車が使われている。

・戦地へ旅立つ夫アントニオを乗せた列車。
・帰還を信じて夫の写真を手に列車を待つジョバンナ。
・夫アントニオに妻と子がいる事を知り、ジョバンナが逃げるように飛び乗った列車。
・夫アントニオと再会しても、お互いに妻子がいて感情がすれ違い、永遠の別れとなる列車。

愛する男女の仲は、列車という自分たちの意思ではコントロールできないものによって、引き裂かれてしまう、という意味を暗示しているのだろうと思う。

プロローグやエンドロールで流れるクラシックなテーマ曲(名曲!)とともに、画面いっぱいに広がるひまわり畑の美しさが鮮やかで、また悲壮感が漂う。

この映画では一貫して主要な場面では、このクラシックなテーマ曲が流れる。
この曲のフレーズが映画のシーンに絡められて、人々の記憶に残るのだろう。

【7】映画「ひまわり」は名作と思う理由の一つは、喜怒哀楽のユーモアや緊張感が単調ではなく激しい起伏があって、感情を呼び起こすから。

プロローグでは、ジョバンナとアントニオが陽気なイタリア人らしく、キスしたりやたらベタベタする場面がある。
そして、アントニオの徴兵を回避したいために、ジョバンナとアントニオは、徴兵されるときに結婚したら、結婚休暇が12日間もらえることを理由に、彼らは結婚式をあげて、わずか12日間だけの夫婦で新婚生活を楽しむ。
卵30個以上のオムレツづくりとか、コミカルな場面が多い。

しかし、映画の中盤以降は、ロシア戦線の激戦地や過酷な冬のシーン、多数の死んだ兵士や農民が埋まっているひまわり畑、そして、夫を見つけたのに取り戻せないと知ったジョバンナの悲しみ、最後に、お互いに愛が残っていても感情がすれ違って永遠の別れを告げる場面、へ流れるように、一転して、辛く悲しい感情が押し寄せる。
つまり、アップテンポのシーンで上げておいて、後半では辛く悲しい場面を流すことで感情の起伏を故意に作っている。
実際、後半では、イタリア人の陽気さの雰囲気が全く出てこない点が、感情の落差をもたらし、人々の印象に残る仕掛けになっているのだろう。

【7-2】また、映画「ひまわり」は名作と思うもう一つの理由は、脚本の三幕構成で上手く作られていること。
一般に、三幕構成の理論では、序盤・中盤・終盤の3つで構成されるが、上映時間を4分割した時に、序盤は最初から1/4まで、中盤は1/4から3/4まで、そして終盤は3/4から最後までで時間配分されている。
序盤と中盤の境目はプロットポイント1という区切りの事件、中盤と終盤の境目にはプロットポイント2という区切りの事件が設定されて、三幕構成のストーリーの質が劇的に変わるように仕組まれている。
また、中盤の真ん中のシーンにはミッドポイントが置かれて、この映画が最高潮に印象付けられるシーンが配置される仕組みになっている。

映画「ひまわり」では、プロットポイント1は、夫アントニオがロシア戦線に向かう列車をジョバンナが見送るシーンになっている。
つまり、序盤は甘い新婚生活の流れだったが、ここでそれまでの流れは断ち切られて、中盤の重苦しい独ソ戦の悲劇、行方不明となったアントニオを探すストーリーへ映る。
実際、プロットポイント1は映画の上映時間の1/4辺りに置かれている。

ミッドポイントでは、ジョバンナがロシアでマーシャの家を見つけてその経緯を知り、アントニオと再開できるが、妻子がいることを知って、ジョバンナが列車に逃げ込むシーン。
このシーンはこの映画で一番感動的なシーンとして、Youtubeでもたくさん流れている。

最後にプロットポイント2は、アントニオがイタリアに戻って、ジョバンナと再開するために会いに行くシーン。
ここから、2人の関係は、お互いに愛が残っていても、お互いに家族がいることが分かり、最後に、夫がロシア戦線へ出征する時に見送った時と同じ駅で、妻が夫を見送るラストシーンへつながる。
つまり、最後の感動的なラストシーンというクライマックスへつながる事件として、ジョバンナに会うためにイタリアへ行くきっかけの事件がプロットポイント2で設定されている。

すなわち、プロットポイント1・2、ミッドポイントというシーンを三幕構成に合わせて配置することで、映画のストーリーがコンポーネントのように上手く組み立てられていて、感情の起伏もそれに合わせるように人々の感情に働きかけるように作られているわけだ。
こういうロジカルな構成が名作と言われるどの映画でも構成されていると分かると、映画を見るのがより楽しくなってくる。

【8】映画「ひまわり」は1970年公開とあって、映像自体は今よりも遥かに素朴で洗練されていない。
しかし、各場面のシーンを後から見直すと、ここに以前使った伏線が使われているのか、とか、映画のストーリーがロジカルに作られているのが分かる。
すべてのシーンが映画の主テーマである男女の愛を戦争が引き裂いた悲劇のストーリーに沿っている。
たぶん、映画を作った監督も、ロジカルに組み立てる意思を強く持って、ストーリーとシーンを作り込んだのだろうと思う。


| | コメント (0)

2022/03/06

RedmineJapanで参考になった講演資料を読み直す

RedmineJapanで参考になった講演資料のリンクを集めておく。
ほかの講演資料もあるみたいだが、ネット上で検索するのが面倒。
まだ公式サイトにも講演資料のリンクも動画リンクもないので、自分が気になった資料だけリンクしておく。

【参考】
RedmineJapan vol.2 2022/2/25 - Togetter

【参考1】
情報のまとめ方を議論する  #redmineeva | マドびっ! Madosan's View

気になった講演内容がいい感じでまとめられている。
みうみうさんの講演では、「ストックとフローの話だけどPMISの話」「情報が分かれると検索性が落ちる」点は参考になる。

【参考2】
Redmineを使った技術サポートサービスの運用効率改善事例 #RedmineJapan - 2022-03-04 - ククログ

理解できた内容は、下記に書いた。
ククログさんの「Redmineを使った技術サポートサービスの運用効率改善事例」がとても役立つ: プログラマの思索

【参考3】


【参考4】

後でじっくり読む。

| | コメント (0)

ククログさんの「Redmineを使った技術サポートサービスの運用効率改善事例」がとても役立つ

RedmineJapanで講演されたククログさんの「Redmineを使った技術サポートサービスの運用効率改善事例」がとても役立つと思ったのでメモ。

【参考】
Redmineを使った技術サポートサービスの運用効率改善事例 #RedmineJapan - 2022-03-04 - ククログ

Redmineをサポートデスク管理に使う時に、いくつかの問題点を自社開発したプラグインで解決した事例。
とても参考になる。

【1】Redmineでヘルプデスクを扱うアイデアは、10年以上前から、@g_maedaさんが試されていたし、僕もそれに触発されて色々アイデアを考えていた。

Redmine 4.2で作るヘルプデスク向け問い合わせ受付・管理システム

Redmineを使ったヘルプデスクシステムでサポート業務を効率化

Redmineによるwebサポート窓口の実装と運用

Redmineによるメール対応管理の運用事例

メールからRedmineのチケットを自動登録する時の注意点: プログラマの思索

【告知】「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」を講演します: プログラマの思索

Redmineの最新機能でサポートデスク管理をより効率よく使う運用方法のアイデア: プログラマの思索

本来、顧客からの問い合わせ管理というヘルプデスクは、いわゆるSoEの観点では非常に重要な業務になっている。
顧客満足度を維持していくには、製品やサービスを売り切り型ビジネスではもはや意味がなく、購入後にいかに顧客の不満を吸い取って対応したり、事前に顧客の不満を解決するなど、事前事後の対策が必要だ。

その場合、顧客ごとに問い合わせ情報を管理して、過去の履歴を見れるようにして、オペレータが即座に対応できる体制を作りたい。
Redmineはチケット管理機能が強力なので、問い合わせメールをチケットに取り込むことさえできれば、メールの履歴はチケットのコメントに対応付けることで、一つのスレッドにまとめることができる。
チケットに情報が蓄積できれば、強力なチケット集計機能により、問い合わせ内容を分類したり、問い合わせ工数を集計して、顧客へ月次報告する元ネタに使うこともできる。
普通は実績ベースの作業工数を報告して、検収してもらって費用を回収する場合が多いはずだ。
だからこそ、顧客の問い合わせ管理をRedmineで集約して管理することは、ナレッジを蓄積したい目的だけでなく、月次検収をスムーズに行うために必要なツールになりうるはずだ。

【2】しかし、Redmineのデフォルトの機能では、問い合わせ管理のかゆい点に届かない場合も多い。

では、Redmineを使った技術サポートサービスの運用効率改善事例 #RedmineJapan - 2022-03-04 - ククログにどんな新しい観点、問題意識があったのだろうか?

【2-1】サポートデスクでは、顧客からの問い合わせメールに対し、やり取りしながら対応する必要がある。
Redmineのデフォルト機能でも、rakeコマンドでメールをチケット登録できるが、問い合わせメールをチケットに登録したとしても、メールタイトルの揺れ、チケットの更新ミス、メール内容の反映漏れなどが発生しがち。

そこで、ClearCode Inc. / Redmine plugin email importer ・ GitLabを使う。
問い合わせ専用メールアドレスを各顧客専用に発行しておき、宛先メールアドレスに対応する顧客用のプロジェクトにチケットを自動起票する運用が可能になるので、起票済みの問い合わせに関するメールのやり取りを既存のチケットへのノート注記として自動的に追記できる。

【2-2】顧客によっては「その顧客専用の問い合わせ用メールアドレス」が発行されていない場合や、別のアドレス宛に問い合わせメールを送信されていたりする時は、Thunderbirdからメールを元にRedmineのチケットを発行・更新できるようにする。
メールから手動でRedmineチケットと対応付けたい時に便利だと思う。

RedThunderMineBird Plus - Redmine連携+ :: Thunderbird向けアドオン

【2-3】問い合わせに対して過去の回答を参照する必要がある場面は多い。
その時に、Redmineの全文検索プラグインを使う。
これにより、Redmineのデフォルトの検索機能よりも遥かに強力に検索できるから、Redmineに蓄積されたDBが事実上ナレッジDBとして扱える。

Redmineで高速に全文検索する方法 - 2016-04-11 - ククログ

全文検索プラグインにより、チケットに添付されたPDFやWord文書なども検索対象にできるので、RedmineDBも添付ファイルも全て検索対象になる。
つまり、実際の運用ではデータの整合性に神経質になるよりも、どんどんチケットに書き込んだり、ファイルをチケットに添付すればいいと思う。

【2-4】サポートデスク管理では、顧客単位にRedmineプロジェクトを割り当てる運用が多いだろう。
顧客ごとにチケット管理したいし、顧客ごとにナレッジを蓄積したいから、プロジェクト単位で分割したくなる。
すると、プロジェクト概要に顧客の基本情報を書いておくと便利。
しかし、実際の運用では、チケットで問い合わせ対応している時に、概要タブをワンクリックの作業をやって顧客が使うシステム環境、利用者情報などの情報を見る操作が一手間かかる。

そこで、ClearCode Inc. / redmine-plugin-descriptions-sidebar ・ GitLabを使って、チケットの一覧や個別表示の画面のサイドバーに「概要」の内容を埋め込み表示させる。
これにより、「画面を切り替える」という一手間なしに顧客情報を即座に参照できる。
こういうちょっとした機能が作業の効率化を進ませてくれる。

【2-5】サポートデスクの管理では、毎月の作業報告を顧客に送って、検収してもらって月次費用をいただくという契約が多いだろう。
すると、顧客単位のRedmineプロジェクトに、問合せチケットは蓄積されているので、チケット一覧からそのまま出せば良い。
そこで、重要な情報は、問い合わせチケットごとに記録された問い合わせ情報と実績工数だ。

しかし、Redmineのデフォルトの工数出力CSVはあるが、そこからExcelマクロに取り込んで、顧客向けの毎月の実績報告を作るのは面倒だ。
そこで、ClearCode Inc. / redmine-plugin-work-report-exporter ・ GitLabを使って、作業実績のExcel報告をワンクリックで出力できるようにする。

【3】改めてククログさんの資料を読み直すと、Redmineの素の機能をあまりカスタマイズせず、ヘルプデスクの機能を強化している点が素晴らしいと思う。

本来、ヘルプデスク管理の機能をRedmineに追加していけば、最終的にはRedmineはCRMと同じになると思う。
特に、アウトバウンドメールやインバウンドメールのような機能がRedmineにも欲しくなる。

しかし、Redmineをカスタマイズしすぎると、Redmineのバージョンアップに追随できなくなるデメリットが出てくる。
だから、Redmineの素の機能をあまりカスタマイズせず、ヘルプデスク管理機能を強化できるように、Redmineバージョンアップに追随できるように機能強化を図るという綱渡りのような技術が要求される。
そういう観点から見ても面白いなと思った。

| | コメント (0)

2022/03/04

タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine

RedmineJapanの懇親会で友人たちと議論しているとき、「タスク分割は親子チケットにすべきか、それともチェックリストにすべきか」というテーマで盛り上がった。
考えたことをメモ。
結論のないラフなメモ。

【参考】
ActivityとTaskはどう違うか ? ガントチャートと課題管理表から考える : タイム・コンサルタントの日誌から

akipiiさんはTwitterを使っています 「懇親会は人数が少ないのに、Redmineの濃い話で盛り上がる。Redmineでは、親子チケットを切る基準と1チケット内でチェックリストを作る基準の違いは何か?進捗率はどう決めるべきか?面白すぎw #RedmineJapan」 / Twitter

【1】Redmineでチケット駆動開発を実践すると、チケットの粒度に悩む。

タスクの粒度が大きすぎるチケットは、完了までの期間が長くなるので、進捗を管理しにくい。
肥満児チケットも言う。
こういう肥満児チケットは、完了条件が曖昧なので、作業していくと次から次へと問題が噴出して、進捗率が90%のまま停滞しがち。
たとえば、1本のプログラム開発のチケットでも、エラー処理のメッセージが決まっていなかったと後で判明して保留になったり、実際に作り込んでみるとSQLチューニングしないと使えない代物だった、とか。

一方、タスクの粒度が小さすぎるチケットは、作業しやすいが、大量のチケット保守に苦労する。
経験的には、1チームで管理できるチケット枚数には上限があると思う。
それ以上のチケット枚数になると、チケットが放置されて、今日は何をやればいいのか、今後どの順番でチケットをやっていけばいいのか、混乱しがちになる。

管理者も担当者も、細かくチケットを切って、チケットを1個ずつこなしていくようにしたい。
では、どのように細かいタスクをチケット管理すべきなのか?

【2】タスクの粒度の解決方法としては、親子チケットにすべきか、それともチェックリストにすべきか、という問題に落ち着くのではないか。

1個のタスクを親子チケットで階層化し、細かく切った子チケットを親チケットでグルーピングして、親チケットでステータスや進捗率を把握する。
一方、1枚のチケットの中にチェックリストを設けて、チェックリストの1項目ずつ消し込んでいくことで、どこまでやり切ったのか、後は何が残っているのか、を把握する。

どちらが良いのだろうか?

【3】チェックリストを使いたい場面は、担当者が1人で決まっていて、自分のタスクを作業の順序や作業の詳細ごとにチェックリストに落とし込んで、作業をこなしてはチェックリストを消し込んでいきたい時だろう。
つまり、自分だけのToDo管理に近い作業になる。

たとえば、こういうToDo管理は、研究者が道の問題解決の時に使う手法でもあるし、すでに手順化された作業をチェックリストにして使う時もあるだろう。
たぶん、担当者1人だけの作業に閉じている時、1枚のチケットにチェックリストを書く方がいい。
お手軽だし、チェックリストを考えること自体が、作業分割に繋がり、作業のクリティカルパスを考えることにも役立つ。

しかし、チェックリストのデメリットもある。
チェックリストの進捗を把握するには、1枚のチケットを開きっぱなしにしておく必要がある。
タスクボードやチケット一覧では、チェックリストの中身は見えないし、残項目数がどれだけあるか分からない。
つまり、チェックリストはチケット集計機能に向かない。

【4】親子チケットを使いたい場面は、1つの作業を複数人で分担して並行作業したり、課題の解決方針から複数のアクションタスクが派生してそれらを管理したい時に使いたいだろう。

一般に、WF型開発であれば、1つの工程の中で複数人が作業分担して、作業を逐次実行したり、並行作業で行う。
たとえば、コーディングして、コードレビューを受けて、ビルドを通すという一連の作業では、プログラマとレビューア、ビルド職人で担当者が切り替わる。
あるいは、1つの機能を複数人が分担してプログラム開発を並行作業し、最後に統合してビルドする時もあろうだろう。

そんな時は、各人のタスクを子チケットにして、親チケットでグルーピングして、親チケットでロールアップする方が進捗管理しやすい。
親チケットで進捗やステータスが分かるからだ。
また、チケット一覧やタスクボードで、子チケットを集計すれば、ガントチャートやEVMなど色んな集計機能でPJ全体の情報を把握できる。

しかし、親子チケットのデメリットはある。
何でもかんでも親子チケットにすると、チケット枚数が増えて、一瞥して管理しにくい。
大量のチケットであふれると、チケットは乱発され放置されて、誰も保守しなくなる。
だから、普通は毎日棚卸しタイムを設けるなどしなければ、PJの現状がチケットに反映されないだろう。
それだけの手間を惜しまない気力が必要と思う。

【5】親子チケットが特に重要と思う場面は、課題管理だろうと思う。

プロジェクト運営では、ゴールに向けた作業が全て洗い出されて、タスクがチケットに落とし込まれれば、その時点でほぼコントロールできる可能性が高まる。
作業に落とし込めるということは、ある程度標準化された作業、想定される作業に落とし込めることなので、ほとんど未知のリスクはない。
定常作業がそういう部類だろう。

しかし、一般には初めてのプロジェクトでは、どんな作業があるか分からない時もある。
むしろ、作業を進めていくうちに、今まで経験しなかった課題が噴出して、それらをもぐら叩きのように丁寧に潰し込んでいかざるを得ない。

すると、それら課題を発生の都度チケットにして、課題チケットを一つずつステータス管理していく必要がある。
僕は、プロジェクトマネジメントのほとんどは課題管理、もっと言えば、リスク管理に尽きると思っている。
なぜならば、未知のリスクに遭遇した時、それらの問題を課題に置き換えて、それら課題を潰し込んでいきながらゴールへ近づいていくというイメージが強いからだ。

【6】では、課題管理では何が重要なのか?
一つは、課題のステータス管理。
もう一つは、課題の解決方針から導出されるタスク群のステータス管理だ。
つまり、課題は親チケットにして、それに子チケットのタスクがぶら下がるイメージだ。

課題を調査して、試行錯誤して解決方針を決定し、タスクに落とし込んで、それらタスクが完遂されて初めて、課題は完了する。
すると、課題は今はどのステータスで滞留しているのか、を知りたくなってくる。
大抵の場合、課題の解決方針を決定するまで持ち込むのが割と大変ではないか。

そもそも、課題の解決方針がすぐに分かるようならば、それは課題ではなく、タスクであるべきだ。
なぜならば、タスクとはやるべき作業の具体的内容と完了条件が分かっているものであるが、課題はその解決方針すらも分かっていないのでどんな作業内容すらも分からないからだ。

課題を解決するには、技術情報を調査したり、集めた情報を分析したり、経験者からアドバイスをもらう、などいろんな手段があるだろう。

課題を解決する時に重要なのは、何を持って課題を解決できたとするのか、課題の完了条件を決めることだろう。
課題の方針が決まれば完了とするなら、課題チケットだけで、子チケットにタスクチケットは必要ではない。

一方、課題の方針を決めてそれらをタスクに落とし込んで、それらタスクを実践して結果をさらに分析してみて評価する、という方法もあるだろう。
つまり、課題は親チケットにして、解決方針の内容を子チケットのタスクで詳細化していくイメージだ。

能力のあるプロジェクトマネージャは、課題管理やリスク管理に敏感で、落とし穴にはまらないように未然防止策を立てていたり、落とし穴にはまり込んだ時のコストやスケジュールをバッファとして保持するなど、リスク対策をよく考えている人が多い。

【7】「親子チケットにすべきか、それともチェックリストにすべきか」という問いは、タスク管理よりも課題管理のほうが重要ではないか、と思う。
最初は、いきなり課題チケットからタスクチケットに分割できる訳ではない。
試行錯誤しながら課題を解決する必要があるから、チェックリストでまずはラフでもいいので書き込んで、それらを一つずつ潰していきながら、解決方針を探り当てる。

チケット管理の面白さは、こういうプロジェクト管理の技法を実際にチケットの中で色々試せることだ。
どういう場面でチケット管理のどの技法を使うと有効なのか?

それを手順に落とし込むことができたら、チケット管理という意思決定は、単純な条件分岐だけの意思決定まで落とせるるはずだ。
なぜならば、場面ごとのIF文ごとにチケット管理の技法を実行する、というSwitch文に置き換えられるからだ。

プロジェクトマネジメントとは、最終的には、単純な条件分岐だけの意思決定まで落とし込んで、プロジェクト運営の問題を具体化して分割することに過ぎないのではないか、と思っている。

| | コメント (0)

« 2022年2月 | トップページ | 2022年4月 »