小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2

小説分析ツールyWriterの機能やビューについて、分かったことをメモ。

【参考】
小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1: プログラマの思索

なぜユーザーストーリーによる要件定義にピンとこなかったのか: プログラマの思索

アウトラインから書く小説再入門 ? なぜ、自由に書いたら行き詰まるのか？ | 動く出版社 フィルムアート社

ストラクチャーから書く小説再入門 | 動く出版社 フィルムアート社

【要約・感想】アウトラインから書く小説再入門 - Ｋ．Ｍ．ワイランド、シカ・マッケンジー - スキモノガタリ

【要約・感想】ストラクチャーから書く小説再入門 - Ｋ．Ｍ．ワイランド、シカ・マッケンジー - スキモノガタリ

ブレンミコミコポ　yWriterの使い方

ブレンミコミコポ　yWriter for Androidの使い方

小説分析ツールyWriterの構造 from akipii Oga

【1】yWriterの基本的な流れは、以下の通りだ。

1・プロジェクトを新規作成する
2・人物、場所、アイテムをマスタ登録する
3・章、場面（シーン）をマスタ登録する
4・場面に、人物・場所・アイテムを割り当てる
5・場面に、視点となる人物を登録する
6・章に場面を割り当てる
7・場面をプロットとみなして、書き始める
8・ストーリーボードを開いて、場面の組合せを修正する
9・ワークスケジュールを出力して、進捗確認する
10・完成したら、プロジェクトを出力する

まず、プロジェクトを登録する。
プロジェクトは、作品の基本情報になる。

次に、作品の構成要素をマスタ登録する。
構成要素は人物、場所、アイテムになる。

「アウトラインから書く小説再入門」「ストラクチャーから書く小説再入門」では、脚本は人物描写から始めよう、と言っている。
なぜなら、人物の価値観、言動、生い立ち、葛藤を詳細に書くことで、たくさんの場面を書きやすくなるからだ。
そういう意味では、人の言動を観察するのが好きな人は、小説家に向いているのかもしれない。

次に、章、場面をマスタ登録していく。
場面には、人・場所・アイテムを属性として登録し、アウトラインやプロットの文を書いていく。
場面に絵を貼り付ける機能もあるので、絵が登録されるとなお良い。
画像があれば、イメージが湧きやすいからだ。

次に、場面の視点となる登場人物を設定する。
yWriterの場面には、視点（View Point：VP）という項目があり、その場面は誰の視点なのか、を設定できる。
視点の人物と登場人物の行動が一致する場面もあれば、登場人物の行動を第三者の視点で客観的に描写するという場面もあるだろう。

場面には数多くの属性がある。
行動・反応で、そのシーンがアクションなのか、心理描写なのか、を表す。
「行動」の場面では、登場人物のアクションがメインプロットとして描かれて、目的（ゴール）・対立（葛藤）・結果（災難）により、場面の特徴を端的に表す。
一方、「反応」の場面では、登場人物の心理描写をメインプロットとして描かれて、反応・ジレンマ・選択により、場面が三幕構成で展開される。

重要度では、その場面がプロットなのか、サブプロットとして他のプロットに誘導する役割なのか、を表す。
状態は、執筆状況がアウトラインか、下書きか、推敲しているのか、を表す。
評価には、緊張度・ユーモア・品質・妥当性の評価指標に対し、10点満点で採点する。
日時には、場面の開始時から終了時を設定する。

タグを付ける機能もあるので、この場面の特徴を表す機能をつければ良い。
たとえば、英雄伝説の構成要素、三幕構成の構成要素、小説の中のサブテーマ、など。

場面にあるこれら属性は、小説分析ビューや執筆ビューで使われることになる。

次に、章に場面を登録する。
章にはエクスポートに関するチェックボックス、「この章で新規セクションを開始する」「この章を出力しない」「この章のタイトルを出力しない」「この章の区切りを出力しない」がある。
つまり、執筆中の文章を出力する時に、章として区切りを調整する機能になる。
章の区切りがなければ、前の章から続く文章となるので、連続した章になる。
アウトライナーによる文章構成と同じ感じ。

章のエクスポート機能を調整するには、章一覧の右クリックで出てくる「章タイプ」で制御することになる。
具体的には、章のタイプ・場面のタイプには、未使用（Unused）・ToDo・ノート・生存中の4つの初期値があり、生存中以外の値を選ぶと、エクスポートに関するチェックボックスがONに設定され、エクスポートできない設定になる仕組み。

【2】次に、ある程度、場面に文章を書いたら、ストーリーボードを開いて、時系列に場面の流れを見る。
場面の視点になった人物ごとに、ストーリーボードのタイムラインに場面が配置される仕様になっている。

場面に絵を添付していれば、ストーリーボードのビューから場面をポップアップさせて、絵を表示するした状態で前へ・次へボタンで前後させれば、紙芝居のように見ることができる。
別の小説執筆ツールでは、パワポの自動プレゼンのような機能があるらしいので、そういう機能がyWriterにあると良いと思う。

【3】yWriterで使われるビュー

ストーリーに関するビューは下記が最低ある。他にあるかもしれない。

ストーリーボード
章一覧
場面一覧
人物一覧
場所一覧
アイテム一覧
プロジェクトノート（場面などに依存しない単独メモ）
人物ごとの場面一覧
場所ごとの場面一覧
アイテムごとの場面一覧
タグごとの場面一覧
タグごとの人物一覧
タグごとの場所一覧
使用単語数一覧
場面評価表
ワークスケジュール

人物一覧・場所一覧・アイテム一覧では、各人物・場所・アイテムの場面数を集計してくれる。
場面の露出度が低い構成要素は、もっと各場面に入れた方がいいかもしれない。
逆に、場面露出しすぎる要素があれば、物語が単調になっている可能性もある。

タグごとの人物一覧・場所一覧・アイテム一覧も、上手く使えば、小説分析に役立つビューだろう。
タグに英雄伝説の構成要素、三幕構成の要素などを入れておけば、場面数に偏りがあれば、バランスが悪いことになる。

yWriterには、単語数（W）、合計単語数（S）という集計項目がある。
英語の小説であれば、文字通り単語数をカウントしてくれるので、小説1本7万語をゴールにすれば、どれだけ執筆できたのか、を見ることができる。
さらに、執筆日も記録しているので、ワークスケジュールによって、場面ごとの単語数を集計して、今日はどれだけ書けたか、を見れる。
つまり、各章の締切日、単語数を目標値としておけば、ワークスケジュールのビューを使えば、執筆の進捗管理や予実管理もできる。

興味深いのは、場面評価表だ。
評価という項目にはこんなメッセージが記載されている。

「これらのフィールドはそれぞれ 1-10 を設定します。
例えば「緊張度」を使って、あなたの小説の全場面を緊張感の面から評価することができます。
主観的なものではありますが、仮にスリラー小説を書いたとして、四分の三が緊張度が低いという評価ならば、　まだまだやるべきことがあるということです。」

たとえば、評価項目に緊張度、ユーモア、品質など設定しておき、場面ごとにそれらをランク設定すれば、物語全体でどれだけ、ドキドキするシーンがあるのか、品質が高いのか、ユーモアが足りないのか、が雰囲気として伝わる。
評価項目ごとに時系列の折れ線グラフで表示するので、英雄伝説の構造と対応付けて、クライマックスで緊張度合いが高まっているか否かを、見ることができる。

yWriterで面白いのは、執筆の進捗管理のビュー「ワークスケジュール」もあることだ。
単語数、執筆日時を記録できるので、目標となる単語数、章ごとの締切日を決めれば、予実管理ができる。

【4】小説分析ツールyWriterから理解できたこと

【4-1】僕の感想は、物語をいきなり書くのは失敗しやすいんだな、と思った。
むしろ、人物・場所・アイテムの初期マスタを準備すること、そして、場面や章をアウトライン形式、または目的・対立・結果という概要でまとめることが重要、と理解した。
つまり、小説を書く前の事前準備、マスタ登録をかなりやっておく必要がある。

実際、「アウトラインから書く小説再入門」「ストラクチャーから書く小説再入門」では、人物描写は脚本を書くのに最適だ、という。
ヒーローやヒロインの性格、生い立ち、ポリシーを深く書き込んでおけば、いろんな場面にその内容を少しずつばらまけばいい。

【4-2】「アウトラインから書く小説再入門」「ストラクチャーから書く小説再入門」では、主人公の葛藤・対立こそが物語の原動力なのだ、と言う。
つまり、ヒーローが日常世界から冒険を始めて、困難にぶつかり、葛藤や対立を乗り越えて成長するストーリーこそが、物語の基本構造になると思う。

このストーリーの構造をよく考えると、課題解決のストーリーと全く同じだ。
実際、現状の問題があり、あるべきゴールが設定されていて、そのギャップが葛藤でありコンフリクトを発生させている。
そのギャップ（葛藤）を解決するのが、こういうシステムなんですよ、と言う流れになるわけだ。

ITに詳しくない人に、Webやら、クラウドやら、AIや機械学習の技術の凄さをいくら語っても理解してもらえないが、ストーリー形式で物語で語れば、理解してもらえるし、何よりも納得してもらえる。

だからこそ、ITに詳しくないユーザから、ユーザーストーリーという物語形式で顧客価値や要求、システム要件を会話できる基盤を与えて、引き出そうという流れが、最近のアジャイル開発の製品企画や要件定義に使われているのだ、と理解している。

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説してみる。
yWriterは米国製ツールなので、yWriterの機能はすべて英語。
それを変に日本語訳しているので分かりにくい。

「アウトラインから書く小説再入門」「ストラクチャーから書く小説再入門」を読んでみて、yWriterの機能はこれらの本のこの概念に相当するのだろう、という当たりが付いた。
いくつか理解できたことをラフに書く。

【参考】
なぜユーザーストーリーによる要件定義にピンとこなかったのか: プログラマの思索

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2: プログラマの思索

アウトラインから書く小説再入門 ? なぜ、自由に書いたら行き詰まるのか？ | 動く出版社 フィルムアート社

ストラクチャーから書く小説再入門 | 動く出版社 フィルムアート社

【要約・感想】アウトラインから書く小説再入門 - Ｋ．Ｍ．ワイランド、シカ・マッケンジー - スキモノガタリ

【要約・感想】ストラクチャーから書く小説再入門 - Ｋ．Ｍ．ワイランド、シカ・マッケンジー - スキモノガタリ

ブレンミコミコポ　yWriterの使い方

ブレンミコミコポ　yWriter for Androidの使い方

【１】yWriterとは小説分析ツール

たぶん、同人誌を書きたい若手執筆者が、このツールを使って小説を書いたら、小説をプロットの集合体として上手く構造化できるのではないか。
既存の小説を構造分析する時には、非常に役立つ。
たとえば、青空文庫にあるグリム童話、走れメロス、シャーロック・ホームズの冒険などの小説を実際にyWriterに読み込んで、バラバラに分解して一覧化してみると、こういう仕掛けがあるのね、とか分かると思う。

一方、実際に使ってみると、ゼロから書き始めるのは正直しんどい。
エディタではないから。
また、日本人の解説ページは唯一つしかない。
yWriter自身も日本語化が不十分で英語メニューもチラホラ残る。
yWriterのUIは正直使いにくいと思う。
たとえば、D&Dで順序変更とかできない。

なお、yWriterを使いこなせたからと言って、良い小説が書けるわけでもない。

青空文庫のシンデレラを落として、yWriterに実際に落とし込んで分析してみた。

図書カード：シンデレラ

以下、yWriterのクラス図、システムユースケース図、画面キャプチャを貼っておく。

小説分析ツールyWriterの構造 from akipii Oga

【２】yWriterの基本概念は、章・場面(Scene)・場所(location)・人物（Character）・アイテム（Item）の５つ

yWriterの基本概念で、最初は、場所(location)・人物（Character）・アイテム（Item）の３つだ。
ロールプレイングゲームを想像すればいい。
ヒーローまたはヒロインがいて、彼の象徴となる武器またはドレスがあり、ヒーローが戦う場所がある。
yWriterには、まず、人物・場所・アイテムを初期マスタとして登録する。
yWriterには、XMLで一括登録したほうが速い。

次に、場面（シーン）は、人物・場所・アイテムを組み合わせて、ヒーローが事件に巻き込まれて行動し戦う場面が生まれる。
この場面（シーン）が、「アウトラインから書く小説再入門」「ストラクチャーから書く小説再入門」で言われるプロットになる。

それぞれの場面は、英雄伝説の流れ、つまり、ストーリーの各要素になる。
具体的には、状況説明 → 事件や問題の発生 → 盛り上げ → 危機→クライマックス → 落とし込み (オチ) → エンディング の７つのぞれぞれが場面、あるいはもっと分解したサブプロットになる。

【３】yWriterで最重要な概念は、場面(Scene)だ。
だから、場面の画面には数多くの入力項目がある。

【3-1】yWriterの場面に、場面の種類「行動」「反応」がある。

「アウトラインから書く小説再入門」「ストラクチャーから書く小説再入門」では、行動とは、人物の葛藤、対立を見せる場面である。
ヒーローが悪役と戦って倒すような、ハラハラ・ドキドキする場面だ。

一方、反応とは、人物の心理描写を見せる場面であり、行動した結果をヒーローが振り返るときの心理描写になる。
反応の場面があるから、物語に深みが出てくる。

yWriterのビューには場面一覧があり、「行動」の場面はVP Scensにカウントされる。
一方、「反応」の場面はVP Scens(Unused)にカウントされる。人物がViewPointに設定されても、VPScensに含まれない。
つまり、「行動」の場面数と「反応」の場面数を見ることで、物語のバランスを調整することができる。

すなわち、派手なアクションシーンと、回想やふりかえりなどの心理描写シーについて、配分や配置場所を考える為の分析に役立つ。

【3-2】yWriterの「場面の種類」を切り替えると、3種類のテキスト項目が入れ替わる。
「行動」に対応する項目は、目的・対立・結果。
「反応」に対応する項目は、反応内容・ジレンマ・選択。

場面で重要と思われる機能は、「場面の種類」ごとで決まる項目だと思う

