パターン言語

2020/12/31

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

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

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

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

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

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

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

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

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

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

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


| | コメント (0)

2020/12/30

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図書カード:シンデレラ

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

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

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

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

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

【3】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の肝はストーリーボードにあり

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

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

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

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

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

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

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

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

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

残りは次回に続く。

| | コメント (0)

2020/12/29

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

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

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

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

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

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

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

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

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

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

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

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

【参考4】
カスタマージャーニーマップとは? 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のおかげで、僕はユーザーストーリーの考え方を理解できたような気がした。

| | コメント (0)

2020/03/01

AWSクラウドデザインパターンの感想~RDP(Redmine Design Pattarn)の構想

「AWSクラウドデザインパターン」を読み直した。
以下、AWS初心者によるラフなメモ書き。

【参考】
AWS-CloudDesignPattern

【1】「AWSクラウドデザインパターン」本を買ったのは、2013年のデブサミの時だった。
玉川さんにサインを書いてもらった。
「Work hard, Have fun, Make history!」と。

あの頃はまだCDP(クラウドデザインパターン)理解しきれてなかった。
AWSに触れて、ようやくCDPの威力を理解することはできた。
ただし、CDPに記載されたAWSサービスは2012年頃の内容なので、Lambdaなどが含まれていないから、そういう最新のサービスで置き換えられる部分はいくつかある。

振り返ると、2010年代前半にCDP本が出たからこそ、AWSが日本に普及し始めたのだと思う。
CDPは、システムのアーキテクチャ設計、インフラ設計において、AWSのサービスや機能をどの場面で適用するとどんな効果が得られるのか、を明確に示唆してくれる。
クラウドによる設計や実装を試行錯誤していた頃に、CDPを用いることで、より良いクラウドによるアーキテクチャ設計が実現可能になったためだ。
また、アーキテクト同士で、クラウドによるアーキテクチャ設計について、共通の言葉を使って議論できるようになった。
そういうメリットがCDPにはあった。

CDPの形式はGOFのデザインパターンに似ている。
CDPの形式はもっとシンプルだ。
解決したい課題、クラウドでの解決、AWSによる実装、利点、注意点、その他の関連パターン、という項目で必要最低限に絞り込まれている。
CDPというカタログを読んでいくと、どのユースケースでは、どんなパターンを用いるとどんな利点があるのか、クラウドでの解決方針に沿ってAWSはどんなサービスや機能を提供してくれているのか、が理解しやすくなる。
実際に、オンプレのインフラ構築や運用で苦しんできた経験のある人ほど、AWSによる実装方法で、なるほど、と気づく場面が多いはずだ。

イントロの部分もすごく惹かれた。
AWS普及に心血を注ぐ3人が、ある居酒屋にて、クラウドを語る上で共通言語となるデザインパンターンのようなものが必要である、という議論が白熱し、その場で40種類以上のクラウドデザインパターン(CDP)の種をノートに書き出した、とある。
この文に触れて、クラウドの導入でつまずいているプロジェクトがあって苦労したり、オンプレの設計思想に囚われすぎてAWSの良さを活用しきれていない場面で歯ぎしりしたりしたのではないか、と勝手に想像した。
そういう経験を元に、CDPが生み出されたのだろう。

【2】そんなことを考えているうちに、Redmineデザインパターン(RDP)みたいなものが作れないだろうか、と想像したりした。
Redmineの導入・運用も既に10年以上の蓄積があり、必要な運用ノウハウはネット上にたくさん語られているし、運用で必要なロール(組織上の役割)もいくつか語られている。
しかし、そういうノウハウはバラバラに散らばっているに過ぎない。
それらを一つの体系として、暗黙知となっているものを形式知化することには意義があるはず。
なぜなら、まだ困っている人も多いだろうし、経験者が議論する時の共通言語はまだ暗黙知になっている部分が多いからだ。

僕も以前、チケット駆動開発のパターン集みたいなものを編み出そうと考えていた。
そのパターンの根底は、アジャイル開発にチケット駆動開発を適用するにはどんな考え方が必要なのか、があった。
でも、それから5年以上たち、今は情報システム部門の人達が一般ユーザに使ってもらう運用基盤に変化したので、異なるパターン集が必要になっていると思う。

今僕のアイデアとしては、パターンに4つほどのレイヤで階層化して詳細化できないか、と考えている。
イメージは、ユースケース層>マネジメント・ロール層>アプリ・機能層>ソース・実装層。
たとえば、ユースケース層では、課題管理・ソフトウェア開発・サポートデスクなどの実際の利用シーンでカテゴライズする。
マネジメント・ロール層では、Redmine職人・Redmineエバンジェリスト・Redmine警察のようなロール、PMxTMマトリクスのような組織への導入方法。
アプリ・機能層では、Redmineの各機能のベストプラクティス。たとえば、チケットのワークフロー、JAXAが生み出したカスタムフィールドやプロジェクトのOR・AND条件など。
ソース・実装層では、ViewCustomizeプラグインによる課題解決、プラグインやカスタマイズによる課題解決など。

このようにパターンをレイヤ化して区別することで、パターンの粒度を区別できること、初心者や経験者が会話できる共通言語を提供できること、というメリットがあると思う。
僕が以前考えていたパターンはアジャイル開発への適用に特化しすぎていたので、2020年現在の実情に合わせたデザインパターンを作れたらいいなあ、と考えた。


| | コメント (0)

2018/12/10

チケット駆動開発のアイデアがRedmineへ与えた影響は何か

この記事は Redmine Advent Calendar 2018 の12月25日分です。

Redmine Advent Calendar 2018 - Adventar

チケット駆動開発というアイデアがRedmineに与えた影響を改めて考察してみる。
以下はラフなメモ書き。

【1】チケット駆動開発の発端とは?

Redmineを導入運用する時、「チケット駆動開発」という言葉を使う場面がある。
既に、さかばさんがチケット駆動開発の由来と経緯について書かれている。

TiDD:チケット駆動開発: ソフトウェアさかば

必然から生まれたチケット駆動開発 - XP祭り関西2009 その3-: ソフトウェアさかば

チケット駆動開発の概念は、2007年にTracのチケット管理から生まれた。
その素朴なアイデアは、「チケット無しのソースコミット不可」「No Ticket, No Commit」。

