astahによるUMLモデリング

2021/02/12

Astah C4 model pluginが公開された

Astah C4 model pluginが公開されたと聞いたのでメモ。

GitHub - ChangeVision/astah-c4model-plugin

複雑なUMLの代わりにC4モデルが提案されている: プログラマの思索

ソフトウェアアーキテクチャのためのC4モデル

ソフトウェアアーキテクチャのためのC4モデル - 雪泥鴻爪--IT技術者の随筆

C4 Model - albatrosary's blog

(引用開始)
C4 Model は
コンテキスト(context)
コンテナ(containers)
コンポーネント(components)
コード(code)
の略です。
(引用終了)

C4モデルは、クラウド上のWebシステム構築に特化したモデリング技法とみなした方がいいのだろう。
astahでもC4modelが描けるプラグインが出たので今度試してみる。

| | コメント (0)

2021/02/01

本を書く時の心構え

結城さんが本を書く時の心構えを公開していたのでメモ。

【参考】
次に書く本を考えているときのこと(思い出の日記)|結城浩

(引用開始)
でも、次に書く本を考えているときは、モードがずいぶん違います。
自分の心をとにかく広く広く広げる。遠くの地平線のその向こうまで見るような気持ちで、自分の四方を見渡す。
自分の両手がまるで大きな大きなコンパスになったような心持ちで、ぐるーりと巨大な円を描く。
「よーし、ここまでは届くかなあ。いや、もっと行けないかな?」などと考えつつ。

自分が、現在の段階で、その領域の境界部分を詳しく知っているかどうかはあまり考えない。
でも、数ヶ月の後に、その境界付近にある「とっても面白いところ」に接近できるかの見込みは立てる。

……私が次に書く本を考えているときには、そんなことをイメージしているように思います。

書き始める時点では知らなくてもよいけれど、書き終えた時点ではかなり詳しくなっているはず……という微妙な案配を見極めるのは難しい。
つまり、「自分がすでに知っていて何も考えなくても書ける」という難しさの本だと、私は書いていてつまらなく感じる。
それよりも「調べつつ・考えつつ・謎解きしつつ書かなくちゃ」という難しさの本がよい。
(引用終了)

僕は、本を書くということは、「今ここにいる自分」の知識と経験をフル動員して書くものだと思っていた。
僕は、全ての書物は、私小説だと思っていたから。

なぜなら、何かを書いて本として公開する、という意味は、自分がどこまで理解して、今まで誰も知らなかったことを発見したから世の中に広く知らしめたい、と思っていたから。
たとえば、自分の理解度が浅かったり、経験が少なければ、書物の内容はとても浅薄なものになりがちだ。
よって、書き始める時点で、内容のほとんどは自分が抑えていて、コントロールできなければならない、と思っていた。

たとえば、戦前の日本の小説家が書いたスタイルである私小説は、小説家自身の生活をベースに書いていたから、彼らのインプットが非常に少ないので中身はとてもつまらないと思っていた。

一方、結城さんの意見では、「最終的に本を書き上がる時点の自分」の知識と経験を書けばいい、というスタンスだ。
つまり、書き始める時点では、中身はまだ曖昧模糊でもいい。
書き終えた時点で、骨格も中身もプロットも全て完成していればいい。

よって、書き始める時点では、調べて考えてストーリーが決まったな、という範囲を予測できればいいし、その予測した範囲が自分の手の内に収まる程度であるか見積もりすればいい。
つまり、調べながらあれこれ考えたり、空想したりする余裕がある。
謎解きする楽しさの余地を残している。
書き始めた時点のストーリーが、謎解きするうちに、書き終えた時点では全く違うストーリーで完成度が仕上がっている、みたいなイメージになるのだろう。

今度書く機会があれば、こういう発想を使ってみたい。

| | コメント (0)

2021/01/05

yWriterは映画の脚本を作るためのアプリだったのではないか

小説分析ツールyWriterに似たようなソフトとして、ストーリー作成ソフト『StorYBook』があるらしく、その記事を読んでいたら、こういうストーリー分析ツールは映画の脚本を作るためのアプリだったのではないか、と気づいた。

【参考】
ストーリー作成ソフト『StorYBook』を使ってみた: はまログ

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

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

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