「行動」に対応する項目で、目的・対立・結果の意味は下記と推測している。

「アウトラインから書く小説再入門」「ストラクチャーから書く小説再入門」では、目的は動機、欲望、ゴール。
つまり、その場面の存在意義、果たすべきゴールを設定する。

対立は葛藤。
「アウトラインから書く小説再入門」「ストラクチャーから書く小説再入門」では、では、「葛藤がなければ人物とプロットは存在しない」と言い切っている。
つまり、小説家は、脳みその中で、ヒーローにわざと苦難や葛藤を与えて、ヒーローが簡単に成長しないようにわざと苛め抜く。
ヒーローはクライマックスでその葛藤を乗り越える、という流れを作る。

結果は葛藤に対処した結末。
ヒーローが葛藤を乗り越えれば成功結果だが、もちろん悪い結果もありうる。
「アウトラインから書く小説再入門」「ストラクチャーから書く小説再入門」では、わざと「災難」とも呼ぶ。
なぜなら、ヒーローがいつも成功していては物語が単調で面白くない。
むしろ、ヒーローにとって悪い結果となる災難がたくさんある方が、読者もハラハラ・ドキドキしやすい。

「反応」に対応する項目で、反応内容・ジレンマ・選択も似たような意味だろう。
つまり、登場人物が行動した反応内容をふりかえり、そこで心理的ジレンマが生じて、その結果、登場人物は何からの選択・決断を行う。

すなわち、場面に目的・対立・結果、反応内容・ジレンマ・選択を一言添えることで、場面の概要を端的に表す。

【3-3】yWriterの場面に、状態という下記のような区分がある。
状態は、書きかけの場面の原稿の執筆状態を表す。

アウトライン
下書き
第1回推敲
第2回推敲
完了

最初は、ラフなスケッチであるアウトラインから始まり、下書きを作り、何度も推敲して最終的に完了ステータスになる。

この「状態」区分は、yWriterの執筆ビューの進捗管理で使われる仕組みになっている。
場面に書かれた原稿の単語数、文字数はカウントできるので、状態・文字数を元に、時系列で日々の進捗を把握できるわけだ。

【4】yWriterの肝はストーリーボードにあり

人物・場所・アイテムをマスタ登録し、場面に人物・場所・アイテムを組み合わせて１千語の文章を書き、章にまとめる操作を行ったら、ようやくストーリーボードが使えるようになる。

ストーリーボードとは、横軸に章や時系列、縦軸に人物をおいた表であり、表に場面をプロットしてくれる。
ストーリーボードを見れば、タイムライン（時系列）に従って、場面（シーン）が配置される。
つまり、物語の情報が可視化される。

ストーリーボードを使うために、人・場面・アイテムを事前入力して下準備していたわけだ。

yWriterの場面には、視点（View Point：VP）という項目があり、その場面は誰の視点なのか、を設定でき、視点になった人物ごとに、ストーリーボードのタイムラインに場面が配置される仕様になっている。

ストーリーボードの場面をクリックすると、場面ダイアログがポップアップされる。
場面の「絵」に挿絵やアクション画像を貼り付けておけば、画面下部にある前へ・次へのボタンで、スライドショーのようにストーリーを流すことができる。
yWriterの場面の挿絵を元に、紙芝居のように実現できるわけだ。

yWriterの場面には音声も登録する機能があるようなので、本来は、パワポの自動スライドショーのような機能であれば、ちょっとした動画みたいに機能改善できると思う。

【5】「アウトラインから書く小説再入門」「ストラクチャーから書く小説再入門」では、小説を１冊書き上げるのに、７万語が必要で、１シーン１０００語とすれば、シーンは７０個ぐらい書く計算、と言っていた。
つまり、場面を７０個用意して、英雄伝説の構造に併せて、場面を時系列に並べれば、１冊の小説が出来上がるわけだ。

場面は高々７０個ぐらいなら、そう大した量では無い気がするが、物語のテーマの整合性、ヒーローや悪役の言動の整合性などを考えると、組み合わせが増えるだけ難しくなる。

それら場面は章ごとにまとめられて、さらに、章をまとめたものが最終的な物語というプロジェクトになる。

残りは次回に続く。

なぜユーザーストーリーによる要件定義にピンとこなかったのか

最近、システム企画や要件定義フェーズで、ユーザーストーリーを使う手法が多い。
ユーザーストーリーマッピング、カスタマー・ジャーニー・マップナラティブアーク、別名、ストーリーマッピングなど。
内容に詳しくないと、どれも似たような内容じゃないの、とか思ってしまう。

アジャイル開発の要件定義では、ユーザーストーリーをよく強調されるが、どうしても納得感がなかった。
最近、ストーリーテリングに関する本をいくつか読んでみて、ユーザーストーリーはなぜ要件定義で必要になったのか、自分なりに考えるところがあった。
ラフなメモ書き。

【参考１】
何のために作るのかを考えながら作ることについて考えたこと?「ユーザーストーリーマッピング」感想 - Qiita

ユーザーストーリーマッピングについて - ryotaku's Tech Blog

【参考２】
あなたが開発しているプロダクトにストーリーはあるか。クリフハンガーに陥らないための作戦がここにある。 - The Dragon Scroll

「ストーリーマッピングをはじめよう」を読んだ : void chachaki::Blog::main()

人材育成コラム -- ITスキル研究フォーラム(iSRF／アイサーフ)

【読んだ本】ストーリーマッピングをはじめよう／ドナ・リシャウ｜クリタトオル｜note

「ストーリーマッピングをはじめよう」を読んだ | けんちゃんくんさんのWeb日記

【参考３】
UXデザインで使いたい「３つのストーリー」、UXにクライマックスをつくってみよう | 起業tv

ユーザーの心に響く体験の「物語」を創りだす、ストーリーマッピング | ツナググループ・イノベーションズ

【参考４】
カスタマージャーニーマップとは？ UX向上を達成する7つの事例と作成方法 | 実践！ プロも使うラピッドUX手法 | Web担当者Forum

【1】なぜ、ユーザーストーリーはシステム企画や要件定義で必要になったのか？

システムを利用するユーザはITに詳しくないから、ストーリーという物語形式で伝える必要があるから。
顧客から、システムの要件や仕様を引き出す為のツールの一つとして、ストーリーという物語形式が有効だから。

たとえば、カスタマー・ジャーニー・マップでは、Webサービスを利用する顧客との接点（チャネル）が最近はWeb、SNS、商店など複雑に絡み合っている為、O2Oの動線として扱い、顧客体験による顧客価値、顧客心理、顧客行動の分析に使う。
その時に、物語形式で語ってもらう。

たとえば、ユーザーストーリーマッピングでは、プロダクトバックログに溜まったシステム要件を表したユーザーストーリーを元に、横軸にユーザ行動の時系列や処理ステップ、縦軸に実装すべき優先順位の表に、ユーザーストーリーをプロットする。
横軸に優先順位度別にスライスして、優先順位が最も高いユーザーストーリーがMVP、つまり、顧客に提供すべき最低限の機能を満たした新製品になる。

よって、ITに詳しくないユーザから要求をユーザーストーリーで引き出し、それらを抽出してプロダクトバックログにまとめた後、ユーザーストーリーマッピングに当てはめれば、自然にリリース計画が定まることになる。

従来のアジャイル開発では、システム要件や仕様を収集してまとめる手法が正直なかった。
だから、とても苦労していた。
そこで、ユーザーストーリーをキーとして、ITに詳しくないユーザと開発者が深く会話できる基盤が揃う。

【2】では、僕は、なぜユーザーストーリーによる要件定義にピンとこなかったのか？

ユーザーストーリーがアジャイル開発の要件定義で重要なツールであり重要な概念なのに、僕はどうしても腑に落ちなかった。
ストーリーという概念が、小説や映画みたいな適当なラフなモノみたいに思えて、到底、システムやプログラムという硬い箱に収まるようには思えなかったから。

実際、ダラダラとした小説や映画を見ても、システムなんて連想できない。
ふりかえれば、僕は現代文が大の苦手だった。
小論文はまだしも、随筆や小説みたいに、執筆者の思いや考え方を推測しろ、と言われても、身近な友人や家族すら完全に理解できないのに、赤の他人の気持ちがすぐに分かるのか？
現代文のテストでは、出題者の意図を分かりなさい、というが、教師の気持ちすら分からないのに、理解できるのか？
ストーリーにはそんな反発があったかもしれない。

最近、「アウトラインから書く小説再入門」「ストラクチャーから書く小説再入門」を読む機会があった。
小説を書きたいのではなく、アウトラインによる執筆方法を調べていた時に見つけた本なのだが、内容はまさに、欧米の脚本家が映画や小説をどのように物語として構成すべきか、という考え方、手法が述べられていた。
いわゆる、脚本は三幕形式による構成、物語の基本構造は英雄伝説なのだ、という主張なわけだが、僕としては、ストーリーはこれだけ構造化されているものなのか、とすごく参考になったし、ようやく腑に落ちた経験をした。

【3】以前、「言語技術トレーニング」という本も読んでいた。

「大学生・社会人のための言語技術トレーニング」の感想: プログラマの思索

英語の考え方と学習方法: プログラマの思索

「言語技術トレーニング」の一節には、こんな事が書かれていた。

バーバラ・ミントの「考える技術・書く技術」はロジカルシンキングの原本として有名だが、「プレゼンテーションの導入部は常にストーリー形式を取ります」と書かれている。
この意味は、物語の構造を理解すれば、自分で物語の形式を用いて説明したり、スピーチしたり、プレゼンテーションを組み立てるスキルに応用できるよ、ということだ、と。
なぜなら、物語は古今東西に関わらず同じ形式であり、世界中の誰もが馴染みやい形式だから、と。

また、「言語技術トレーニング」の一節には、こんな事も書かれていた。

バーバラ・ミントの「考える技術・書く技術」では、「古典的なストーリー展開、状況→複雑化→疑問→答えによって、書き手と読み手が同じ立場に立ち、そこで初めて、読み手を書き手の考え方に沿って導ける」と書かれている。
しかし、古典的なストーリー展開の説明は、バーバラ・ミントの「考える技術・書く技術」に一切ない。
なぜなら、欧米人にとって、古典的なストーリー展開、つまり、物語の構造とは、小学校で習うべき基礎知識だからだ、と「言語技術トレーニング」の著者は言う。

「言語技術トレーニング」では、物語の形式は、いわゆる英雄伝説、冒頭→発端→山場→頂点（クライマックス）→結末という流れで説明してくれている。
ちなみに、「ナラティブアーク」あるいは「ストーリーマッピング」に相当すると思う。
実際、物語は時系列に出来事をプロットして、その緊張度合いが逆U字型の曲線で描かれる。

一方、日本の学校教育で僕は、物語の構造を「状況→複雑化→疑問→答え」という形式で教えてもらって習った、という記憶はない。
たぶん、今もないだろう。
つまり、ストーリーという言葉に違和感があるのは、ストーリーの基本構造を今まで習得してなかったから、その重要性を体の底から理解できていなかったから。

【4】そんな状況で、偶然にも、小説分析ツールyWriterなるソフトを見つけて、色々知ることができた。
yWriterを使って、実際の小説を分析してみたら、なるほど、小説はストーリーの集合体であり、各ストーリーは構造を持ち、役割があるのだ、と気づくことができた。

ブレンミコミコポ　yWriterの使い方

ブレンミコミコポ　yWriter for Androidの使い方

BCCKS / ブックス - 『yWriterで物語を書こう』神楽坂らせん著

yWriterの体験を後で書く。
yWriterのおかげで、僕はユーザーストーリーの考え方を理解できたような気がした。

大規模スクラムはLeSSとSAFeのどちらが良いのか

LeSSとSAFeの違いの記事のリンクをメモ。
僕にとっては理解しやすかった。
記事から一部引用している。

「エンタープライズ・アジャイル」LeSSとSAFeどちらを選択すべきか。その違いと比較。 ? 変化から進化の物語へ/(株)Salt

LeSSは最大8チームまで。
8チームを超えるとLess Hugeになる。
LeSSはスクラムを忠実に大規模チームへ拡大している。

（引用開始）
基本的にチームが分かれていても、一つのバックログで対応します。そしてそれぞれのチームの代表が（Scrum of Scrumと同じく）、スプリントプランニングやレトロスペクティブ（振り返り）を行い、それと連動する形で、各チームもスクラムのイベントを行います。
新たな製品やシステムを開発する場合、それがどのくらいの規模感でどのくらいのチーム編成になるか、最初はわからないケースが多いと思われます。
そこでLeSSでは、まず少数のチームでスプリントを回しながら全体の計画をつくっていきます。
したがって、柔軟なチーム編成ができる組織づくりが必要となります。
日々行う業務は、スクラムでやっていることと殆ど変わりません。スクラムに慣れている組織なら、比較的スムーズに実行が可能であると考えられます。
（引用終了）

「SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意」でも、大規模スクラムはLeSS一択です、と記載されていた。

一方、「SAFeは４つのレイヤー（レベル）でマネジメント」する。

（引用開始）
上位のレイヤー（レベル）で、ユーザー要求や設計を行い、下位のレイヤー（レベル）で開発を行います。プログラムレベルとチームレベルの関係はScrum of Scrumに近いです。
階層を持つことや、設計（上流）と製品開発（下流）が分離しているところから、ウォーターフォール的なエッセンスもあり、「これはアジャイルではない」という声も聞かれます。
反面（特に日本の）SIerが現在の組織体制をそれほど変えずにアジャイルに取り組むフレームワークとして取り掛かりやすい一面も見逃せません。
（引用終了）

「More Effective Agile」では、SAFeが推奨されていた。
理由は、「More Effective Agile」のP.134に記載されているように、Scrum of Scrumは上手く機能しない場合が多いからだ、と著者は言う。
Scrum of Scrumを選択することで、プロセスと全体的なワークフローを調整しようとするが、実際は、要求となるプロダクトバックログに問題が起きやすい。
一般的に、Scrum of Scrumにはスクラムマスターではなく、プロダクトオーナーを出席させて要求を調整した方が良い、と言う。

記事では、下記の結論を出している。