2008年頃、そんなチケット駆動開発のアイデアをRedmineで試してみたら、XPに基づいたアジャイル開発に適用できることに気づいた。
そんな僕の経験を熱く語っていたら、さかばさんが「チケットはXPのタスクカードと同じ」と上手くまとめてくれた。
この言葉がヒントになって、Redmineによるチケット駆動開発を運用した時のPJ管理の技法、チームビルディングの技法に対し、既存の専門知識を片っ端から適用してみた。
たとえば、アジャイル開発、ソフトウェア工学、PMBOK、ITIL、品質管理、など。
そういうアイデアを専門知識で補強することで、より理解が深まる一方、理論はそのまま適用できず、効果を出すには前提条件や制約条件が色々あることにも気づいた。

【2】チケット駆動開発はどのように定義されているのか?

【2-1】Redmineでチケット駆動開発を実践した時のプロセスをフレームワーク化する試みは、下記から始まった。

脱Excel! Redmineでアジャイル開発を楽々管理 (1/5):エンジニアがお薦めする 現場で使えるツール10選(3) - @IT

【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」: プログラマの思索

【2-2】チケット駆動開発をアジャイル開発プロセスとみなした時の運用サイクルは以下になる。

1・プロジェクトで発生するタスク、課題、障害は、「XPのタスクカード」とみなし、全てチケット化する(Ticket First)。
チケットは作業指示書であり、課題管理票、障害管理票でもある。

2・それらチケットは、リリースするタイミングで、Redmineのバージョン単位にグループ化する。
Redmineのバージョンは、XPのイテレーション、Scrumのスプリントに相当する(Iteration is a version)。

3・リリースまでのPJ管理は、Redmineの優れたチケット集計機能、構成管理ツール連携機能でリアルタイムにモニタリングすることで実現する。
「No Ticket, No Commit」で、ソース修正履歴は全て、チケットで把握できる。

4・Redmineのバージョンの進捗が100%になったらリリースする。

5・リリース後、チームはふりかえりを行うし、顧客からの改善要望を収集して、次のイテレーション計画へフィードバックして再修正する。

【2-3】上記によって、チケット駆動開発によって明確になったプロジェクト運営のやり方は2つある。

一つは、プロジェクト内で発生するあらゆる作業や課題などをチケットに記録することで、プロジェクト運営はチケットのライフサイクルに置き換えられること。
もう一つは、RedmineバージョンをXPのイテレーション、Scrumのスプリントと同一視することで、Redmineのロードマップ機能は、長期のリリース計画と短期のイテレーション計画に置き換えられること。

つまり、プロジェクト運営の日々の作業は全てチケットでリアルタイムに追跡できるし、それらチケットはRedmineのロードマップ機能など数多くの優れた機能で、プロジェクトの長期の計画づくりにも使えるようになった。
すなわち、チケット駆動開発の概念をRedmineに導入することで、プロジェクト運営の全ての管理プロセスをコントロールできるようになるメリットがある。

【2-4】では、このメリットによって、PJ管理技法がどのように変化するのか。
僕がチケット駆動開発で運用した時に、プロジェクトリーダーとして一番意識したことは「チケットの取捨選択」だった。

プロジェクト運営では、日々数多くのチケットが発生し、計画当初のタスク以外に、納期までに収まらないタスクが発生する。
それらチケットを1つずつ精査し、対策を打ち、1つずつ潰していかなければならない。
見て見ぬふりして放置しても、悪い状況は何も変わらないから。

すると、ガントチャート保守という面倒な作業が必ず発生し、その作業に多大な管理工数を取られて、悪循環に陥る。
一方、チケット駆動開発では、ガントチャートは所詮、1個のビューに過ぎない。
ロードマップ、チケット一覧、カレンダー、かんばん、EVM、リソースヒストグラムなどのビューをチケット集計機能として実現できるし、それらでモニタリングすればよい。
1個のビューにこだわらず、必要な状況で必要なビューを使い、手を打てばよいのだ。

それら機能を使っていくと、バージョン単位にグループ化したチケット群を精査して、優先度の高いチケットから一つずつ潰していくようになる。
もちろん、それらチケットは時々刻々変わるが、Redmineの優れたチケット集計機能で把握できるので、プロジェクトリーダーの意思決定を支援できる。
すると、チケットを分割して次バージョンへ延期したり、捨てる意思決定が多くなると思う。
「直近の納期までに何が必要なのか」をプロジェクトリーダーに徹底的に考えさせる基盤をチケット駆動開発は提供してくれるからだ。

つまり、PJ運営を「チケットの取捨選択」というミクロな意思決定に落とすことが、実はマクロな観点のPJ運営を実現しているわけだ。

【3】チケット駆動開発の具体的な特徴は何か?

チケット駆動開発をRedmineで実装すると、下記の3つの特徴が見えてくる。

チケット駆動開発の戦略: プログラマの思索

【3-1】Redmineの優れた構成管理連携により、要件からソースコードまでのトレーサビリティのインフラが整う。これにより、Redmineは本来の(真の)構成管理ツールとして実現される。

「チケット無しのコミット不可」の運用ルールにより、チケットとソースが密関係で相互リンクされる。
つまり、チケットが作業指示書であれば、チケットを発生させた要件や仕様書からソースやビルドモジュールまで、相互にリンクで遷移でき、追跡可能になる。
よって、要件からビルドモジュールまでのトレーサビリティを理論上は実現できる。

過去のソフトウェア工学の書籍を読むと、トレーサビリティの重要性は謳っているが、その実現方法はExcel台帳でソースやバージョンを管理するなど非常に面倒に思えた。
他方、Redmineであれば、事実上、トレーサビリティを実現できる「真の」インフラになりうる。

また、Redmineはツール連携できるI/Fを持っているので、GitやJenkinsなど数多くのツールと連携すれば、「プロジェクト管理サーバー」なるものを実現できる。
つまり、PMBOKの言う「PMIS(プロジェクト管理システム)」を初めて実現できる。
僕は、PMBOKが目指していたものは、たぶん、こういうインフラが前提であって初めて理解できるのではないか、と思った。

そして、このアイデアは、ソフトウェアプロダクトライン(SPL)にもつながっていく。

さらに、チケット管理システムはソース管理と同じように、作業のUnDo、ReDoを行う為のリポジトリとみなすこともできる。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

【3-2】Redmineの優れたワークフロー管理機能により、プロジェクト管理のフレームワークへ昇華・汎用化できる。