【1】実際に、yWriterは映画の脚本を作るのに最適だ。
理由は2つある。

【2】一つは、場面ごとに、人物・場所・アイテムという貴重なリソースを割り当てることが明確になるからだ。
映画では、一つの場面ごとに、高額な俳優に来てもらい、海辺やビルなどの場所を確保して、衣装や車などの道具(アイテム)を準備して望む。
1つの場面がたとえ5分であっても、人物・場所・アイテムという貴重なリソースをたった一つの場面に割り当てる必要がある。

一方、ある俳優の撮影期間が限定される場合、彼が出演する場面をすべて抜き出して、あらかじめ撮影すれば良い。
そのために、映画を数百本の場面にバラしておき、特定の俳優がアサインされる場面だけを抽出して、全体ストーリーとは無関係に個別にシーンを撮影するように、人物ごとの撮影スケジュールを作ればいい。

つまり、場面の観点ではなく、人物の観点で場面を抜粋しているわけだ。
あるいは、夕焼けの海辺のシーンのように、この一瞬しか場面を撮影できないとなれば、場所の観点で撮影スケジュールを作ればいい。

つまり、人物一覧・場所一覧・アイテム一覧のビューで、場面数が集計表示されるのは、そういう意味があったわけだ。

【3】もう一つは、ストーリーボードで時系列に場面を簡単に入れ替えたり、追加・変更・削除できることにより、映画のストーリーを柔軟に変更しやすくなることだ。

映画は2時間という制約があるので、場面数には上限がある。
よって、脚本家が数多くの場面を細切れに作った後で、まるでブロックを組み立てるように、場面を時系列に並べると映画が完成する。
名作と言われるレベルまで練り上げるために、場面を入れ替えたり、削ったり、場面を書き直したり、何度も推敲すればいい。
そういう推敲作業をツールが支援してくれるわけだ。

yWriterにはストーリーボードなど数多くのビューがあるけれど、その他の米国製のストーリー作成アプリを調べてみると、登場人物の家系図や関係図を表示したり、場面・人物ごとのカレンダーを表示したり、場所を集めた地図を表示するような機能もあるらしい。

確かに、歴史小説や推理小説であれば、人物の家系図や時代表はあると理解しやすい。

【4】こういう小説分析ツール・ストーリー作成ソフト・映画の脚本作成ツールは、なぜか日本製のツールがなくて、ほとんどが米国製だったりする。

たぶん、ハリウッド映画のように大量に映画を作成するには、こういう脚本作成ツールでロジカルかつ大量な場面を管理するツールが必要なのだろう。
また、欧州では小説を論理的に場面を意味あるもので組み合わせて構成するようなので、場面を管理して分析できるツールは必要なのだろう。

一方、日本ではこういうツールがない事実があるので、小説や映画、テレビ番組の脚本は、小説家や脚本家の個人的能力だけに依存しているか、アナログの京大式カードなどで場面を管理するとか、そういうレベルに過ぎないのかもしれない。
あくまでも推測に過ぎないが。

【5】yWriterをモデリングの観点で分析してみることで、アジャイル開発に出てくるストーリーのニュアンスや役割が何となくイメージできた気もする。
たぶん、欧米人がシステム要件をユーザーストーリーと呼んで扱っている場合、日本人の想像を遥かに上回って、もっとロジカルなレベルで考えているのだろうと思う。
つまり、ユーザーストーリーには、目的・対立・結論の構造と、人物・場所・アイテムの構成要素を持ち、英雄伝説の構造に沿って、世界中の人が誰でも親しみのある物語形式のロジックに組み込むように、彼らは作り込んでいるのだろう。

この考え方を使って、ユーザストーリーマッピング、カスタマー・ジャーニー・マップ、ナレーティブ・ジャーニー・マップなどの要件定義手法を考えてみたいと思う。

| | コメント (0)

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/12/25

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【6】感想

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

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

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

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

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

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

| | コメント (0)

2020/12/15

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のあるべき姿: プログラマの思索

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

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

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

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

| | コメント (0)

2020/12/13

第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(モノイスト)

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



| | コメント (0)

2020/12/06

考えながら書く人のための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次元のデータに変換して、論理構成を保つには、アウトライナーのようなツールが必要だと直感していたためだろうと思っている。

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


| | コメント (0)

より以前の記事一覧