（引用開始）
LeSSとSAFeどちらが自分の組織に向いているのか。
LeSSは、アジャイル本来の目的である自己組織化組織、自律的なプロジェクトに向いています。またイノベーションも起きやすいでしょう。
ただし、上流工程に関する手法があまりないため、特にチームが増えると全体像が見えなくなる不安はあります。
この場合、後述のICONIXとの組み合わせは、組織やシステムのダイナミズムを失わせないで、全体像を見ることができる方法論です。

一方で、大企業のSIer等が既存の組織をできるだけ変えずがリスクをできるだけ少なくすることを考えるとSAFeが向いていると思います。
反面アジャイルの根幹であるAgility（俊敏さ、柔軟さ）が失われやすく、特に経営陣やビジネスサイドが硬直化すると、変化に対応できなかったり社会や顧客に合わないシステムが出来上がってしまう可能性はあります。デザイン思考を取り入れるなど、顧客や社会情勢の変化にうまく対応できるかどうかが成功の鍵となります。
（引用終了）

僕の感想は、日本の企業ではSAFeの方が大規模アジャイルを実践しやすいだろうと思う。
日本の企業は組織文化が独特の価値観を持ち、正直柔軟ではない。
アジャイル開発を実践してすぐに効果を出したい場合は、組織構造や組織文化をいじる必要性が少ないSAFeの方がリスクは小さいだろう。

しかし、小規模なチームでスクラムが成功した経験がなければ、いきなり大規模アジャイルに挑戦しても失敗する。
LeSSのように、小規模なスクラムチームが8個以上準備できた後で、大規模アジャイルに挑戦すべきだろう。
LeSSであれば、スクラムの大規模化は運用しやすいのではないか。

「大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法」と「SAFe 4.5のエッセンス―組織一丸となってリーン‐アジャイルにプロダクト開発を行うためのフレームワーク Amazon」を今度読み比べてみようと思う。

因果ループ図を再考する～問題の症状をシステム構造として捉えて解決策を見つける

プロジェクト管理や要件定義、システム企画をやっていると、どうしても因果ループ図のような考え方が欲しくなる。
自分の気づきをラフなメモ書き。

【参考】
因果ループ図（いんがるーぷず） - ITmedia エンタープライズ

システム原形とは？複数の切り口で根本原因を探る | akibito

システム原型を知れば、課題に予め対処することができる ? 変化から進化の物語へ/(株)Salt

因果ループ図の書き方　ルール編 ? 変化から進化の物語へ/(株)Salt

因果ループ図の書き方　実践編 ? 変化から進化の物語へ/(株)Salt

「引き寄せの法則」はシステム思考で説明できる ? 変化から進化の物語へ/(株)Salt

システム思考がアマゾンを世界一のECサイトにした ? 変化から進化の物語へ/(株)Salt

ルールを覚えても、因果ループ図がうまく書けない理由 ? 変化から進化の物語へ/(株)Salt

新しいビジネスモデルの作成（構築）方法 ? 変化から進化の物語へ/(株)Salt

System Dynamics 日本未来研究センター　Japan Futures Research Center

相殺フィードバックを再考: プログラマの思索

相殺フィードバック: プログラマの思索

因果ループ図の事例 from akipii Oga

【1】因果ループ図を使いたい場面はどこなのか？

ロジックツリーやWBS詳細化のように、既に確定した要件を分解していく時ではなく、輻輳した現状、混沌とした現状で使いたい。
問題の原因を掘り下げていく時に、単純ななぜなぜ分析では難しく、いくつかの要因が複雑に絡み合っている場面で使いたい。

プロジェクト管理で、進捗遅延が発生した問題、テスト工程でバグが噴出して品質が劣化している問題。
企画や要件定義で、利害関係者の要望が予算の上限枠に当てはまらない問題、要件定義やシステム企画が混乱している問題。
それらの背後には、数多くの因果関係が問題を複雑にしている。
単純な解決策では、応急処置に過ぎなかったり、逆に問題をさらに悪化させる場合もある。

【2】因果ループ図のメリットは何なのか？

問題の症状を定義して、その問題を増幅させる変数を複数個洗い出し、それを因果関係でつないで、一つのシステム構造として見てみたい。
そうすることで、問題の本質が見えてくる。

堂々巡りの議論ではなく、問題を一つの構造として洗い出したい。

【3】因果ループ図を書くコツは何か？

基本は、時系列グラフを収集して、変数を洗い出す。
時系列で見ると、何らかの目的変数が増大して、問題になっている。
顧客の不満、コスト、行動、利益、資源、など。

時系列グラフにはパターンがある
指数関数、S字型曲線、頭打ちの曲線、振動する曲線、振動しながら成長する曲線、成長するが最後に崩壊する曲線、など。
それらは因果ループ図が背景として構造を持つが、それを具現化したもの。

相関関係と因果関係は異なる。
因果関係→相関関係だが、相関関係→因果関係とは限らない。
統計学では当たり前の常識。

因果関係の間にある潜在変数は書き出す。
潜在変数があるということは、疑似相関があること。
因果の飛躍を避ける。

因果ループ図では、フィードバックという考え方が大事。
システム思考の構造が「システム」「情報」「制御」から成り立つ。
制御＝フィードバックになる。
システムダイナミクスの創始者がフィードバック制御の専門家だった。

フィードバックして因果ループ図になる。
たとえば、因→果が正の相関であっても、果→因は負の相関の時もある。
この場合、バランスループ、均衡ループになる。

各ループが自己強化型かバランス型かを判断することが大事。
変化を強めているのが自己強化ループ。
抑制しているのがバランスループ。

拡張フィードバック⇒自己強化ループになる。
拡張ループとも呼ぶ。
雪だるま（スノーボール）が転がる絵を描く方法を指導している。

相殺フィードバック⇒バランスループになる。
均衡ループとも呼ぶ。
天秤の絵を描くように推奨している。

以前、「相殺フィードバック」という言葉が何故か頭の片隅に残っていたが、意味を理解できていなかった。
たぶん、相殺フィードバックはバランスループを表す。

ループ構造に名前を付ける。
因果関係のループには意味がある。
フィードバックの特徴を表す名前を付ける。
読者の直感的理解を促進する。

ストックフロー図に置き換える。
微分方程式に置き換えられる。
専用ツールで、時系列グラフに変換できる。
因果ループ図は定性分析。
ストックフロー図は定量分析に相当する。

【4】自己強化ループ、バランスループの区別するコツは何か？

2つある。
一つは、どこか任意の変数を出発点として、ループに沿ってぐるっと一周して、最初の変数の変化を強めるのか、抑制するのかで判断する。

他方は、マイナスループの合計個数で、自己強化orバランスに分ける。
奇数ならバランスループ。
偶数なら自己強化ループ。

【5】因果ループ図を元に、どんな解決策を実行するのか？

絡み合った因果関係の中で効果的な作用点＝レバレッジポイントを発見するのが大事。
Amazonビジネスモデルの初期モデルは、顧客体験だった。
Kindleビジネスは、出版社だった。

割れ窓理論では「割れた窓ガラス」だった。
割れた窓ガラスを徹底的に無くすことで、最終的に犯罪件数が劇的に減った。

目的は成長させたい場合、
システム内の自己強化ループを強める施策を入れるなら、「ベゾスが考えたAmazonビジネスモデル」のように、別の自己強化ループを作る。

システム内のバランスループを弱める施策を入れるなら、「成功の限界」のように、制約を入れる。
「犯罪都市ニューヨークの割れ窓理論」のように、流量を抑える変数を入れる。

目的は現状維持なら、
システム内のバランスループを強める施策を入れるなら、制約や流量を抑える変数を入れる。
システム内の自己強化ループを弱める施策を入れるなら、別の自己強化ループを作る。

【6】感想

因果ループ図は使いこなすのが難しい。
因果関係となる変数を導くこと、それらを意味あるようにつなぐのが難しい。

一つのきっかけは、時系列グラフとセットで考えること。
そして、２つの変数のみでまずはループ構造を描いて、雪だるま式に自己強化ループを増やす。
あるいは、天秤のようにバランスループを書き出す。

ループ構造に名前を付けるのも重要。
この認識が以前はなかった。
売上増大ループ、顧客関係性強化のループ、とか。

因果関係と相関関係は違うのに、混同している時もある。
まずは書いてみては直す。

やりたいのは、問題となるシステム構造を描き出したい。
そうすれば、どこかの変数に制約を入れれば、流量が減るので、拡張ループは抑えられる。
成長させたい時は、別の拡張ループを増やるように、売上増加の別の戦略を打ち立てれば良い。

Amazonのベゾス、MSのビル・ゲイツも因果ループ図を使いこなしていた、と言う。
この考え方を実際に使ってみる。

技術をコントロールの配下に置く

牛尾さんの記事を読んだ感想をラフなメモ書き。
論理的でないラフなメモ書き。

【参考】
技術者には試行錯誤は圧倒的に悪であると腹落ちした話｜牛尾　剛｜note

クネビンフレームワークについて講演してきました | サーバントワークス株式会社

カネビン・フレームワークで問題解決策を見極める

問題解決アプローチを見極める『クネビンフレームワーク』のメモ: プログラマの思索

【1】クネビンフレームワークのうち、煩雑系の問題には、パターンに基づいて専門知識を使って分析すれば解ける。
つまり、試行錯誤しても解決できる。

しかし、複雑系の問題では、因果関係がすぐには分からない。
しかも、初めて経験した結果、その因果関係が分かる時も多い。

つまり、複雑系の問題では、既存の知識だけで試行錯誤しても無意味。
むしろ、新たな知識や技術を事前にインプットしておき、問題に対処しながら、その適用場面を探っていく。

記事では「技術をコントロールの配下に置く」の重要性を語っているが、同感する。
ソフトウェア開発では、そもそもゴールはあっても、その道筋が明確ではない場面が多い。
手探りでやるしかないのだが、経験値を貯めていくには、関連する技術をすべて自力でコントロールできるようにしておくべき。
そうすれば、経験しながら、自分なりに検査・適応して、成長できる。

【2】そんなことを連想していると、ソフトウェア開発は従来の製造業の生産管理とは別次元の仕事だと思う。
生産管理では、試作できた製品を高品質で大量生産するための量産プロセスの確立に力点を置く。
製造プロセスを標準化する点が重要。

しかし、ソフトウェア開発では、常に新しい技術が出てきて問題の次元そのものが変わってくる。
問題領域が、決められた要件からいかにQCDを守りながらリリースするか、から、コロコロ変わるマーケットに対してタイミングよくどのように開発してリリースしていくか、に変わってきた。
すると、それをコントロールできる技術やプロセスが必要になってくる。

アジャイル開発は必ず2度失敗する～「正しいものを正しくつくる」の感想: プログラマの思索でも、「アジャイル開発は必ず2度失敗する」という話があった。
ここでも、高速にリリースできる開発プロセスを持っていたとしても、「正しいものを作る」という要件定義、要求開発の部分をコントロールできていないと問題解決できない。

日本の設計者の一部では、その問題をデータモデリングとして解決しようとしてきた。
アジャイル開発では、ユーザーストーリーマッピングなど、各種の技法を生み出して対応しようとしている。

【3】ソフトウェア技術者は、技術をコントロールの配下に置く必要性があるので、常に最新技術を習得しようと務める。
すると、彼らは、手段の目的化、という罠に陥りやすい。
新技術を追いかけること、そのものが目的になってしまったり、問題解決よりも、身につけた道具が活用できる問題領域だけに特化しようとしてしまう。

たぶん、日本人特有の病気なのかもしれない。

手段を目的化するのは日本人の病: プログラマの思索

増刷記念「ここはウォーターフォール市、アジャイル町」の裏話の感想～日本人はフレームワークが苦手でいつも振り回されている: プログラマの思索

若手プロジェクトリーダー向けのRedmine教育資料の構想

最近、若手プロジェクトリーダー向けのプロジェクトマネジメント教育に、Redmineによるチケット駆動開発の資料がありませんか、とよく聞かれる。
本来は、自分が書いた本「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」を渡せばいいだろうが、何せ2011, 2013年出版なので、Redmineの内容も古く、若手向けの内容ではない。
そこで、若手PL向けのRedmine教育資料の構想について考えてみた。
ラフなメモ書き。

なお、この記事は、Redmine Advent Calendar 2020の記事です。

【参考】
Redmine Advent Calendar 2020 - Adventar

akipiiさんはTwitterを使っています 「最近、若手リーダー向けにRedmine教育の良い資料はありませんか、と複数人から問い合わせを受けているが、いい本がない。僕の本も既に5年経っているので、最新バージョンに合っていない。うーむ、新しい教育資料が必要なんだけど、僕がストーリーを話したら誰か書いてくれない？笑」 / Twitter

akipiiさんはTwitterを使っています 「それから、PMOの立場でのRedmine資料の問い合わせも受けている。この手の話はそもそも少なくて、 @MadoWindahead さんのブログ記事と発表資料くらいしかない。昨今の導入事例の話を聞くと、Redmineの全社展開が多いのでニーズはあると感じる。アイデアを話すので誰かまとめてくれないかな？笑」 / Twitter

【１】Redmine教育資料が必要とされる背景とその需要の原因

市販のRedmine本が既に古くなっている。
実際、@g_maedaさんの本「入門Redmine 第5版」も2016年を最後に止まっている。
もちろん、自分が書いた本「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」は2010～2012年なのでもう10年前になってしまう。

その間、Redmineは着実にVerUPして、不足している機能についてあれこれ考えていた内容はほぼ実装されてきている。
たとえば、親子チケット、構成管理ツール連携後のチケットNoの修正、など。

すると、最新の機能を持つRedmineをどのように扱えばよいか、という話にVerUPすべき。

もう一つは、チケット管理の考え方が普及して当たり前になったこと。
特に、BacklogやJiraなどのユーザ数が圧倒的に多い。
「ここはウォーターフォール市、アジャイル」では、Backlogのチケット管理が当たり前のように運用されていた。

すると、チケット管理が当たり前の時代では、従来のプロジェクト管理手法ではなく、今の時代に合った手法や考え方を提示すべき、となる。

【２】Redmine教育資料の立場はどこにあるのか