Redmineのワークフロー設定画面が意味するものは、三位一体論だ。
つまり、業務フローというアクティビティ図、ワークフローの状態遷移図、ワークフローの状態遷移表という3つの機能は、Redmineの1つの機能として実現される。

よって、PJ運営に出てくる全ての業務フロー、開発プロセスは、事実上、Redmine上で全て実装できる。
このアイデアにより、Redmineでは、WF型開発も、Agile開発も共存して運用できるメリットが出てくる。
もちろん、PMBOK、ITIL、サポートデスク、会議体管理、PC資産管理など、ソフトウェア開発以外の業務にも適用できるようになる。
ここが、Redmineの運用で一番面白く、そしてホットな部分だろうと思う。

【3-3】チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

Redmineに蓄積された過去の大量のチケットは、データマイニングの宝庫だ。
PMOや品質保証部にとって、ソフトウェア工学のメトリクスを実際に研究できる元ネタになりうる。
信頼度成長曲線というメトリクスも、こうやって作るのか、ということも初めて体験できた。

しかし、実際は、チケットの内容が詳細に記載されていないと、なかなか理論通りのメトリクスが得られないことも分かった。
他方、PMBOKのEVMやリソースヒストグラムは、こうやって実装できるのか、ということも体験できた。

チケットと言う一つのデータが蓄積できれば、PJ管理で使われるビューのうち、既存の理論をRedmineで簡単に実装できる。
さらに、Redmineは柔軟でカスタマイズしやすい特徴を活かせば、新たな観点のPJ管理のビューを生み出す可能性があるはずだ。

【4】チケット駆動開発で最も面白い特徴は、「チケットはストックとフローの二重性を持つ」ことだ。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索


Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

チケットはタスクカードであるから、フローとして流れる「流通媒体」。
一方、チケットは障害管理票、課題管理票でもあるから、ストックとして蓄積される「記憶媒体」でもある。

この2つの特徴が混在しているので、チケットの粒度を標準ルールでガチガチに定めるのは難しくなる。
なぜなら、流通媒体のチケットは細かくなるし、記憶媒体のチケットはどうしても大きくなりがちだから。

また、1つのチケットという実体は、ステータスが変更されるたびに、流通媒体と記憶媒体に性質が変わる特徴も持つ。
たとえば、タスクのチケットはフローとして流れるが、途中で仕様変更やらソース修正の内容など、ストックの内容が蓄積される。
他方、障害管理票のチケットは、当初は障害内容や対策を詳細に書いてストックとして蓄積されるが、テスターと開発者の間でやり取りする時、チケットはフローとして流れる。
そのおかげで、チケットはキャッチボールのような雰囲気になる。

つまり、チケットは障害や仕様変更の内容をストックして持つ一方、チケットで進捗管理でき、ワークフロー設定に沿って変更管理が自然に行われる。
すなわち、チケットは、データマイニングの元ネタやナレッジ基盤となる「記憶媒体」の側面と、進捗管理や変更管理などを回す「流通媒体」の側面が既に埋め込まれている。
よって、チケットの粒度に悩むよりも、このチケットの二重性を意識して運用したり、その特徴を活かすように知恵を絞る方が良いと思っている。

【5】チケット駆動開発の今後の課題は何か?

課題は3つあると思う。
一つ目は、チケットの粒度、チケットの完了条件について、考え方を整理すること。
チケットの粒度は、ソフトウェアの本質的な複雑性に由来すると考えているので、それを逆手に取って、ソフトウェアの本質をチケット駆動開発で探ることもできるはず。

チケット駆動の罠~複雑さはチケットの粒度に関連している: プログラマの思索

TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine: プログラマの思索

チケットの粒度と進捗ビューの関係: プログラマの思索

2つ目は、チケット駆動開発で実装できるプロセス基盤の種類を整理し、それらプロセスの特徴・メリット・デメリット・プラクティス・アンチパターンを明確にすること。
たとえば、WF型開発、Agile開発、PMBOK、ITIL、サポートデスク、PC資産管理、など。

Redmineが今後発展する方向のアイデア: プログラマの思索

Redmineが今後発展する方向のアイデアpart2: プログラマの思索

3つ目は、チケット駆動開発と組織の関係を整理し、「組織がチケット駆動開発をどのように複雑化させるのか」「チケット駆動開発は組織にどんなメリットをもたらすのか」を明確にすること。

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT: プログラマの思索

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響: プログラマの思索

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影: プログラマの思索

Redmineとチケット駆動開発は表裏一体と思っているので、Redmineを使うことで、色んな実験ができると思う。
それらアイデアを試してみたい。


| | コメント (0)

2016/12/05

AgileTourOsaka2016の感想~エバンジェリストは市場を作る人である

AgileTourOsaka2016に行ってきた。
知り合いも多くて居心地の良い場だった。
感想をラフなメモ書き。
メモを殴り書き。