ニーズとして、20代の若手のプロジェクトリーダー候補、またはプロジェクトリーダーに初めてなった人が対象になる。
こういう人たちに、チケット駆動開発という当たり前の考え方に慣れてもらい、ツールを使いながら、プロジェクト管理を実践して欲しい、という考えになる。

もう一つの立場は、PMO向けの資料だ。
つまり、単独のプロジェクトではなく、複数PJのQCDをチェックして報告すること、問題プロジェクトを一早く検知してリスク対策したい、という役割を持つ。
おそらく、最近は全社的にPJ管理ツールを導入し、社内へ標準化を推進して展開する現場が多くなったのではないか、と想像する。

【３】Redmine教育資料がもたらす効果は何か

Redmine教育資料があれば、初めてPJ管理ツールに触れるリーダーには、こういうチケット管理の考え方なら上手くいくのか、というイメージが湧くので、実践しやすくなる。
教える側としては、PMBOKのようなPJ管理の共通的な考え方にも触れながら、チケット管理して欲しい。
あるいは、スクラムのようなアジャイル開発手法、プラクティスを上手く使って、チケット管理と組み合わせて運用して、効果を出して欲しい。

【４】Redmine教育資料の観点や論点は何か

観点はいくつかあるだろう。
従来のWF型開発であれば、PMBOKベースに、PJ立ち上げ→PJ計画・実行・監視→PJ終結の流れに沿って、Redmineのチケット管理でプロジェクトのQCDを維持する考え方を習得することになるだろう。
特に、PMBOKはWBS駆動が多いので、WBS管理とRedmine機能の対応が重要になると思う。

もちろん、ウォーターフォールであっても、アジャイル開発のプラクティスとチケット駆動開発は相性がいいので、チームビルディングにも適用できる。

もう一つは、スクラムをベースとして、PJ立ち上げ→スプリント計画・デイリースクラム・スプリントレビュー・スプリント・レトロスペクティブ→PJ終結、という流れがある。
ここでは、スクラムのイベントとRedmineの機能の対応付けが重要になる。
Ver2.x時代はScrumの良いプラグインがあったが、今は無いので、Redmineの標準機能でどこまで対応付けて運用するか、という点が論点になる。

一方、カンバンをベースにしたチケット管理の手法もある。
「カンバン仕事術」を読んでいたら、チケット管理とカンバンはとても相性が良いという点に改めて気づいた。

実際、「ここはウォーターフォール市、アジャイル」でのBacklogのチケット管理は、カンバンの運用にそっくりだ
なぜならば、統合認証基盤チームではシステム保守が仕事なので、開発プロジェクトというよりもシステム運用でエンドレスな仕事になるため、カンバンで常に流れるタスクを管理したい動機があるからだ。

結局、PMBOK＋WF型、スクラム＋アジャイル開発、カンバン＋ITILという3つの運用について、Redmineと組み合わせたPJ管理手法を説明すべきだろう。

【５】Redmineによるチケット駆動開発の注意点、よく聞かれるFAQ

上記の3つの論点でRedmineによる運用を教育資料で伝えたとしても、気に留めておいた方が良い注意点はある。
実際の現場では、そんなきれいな運用ではないからだ。

また、よく聞かれるFAQもあるので、それらも追加しておきたい。
困った時に、そのFAQを思い出せるだろうから。

このFAQを煮詰めて共通化してストーリー化したら、パターン言語になるだろうと思う。

最後に、こういうRedmine教育資料が公開されたり出版されたりしたら、需要はありますか？？

AgileTourOsakaでSCRUMMASTER THE BOOKの裏話を聞いた

AgileTourOsakaでSCRUMMASTER THE BOOKの裏話を聞いたのでメモ。
以下は議事録っぽいメモ。

【参考】
Agile Tour Osaka × miniPLoP 2020 Day2 2020年12月22日（オンライン・Zoom） - こくちーずプロ

「SCRUMMASTER THE BOOK」の感想～スクラムマスターはチームが自己組織化したら御用済みなのか？: プログラマの思索

【１】Making of the bookを川口さんが話す。
執筆者が集まったので、すぐに始めず、まず１章を全員で訳す。
Velocityを測ると、２年近くかかる。
そこで、全員ではなく３人が集まったら、モブプログラミングで訳す。
この仕組みでバーンダウンチャートを書いて、半年ですべての翻訳を完了。

Googleスプレッドシートで日付と実績を残して、バーンダウンチャートでグラフ化した図を見せてくれた。
これがあれば、Velocityも分かるし、終了時点を予測できる。
本当に上手いなと思った。

【２】タックマンモデルでは、統一期に注意。
統一期では、まだハイパフォーマンスの機能期まで行く途中なのに、そこで現状満足して現状維持で停滞してしまう罠がある。

仕事ができる人は｢正しい衝突｣が超得意！ | 30代から身につけたいキャリア力実戦講座 | 東洋経済オンライン | 経済ニュースの新基準

スクラムマスタは、統一期から機能期へ行けるように、チームをコーチングする必要がある。

似た話で、変動に注意。
チームが混乱期を経て統一旗に差し掛かったのに、何らかの変動で、チームの状況が形成期に戻ってしまう状態。
スクラムマスタはチームを常に観察する必要がある。

【３】スクラムマスターはチームが自己組織化したら御用済みなのか？と聞いてみた。
どうやら、チームが上手く回り始めたら、スクラムマスターはいなくなるのが多いらしい。
そういう状態になれば、スクラムマスターはチームから去っていく。

川口さんから丁寧な回答を頂いた。

スクラムマスターが関与する障害のレベルが上っていく。
スクラムマスタ道では、レベル１は、チームの進捗を妨害する課題レベル。
レベル２からは、チームを取り巻く利害関係者との衝突などを解決する。
つまり、組織のバグを解決する役割に変わっていく。

では、大企業におけるスクラムマスターは中間管理職以上の立場で、経営層に物申すような立ち位置になるのか？
回答では、どうやら、スクラムマスターは現場とトップ層を繋ぐ役割になるのが理想。

【４】以前、細谷さんの会社の静岡のスクラムマスターも参加されていた。
彼の質問が面白かった。

「製造業アジャイル、静岡での実践！」を聞いてRedmineはコミュニケーション管理ツールなのだと気づいた #devlove #静岡ギルド: プログラマの思索

自分がスクラムマスターをやってみて、その評価は真っ二つに割れている。
開発チームからは高評価で、またやって欲しいと言われている。
しかし、経営層からは、低い評価。
なぜなら、開発チームが頑張っただけであり、スクラムマスターは何もやっていないのでは？　スクラムマスターは何もアウトプットを出していないでしょ、と。
では、スクラムマスターとしてのモチベーションが落ちていて、どうやってモチベーションを維持したらいいのか？

皆さんのアドバイスでは、基本は経営層の評価がおかしい。
スクラムマスターがいるからこそ、開発チームは上手く回る。
彼がいなくなれば、チームは以前のような生産性を出せない。
ピープルウェアにもそういう話があったよね、と。

そういう会社に居づらくなれば、会社を出ていきましょう、と。
実際は、経営層からも評価されていますよ、とのこと。

この話は理解できる。
スクラムマスターは触媒のような役割なので、火消しのプロジェクトマネージャのように目立つ存在でもないし、アウトプットが正直見えにくい。
MBOの人事評価が当たり前なので、スクラムマスターの評価は正直難しいかもしれない。

【５】スクラムマスターの方の話を聞いていると、殆どの人たちがアジャイルコーチとしてフリーないし独立を経験されている。
そういう背景と、「スクラムマスターはチームが自己組織化したら御用済みなのか？」という疑問を振り返ると、スクラムの最大の功績は、スクラムマスターやアジャイルコーチという職業をビジネスモデルとして生み出したことではないか、と思う。

スクラムマスターとして成功するほど、開発チームは自己組織化しどんどん手離れしていく。
スクラムマスターがそういうチームをどんどん作っていくと、最終的には組織内では開発チームはすべて自己組織化されて、スクラムマスターの関与度合いは劇的に減るだろう。
すると、スクラムマスターの居場所は組織内にはなくなり、組織外の別のチームを自己組織化するように関与していく方向に進むだろう。

つまり、スクラムマスターとして成功するほど、現状の組織内には居続けるのは、居心地が悪くなる。
よって、スクラムマスターは会社から離れて、アジャイルコーチとしていろんな組織と関わり合うようになり、アジャイルコーチというコンサルタントとして独立した存在に進みやすい、と考えた。

つまり、スクラムはスクラムマスターという役割をアジャイル開発から抽出し、独立した存在として際立たせることに成功し、最終的にはアジャイルコーチという職業を生み出したわけだ。

実際、スクラムギャザリングのイベントは、スクラムマスターのコミュニティに近い。
「SCRUMMASTER THE BOOK」にも、スクラムマスターが集まるコミュニティ「スクラムマスターランド」（スクラムマスターの島）の話がスクラムマスタ道にあったけれど、独立したアジャイルコーチが増えるほど、そういうコミュニティが必要とされるのだろう、と思った。

PMO観点でRedmineの使い方とは何か

PMO観点の教育資料の要望も割と多いと思う。
ラフなメモ。

【参考】
akipiiさんはTwitterを使っています 「それから、PMOの立場でのRedmine資料の問い合わせも受けている。この手の話はそもそも少なくて、 @MadoWindahead さんのブログ記事と発表資料くらいしかない。昨今の導入事例の話を聞くと、Redmineの全社展開が多いのでニーズはあると感じる。アイデアを話すので誰かまとめてくれないかな？笑」 / Twitter

【1】IPA資料：ITプロジェクトの「見える化」総集編のP.78では、IPAの観点で、PMOの類型を紹介している。

ITプロジェクトの「見える化」総集編

当初は、問題プロジェクトの撲滅にある。
すなわち、問題になるPJの事務局を作り、PMOがPL/PMを支援していく。
これは事務局型PMOであり、PMOはPLの世話役みたいな立場である。

そして、PMOは標準化推進型PMOになる。
これは、全社標準でプロジェクトのQCDをコントロールし、安定させるために、進捗・品質・課題・コスト管理の標準ルールを定めて、経営陣に報告させて、プロジェクトをモニタリングする。
こういう役割の仕事が、PMOの主なお仕事。

すると、全社横断的なリスク管理指向の「リスク対応型PMO」プロジェクト管理に進展する。
つまり、全社から見て、早めに問題プロジェクトを検知し、そのリスクを摘み取るようにPMOは動く。
実際は、プロジェクトの各フェーズでゲートを設けて、経営陣や管理部門、技術部門がレビューする運用が多い。
よくある例は、受注前の企画や予算確保、要件定義での開発費用の確定では必ず、経営陣のレビューが入る。
そして、テスト計画やテスト完了、リリース判定のレビューが多いだろう。

ITプロジェクトの「見える化」総集編にある「戦略型PMO」は、たぶん経営企画部みたいな役割だろうか。
このレベルになると、PMOではなく、社長直属の経営企画室みたいな感じだろうか。

こういう類型を踏まえて、それぞれのPMOの役割、期待される機能、実際の活動とRedmineの機能をフィットギャップ分析することになるだろう。

【2】PMOとRedmineに関する資料は、PJ管理の事例に比べるともっと少ない。
門屋さんの資料ぐらいしかないのが現状。

予防型PMOがRedmineでのプロジェクトモニタリング方法を伝授する | マドびっ！ Madosan's View

門屋さんの記事のポイントは2つあると思う。
一つは、PMOがPJの現状を把握する時に、Redmineのどの機能に着目するのか、という点。

注目すべき点は、チケット一覧だけでなく、活動タブを重視している点。
PJの活発度合いから、PJの傾向を定性的に見ている。

（引用開始）
活動
どのくらいの頻度で更新されているか
新規と完了の比率はどのくらいか
利用メンバーはどのくらいいるか

チケット一覧
親子チケットを多数使う管理方法が主です
カスタムクエリ「親チケット別整列」を利用する
（ソート順に親チケット・昇順を追加したもの）

全体像とチケットの設定具合を比較する
何割程度チケット化されているか

次のトラッカーごとの確認において
必要に応じてカスタムクエリを作る

トラッカーごとの確認
「WBS」
チケットの粒度について
大日程レベル・作業まで落とし込まれているか
開始日・期日の登録具合はどの程度か
週あたりの完了数を算出し
進捗に問題がないかを把握できればベスト

「課題・障害」
動きがあるチケットは実施者に任せる
動きがないチケットは問題ないか確認する
動きがありすぎるチケットは話がずれていないかを確認

課題の傾向を確認するときは全件を確認する
類似課題、一部機能に偏っている
などの癖を見つけて
今後の作業において予防できないか考える

収束時期を読むときは、残を確認する
発生数・完了数を日別に追えれば良いが
定点チェックのほうが多い
（週ごとのチェックなど）
作成日や更新日からも判断する

チケットの注記の確認
更新回数が多いチケットについては
注記から話がずれてないか、混乱していないかを確認する
（引用終了）

他に面白い点は、週毎のチケットの完了日数や完了チケット数を元に、PJの進捗度合いを定量的に見ている点。
つまり、リードタイムやベロシティも見ているわけだ。

また、PJの途中の工程で、概要スケジュールを元に、詳細化したWBSがどこまで実現されたのか、その割合も見ている。
実際、PJ計画時に担当者レベルまで落としたWBSまでは作れないから、各工程が始まる時点までには詳細化されているはずだ。
それを元に、全体スケジュールのうちどこまで実現可能なスケジュールに落とせたのか、実際の進捗はどこなのか、を把握することができる。

【3】もう一つは、PMOで長年PJの状況を調査した結果、プロジェクトリーダーが能力を向上させて成長していくパターンに傾向がある事。
PMｘTMマトリクスの考え方が参考になる。

PMｘTMマトリクスの考え方 from akipii Oga

Redmineを活用したプロジェクトマネジメント技術向上について from Hirofumi Kadoya

PJ管理のようなマネジメントは経験しないと向上しない。
しかし、誰もが経験できるわけではない。

一方、実際のPJ管理では右往左往しやすい。
そういう時に、PJの状況を把握し、PJをコントロールできるような管理基盤が必要だ。

そんな管理基盤としてRedmineのようなツールが必要となる。
なぜ、そんな管理ツールがあるとメンバーのマネジメント力は上がっていくのか？

理由は2つあると思う。
一つは、管理ツールによってプロジェクトをモニタリングでき、PJで問題が発生しても、その状況や原因を把握しやすく、対応しやすいから。
チケットに状況が最新状態で書かれていれば、問題解決のためにメンバーがどう動くべきか、を的確に指示できる。

もう一つは、特にチケット管理は、PMBOKの言うコミュニケーション計画のイベントやスクラムのようなアジャイル開発のイベントと相性が良いから。
毎日の朝会でチケット状況を共有する。
毎週の課題確認会で、チケットの棚卸しをする。
毎週・毎月のチームふりかえりで、メンバー全員で改善策を上げて、改善活動を実施していく。

つまり、イベントにチケット運用を対応付けて、チケットを見ながらメンバーと状況確認すればいい。
そうすれば、「問題　対　私達」という関係を作れるので、議論しやすくなる。

【4】他にPMOで必要な観点は何だろうか？
PMOは、SEPG（Software Engineering Process Group）の役割もあるので、チケットのデータを元に、PJやソフトウェアのQCDの情報を集計分析したくなる。

プロダクトの品質分析、ゾーン分析、テスト工程ごとのトレンド分析、信頼度成長曲線、プロセスの品質状況の分析とか。
リードタイム、ベロシティ、サイクルタイムなどの進捗や生産性の情報とか。
つまり、プロダクト、プロセスの両方の観点でQCDのデータを分析したくなる。
そして、その情報を元に、PJ側にフィードバックして、PJの改善活動に役立てたい。

すると、メトリクスを得るにはチケットにQCD分析用カスタムフィールドを設定すればいいのか、どんなメトリクスがどの場面で効果的なのか、という問題が出てくる。
この辺りは一般論もあれば、個々の現場では異なってくるだろう。
いろんな知見もあると思う。

そういう内容も整理してみたいと思う。

アジャイル開発は必ず2度失敗する～「正しいものを正しくつくる」の感想

「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」を読んだ。
この本はいいね。
アジャイル開発、スクラムを実践してきた人が、その経験を振り返って書いているので、すべての文章に重みがある。
たぶん、こういう苦労をしてきたのだろう、という想像ができる。

「アジャイル開発は必ず2度失敗する」というフレーズにしびれた。

【1】「アジャイル開発は必ず2度失敗する」とはどういう事なのか？

【2】アジャイル開発を導入した初めてのチームは、最初の壁にぶつかる。
それは、成長しないこと。
スクラムであれば、チームはスクラムもどきのプロセスでしか運営できず、本来のスクラムのプロセスを忠実に再現できていない。
たとえば、デイリースクラムやスプリントバックログはできても、スプリントレトロスペクティブをスルーしてしまい、スクラムの検査と適応が不十分になる。
結局、チームはたくさんのスプリントをこなしても、その経験を活用しきれていない。
つまり、「正しく作る」というプロセス面に問題がある。

特に、「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」では、プロダクトオーナーの役割についてフォーカスを置いている。
なぜならば、スクラムを導入すると、チームは開発に専念すればよく、技術者主体なので自分たちのペースで開発しやすくなる
しかし、プロダクトオーナーになった人は、スクラムを導入するとそういう役割をいきなり任されてしまい、どのように振る舞えばよいか、分からない場合が多いからだ。
実際、プロダクトオーナーになる人は、システム提案やシステム企画、ユーザ部門に関わる人だろうから、それほど技術面に詳しいわけでもなく、要件定義の技法を知っているわけでもなく、単にそのドメインに詳しいだけであって、開発者に整理された仕様を伝えるスキルがないからだ。

そこで、プロダクトオーナーに足りないスキルはチームの別メンバーがカバーするなどの解決法を提案している。
この点は、著者の経験が出ているなと思う。

【3】次の壁は、「間違ったものを作ってしまう」こと。
チームがスクラムをスムーズに運用できるようになると、定期的にプロダクトをリリースできるようになる。
しかし、実際に顧客に提供してみたら、本来欲しいものはそれではなかった、と突き返されてしまう。
「オレゴン大学の実験」の話と同じ。
つまり、チームは生産性は高いものの、高速に価値のないプロダクトを作り出しているだけ。
すなわち「正しいものを作る」という要件定義、要求開発の部分に問題がある。

［姿勢編］理由無き要求は機能化してはいけない | 日経クロステック（xTECH）

こういう話を聞くと、クネビンフレームワークの複雑系の問題を連想する。

クネビンフレームワークについて講演してきました | サーバントワークス株式会社

複雑系の問題では、正解がないから、過去の知見を利用できない。
実際に調査して、試してみて、初めて因果関係らしきものが分かるが、それでもその複雑性を完全にコントロールできるわけではない。
複雑系の問題では、調査→把握→対処という順番で解決するしかない。

「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」では、仮説検証やMVP以外にも数多くの手法を紹介して、「正しいものを作る」命題に対処しようとしている。
おそらく著者の市谷さんの数多くの経験が盛り込まれているのだろうと思う。

「ここはウォーターフォール市、アジャイル町」の感想

「ここはウォーターフォール市、アジャイル町 ストーリーで学ぶアジャイルな組織のつくり方」を読んだ。

アジャイル開発のストーリーに過ぎないだろう、と思ったら、すぐに、Backlogでチケット管理する話が出てくるではないか！
しかも、チケット管理のコツが細かく書かれて、すごくいい。

増刷記念「ここはウォーターフォール市、アジャイル町」の裏話の感想～日本人はフレームワークが苦手でいつも振り回されている: プログラマの思索

また、アナログのホワイトボードでチケットやPJ状況を書き出し、部長さんとも立ち話で情報共有する。
Slackを入れて、1to1で話しやすい環境を作る。
もちろん、デイリースタンドアップ、ふりかえりも取り入れている。

こういうストーリー形式で物語になるのは読みやすくていいと思う。

あとがきで、沢渡さんが、自分はウォーターフォール畑で育ち、そこで改善活動していたら、そのプラクティスがアジャイル開発だった、という経験をした。
その経験を書きたいが、アジャイル開発の専門家でないので共著でお願いした、と。
ウォーターフォールとアジャイルの二項対立でなくてもいいではないか、と。

そうだなと思う。

Pythonデータ分析の気づき

Pythonデータ分析ライブラリでコーディングしていると、いくつか気づきがある。
初心者のラフなメモ。

【参考】
Pandas Cheat Sheetのリンク: プログラマの思索

ゆるふわPandasチートシートのリンク: プログラマの思索

scikit-learn「アルゴリズム・チートシート」のリンク: プログラマの思索

NumPyを図解で理解する: プログラマの思索

Python と R の違いのリンク: プログラマの思索

Numpyは普通の行列計算だが、常識と違う部分がある。
ブロードキャストとユニバーサルファンクション。
いずれも、行列の要素に一括計算できる。

2つの行列のShapeが違う場合に、ブロードキャストできるかどうかでまだ間違える。

Numpyのブロードキャストの挙動 - Qiita

NumPy♪ブロードキャストを雰囲気で理解していませんか？ | Snow Tree in June

「ゼロから作るDeep Learning」を読むと、シグモイド関数の計算でNumpyのブロードキャストがトリックとして上手く使われていると感じた。

Pandasは、SQLの代わりになること、グラフ表示の2つがある。
concat, merge, groupbyなど色々ある。
ExcelもCSVも読み込めるので、SQLの代わりとして、データの結合・抽出・マージ・分割が簡単にできる。

Pandasのグラフ表示は簡単だが、割と癖があるように思う。
MatplotLibとは使い方が微妙に異なるのでまだ間違う。

データフレームに利用人数、利用料金があったとする。
利用料金ごとの人数をヒストグラムで表示する場合、同じ結果を出すソースコードが4種類もある。

df["利用料金"].hist()
plt.show()

df["利用料金"].plot(kind='hist')
plt.show()

df["利用料金"].value_counts().plot.bar()
plt.show()

df["利用料金"].value_counts().plot(kind="bar")
plt.show()

Pandasでヒストグラムの作成や頻度を出力する方法 - DeepAge

とはいえ、Pandasに慣れると、Excelの表データがあれば、データ読み込み→データ集計と整形→折れ線グラフ・棒グラフ・散布図などでグラフ表示までの処理をスクリプトで簡単にかける。
VBマクロやExcelのピボットテーブルもいらない。
特に、散布図が簡単にかけるのはいい。

MatplotLibは多彩なグラフが書ける。
グラフの種類が多い。
plot, pie, bar, barh, scatter, hist, boxplot, corr。
積み上げ棒グラフも簡単。

グラフ要素を細かく設定できる。
枠線・折れ線・棒の色や太さ、凡例、タイトル、などなど。
引数の細かい仕様を覚えるのは面倒だが、凝った作りにできる。

skelarnは機械学習をお手軽に実践できる。
データをテスト・検証用データに分けて、fit→predictするだけ。
サンプル数が100程度でも十分に色々遊べる。

skelarnは、おおまかに、カテゴリで分類すること、回帰モデルで予測すること、の２つ。
アルゴリズムが多いので、どれがどの場面で有効なのか、1個ずつ、抑える。

モデル評価も、分類・回帰の2つ。
混同行列は「分類モデル」を評価する。
「回帰モデル」を評価するのは、MAE, MSE, RMSE, 決定係数の 4 つ。

ROC曲線を見て、最近、コロナニュースでよく聞く、偽陽性率と真陽性率の話も関係することが何となく分かってきた気がする。
そういうことを考えると、機械学習がこんなに簡単なPythonライブラリで初心者が簡単に扱えることがすごいし、統計やデータ分析を知らない専門家の話はアホかな、とか思う時もある。

機械学習をきちんと理解したいので、「Pythonではじめる機械学習 ―scikit-learnで学ぶ特徴量エンジニアリングと機械学習の基礎」を読み始めた。
他の本も色々立ち読みしてみたが、この本が初心者でも取り掛かりやすいように思った。

「SCRUMMASTER THE BOOK」の感想～スクラムマスターはチームが自己組織化したら御用済みなのか？

「SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ」を読んで、スクラムマスターはチームが自己組織化したら御用済みなのか？という根本問題に気づいた。
論理的でないラフなメモ書き。

スクラムマスターの目標は、チームを自己組織化させること。

スクラムマスターの手腕により、スクラムが上手く回ると、スクラムマスターの出番は少なくなる。
チームは自己組織化されると、スクラムマスターの力を借りずに、チーム自らが問題解決するようになる。
では、スクラムマスターの本来の責務は何なのか？

スクラムマスターはチームの秘書ではない。
スクラムマスターはチームの世話焼きではない。

スクラムマスターが他の役割と兼務した場合、どうなるか？
チームと兼務すると、リーダーシップが欠如となり、チェンジマネジメントの役割が消える。
プロダクトオーナーと兼務すると、相反する役割を1人の人間が持つので、矛盾する言動に陥る。
マネージャと兼務すると、チームへのマイクロマネジメントになる。

複数のスクラムマスターと兼務する場合、作業負荷は高くなるが、経験値は増えるし、システム思考で考えることに秀でるメリットがある。

自己組織化したチームとは何か？
チームの全メンバーがリーダーとなって、リーダーシップを発揮すること。
フォロワーはいない。

各人がリーダー経験があれば、問題を自己解決する能力はある。
リーダーがー求める行動を理解でき、そのように振る舞うこともできる。

スクラムマスターはリーダーである。
チェンジマネジメント、つまり、ステークホルダーとの関係を通じて組織変革の役割を担う。

スクラムマスター・ウェイのレベルは３つ。
レベル1は、私のチーム。
まず、自分のチームを自己組織化させる。
でも、自分のチームが自己組織化したら、スクラムマスターは何をするのか？
仕事がないのでは？

レベル2は、関係性。
つまり、チェンジマネジメント。
ステークホルダーとの関係を良くする。
スクラムチームの3つの関係が良くなる。

レベル3は、スクラムの価値観を企業レベルに持ち込む。
スクラムマスターのグループが集団となる。
スクラムマスター自身がそういう技術を持っているのだから、それ自身が自己組織化したチームとなる。

スクラムマスターの道具箱。
ファシリテーションとして、レトロスペクティブの技法。
コーチング。
根本原因分析として、特性要因図、なぜなぜ分析。
ここは古い技法を割と使っている。

製品開発の手法インパクトマッピングを使って、スクラムの導入・実践に適用する。
なぜ？＝ゴール
誰が？＝アクター　
どうやって？＝アクターの効果を変える
何を？　＝解決策

大規模スクラムは、LeSS一択。
窮屈な方法、官僚主義的な方法でスクラムを改修する必要はない。
スクラムはシンプルで経験主義なのに、なぜ官僚化したプロセスがいるのか？

LeSSの特徴。
製品の大きさに無関係にスケールできる。
製品の大きさに関係なく、プロダクトオーナー1人、プロダクトバックログは1つ。

計画フェーズは故意に2つ入れる。
プロダクトオーナーとチーム代表による計画、各チームのスプリント計画。

レトロスペクティブも2つ入れる。
OverAll Retrospectiveはチーム代表、スクラムマスター、プロダクトオーナー。
普通のレトロスペクティブは、各チーム。

再び、問う。
スクラムマスターはチームが自己組織化したら御用済みなのか？
スクラムマスターは、自分のチーム、外部のステークホルダーを通じて、組織文化を変革する役割を担う。

Redmineのチケット管理はイベントに対応付けて組織文化を設計するアイデア

Redmineのチケット管理はイベントに対応付けると運用しやすいと思う。
Redmineのチケット管理はイベントに対応付けて組織文化を設計する発想だ。

なぜ、イベントが大事なのか？

チケットはすぐに滞留して、放置されやすいので、定期的なメンテナンスが必要になる。
チケット管理に定期的なイベントを対応付けて、単なる報告会ではなく、メンバーの自主的な改善活動を促すように、イベントを設計すればいい。

例えば、毎日の朝会、毎週の棚卸し会、毎週・毎月のふりかえり、毎週・毎月の顧客・ベンダー報告会、最後にPJ完了報告。