【参考】
Agile Tour Osaka 2016 2016年12月3日 - こくちーずプロ(告知'sプロ)

現場の経験知をパターン言語にするコツが分かった #agileto2014: プログラマの思索

【公開】AgileTourOsaka2010講演資料 "Why Ticket Driven Development is Agile? : No Ticket, No Commit!" #agileto2010 #tidd: プログラマの思索

パターンを使うもう一つの動機~パターン言語の構築よりも設計・実装・運用のノウハウをカタログ化する: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

【1】パターンの中で「デザインパターン」は最も有名だが、「デザインパターン」の最初に「これはパターン言語ではない」とはっきり述べている。
パターンとパターン言語は違う。

パターン言語は、もっと広い概念。
パターン言語は、全体性が特徴、と原田さんは言う。

【2】Scrumパターンは、「組織パターン」から生まれた。
7年経った今もなお作成中。
来年に完成すればいいね、という感じだね、と。

Scrumパターンを見ると、「防火壁」はスクラムマスター、「顧客の代弁者」がプロダクトオーナー、「ワークキュー」はバックログ、「スタンドアップ・ミーティング」はデイリースクラムという概念が自然に出てくる。
組織パターン」から、プロダクトオーナー、スクラムマスター、プロダクトバックログの概念が生まれた。

Scrum Patterns : スクラムを構成する要素を分解し、組織パターンに対応づける - kawaguti’s diary

Scrumパターンは、パターンがつながっていて、一つの言語(ランゲージ)になっている。
つまり、パターン名を言えば、パターンの発生源となる問題や背景が自然に出てきて、人々で共有される。
パターンで問題解決されると、新たな課題が発生し、別のパターンが使われる時もある。

【3】アンチパターンはパターンなのか?
アンチパターンはパターンではない。
アンチパターンはパターンのコンテキストを表すものでしかない、と。

【4】パターンはベストプラクティスではない。
パターンは「Good practice」である、と変えた、と。

【5】パターンの中で、Forceを書くのが一番難しい。
Forceは、パターンの背後にある、利害関係者の力の衝突を表す。
たとえば、プロジェクトが遅延しているから作業方針を変更したいのに、マネージャが駄目だ、と拒否権を発動する場合、とか。
Forceはトレードオフを表す。

だから、パターン、コンテキスト、ソリューションを書くのを勧めている、と原田さんは言う。

この意見には、僕は違和感を持っていて、別の意見を持っている。
むしろ、経験者はForceから書き出した方がいいのではないか、と思っている。

実は、午前のプレセッションで、パターン・ワークショップがあり、Scrum道関西で有名な山本雄一郎さんたちと同じチームで、パターンを洗い出そうとしていた。
すると、僕も山本さんも、いきなりパターン名やソリューションを出したものの、そこから話が進まない。
コンテキストや問題がメンバーの間で違うので、議論が発展せず、深掘りされなかった。
結局、時間切れで、僕らのチームは、パターンを作り出すこともできなかった。

プロジェクト運営の経験があり、何らかの問題に対して自分なりのソリューションを持っている人は、パターン名らしき概念を既に持っている。
そんな場合、パターン名やソリューションを書き出した後、そのソリューションが使われる背景(コンテキスト)や、Forceのような力関係を洗い出し、そこから、もっと他のソリューションがあるのでは?、他の問題が出てくるのでは、という方向へ議論しても良かったのでは、と後で感じた。
なぜなら、自分が持っているソリューションのコンテキストを説明しようとすると、過去の案件ではこんな対立があった、とか、以前のチームではこんな人間関係があって対立していた、と言う内容を説明しやすくなるからだ。
経験者が持っていたリアルな現場感を伝えるために、Forceを使うわけだ。

なお、原田さんからは、もっとパターンを抽象的にしたら、というアドバイスをもらった。
その意味を考えると、ソリューションにこだわりすぎて、パターンというもう一つ上のレベルへ抽象化できなかったのではないか、と思う。

【6】チームでパターンを作った後、どうするか?
チームで、あるノウハウに名前(パターン)が付くと、良い傾向。
チーム内の良い習慣を、パターンで共有できる。

「おやつ神社」と言えば、日本人なら分かるでしょ?
ふりかえりミーティングでは、お菓子を持ち寄り、くつろいだ雰囲気を醸し出す、と。

僕も、チケット駆動開発のプラクティスをパターンとして表現できないか、狙っている。
今、日本各地でRedmineエバンジェリストの役割を担う人達が出現しているので、彼らのノウハウをパターンという名前で具体化して、皆で共有できるようにしたいのだ。

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT: プログラマの思索

つまり、皆がバラバラに持っているノウハウをパターンとして抽出して、パターンカタログのような形式でまとめたい。
パターンはカタログではない、という意見があるのは重々承知だが、ボトムアップで経験知を整理して、誰もが共有できる形式知にしたい。

【7】その意味では、欧米人はネーミングが上手い。
同じような概念を時代に合わせて再パッケージングして、いかにも新しい流行のようなワードを作り出し、世の中に広めている。
アジャイル開発やXPのプラクティスは以前から知っていた、と日本の年上の技術者は誰もが言うが、僕ら若手はそんな技術はつゆ知らず、むしろ、アジャイル開発やXPを知って、すごく興奮した。

似たような例はたくさんある。
日本の製造業の品質管理(TQM)に対するシックスシグマ、トヨタ生産方式に対するリーン生産方式、ソフトウェア再利用の設計に対するマイクロサービスアーキテクチャ、とか。

日本から独自のパターンを生み出せないか?

【8】長沢さんに、エバンジェリストはどんな役割なのか、を聞いた。
彼の回答は明確で、「エバンジェリストは市場を作る人である」と。
僕のイメージは、エバンジェリストはツールや製品を宣伝する人と思っていたから、その固定観念を打ち砕かされて、しびれた。

また、キャズム理論や製品プロダクトライフサイクル理論では、市場の立上げ・成長期・成熟期・衰退期に応じて、イノベータ、アーリーアダープター、マジョリティ、ラガードなどの市場参加者の種類がある。
その中で、エバンジェリストは新しい製品を市場に導入して、パイを広げるべきと思っていたから、イノベータやアーリーアダープターに専念すべきと思っていた。

しかし、長沢さんによれば、エバンジェリストは市場の全体の人達にフォーカスする。
特定の人達にフォーカスするのではない、もっと広い層の人達に伝えるべき、と。

さらに、ツールや製品にこだわるべきではない。
一段上のレベルで話をすべきである。
ツールや製品は流行り廃りがある。

エバンジェリストは新しい技術の動向を伝えるだけでなく、それによって市場を拡大するように、方向性を示すべき、と。
だから、自分は、マイクロソフトやアトラシアンの製品だけにこだわってはいない、アジャイルやプロセスの話をしている。
RUPの頃から何も変わっていない、RUPにも既にアジャイルやDevOpsの萌芽はあった、と。

【追記】akipiiさんのツイート: "長沢さんの言葉、エバンジェリストはマーケットと言う市場を創造する人だ、にすごく痺れた経験があった。カッコいい。RT @MadoWindahead: #redmineeva としての指針にもなりそう ーー私のエバンジェリストとしての矜持 | 長沢智治のブログ… https://t.co/xuqgmnp1tl"

私のエバンジェリストとしての矜持 | 長沢智治のブログ

売り物のためでなくマーケットのためのマーケティング | 長沢智治のブログ

| | コメント (0)

2015/08/25

「ビヨンド ソフトウェア アーキテクチャ」は買い?

ビヨンド ソフトウェア アーキテクチャ」がもうすぐ販売されるのでメモ。
興味がそそられる。

【参考】
ビヨンド ソフトウェア アーキテクチャ(LukeHohmann 岡澤裕二 和智右桂) | 翔泳社の本

おおお『Beyond Software Architecture』訳されたのか! これはとても良い本でした。 - t-wada のコメント / はてなブックマーク


(引用開始)
「アーキテクチャ」について技術的な観点から書かれている本は数多くありますが、ビジネスの視点からシステムを商品として見た時に考えるべきことを教えてくれる本が、実はありませんでした。
本書は、アーキテクチャにおけるビジネス(マーキテクチャ)と技術(ターキテクチャ)をつなぐ架け橋として、情報システム部の方全員に読んでほしい本(情シス必読書)です。
エンジニアにとっては、マーケティングの基礎を学ぶ上でも役に立ち、かつ、技術面でのアーキテクチャ論としても、経験豊富な著者の実体験に根ざす優れた考察に富んだ一冊となっています。

原書は2003年にMartin Fowlerシグネチャシリーズの一冊として刊行されました。Jim Highsmith、Mary Poppendieck、Ed Yordon、Craig Larman他から多数の賛辞が寄せられています。著者のLuke HohmannはOOPSLAやUML Worldの常連スピーカーとして、QUALCOMMなどを経て現在はConteneo,Inc.のCEOに就いていますが、それ以前には全米フィギュアスケート選手権のジュニアチャンピオンでもあった異色の存在でもあります。

最後に、訳者より一言「情シスの方はアジャイルやスクラムもよいですけど、こういうアーキテクチャのこともきちんと考えてみませんか?」
(引用終了)

(引用開始)
目次

第1章ソフトウェアアーキテクチャ
第2章プロダクト開発入門
第3章マーケテクチャとターキテクチャ
第4章ビジネスとライセンスモデルの共益関係
第5章インライセンステクノロジー
第6章可搬性
第7章デプロイメントアーキテクチャ
第8章統合と拡張
第9章ブランドとブランド要素
第10章ユーザビリティ
第11章インストール
第12章アップグレード
第13章コンフィギュレーション
第14章ログ
第15章リリース管理
第16章セキュリティ
補遺A:リリースチェックリスト
補遺B:戦略的プロダクトマネジメントのためのパターン言語
(引用終了)

本棚を見返すと、和智さんの翻訳本はほとんど購入している。
エリック・エヴァンスのドメイン駆動設計」「組織パターン」「エッセンシャル スクラム」「実践テスト駆動開発」然り。
どれも分厚くて、何度も読み直して咀嚼し直すたびに、新しい発見がある。

今度の本もすごく楽しみだ。

翻訳された本の分野を見ると、アーキテクチャ設計やアジャイル開発にフォーカスされている。
僕が興味を持っている分野にドンピシャリだなと思ったりする。

ビヨンド ソフトウェア アーキテクチャ」でググってみると、下記のPDFが見つかる。
目次がそっくりなのだが、関係あるのかな?

/ - alimnova - Grupo de trabajo ingenieria de software - Google Project Hosting

| | コメント (0)

2014/10/13

【告知】第7回redmine.tokyo勉強会を開催します~テーマはRedmine利用時のアンチパターン

2014/11/15土にredmine.tokyo第7回勉強会を開催します。

【元ネタ】
第7回勉強会 - redmine.tokyo

第7回redmine.tokyo勉強会 - PARTAKE

第7回redmine.tokyo勉強会 懇親会 (夜の部) - PARTAKE

(引用開始)
shinagawa.redmine あらため、redmine.tokyo の第7回勉強会を開催します。

Redmine利用時のアンチパターン、システム統合事例、新バージョン情報の他、LTを予定しています。

また今回、実験的にオープンディスカッション形式のセッションを行います。
申し込み時のアンケートで下記について意見を募集していますので、ぜひご回答ください。

1.Redmineをどのような用途で使っていますか。またはどのような用途で使えることを期待しますか?
2.Redmineを使ってみた上での問題点、または、これからの利用を考えるうえでの懸念点。

日時
2014/11/15(土) 13:00~

場所
東京都品川区大崎1-2-2 アートヴィレッジ大崎セントラルタワー15F

Twitterハッシュタグ
#redmineT
(引用終了)

【1】私は、以下の内容で講演します。

タイトル:「RedmineのFAQとアンチパターン集【2014年度版】(仮)」

概要:
プログラマ上がりのプロジェクトリーダーは、チーム運営やプロジェクト運営の経験が不足しているため、Redmineのチケット駆動運営が上手くいかない状況が時々あります。
その原因の一つは、チームや案件の制約条件の違いによって、チケット管理を微妙に変えて運用することに気付かなかったこともあります。
今回は、自分の経験談を元に、チケット駆動開発のアンチパターンを説明します。

【2】講演の目的とねらい

おかげさまで、「Redmineによるタスクマネジメント実践技法」は4年経った今でも出版されています。

さかばさんはTwitterを使っています: "おかげさまで増刷(第7刷)が決定しました。累計部数は9,500部。ヒット作品まで、あと一息です。/ 小川 明彦 の Redmineによるタスクマネジメント実践技法 http://t.co/PxuwT2uFxQ"

私は、Redmineで初めてアジャイル開発を実践し、チケット駆動開発という開発プロセスを定義しようと色々模索していました。
そして、Redmineが今後発展する方向のアイデア: プログラマの思索にも書いたように、6個のテーマを今も思索しています。

【2-1】アジャイル開発への適用
【2-2】チケット駆動開発のプラクティス集 or パターン言語
【2-3】Redmine運用のアンチパターン集
【2-4】Redmineの運用パターン集
【2-5】開発基盤としてのRedmine
【2-6】メトリクス収集ツールとしてのRedmine

今回の勉強会の発表テーマは、【2-3】Redmine運用のアンチパターン集の続きです。
2011年に第1回RxTStudy勉強会で発表した時は、「空っぽのロードマップ」「停滞したチケット」「工程単位のバージョン」などのように、Redmineを入れたのにアジャイル開発の良さを発揮できないアンチパターンを紹介しました。

当時の発表資料「RedmineのFAQとアンチパターン集」はいつの間にか、5万ビューを超えるスライドになってました。
おそらく、紹介したアンチパターンは、皆さんの琴線に触れる場面があったのでしょう。

一方、2014年の第7回redmine.tokyo勉強会では、以前はアジャイル開発の観点を中心に据えたのに対し、今回はチームの規模や案件の種類の観点での失敗事例を集めてみました。
具体的には、以下の観点で、自分の経験談を含めて、アンチパターンを紹介したと思います。

・5人の小規模チーム x 20人の複数チーム
・自社開発 x オフショア開発
・大規模な受託開発案件 x 小規模な保守案件

| | コメント (0)

2014/10/11

現場の経験知をパターン言語にするコツが分かった #agileto2014

AgileTourOsaka2014に参加してきた。
テーマは「パタン特集」。
パターン言語とは何か、現場の経験知をパターン言語にするコツが分かった。
とても有意義な勉強会だった。
ラフなメモ書き。

【元ネタ】
10月11日 AgileTourOsaka2014

Agile Tour Osaka 2014でパタン・ランゲージのワークショップを担当しました

AgileTourOsaka2014 #agileto2014 のまとめ - Togetterまとめ

KenColle/AutomationPatternLanguage

パターンを使うもう一つの動機~パターン言語の構築よりも設計・実装・運用のノウハウをカタログ化する: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

「アジャイルに効く アイデアを組織に広めるための48のパターン」の感想~エバンジェリストが自分のアイデアを組織に導入する時に役立つパターン集: プログラマの思索

チケット駆動開発のナビゲーションマップ #Redmine: プログラマの思索

以下、勉強会のログを書いておく。

【1】パターン名は解決策である。
名前は体を表す。
パターン名が解決策とその問題を連想させるのが良いパターン。
パターン名からピンとこなければ、良いパターンとはいえない。
解決策をパターンの名前にする。
パターン名から、すぐに行動を起こせるかどうか。

懸田さんのワークショップでは、いかにダイエットして健康的な生活にするか、というテーマでパターン言語にする話。
各チームでパターンを作ってみると、「エクストリーム通勤」などメッセージ性はあるが、だからどう行動するのか、分かりにくいパターンが多かった。

【2】アンチパターンは状態を表す。
アンチパターン名は、問題を表す。
解決策ではないから、アンチパターンはパターンではない。

アンチパターンは、パターンの結果文脈に含まれるべきもの。
つまり、パターンを適用した結果、フォース(力の衝突、利害関係者からの圧力の衝突)は解決されたが、その結果が良い場合もあれば、予期しない副作用やリスクが出てくる時もある。
その時にアンチパターンが出てくるだろう。
例えば、パターン病の人のように、何でもかんでもパターンを適用してみたら失敗した、という時もアンチパターンに含まれるだろう。

例えば、テスト自動化パターン言語では、パターンとアンチパターンが関係付けられていたが、本来はアンチパターンは必要ない。
アンチパターンは、パターンの結果文脈の一つにすぎないから。

【3】フォースとは、力の衝突。
パターンは、利害関係者の力の衝突を解決するのではなく、「力の衝突をいなす」だけ。
パターンを適用した結果、良い結果になる時もあれば、副作用が起きて別のリスクや課題が出てくる時もある。

その時は、別のパターンを当てていく。
パターンは、現状をいきなり変えるのではなく、漸進的に変えていく。

【4】パターンはスケールしていく。
パターンはツリー構造ではない。
セミラティス構造、つまりネットワーク構造。
地形、建物、オブジェ等の場をネットワーク構造でパターンをつなげる。

スケールとは、パターンの一種のカテゴリ(?)

例えば、アレクサンダーの建築パターンは、大中小の3種類のスケール。
大:地形、環境、場所
中:出来事、行動、習慣
小:道具、ツール

例えば、デザインパターンのスケールは、生成・構造・振る舞いの3種類。

スケールには2種類ある。
時系列という横軸、利害関係者の人数という縦軸。

時系列にパターンを関連付けると、シーケンスのパターンになる。
例えば、テスト自動化のパターン言語がその例。
自動化開始→自動化導入→普及・終焉という時系列でパターンを関連付けているので、すごく理解しやすい。

では、テスト自動化パターンでは、スケールを成熟度別にできないか?
CMMIみたいに。
例えば、あるパターンを適用してアンチパターンが出たならば、それはレベル1。
そのアンチパターンを乗り越えたら、レベル2のように、成熟度別にできないか?

スケールは一つだけではうまくいかない。
幾つかのスケールを組合せると良くなる。
例えば、XPがまさにそう。
XPの12個のプラクティス単体では、品質や効率化について何も触れていないが、それらのプラクティスを全て実行すると、初めて、高品質で効率の良い開発が生まれる。(生成される)

例えば、スクラムパターンは組織パターンの一種。
スクラムパターンでは、スケールを時系列(リリース>スプリント>デイリー)でも分けるが、利害関係者の規模でも分けている。

EnterpriseArchitectureは、ツリー構造かつ階層化しているが、失敗した。
ビジネス向けシステムをアーキテクチャをビジネス・情報・アプリケーション・データに階層化したが、階層のつながりや組合せの方法が具体的に書かれていないので、苦労している。

【5】パターンは、最重要な基本的なパターンからスケールの単位で派生していく。
基本的なパターンは「センター」と呼ばれる。

例えば、組織パターンでは、「信頼された共同体」を起点として、他のパターンが派生していく。
例えば、「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」では、「エバンジェリスト」を起点として、他のパターンが派生する。

例えば、リーンスタートアップでは、MVPを中心に、プロダクトを洗練させていく。
途中で、ピボットで方針を変えたり、Build→Measure→Learnでプロダクトを進化させていく。

【6】パターン言語とは、関係者で紡ぎ合う物語。
基本的なパターンから派生したパターンを関連付けて、絵日記にしてストーリー化すると、パターン言語になる。

いつ、どこで、誰が、どんな問題を抱えていて、パターンを適用して、解決して、どんな結果になったのか。
絵日記というストーリーに、パターンが言語として自然に組み込まれる。

例えば、「ドメイン駆動設計」では「ユビキタス言語」パターンでは、「声に出してモデリングする」という解説がある。
ドメインをチームの言語とするには、モデリングした結果を声に出して、チーム全員で情報共有して理解できるまで、噛み砕く。

【7】プロジェクト・ランゲージは、場に適した実現可能な戦略。
パターン言語をあるドメインに適用した戦略。
具体的なプロジェクトに、パターン言語を適用し、パターンがドメイン特有の文脈やフォース、問題に適用できるか、検証し、その結果をパターン言語にフィードバックし、洗練させていく。

例えば、ソフトウェア開発のそれぞれの現場に対し、一つのストーリーであるパターン言語を適用してみて、その現場特有のドメインに適用できるようにパターン言語を改善していく。
その結果をパターン言語へフィードバックし、パターン言語を洗練させていく。

パターンは仮説。
パターンは実現したいイメージ。

パターン言語やプロジェクト・ランゲージを評価検証する時、その評価基準は、感情をモノサシにする。
パターンを適用した結果、楽しいですか?
パターンは、そのコンテキストやフォースにしっくりきますか?
パターンを適用した結果、なぜそう感じるのか?

最終的には、QWAN(無名の質)につながる。

【7-1】パターンは成長すべき。
アレクサンダーのパターン言語は「A Pattern Language」。
つまり、不変なパターン言語ではなく、アレクサンダー個人が見つけたパターン言語。
皆のパターン言語を集めて、洗練させて、一つの体系にできれば「The Pattern Language」になる。

俺のパターンが皆のパターンへ変わる。
だから、皆も自身でパターンを作ってみよう。

アレクサンダーの建築パターンは、「人の集まる場所」に注目している。
人が集まれば、コミュニケーションが生まれ、コミュニティが形成されていく。
コミュニティという場で、住民が自分たちの街を少しずつ漸進的に改善していく。

【7-2】小林さんの話。
伊丹市内を散策した時、鉄の柵と竹の柵があった。
どちらのほうが良いのか?
普通は、竹の柵は壊れやすく、鉄の柵の方が長持ちするから、鉄の柵の方が良い。

しかし、鉄の柵は、業者に頼まないと修理できない。
一方、竹の柵は住民が修理しやすい。
住民が竹を取ってきて、すぐに自身で改善できる。

良いパターンは当たり前な概念。
でも、言葉になっていない。
だから、パターンは暗黙知を見える化する。

【8】XPは場の設計を重視している。
「朝会(デイリースタンドアップ)」は組織パターンから出てきた。

XPは全体を重視している。
技術だけのプラクティスでは不足。
コミュニケーションだけのプラクティスでも不足。

XPは比較的広い観点で作られた、プロセスのパターン言語。
プラクティスを分離して、単体だけでは考えられない。

パターン指向リファクタリングは、パターン病という病気も生み出した。
リファクタリングにデザインパターンを適用しなければならない、というバイアスがかかった。

パターンはフォースをいなすだけ。
フォースを変えない。

アジャイルプラクティスはパターン言語か?
アジャイルコミュニティはパターンコミュニティの人達から生まれた経緯を考えれば、多分Yes。

【9】「パターンが生成的である」とはどういう意味か?

例えば、XPやアジャイルのプラクティスがそう。
技術的なプラクティスやコミュニケーション、チームビルディング、ファシリティに関するプラクティスを全て実践した結果、高品質で短納期の製品が作れる。
単体のプラクティスだけでは、品質や納期、効率化の効果は現れない。

XPのプラクティスはカッコイイ。
パターン名にメッセージ性がある。

例えば、「ドメイン駆動設計」の「ブレイクスルー」が、パターンが生成的になった結果のタイミングに相当するだろう。
つまり、モデルのあるべき姿は分からないが、モデルを綺麗にして分かりやすくしたい、という気持ちを持ってリファクタリングし続けると、ある時点で、急にモデルの見通しが良くなる。
それがブレイクスルー。

【10】自分の経験から、パターンにできるか?
パターンにするには、同じような状況で、3回パターンを適用して経験しているか?

繰返し性からパターンが生まれる。

パターンは難しい。
自分で、しょぼいパターンを書いて初めて分かった、と。

だから、シェパーディングで、ペアになってパターンを書いて評価してもらうと良い。
レビューアとレビューイの役割と同じ。
パターンのフィードバックをしてくれる。
構造的に見てくれる。
状況が分からない、フォースが分かりにくい、など、的確なアドバイスがもらえる。

【11】僕の感想:

たくさん刺激を受けた勉強会だった。
チケット駆動のパターンを未完成にしたからテスト自動化のパターン言語を見た時はやられたと思った笑。

テスト自動化のパターン言語は、ちゃんと時系列に関連付けられて、時系列の観点のスケールで区別されている。
また、一つのストーリーで、パターンやアンチパターンが語られている。

そういうストーリーを聞くと、そうそう、テスト自動化ではそんな落とし穴があるよね、せっかく自動化を頑張ったのにいつの間にか保守されなくなるよね、など、共感できる。
正直、すごいなーと思った。

KenColle/AutomationPatternLanguage

過去に僕が書いたチケット駆動のパターン言語は以下の通り。
テスト自動化パターン言語に比べれば、ナビゲーションマップまでストーリー化できておらず、中途半端だ。
まだアイデア段階にすぎない。

チケット駆動のプラクティスをナビゲーションマップに試しに書いてみたが、ストーリー化できておらず、パターン言語にはなっていない。

それが今後の課題。
チケット駆動のプラクティスもパターン言語で体系化して、広めたい。
アジャイルの現場、WF型開発の現場、大規模な受託案件の現場、小規模な保守案件の現場、など、色んなプロジェクトランゲージを作り、最終的なパターン言語としてストーリーを作り、皆が暗黙知として認識しているプラクティスを明示したいのだ。

【追記】
Agile Tour Osaka 2014でパタン・ランゲージのワークショップを担当しましたの記事の一節をメモ。

(引用開始)
日本におけるパタン・ランゲージの第二次隆盛がきている?

私のワークショップ後に、@Posauneさんがテスト自動化のパターンランゲージの発表されていました。

この発表を聞いていて感じたのは、自分達でパタンをまとめ、Githubに置いてフィードバックをもらえるようにして、どんどんコラボレーションし改善していく、これこそまさに、数年前から構想していて(未だ心が折れてできていない)現場パタン構想(GembaPLoP)のひとつの現れなのかしれない、ということです。

他にもチケット駆動のパタン・ランゲージを@akipiiさんがまとめているという話も聞きました。
(引用終了)

懸田さんの別資料もリンクしておく。


| | コメント (0)

2014/08/24

第10回ドメイン駆動設計勉強会の感想 #dddosaka

第10回DDD勉強会で議論した内容をメモ。
自分が理解できたことだけを書いておく。

【参考】
第10回ドメイン駆動設計(DDD)読書会@大阪 - ドメイン駆動設計(DDD)読書会@大阪 | Doorkeeper

dddosaka/reading_ddd_report

第7回ドメイン駆動設計勉強会の感想 #dddosaka: プログラマの思索

第6回ドメイン駆動設計読書会の感想: プログラマの思索

第4回ドメイン駆動設計読書会の感想: プログラマの思索

ドメイン駆動設計に出てくる「モデル」とは何ですか?~第28回関西IT勉強宴会の感想: プログラマの思索

ドメイン駆動設計の感想~OOAは過ぎ去りDOAはもう一度舞台に上がるのか: プログラマの思索

ドメイン駆動設計は設計のアジャイル化~オブジェクト指向設計の先祖返り: プログラマの思索

いまさら「ドメイン駆動設計」を読み終えた - 勘と経験と読経

【1】15章「汎用サブドメイン」「隔離されたコア」

コアドメインは、ソフトウェアプロダクトラインのコア資産とほぼ同じ。
蒸留は、コア資産抽出の作業と同じ。

コア資産こそがそのモデル、そのシステムの中核となるドメインの塊。

すると、そのコアドメイン(コア資産)から、補助的な役割を持つドメインを分離して、コア資産の凝集度を高めることが重要になってくる。

【1-1】補助的な役割を持つドメインはいくつかある。
一つは、汎用ドメイン。
たとえば、フレームワークなどの開発基盤、アナパタやリファレンスモデルのようなモデルテンプレート、自動テスト、共通関数など。
ドメイン駆動設計」の例では、タイムゾーンモジュールがあった。

他にも、会計や物理学は既にモデルとしてテンプレート化されているため、汎用サブドメインの範疇になる。

【1-2】他には、隔離されたコア。
ドメイン駆動設計」の例では、P.437にあるように、輸送パッケージから、配送<<コア>>と物流、顧客、金銭<<汎用>>のドメインに分離していている。
コアドメインが配送<<コア>>であり、隔離されたコアが物流、顧客、汎用サブドメインが金銭<<汎用>>に相当する。

責務駆動設計の観点では、以下の点で整理される、という話もあった。

・配送<<コア>>:コアドメイン。実績に相当。「業務」に相当。
・顧客、物流:隔離されたコア(補助的なサブドメイン)。計画に相当。「能力」「潜在能力」に相当。

【1-3】「ドメイン駆動設計」を読んで面白いのは、「汎用サブドメイン」「隔離されたコア」 の注意点やリスクが興味深いところ。

汎用サブドメインは共通関数やモデルテンプレートが該当するので、開発チームの中で優秀なメンバーが割り当てられやすい。
すると、技術系の人間ほど、タイムゾーン変換や物理学のような限定可能な問題を楽しむ傾向があり、そういう問題に時間をかけすぎてしまう。
本来ならば、コアドメインの開発に注力すべきなのに、2級レベルの開発者をアサインして、プログラムがあまりきれいでない状況になってしまいがち。

また、XPのようなアジャイル開発では、アーキテクチャスパイクやゼロリリースのように、初期のイテレーションで、技術的アーキテクチャの妥当性を証明するように、補助的な汎用サブドメインを扱う周辺システムを構築したがる。
しかし、これでは、本来のリスク管理にはならない。
コアドメインを少しずつ作っていき、ドメインモデリングのリスクを下げていく方向に進まないから。

それゆえ、初版のシステムは、単純であってもコアドメインの一部を作らなければならない、と主張している。
この点は同感。

【1-4】また、「隔離されたコアを切り出すタイミングは、システムにとって重要な、巨大な境界づけられたコンテキストがあり、モデルの本質的な部分が大量の補助機能のせいでわかりにくくなった時」と「ドメイン駆動設計」に書かれているが、そのタイミングでは手遅れではないか、という質問もあった。

確かに、コアドメインがどんどん巨大になっていた事実に気づいた時には、リファクタリングしようにも本番稼働中なので手を入れられず、最終的には、既存ドメインを捨てて、新規システムへリプレースするしかない経験が多い。
隔離されたコアを抽出して修正すべきタイミングを見つけるのは、実際にはとても難しい。

議論の中では、一つの解決法として、CIのメトリクスで凝集度や結合度などのメトリクスを常時測定しておき、メトリクスの兆候がある閾値を超えるとか、メトリクスの怪しげな傾向を見つけたら、隔離されたコアを抽出するタイミングと判断することもあるね、という話もあった。

【1-5】「<<コア>>」「<<汎用>>」はステレオタイプ。
パッケージ名やクラス名に、「~コアクラス」と書くのは良くない。
「<<コア>>」「<<汎用>>」はタグのようなものだから、ステレオタイプにした方がいい。

【2】16章「責務のレイヤ」

・ポリシー、業務、能力のレイヤは、パッケージを横断した構造ではないか?

・「業務」はイベント、トランザクションに相当。
・「能力」「潜在能力」はマスタ、リソースに相当。

・顧客が「能力」に相当する理由:
→輸送会社の例では、顧客はリピータ中心のため、顧客はビジネス上の資源であり、何度も活用する情報である。
 例:ダイレクトメールを客に送って、輸送の注文を促す

・逆に、一見の顧客の場合、顧客は「業務」でとらえられる。
 一見の顧客なら、顧客の情報をマスタとして持つ必要がない。
 トランザクションテーブル(例:輸送、配送、注文)に顧客の情報が含まれて、混在しているだろう。
 トランザクションテーブルに混じっている顧客データは、再利用される対象ではない。

・運送行程クラスは「能力」層なのに、「望ましい(isPreferred)」というメソッドがあり、唯一調和していない。
 そこで、「ドメイン駆動設計」では、運送行程クラスの「望ましい(isPreferred)」を「経路偏向ポリシー」クラスへ外出しして、「ポリシー」層に抽出している。

・新しい機能「特定の危険物に対しては、経路選択時に制限が適用される」をドメインモデルに反映する場合、従来のクラス設計では、「危険物経路サービス」を作ったとしても、呼び出しクラスになる「貨物」クラスにロジックが集中し過ぎて良くない。
 そこで、「ドメイン駆動設計」では、「経路選択サービス」に危険物の経路判断の呼び出しロジックを移動し、貨物クラスから切り離す。

・「ドメイン駆動設計」における「~サービス」クラスは、ユースケースに相当する。
 ユースケースに該当するサービスクラスが、業務ロジックのトリガーになっている。

| | コメント (0)

より以前の記事一覧