朝会で、Scrumのデイリースクラムのように、自分の進捗・課題の状況報告を全てチケットに基づいて発言させればよい。
チケットはPJ全体で公開されているので、自分の進捗状況は誰でも確認できる。
チケットが更新されず停滞すると、本人は頑張っていたとしても、周囲から見れば何も捗っていないように見える。
だから、頑張って成果を出すか、進捗を遮る課題を状況報告するか、何かしらをチケットを通じてチーム内に発信するようになる。
つまり、チームやメンバーの状況が透明化されると、プリマドンナのような、能力はあるかもしれないが黙っていて誰にも話さない開発者は自然にいなくなる。

棚卸し会を毎週行うことで、溜まったチケットの棚卸しや残課題を棚卸する。
そういう場を設ける事で、メンバー全員で課題を解決していこう、という雰囲気を作り出すことができる。
あるいは、この課題は手ごわい、という危機感を醸成することで、メンバーの気持ちを引き締めることがあるかもしれない。

振り返りを定期的に行うことで、PJ内の運用を改善するアイデアを引き出し、改善案に持ち込める。
今までにこなしたチケットをふりかえれば、メンバーもリーダーも色々気付きが多いはず。
プロジェクトリーダーも、自分が見えていなかったメンバーの気持ち、チーム内のコンフリクトに気づくかもしれない。
立場が違えば、同じ現場にいても見える風景は異なる。

顧客向け報告会、ベンダー報告会をマイルストーンに設定して、それまでにメンバー全員で成果物を作るという目標を打ち立てるのも大事。
過去の経験では、要件定義フェーズでは、毎週の顧客ヒヤリングの打合せが毎週のマイルストーンとなり、それまでに要件をまとめて、不明点を課題一覧にまとめる、という作業が多かった。

イベントの設計は、PMBOKのコミュニケーション計画に相当すると思う。

チケットという蓄積された情報を元にイベントを開催すれば、チケットは大切なものなのだ、チケットは役に立つな、という意識をメンバーに植え付けさせることもできる。
また、プロジェクトリーダーも無駄な報告資料を作る手間も省けるし、QCD観点のチケット集計ビューを常時見れば、PJ状況をモニタリングできる。

よって、蓄積されたチケットをどのように扱うのか、というイベントを運用ルールに組み込んでおくと良い、と思う。
イベントとチケットによって、メンバーのモラールを向上させる仕組みや組織文化を設計しているわけだ。

Redmineのチケット設計はMVCモデルで考えると上手くいく

Redmineのチケット設計はMVCモデルで考えると上手くいくと思う。

Model＝チケット。QCD分析の観点はカスタムフィールドで仕込む。
Controller＝各機能。
View＝QCD観点の集計ビュー。

なぜ、MVCモデルで考えるべきなのか？

MVCで考えると、PLが欲しいデータをチケットで作りこむ発想になる。
PJの状況をリアルタイムにモニタリングして、PJが暴走しないように早めにリスクを検知したい。
飛行機の操縦室のように、数多くの計測機を表示させて、少しでもおかしな点があれば、どこかでアラートが出るようにしたい。
つまり、各機能はQCDの観点で区別して利用すべき。

では、どんなビューが欲しいのか？

進捗の観点なら、ガントチャートやEVM、CCPMのバッファ管理図。
コストの観点なら、工数ベースや金額ベースのEVM。
品質の観点なら、機能ごとの障害・課題数、障害や課題の残枚数の時系列グラフ、信頼度成長曲線、障害密度のゾーン分析、とか。

では、どんな情報をチケットにするか？

進捗の観点なら、開始・終了日の予実、進捗率。
コストの観点なら、工数の予実。
品質の観点なら、障害・課題の原因、発生・流出原因、発生した機能、対応方法の種類など。

つまり、QCD分析したい時に必要な情報は何か、をViewからModelへさかのぼり、チケットの入力項目を決めることになる。
チケットの標準項目が不足していれば、カスタムフィールドを追加すればいい。
Redmineではカスタムフィールドをトラッカーごとに割当られるので、複数のトラッカーの入力項目から正規化することで、カスタムフィールドの数を減らせる。
この辺りは、データモデリングの設計思想と全く同じ。

@g_maedaさんは、「トラッカー設計＝帳票フォームの設計＝入力フォームの設計」と言われているが、MVCモデルで考える発想はこの設計に通じる。

はじめる! Redmine (2017) from Go Maeda

新型コロナウイルスの感染者の情報をRedmine（RedMica）で公開している事例

新型コロナウイルスの感染者の情報をRedmine（RedMica）で公開している事例があったのでメモ。

【参考】
Redmineヘッドライン 月刊まとめ（2020年11月） | Redmine.JP Blog

一覧表示 - 山梨県 - 新型コロナウイルス感染者情報（非公式）

（引用開始）
新型コロナウイルスの感染者の情報をRedmine（RedMica）で整理する試み。現在は山梨県の情報のみ対応しています。
感染者ごとにチケットを作成して、症状・経過、行動歴、濃厚接触者などを整理。
（引用終了）

チケットに感染者1人の情報を登録しているので、チケット一覧がそのまま感染者一覧になる。
感染者情報を「チケット一覧」をリネームして「情報一覧」で表示している。
チケット属性が良く考えられている。

ステータスに、感染・回復・死亡・不明・取り下げがある。
カスタムフィールドに、年代、重症度、居住地、生活圏、判明日、回復または死亡日、性別、職業、発症2週間以内の外出有無などがある。
チケットのタイトルはXX例目。

他に、タグがあるので、タグプラグインを入れて、咳・発熱・倦怠感・味覚障害・胸痛などの詳細な症状がある。

こういうチケット情報であれば、チケットをCSV出力すれば、PythonのPandasでデータ集計しやすくなるし、Matplotlibで時系列の新規感染者の増加傾向、症状別の人数なども簡単にグラフ化できる。
つまり、チケット情報が正規化されているので、非常に使いやすくなっている。

面白い点はカレンダーで、カレンダーを見ると、感染者番号ごとに表示されるので、たとえば、12/1はこんなに大量に感染者が出たのか、とかすぐに判別することができる。

現状は山梨県だけみたいだが、日本全国でこういう情報があるといいね。

改めて、Redmineのチケットは色んな情報をデータ化しやすいように思った。

Redmineと組織構造や組織文化はどのように関係するのか

Redmineと組織構造や組織文化はどのように関係するのか、については、２つの仮説を持っている。

一つは、複雑な組織構造はRedmineを複雑化させる。
コンウェイの法則のRedmine版みたいなもの。
サイロ化された組織であれば、縦割りの組織構造により、コミュニケーション経路やプロセスが複雑になるので、Redmineのシステム設定にその内容が反映されてしまう。

あるいは、この発想の源は、チャンドラーの「組織は戦略に従う」にあった。

一方、Redmineに実装されたプロセスが、その組織にとても適合するならば、組織を活性化させ、メンバーの士気を向上させるような組織文化を生み出す。
実際、Redmineでアジャイル開発を実装できて、そのアジャイル開発が上手く運用できるならば、アジャイル開発のプラクティスの効果はスムーズに発揮されるだろう。
その結果、メンバーの自発的な行動を促すことで、チームの自己組織化が実現され、マネージャのマイクロマネジメントは不要になる。
各チーム、そして各部署は一つの機能部品として、組織の中で協調して動作するように働く。
つまり、沈滞していた組織は、活性化されるはず。

この発想の源は、アンゾフの「戦略は組織に従う」にあった。

逆コンウェイの法則は、この２つを逆手に取って、ソフトウェアのあるべきアーキテクチャに沿った開発チームを構成することで、ソフトウェアの開発をスムーズに行える開発プロセスを実装し、組織の活性化をもたらす効果を狙う。

ソフトウェアと組織構造、組織文化の関係は、相互に作用しているのが面白い。

astahのM＋プラグインでモデル間のトレーサビリティが実現できる

astahのM＋プラグインがいい感じで使えるのでメモ。

【参考】
M PLUSプラグイン | astah* プラグイン

astahのM＋プラグインは、多種類のソースコードをクラス図から自動生成するだけ、と思っていた。

（引用開始）
1. ソースコード出力
C++ / C# / Crystal / Golang / Java / JavaScript / Kotlin / Python / Ruby / Scala / Swift / TypeScript / Alloy / VDM++に対応。
Acceleo, MOFScript, Xpandのように手書きのコードを維持するため、繰返しのコード生成が可能です。
（引用終了）

しかし、便利な機能があることが分かった。

（引用開始）
2. モデルプレビュー
構造ツリー上のパッケージを選択して、パッケージ内のモデル構造をプレビューできます。

3. ダイアグラムマップ
プロジェクト内の複数の図を1箇所に表示し、図をまとめて見れるだけでなく、図要素をマウスオーバーすると、同じ型のモデル要素同士が ハイライト線で繋がる為、図を跨いだ要素のトレースができます。

4. 依存関係マトリクス
プロジェクト内のモデル間の依存関係をExcelに出力します。
（引用終了）

モデルプレビューは、パッケージを選択すると、パッケージ内のダイアグラムをEnterpriseAcrchitectのようにパッケージ図にダイアグラムアイコンをHTMLで表示してくれる。
astahのパッケージは、ダイアグラムを階層化するための機能なので、モデル間のトレーサビリティ機能として欲しかった機能だった。
ただし、ダイアグラムのハイパーリンクはないので、単に表示するだけなのは残念。
ダイアグラムのハイパーリンクがあれば、下方追跡が実現できるのに。

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

ダイアグラムマップは、２個以上のダイアグラムを含むパッケージを元に、複数のダイアグラムにあるクラスなどの要素が同じであれば、ハイライト線でつないでくれる。
つまり、ハイライト線はモデル間のトレーサビリティを実現した機能になる。

この機能を使えば、クラス図、シーケンス図、コンポーネント図などで、クラスがあちこちに散らばっていたとしても、同じクラスであれば、ハイライト線で該当箇所を見つけることができる。
つまり、ハイライト線でモデル同士の要素をトレースできるので、なぜこんな所にあるのか？とか、モデリング作業中の気づきを増やせる。

依存関係マトリクスとは、RelationshipMatrixというExcelを出力して、モデル間の依存関係を出力してくれる。
これを使えば、本来あるべき依存関係がない、とか、本来ない依存関係があるぞ、とか、モデルをリファクタリングしたり、モデルを精査する時に役立つ。

astah上でモデルのトレーサビリティを実現してほしいな、と思っていたけれど、このプラグインでどこまで対応できるのか、試してみたいと思う。

Redmineの一つのプロジェクト内でユーザの権限を使い分ける要望への対応

Redmineの一つのプロジェクト内でユーザの権限を使い分ける要望への対応があったのでメモ。

【参考】
Redmine 3.3新機能紹介: トラッカーに対するロールベースの権限制御(チケットの閲覧/追加/編集/削除/注記の追加) | Redmine.JP Blog

JAXAのRedmine運用事例の分析～「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索

JAXAのRedmineモデル～Redmineはレイヤ構造になっている: プログラマの思索

【1】背景：
既にRedmineは長年運用されている。
1つのプロジェクト内に、数多くのトラッカーがあり、複数の業務が運用されている。
社員ユーザもいれば、派遣会社さんユーザもいて、それぞれにリーダークラスの人と作業者クラスの人に分かれている。

ある業務のチケットには、派遣会社ユーザだけに更新させて、作業が終わった後、社員リーダーが承認したい。
その業務には、派遣会社のユーザだけが触ることができて、一般社員には更新させたくないし、できれば見せたくない。
たとえば、派遣会社の人向けの教育とか、事務処理とか。

そういうことはRedmineで対応できますか？と。

【2】現状分析から課題へ、そして考えられる解決策

ある特定のトラッカー「教育」に対し、PJで指定されたユーザには、特定のワークフローを設定できるか？という課題に落ち着く。

既に運用済みのプロジェクトなので、トラッカーやロール、ステータス、ワークフローを削除することは不可。
ただし、新規追加で対応できると仮定しよう。

考えられる解決の方向性は、リーダー・一般ロールを増やし、特定のロールは特定のトラッカー「教育」しかチケットの編集権限を設定しない。
また、ワークフローでは、一般ロールは新規～承認前ステータスまで遷移可能とし、リーダーロールは承認前～承認ステータスを遷移可能とする。
最後に、PJ設定のロール設定画面で、派遣会社の人には一般ロールも追加し、社員リーダーの人にはリーダーロールも追加する。

つまり、（１）トラッカーに対するロールベースの権限制御と、（２）ロール設定のORルールを組み合わせることで実現可能ではないか、と思う。

【3】本当に問題は解決できるのか？

普通は、１個のPJ内のメンバーは、PJ内のすべてのトラッカーのチケットを更新できる状態にしたい。
つまり、PJ＝１個のチームに対応付けることで、PJメンバーの一体感を醸成したいのだ。

よって、上記のような課題が発生した場合は、本来は、そういう業務単位にサブプロジェクトを作って、該当するメンバーだけのプロジェクトを設定する方が良いと思う。
その方が、複雑なロール権限やワークフロー、PJのロール設定を行う必要はないので、Redmineのシステム設定自体もシンプルになる。

しかし、長年の運用ルールに縛られたりする場合もあるだろう。
また、細かな業務ごとにサブプロジェクトを作っていけば、プロジェクトの階層構造が深くなったり、プロジェクト数そのものも状態爆発のような状況に陥るかもしれない。

業務の複雑さを取り込むことで、Redmineのシステム設定そのものも複雑化してしまう事例だな、と思っている。
本来は、Redmine云々の前に、業務改善とかできないのかな？とか。

第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想～モデルの検証を形式手法で自動テスト化する

第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想をラフなメモ書き。
適当なメモ。

あくまでも僕の理解なので、論理が端追っていたり、論理が飛んでいる。

【参考】
モデルベースシステムズエンジニアリングの活用 - connpass

第73回 SEA関西プロセス分科会 「モデルベースシステムズエンジニアリングの活用」 の見所 #seakansai: プログラマの思索

【1】高井さんの2つの講演「モデルベースシステムズエンジニアリングにおける形式手法の効果的な活用」「モデルベースシステムズエンジニアリングにおけるシナリオ生成手法の効果的な活用」は共に、SysMLと戦略の観点のマトリクスによるモデルから、形式手法などのツールを駆使して、別のモデルを作り出し、その生成技法をastahのプラグインで実装したというお話。

あまり詳しくなければ、昔流行したMDA（モデル駆動開発）とか、超高速開発のようなツールを連想してしまうが、実際に聞いてみると、こういうものを実装したい時代背景や動機が色濃くあることがよく分かった。

実際、高井さんが、モデリング技法（astahなどのモデリングツール）と各種の技法（形式手法Spinなど）がほどよく洗練されてきたので、使いやすくなった、と言っていた。

たとえば、形式手法のSpinの問題点は2つあるが、問題点を薄めやすいという。
一つは状態爆発しやすいことだが、状態遷移図だけでなく、SysMLでは上流工程の要求モデルや他のモデルの情報をもとに、状態遷移を明確にすることで、状態爆発しない程度までに抑えることができる。
もう一つは、Spinで検査式が難しくて書きにくいことだが、SysMLのダイアグラムに制約条件を書き込んだり、他ツールとのトレーサビリティから情報を集めて、検査式を作りやすい。

つまり、モデルベースエンジニアリングによるモデルには豊富な情報が含まれているので、形式手法のSpinに合うような情報を連携すれば、Spinの弱点を解決でき、Spinのプログラムを自動生成できるようになるわけだ。

【1-1】具体的には、上流工程から下流工程までの各種のモデルを生み出す技法と、形式手法を組み合わせて、モデルそのものの検証が行えること。
つまり、モデルをいくら書いても、そのモデル自体の正しさはそのままでは保証できないが、モデルに描かれた仕様や制約条件を元に、形式手法のプログラムへ自動生成できれば、モデルそのものを検証できる。
さらに、モデルのテストケースもSysMLで書いておけば、テストケースそのものも形式手法プログラムの一つになる。

デモでは、モデルから形式手法プログラムへの自動生成とモデルの検証をastahで行い、モデルの検証結果がOKであれば、astah上のテストケースが緑色、検証結果がNGなら赤色に変わるように反映されていた。

この手法を使えば、astahで描かれたモデルの検証ケースをテストケースで全て書き込んでおいて、継続手インテグレーションで回せば、モデル検証を自動テストできる仕組みが構築できる。
そうすれば、上流工程のモデルを修正したり追加するたびに、自動テストを動かして、モデルの整合性や正しさを保証できるように運用できるはずだ。

本来は、astahのモデルではなく、PlantUMLのように、モデルをソースコードで書くようにできれば、SpinやLTSAのような形式手法プログラムでモデル検証の自動テストがやりやすくなるはずだ。

【1-2】あるいは、具体的には、自動運転の自動車部品のセキュリティ対処の為に、セキュリティの穴をつくような攻撃シナリオや防御シナリオをastahのGSNモデルとして描き、そこから、具体的に設計や実装が可能なシナリオを自動生成すること。
おそらく、astahGSNで、自動車部品のセキュリティのシナリオを論理的に書いておき、そこからパターンごとにシナリオを生成するイメージ、かな、と思った。
すると、シナリオを元に、具体的な仕様モデルや実装モデルを設計できる。

なお、Spinのような形式手法プログラムもコマンドライン・ベースで動くので、astahの画面からキックして、Spinプログラムを実行できたり、ログ出力された実行結果を読み取ることができる。
Spinはもう随分枯れた形式手法だが、プログラムのI/Fはコマンドラインのまま古い点が逆に良い点に作用しているのだろう。

そういう話を聞くと、astahは外部から接続できるAPIが公開できていたり、astahのプラグイン実装が可能な点が有効に活用できているのだろうと思う。

個人的には、PlantUMLのようにUMLやSysMLをソースコードで書いて、SpinやLTSAのような形式手法プログラムを自動生成＆自動テストを実行できる仕組みを作っておき、一方で、ソースコードで書かれたモデルはastahのようなビジュアルなモデリングツールにいつでも読み込めるようにする手法が運用しやすいのでは、と思う。
モデルがソースコードに落ちていれば、Gitで構成管理しやすいし、I/Fがコマンドラインで実行できるならば、形式手法以外の技法のツールと連携しやすいからだ。

【2】一番興味深かったのは、とある大学の先生の話。

フォルクスワーゲンは「ソフトウェアファースト」を掲げて製造業からソフトウェア業へ本当に変革しようとしていて、実際、2020年には2000～3000人ものソフトウェア技術者をドイツで募集しており、社員の割合もハード技術者とソフト技術者の割合が半々まで来ているらしい。

一方、トヨタも2020年になって社長自ら「ソフトウェアファースト」を掲げて、ソフトウェア技術者を応募しているが、今までのエンジン技術の成功体験もあって、そこまでソフトウェア重視ではないですね、とのこと。

僕は、DXとは、ITが中核事業でない既存企業がソフトウェアを中核とした事業にシフトすること、と思っているので、日本企業がソフトウェアにまだまだ詳しくないからこそ、DXというバズワードが流行しているんだろうな、とか思った。

つまり、DXとは、従来の事業スタイルのメーカーや小売業が、新興勢力のソフトウェア企業に「代替品の脅威」を感じて、何とか自社でもソフトウェアを前提とした事業を打ち出そうと頑張るためのバズワード、と思っている。

すなわち。「DXとは、ソフトウェアが世界を食う脅威に従来型企業が怯えて対抗しようとしている活動」ではないか。

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ: プログラマの思索

ソフトウェアが世界を動かす時代: プログラマの思索

VWがソフトウエア部門を一新、自社開発を大幅に増やす | 日経クロステック（xTECH）

「ソフトウェアファースト」で社会の一部となるクルマづくりへ、トヨタとNTT - MONOist（モノイスト）

【追記】
当日の講演資料が公開されました。

プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある

プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある、という言葉に惹かれたのでメモ。
論理性のないラフなメモ。

【参考】
「曖昧さへの耐性の旅」が近い - 金融そして時々山

（引用開始）
「プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある」という部分でした。これは「世界一わかりやすいプロジェクトマネジメント」という本にでてくる話なのですが、受講者の皆さんはこれまであまり聞いたことがなかったのかもしれません。
（引用終了）

「曖昧性とのたたかい」より抜粋したプロジェクトマネジメントのチェックリスト - takuya0206's diary

（引用開始）
提案依頼書に要求仕様などの詳細が書かれていることはまずない
完璧で完全な契約にこだわりすぎると、顧客に嫌がられ失注する恐れがある
曖昧さが残る状態が避けられない以上、この曖昧性をいかにコントロールするかがプロジェクトマネジメントの最大の課題である
（引用終了）

プロジェクトの曖昧さは不確実性のコーンと同じと思う。
曖昧さが残る状態から開始するのは避けられない。
その曖昧さをどうコントロールするのか？

ウォーターフォール型開発では段階的詳細化によりスコープを狭めたり、QCDが合致切り目られた計画を元にQCDの予実管理で差異を事前に検知しながら、曖昧さをコントロールしていく。

一方、アジャイル開発では、短期間のスプリントでスコープをコントロールしながら、漸進的に品質を高める。
また、ユーザーストーリーはプロダクトバックログの優先順位でふるい分けられて、その時々の状況を織り込みながら、変化を取り込む。

エンジニアであるからには、ソフトウェアであれ、ハードであれ、要件とQCDの実現性のバランスを取るのが顧客から期待されている。
でも、曖昧さとQCDのトレードオフのバランス感覚は、いつになっても難しいと思っている。

プロジェクトマネージャに必要な能力は、そのトレードオフの感覚がいちばん重要なはず。

そういうトレードオフの技法をエンジニアリングとして形式知化してきた。

他方、特にソフトウェアのエンジニアは曖昧性に弱い。
結構自分の裁量が大きいので、作った後でユーザに見せると、全く違う、とよく言われる。
ソフトウェアはいろんな実現方法があるので、1つのロジックを複数のプログラムで表現できるために、コードクローンも発生しやすい。
その分、バグも出やすくなる。
似たようなコードが沢山発生するので、技術的負債はリリース直後から発生し、リプレースするまでその重みで保守すら難しくなる。

曖昧さのコントロールは、PMBOKでもアジャイル開発でもその難しさは変わらない。
QCDでコントロールするのか、スコープでコントロールするのか。

GTDは箱の使い分けが鍵を握る

GTDは興味を持つけど、なかなか使いこなせない。
GTDは箱の使い分けが鍵を握ると気づいたのでメモ。

【参考】
何かとわかりづらい GTD について、エンジニア向けにざっくり説明してみる - Qiita

GTDを噛み砕く

プロジェクトマネージャの意思決定プロセスや判断プロセス: プログラマの思索

GTDのワークフロー from akipii Oga

【１】GTDが難しいのははぜか？
Inboxに溜まったタスクをふるい分ける箱の数が多すぎて、迷ってしまうからではないか。

GTDを噛み砕く　第１章 GTD をわかった気になる

（引用開始）
ただ、この「箱」が曲者で、GTD では何個も「箱」が登場します。
（引用終了）

7 つもあるの？　何かとわかりづらい GTD について、エンジニア向けにざっくり説明してみる - Qiita

（引用開始）
GTD ではリストを 7 つほど使う。この 7 つのリストについて解説する。

7 つもあるの？
7 つというと多そうだが、「気になること」およびそこから派生するタスクには色々性質があり、ちゃんと運用したいなら役割分担がどうしても必要になる。GTD では「こんなリストがあったら便利だよね」という発想で、異なる役割を持つリストをつくって厳選した結果、7 つほどになった。

プログラミングでも神クラスをつくったりはせず役割ごとにクラスを分けたりするが、発想としては同じである。
各リストについて、名前だけ

インボックス(Inbox)
いつかやる(Someday)
資料(Pointer)
カレンダー(Calendar)
連絡待ち(Waiting)
プロジェクト(Project)
次に取るべきアクション(NextAction)
（引用終了）

GTDでは、頭の中にあるモヤモヤしたアイデア、不安なこと、ちょっとした気付きなどは全て、Inboxに吐き出す。
そこから、箱に分けていくのだが、そこで手が止まる。
どこに入れればいいのか、迷ってしまうのだ。
はじめてのGTD ストレスフリーの整理術を読むと、なぜか混乱してしまう。

結局は、それぞれの目的に箱があるだけと思えばいい。
プログラム的には、IF文で条件分岐しているだけと思えばいい。
下記のPythonプログラムが分かりやすい。

何かとわかりづらい GTD について、エンジニア向けにざっくり説明してみる - Qiita

（引用開始）
フローチャートというとひるみがちになるが、イメージとして以下のとおり、ただの条件分岐の列挙なのでひるむことはない。

def proceed_inbox(list_inbox, list_itukayaritai, list_siryo, ...):
for kininaru_koto in list_inbox:
if kininaru_koto means 'いつかやりたい':
list_itukayaritai.append(kininaru_koto)
continue
if kininaru_koto means 'あ、これ改めて見たら不要だわ':
continue
if kininaru_koto means 'これってただの情報源だよね':
list_siryo.append(kininaru_koto)
continue
...
# 全部処理したのでインボックスを空にする
list_inbox = []
（引用終了）

【２】GTDが難しい理由のもう一つが、箱を整理するタイミングが混乱しやすいこと。
「週次レビューが重要だ」とはじめてのGTD ストレスフリーの整理術でよく書かれているのだが、ピンとこなかった。
結局は、箱に溜まったタスクを整理するだけのことだ。

箱ごとに、中身を整理するタイミングは微妙に異なる。
重要度が高ければ、日次レビューだし、随時レビューすることもある。
一方、レビューのタイミングは、週末だけ、月末だけ、年に１回だけのこともある。

リストとは　何かとわかりづらい GTD について、エンジニア向けにざっくり説明してみる - Qiita

（引用開始）
各リストは以下の設定（使い方などのルールを定めた設定）を持つ。

Write Timing …… いつ書き込むか。書き込む頻度はどの程度か。
Write Content …… どんな内容を書き込むか。
Review Timing …… いつ見直すか。見直す頻度はどの程度か。
Review Action …… 見直しとして具体的に何を行うか。
要するに「いつ、何を書き込むの？」と「いつ読み返すの？読み返して何をするの？」を定める。
（引用終了）

【３】「GTDとはリスト駆動生活である」ということだ。
リストを作っておき、１日の生活をリストから駆動して、タスクをこなしていく。
チケット駆動開発と発想は似ている。

（引用開始）
リスト駆動生活とは、リストを中心に生活を回すこと。具体的には

朝起きたらリストを見る
やることが書いてあるので、一つ選んで消化する
リストに戻ってきて、次のやることを選ぶ
...
こんな生活。窮屈そうだが、リストにさえ書いておけば忘れない という状態を手に入れることができるため、ほぼ必須の概念である。

GTD では、「次に取るべきアクション」リストがこれに相当する。
（引用終了）

GTDはリスト駆動開発であり、箱の整理のタイミングを重視している。
その発想をチケット駆動開発に適用すれば、チケット駆動開発でも、チケットの整理や棚卸しはタイミングが重要だ。
チケットの整理のタイミングに対し、プロジェクトのイベントを対応付ければ、チケット駆動開発は上手く運用できるはず。

考えながら書く人のためのScrivener入門の感想

「考えながら書く人のためのScrivener入門　小説・論文・レポート、長文を書きたい人へ」を読んで、改めて、物書きになる環境について色々気づきがあった。

【参考】
統合執筆環境Scrivenerのリンク: プログラマの思索

「考えながら書く人のためのScrivener入門」の帯には、「書く才能はある！足りないのはScrivener」という文言がある。
僕も出版した経験があるから理解できるが、書物1冊を書き出すのは本当に大変だ。
大変な理由は、1冊20万字くらいの文字数を書き出すこともあるだろうが、むしろ、構成やストーリーの一貫性や整合性を考える点の方にあるだろうと思う。

「考えながら書く人のためのScrivener入門」には、3人の小説家がScrivenerを使って執筆した経験談をインタビューしてくれている。
読んでみると面白い。
気になった点はいくつかある。

一つは、小説や書物という長編を書く場合、何かしらの文書の構成方法や構成を管理する環境が必要になる点だ。
たとえば、200ページの本を印刷してつなげると、16メートルの長さになるらしい。
すると、修正する時に、該当の箇所を探し出すのに、画面スクロールを16メートルも指を動かしているわけだ。

修正を何度も繰り返すたびに、そういう動作を何度もやっているわけで、そういう無駄な作業時間をストップウォッチで計測したら相当なロスになるはずだ。
実際、単純な検索機能では、同じような文言が見つかったり、構成を見直すためにあちこちを修正する場合は、考える時間よりも探し出す時間の方が多くなり、せっかくのアイデアが失われてしまう。

そこで、Scrivenerの出番になる。
Scrivenerでは、文書を1ペインのアウトライナー画面、2ペインのテキスト画面、コルクボード形式でアイデアを発散させる画面など数多くの機能がある。
つまり、ある時はアイデアを適当に発散させたり、あるシーンだけを詳細に書いたり、いくつかの物語のプロットの構成を考えながら節ごとに入れ替えたり、などと考える場面に合わせて変更できる。

他にもタグ付け、ラベル付け、とか、数多くのファイル出力機能、Dropboxと連携してバックアップの同期を取るなどができるらしい。
個人的には構成管理が気になるが、スナップショット機能があるらしいので履歴管理できるらしい。

2つ目は、3人の小説家は統合執筆環境Scrivenerだけで書いているのではなく、小説を書くまでのアイデア発散フェーズではマインドマップやアウトライナーのエディタを使ったり、遂行する段階ではPDF出力して印刷した紙で読み直すなど、割とアナログな面も残していることだ。
結局、ITというツールをいかに使いこなして、生産性を上げているとしても、その根っこにあるアイデアの発散や連想によるアイデアの結合などは、従来のアナログの手法とは変わらない。

この点は、Redmineのようなチケット管理ツールでも、その背後にある開発プロセスの話に結局落ち着く点に似ている。

3つ目は、長文の原稿は数多くの短編に分割して管理するのが推奨されていること。
ソフトウェアにおける分割統治と同じ発想だが、ソフトウェアが階層化してポインタを使う手法に対し、執筆では、文書を階層化するとしても1ペインのアウトライナーを有効に使う手法になる。

つまり、Wordのアウトライン機能のように、レイヤごとに見出しを揃えるが、その見出しはフォルダでもありテキストにもなりうる。
BEITELというアウトライナーのエディタのように、1階層目の見出しだけでもストーリーとして読めるし、2階層、3階層の中間レイヤの内容だけでも十分にストーリーとして読めるような構成にするわけだ。

BEITELとは - アウトラインエディタ BEITEL(バイト)

僕はマインドマップが大好きなのだが、何かしらの報告書や議事録のように、長文の文章を書く時にマインドマップでは何か物足りず、何かしらの機能が必要だと思っていた。
たぶんその原因は、発散したアイデアを一つの文章という1次元のデータに変換して、論理構成を保つには、アウトライナーのようなツールが必要だと直感していたためだろうと思っている。

この辺りの思考ツールや書き方については色々まとめてみる。

Pandas Cheat Sheetのリンク

Pandas Cheat Sheetを見つけたのでメモ。
他にも、Numpyとか色々あるので参考にする。
最初はこういうシートがあると参考になる

【参考１】
Pandas Cheat Sheet

Pandas Cheat Sheet（PDF）

Pandas Cheat Sheet from ACASH1011

【参考２】
(Cheat Sheet) Matplotlib: Plotting in Python - DataCamp

NumPy Cheat Sheet: Data Analysis in Python - DataCamp

Python For Data Science - A Cheat Sheet For Beginners - DataCamp

SciPy Cheat Sheet: Linear Algebra in Python - DataCamp

Pandas Cheat Sheet for Data Science in Python - DataCamp

Scikit-Learn Cheat Sheet: Python Machine Learning - DataCamp

Collecting Data Science Cheat Sheets | by Karlijn Willems | Towards Data Science

探せば色々あるね。
MatplotLibとかNumpyのチートシートも役立つ。

【参考３】
データサイエンスや機械学習のチートシートを最も効率的に収集する方法 - Qiita

FavioVazquez/ds-cheatsheets: List of Data Science Cheatsheets to rule the world

最初からここを探せばよかったかもしれない。
Pythonのデータ分析ライブラリ以外にも、RやSQL、Keras、ggplot2とか色々ある。

こういうチートシートは辞書代わりに使いたい。
こういう事がやりたい、という問題意識がある時に、どんな手法で実現できるか、ということを手早く知りたいから。

ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説

「チケット駆動開発がまわりはじめるまでの取り組み」のAdventCalendar記事を読みながら、ツールとプロセスの因果関係や、良い組織文化を生み出すきっかけは何なのか、を改めて考えてみた。
ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説を持っている。
ラフなメモ書き。

【参考】
マインドセットに至るまでの話 - TypeError:

#ssmjp Advent Calendar 2020 - Adventar

タイムテーブル「チケット駆動開発がまわりはじめるまでの取り組み」 | Redmine Japan

【1】僕がすごく興味を惹かれて、同感したのは下記の言葉。

（引用開始）
ゴールの明文化し全体像・規模感を見通し 「誰が」「どこまで」「何を」するのかの明確化しチームで同じゴールを目指して進めていくということに対してチケット駆動開発が非常に強力なツールであることを最後に改めて実感しました。
（引用終了）

困難な状況に直面しているプロジェクトを運営したり支援する立場にいると、技術やプロセス云々ではなく、まず火消しを行って、チーム全員が地に落ちたモラールに火を付けて、プロジェクトのエンジンを回す所から始めるのが必要な時がある。
しかし、火消しはできるが、メンバーのモラールを高めるのは割と難しい。
色んな事情や背景はあるだろうが、何をやっても駄目じゃないのか、みたいな負け犬みたいな雰囲気が出たり、それは私の仕事や責任範囲ではないですから、みたいな縦割り組織の雰囲気があったりする。

それを解決する手法は色々あるし、既に知られているものも多いだろうが、僕は、結局は、ショートカットせずに王道のスタイルを貫くしかないのだ、と思っている。
プロジェクトリーダーはリーダーシップを発揮して、共通目的を掲げてメンバーと共有し、メンバーに権限を委譲し、業務と責任を一致させて、メンバーと目標を共有して、目標を達成するための意欲を引き出す、という王道の方法しかない。

そういう状況において、道具立てとしてRedmineがあって、そういう組織文化を生み出すプロセスとしてチケット駆動開発を当てはめると、メンバーのモラールを向上させる仕組みが整った、という事例ではないか、と思っている。

【2】ツールがプロセスを明確に定義し、プロセスがメンバーのモラールを引き出し、プロジェクトの推進力を加速させる。
たぶん、そういう仕組みを作ることが、プロセス設計であり、プロジェクトリーダーが本来やるべき仕事であるはずだ。

そういう方法を実現する為に、チームビルディングの手法が特にアジャイル開発では数多く生み出されてきているし、参考にもなっている。

ツールでプロセスを透過的に設計して、メンバーにはプロセスを意識させずに運用してもらうが、実はそのプロセス設計にチームビルディングの手法やアジャイル開発のプラクティスを植え付けておけば、自然に、メンバーの自発的な行動を促し、チームはどんどん加速していく。
そういう仕組みを本来は作りたいはず。

スケジュールを厳格に予実管理してメンバーを半ば脅して、進捗遅延の責任を取らせる管理手法がやりたいことではないはずだ。

【3】では、メンバーの貢献意欲やチームの活性化を促すのは、ツールなのか？プロセスなのか？

以前の僕は、Redmineでいかにアジャイル開発というプロセスを実装するか、に興味を持って色々試行錯誤していた。
その結果を振り返ると、結果的にメンバーの自発的行動を促し、チームは活性化するという気付きが得られたが、当初は、Redmineというツールがチケット駆動開発を生み出し、Redmineがチームを活気にさせる仕組みを生み出している、と思っていた。
つまり、ツールがプロセスを生み出し、そこからチーム運営が上手くいく結果が得られたことから、ツールこそが全てだ、と思っていた。

しかし、考え直してみると、アジャイル開発というプロセスが、メンバーに責任感と自律性を促し、チームを活性化させたのではないか、と思う。
アジャイル開発にはプラクティスが豊富で、チームビルディングの手法が様々にあるので、メンバーやチームに自然に影響を与えて、自然に良い行動を促すように仕向けることができる。
すなわち、ツールはプロセスを生み出すが、プロセスの良し悪しがメンバーの貢献意欲やチームの活性化に大きな影響を与えているわけだ。

【4】以前の僕は、官僚化した日本企業がもたらす組織構造によって、Redmineというツールで実装したプロセスがどんどん複雑化する点に興味を持っていた。
「アーキテクチャは組織構造に従う」というコンウェイの法則が、実は、Redmineにも見られる、という点に驚いて、非常に興味深かったからだ。

一方、最近では、メンバーの貢献意欲やチームの活性化を促す組織文化はどうやったら生まれるのか、に興味を持っている。
そもそも、プロジェクトリーダーや中間管理職、経営層にとっては、会社を活性化させる組織文化を作り出す方に大きなインセンティブがあるはずだ。
彼らは、最終的に、戦略に基づいた事業に利益をもたらすための組織文化をいかに作り出すか、に腐心している。

今の仮説は、ツールが定義したプロセスの設計が上手くはまれば、メンバーの貢献意欲や責任感、チームの一体感や使命感を生み出すことは自然にできるはず、というものだ。
では、どんなプロセスで設計すると、メンバーの貢献意欲やチームの一体感を生み出すことができるのか？

この仮説を色々試してみたいと思っている。

IPAがDXのパターン・ランゲージを公開している～新しい組織文化が新しい経営戦略を生み出す

IPAがDXのパターン・ランゲージを公開しているのでメモ。
ラフなメモ書き。

【参考】
トランスフォーメーションに対応するためのパターン・ランゲージ（略称トラパタ）：IPA 独立行政法人 情報処理推進機構

変革のススメ vol.2 沢渡あまね 氏：IPA 独立行政法人 情報処理推進機構

トランスフォーメーションに対応するためのパターン・ランゲージ（略称トラパタ）

今のIT業界のバズワードはDXではないだろうか。
経産省が「2025年のITの崖」の記事を公開してから、特にDXという言葉が独り歩きしている気がする。

そもそもDXとは何だろうか？
僕の考えでは、DXとは、ソフトウェアが本業でない企業がソフトウェア中心のビジネスモデルを構築して事業構造を変換していくこと、と捉えている。
つまり、ソフトウェア開発の特徴や本質をあまり深く知らない人たちが中心になって、ソフトウェア開発のビジネスモデルを作って、売上を拡大していくための仕組みを作るもの、と考えている。
実際、小売業界、自動車などの製造業では特にそういう傾向が強いのではないだろうか。

すると、以前の「日本企業の強みであるモノづくり」というQCDと効率性を重視したビジネスモデルから、「市場に合わせてタイムリーなソフトウェアを提供していく」ソフトウェア開発中心のビジネスモデルに変わることになる。
「ソフトウェア・ファースト」本が言う通り、結局、QCDのスコープが確定した売り切り型のプロジェクト開発ではなく、SaaSをベースにして継続的な運用保守を前提としたアジャイル開発に取り組まざるを得ない。

よって、ビジネスモデルという経営戦略の変革を起点として、その戦略を活かす組織文化、マインドが必要になるわけだが、従来の製造業の生産管理をベースにした組織文化では、ソフトウェア開発になじまない点に苦労している。

そこで、トランスフォーメーションに対応するためのパターン・ランゲージ（略称トラパタ）のような道具を使って、会社にソフトウェアを開発しやすい組織文化を定着させるような仕掛けを導入しよう、という動機が生まれたのではないか、と想像している。

実際、トランスフォーメーションに対応するためのパターン・ランゲージ（略称トラパタ）の中身は、「未来への羅針盤」「共感は発信から」「多文化の架け橋」「自律自走する組織」「多様性が育む」などのパターンのように、ビジョンという共通目的の共有、メンバーに貢献意欲を植え付ける仕組み、メンバー同士のコミュニケーションの活性化、のような組織文化に関わる内容ばかりだ。
つまり、DXを実装するプロセス論や技術論よりも、組織文化の方を重要視している、と推測している。

個人的には、IPAがトランスフォーメーションに対応するためのパターン・ランゲージ（略称トラパタ）の読者層を誰に設定しているのか、が気になっている。
おそらく、本来は、DXを推進する経営層ないし経営トップがこのガイドを読んで、DXのリーダーシップを発揮してください、と言いたかったのではないだろうか。
なぜならば、新しい組織文化を定着させるには、そういう組織文化を取り入れて実現しよう、とトップ自らが汗をかき、リーダーシップを発揮して説明して、メンバーに影響させて、経営戦略のゴールに対し、それをブレイクダウンした目標をメンバーに提示し、メンバーに目標達成意欲を植え付けて焚きつける必要があるからだ。

そんな事を考えながら読んでみると、より一層真剣味が感じられるように思った。

scikit-learn「アルゴリズム・チートシート」のリンク

scikit-learn「アルゴリズム・チートシート」があるのでメモ。

【参考】
【機械学習初心者向け】scikit-learn「アルゴリズム・チートシート」の全手法を実装・解説してみた - Qiita

Scikit-Learn のチート・シートに沿って機械学習 ? FRONT

Choosing the right estimator ? scikit-learn 0.23.2 documentation

scikit-learnで機械学習のプログラムを書こうとする時、ライブラリが多いので最初は戸惑う。
このチートシートがあれば、ああ、この時はこのライブラリを使うのね、と参考になる。

scikit-learnにあるサンプルデータで遊ぶだけでも割と面白いね。
やりたいのは、データを元に、因果関係を推論して、新たな因果関係という経験則を生み出すこと。
そういう道具がPythonで簡単に揃って使えるのは面白い。
業務システムをデータモデリングで考えるのとは別の発想。