Agile

2021/02/15

TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか

TeamsとSlack、Zoomの違いについて、たまたま同一の日にツイートを見かけた。
TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか、というアイデアをメモ。
ラフなメモ書き。

【参考】
akipiiさんはTwitterを使っています 「TeamsとSlackの組織文化の違いが面白い。」 / Twitter

Dai Fujihara | ノーコードテスト自動化SaaS「mabl」 | アジャイルコーチさんはTwitterを使っています 「最近、Teams使うお客さんに出会うことが増えてきたけどSlackなら「やっほー」で済むのがTeamsだと「お世話になっております」になるのが面白い / Slack 対 Teams…スラックの成功がマイクロソフトのおかげというのは「見当違いで、馬鹿げている」 https://t.co/3Ds3uHAlei https://t.co/fWDPik2D1H」 / Twitter

akipiiさんはTwitterを使っています 「TeamsとSlackを使う組織文化の違いは、色んな所で話題になるね。個人的にはTeamsを使うのに慣れて割と便利だと思っていて、逆にGoogleChatやSlackは機能が限定されすぎていて痒い機能がなくて、使いにくく感じる。」 / Twitter

沢渡あまね新刊 #業務改善の問題地図 #ここアジャ #職場の科学さんはTwitterを使っています 「申し訳ないが(私の使い方に問題あるのかもしれないが)、Teamsは組織外との人たちとのコラボレーションまだまだしにくい。特に、私のように複数の組織に属する人間の場合、「顔」を切り替える必要があるのだがそれが出来ない(?)。『役割切替』機能欲しい。パラレルキャリアへの対応、プリーズ。」 / Twitter

コミュニティ活動では、SlackとZoomを一般に使っている。
オンラインの勉強会、打合せ、イベントは、今までの経験ではZoomだけだった。
Slackも、コミュニティの時系列チャットみたいに使っている。

特に、Zoomは日々Updateしている感じで、ブレイクアウトルームやいろんな機能が使えるようになっているので、使っていて楽しい。
音声もクリアだし、利用しているだけなら支障はない。

一方、Teamsは会社の業務で使うのが一般的。
Office365を採用している企業であれば、Teamsがそのまま付属してくるので、そこから使ってくるのではないか。
Teamsの使い心地は割と良い。

チャットはSlackみたいに普通にできるし、Zoomみたいにテレビ会議も普通にできるし、Sharepointもバンドルされているので、Excelやパワポも普通に開いて保存もできる。
OutlookもTeamsの一機能になっているので、予定表でカレンダーを見れるし、Plannerも使えば、タスクかんばんみたいなタスク管理もできる。
一昔前のMicrosoft製品のように、ゴチャゴチャした感じではなく、今風なUIなので便利だと思っている。

しかし、Teamsのせいなのかどうか分からないが、@daipresentsさんの指摘の通り、Teamsではチャットに敬語を使う。
業務で使っているせいかもしれないが、そういう組織文化が出てくるのかもしれない。

また、@amane_sawatariさんの指摘通り、Teamsでは組織というグループ管理が強固なので、グループ外の人は入れない。
会社の業務のように、内部統制やIT全般統制、情報セキュリティを厳しく管理する場合はそういう使い方が必要なのかもしれないが、縦割り文化を助長している面もある。

ツールの機能の違いが組織文化を助長しているのかもしれないし、逆に、組織文化が、組織に合った機能を持つツールを選択しているのかもしれない。
いくら優れているツールであっても、ツールの利用者が使いこなせなければ意味がないから。

| | コメント (0)

2021/01/26

SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説

SAFe 4.5のエッセンス」「大規模スクラム Large-Scale Scrum(LeSS)」を読み比べていると、色々気づきがある。
2冊共に完読していないけど、アイデアをラフなメモ。

【1】SAFeの本質はアジャイルリリーストレインにあるのではないか?

複数のスクラムチームのアウトプットを同期させるために、アジャイルリリーストレインで統制をかける。
さらに、アジャイルリリーストレインを複数チームだけでなく、複数PJの集まりであるプログラム、複数の組織、果ては予算まで同期させようとする。

つまり、アジャイルリリーストレインによって、ソフトウェアという成果物、リリース計画、予算まで同期させようとする目論見を企てている。
ただし、SAFeは既存組織の組織構造は変えずに、アジャイルPMOという立場も認めている所は現実的かもしれない。

たぶん、日本のように組織構造も組織文化も変化させにくい所では、SAFeが導入しやすいのかもしれない。

【2】LeSSは忠実に、スクラムをスケールアップしようとしている。

だから、いくらPJが大規模になってもPOは1人だし、スクラムマスターがPJや組織の中心にいる。
SAFeではスクラムマスターの役割は大規模PJの中に埋もれてしまっているが、LeSSでは、大規模PJであっても、スクラムマスターは積極的に活動し、スクラムプロセスを推進する原動力になっている。

LeSSは最終的には、PJのスクラム運用だけでなく、既存の組織そのものをスクラム化しようと企んでいる。
スクラムマスターは、チェンジマネジメントの変革者として、既存組織の文化を変えてしまう役割も担っているように思える。
実際、LeSSでは、従来のプロジェクトマネージャや中間管理職には否定的で、彼らの存在はなくなってもいい、と思っているから。

| | コメント (0)

2021/01/25

キャズム理論をプロセス導入の問題解決に使うアイデア

「BABOK入門」を読んでいたら、ERP導入の難易度と組織文化をマトリクスで整理していたのが非常に分かりやすかった。
そのマトリクスの考え方の背後には、キャズム理論がある。
なるほど、そういう考えなのか。
適当なラフなメモ。
間違っていたら後で直す。

「BABOK入門」を読むと、キャズム理論は、ERP導入だけでなく、PMOが新しい標準プロセスを導入する時に、どういう対処をすれば運用を拡大して推進できるか、という示唆が得られると思う。

まず、キャズム理論は、ERP導入や開発プロセス導入対象の組織文化のレベル分けに使える。

ビジョナリーは、イノベータなので、最新のERP、最新の開発プロセスに興味を持ち、導入してくれる。
アーリーアダプターは、実利重視なので、自分たちの目的に叶うならば、リスクを背負って導入してくれる。
アーリーマジョリティは、保守的なので、他社が多数導入して、デファクトスタンダードになってから導入し始める。
ラガードは、自分たちの組織文化に誇りを持ち、他の価値観を受け入れないので、そもそも導入しないか、導入しようとしても自分たちの組織文化に合うように、ERPをカスタマイズしまくったり、プロセスをカスタマイズしまくる。

他に、キャズム理論は、ERP導入やプロセス導入の問題解決に使える。
キャズム理論では、アーリーアダプターとアーリーマジョリティの間にあるキャズムを乗り越えるのが重要、と知られている。
だから、ERPであれ、新しいプロセスであれ、キャズムを乗り越える対策が必要。

キャズム理論が教える所では、ホールプロダクト理論が知られている。
ボウリング・ピンのように、主要ターゲットを狙って成功させて、その後は次々にターゲットを定めて落としていく。
同様に、ERP導入でも、プロセス導入でも、主要ターゲットを定めて確実に成功させて、周囲のボウリングピンを一つずつ落として、シェアを高めて、デファクトスタンダードに近づけていく。

アジャイル開発の導入でも、Redmineの導入促進でも、同じような苦労があったことを思い出した。

今、PMOが導入しようとしているフェーズは今どこなのか、自分の足元を確認しながら、進めていくべきなんだな、と改めて気づいた。


| | コメント (0)

2021/01/19

文化は組織構造に従う

大規模スクラム Large-Scale Scrum」を読んでいたら、「文化は(組織)構造に従う」という文章があった。
なるほど、と思ったのでメモ。
以下、結論のないラフなメモ。

【1】「大規模スクラム Large-Scale Scrum」P.63では、「文化は(組織)構造に従う」をラーマンの組織行動の法則として紹介している。

組織は、中間管理職やマネージャの権力構造を維持するために、暗黙的に最適化されている。
その結果、組織を変えようとする試みは、職種の名称を変更するくらいで現状維持になる。
その結果、組織を変えようとする試みは、マネージャや現状維持しようとする人々から、理想主義者として非難される。
その結果、文化は構造に従う。

つまり、組織の文化を変えようとするのは愚かな試みで常に失敗する、と。
人々の行動(文化)はシステムの産物なので、システム(組織構造・組織階層)を変更すると、人々の行動が変化する、と。

【2】チームの文化、メンバーの行動、組織の文化は、所属する組織の構造の影響下にある。
逆ではない。
構造は文化に従うよりも、文化は組織構造に従う力の方が大きい。

人々の行動はシステムの産物。
システムを変更すると、人々の行動は変化する。

組織の構成要素を変更すると、人々の行動は変化する。
たとえば、ポリシー、役割、組織階層など。

【3】「文化は(組織)構造に従う」考え方は、システム思考と同じ考えだ。
システム思考では、発生する問題、人々の行動を即座に変更できないのは、悪循環を生むシステムが存在していて、その因果関係によって発生しているとみなす。
つまり、原因となる悪循環のシステムを変更するか、壊さない限り、問題は変化しないし、人々の行動は変わらない。

また、「文化は(組織)構造に従う」考え方は、行動経済学と同じ考えだ。
行動経済学では、人はインセンティブの奴隷、とみなす。
人々にインセンティブを付与することで、人々の行動を特定の方向に誘導しようとする。
たとえば、政府の財政政策や給付金、競争を取り締まる政策によって、企業や消費者、市場を特定の方向に誘導し、政策の効果を引き出そうとする。

【4】「大規模スクラム Large-Scale Scrum」はまだ読みかけなのだが、組織論の話が多い点に気づいた。

いかにマネージャを排し、フラットなチームを残してスケールさせるか?
現場で生き生きと活動しているスクラムから、いかに大規模な組織のスクラムにスケールアップするか?

そのためには、既存の組織構造に手を入れて、スクラムというチームの活動(文化)に悪影響を与えないようにする。
つまり、組織構造にスクラムの原理を反映させて、組織そのものをフラットにしてしまう。

この考えや意見は理想主義的なように思えるが、「大規模スクラム Large-Scale Scrum」を読んでいくと、あながちそうでもない気もする。

コロナ時代では、企業も人もいきなり変化する環境に放り出されて、物理的な接触を禁じられて、リモートワークを余儀なくされた。
すると、物理的にもマイクロマネジメントなプロジェクト管理は実施できなくなり、事実上、組織人ではなく、自由な一個人として労働するようになっているし、そうならざるを得ない。
コロナがなくなっても、労働環境も組織も変化してしまったのだから、もう昔のやり方に戻ることはできない。

そういう時代だからこそ、スクラムをチームベースではなく、大規模な組織ベースにスケールさせることには意義がある。
そのために、組織構造に手を加えて、人々の行動を変容させることも必要になってくるのだろう、と思う。

| | コメント (0)

2021/01/17

「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい

ストーリーマッピングをはじめよう」本を読んで良かったのでラフなメモ。

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

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

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

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

yWriterは映画の脚本を作るためのアプリだったのではないか: プログラマの思索

【0】「ストーリーマッピングをはじめよう」本の感想は3つある。

1つ目は、ユーザーストーリーで物語を可視化できる。
システム要件を物語として構造化できる。

物語は三幕構成というロジカルな構成を持つ。
アリストテレスが古代ギリシャ悲劇を理論化して、何千年もの歴史がある。
世界中の誰もが馴染みやすい。

そもそも、人間の認知のメカニズムは、ストーリーになる。
人間は、事象を、物語を介して理解している。
たとえば、旅行、映画、体験談。
たとえば、内視鏡検査が痛かった体験談すら、ストーリーで家族に語る。

2つ目は、ストーリーはSaaSと相性が抜群に良い。
ストーリーに合わせて顧客を呼び込んで、顧客行動をWebの画面遷移のWebログで計測できる。
導線のクリフハンガーを特定できる。

ストーリーの効果をKPIで評価できる。
SaaSのKPIなら、AARRRを思い出す。

AARRRとは?サービスを成長させるための基本戦略【テンプレート付】|ferret

つまり、購入率、CVR、成約率というKPIでストーリーの効果を評価できる。

3つ目は、課題解決に適用できる。
現状→問題→葛藤→目的達成→解決、という課題解決の流れは、古典的なストーリーの構造である、状況設定→複雑化→問題→解決と全く同じ。

課題解決には3種類のストーリーで使い分ける。
コンセプトストーリーで、新製品・新規機能をアピールする。
次に、潜在顧客に、オリジンストーリーでメッセージを伝える。
さらに、具体的な利用シーンをユセージストーリーで説明して、末永く利用してもらう。

つまり、新製品のコンセプトを打ち出してユーザを惹きつけ、顧客接点となるWebログイン画面から、物語のようなWebの導線を張ってユーザ誘導して、おとぎ話に落とし込む。
それぞれの機能は、利用シーンに合わせたストーリーで一貫した目的があり、ユーザはそれに一喜一憂して、ハラハラ・ドキドキさせられる。
そういうSaaSを目指すわけだ。

【1】ストーリーマッピングの特徴は3つある。

1つ目は、ユーザー体験を物語の各場面にプロットポイントとしてマッピングすることで、ストーリー化してしまうこと。
物語はナラティブアークと言われる。
ナレーションみたいなものだろうか。

ストーリーマッピングをはじめよう」に出てくるストーリーには、7つのプロットポイントがあり、時系列のグラフとしてマッピングされる。
プロットポイントは、状況説明→事件や問題の発生→盛り上げ→危機→クライマックス→オチ(落とし込み)→エンディング、という流れ。
三幕構成では、状況説明→事件や問題の発生が、始まり。
→盛り上げ→危機→クライマックスが中盤。
落とし込み→エンディングが終わり、に相当する。

ストーリーの構造は、「考える技術・書く技術」に出てくるプレゼンテーションのイントロの技術「状況→複雑化→疑問→答え」と全く同じ。
一方、ストーリーはこの7つのプロットポイントを明確に意識し、観客の感情を上下させるように場面設定を論理的に組み立てなければ、興ざめしてしまう。

各プロットポイントにも特徴がある。
事件発生では、Call To Action、つまり、行動を求める声となるイベントを置く。
ユーザが後戻りできないような事件を引き起こす。

物語では、クライマックスが大事。
クリフハンガーとは、上昇途中やクライマックスで唐突に終わるストーリー。
これは避けなければならない。

halfalogueとは、盛り上がるだけで、オチのないストーリー。
クライマックスやエンディングが半分だけなのでイライラする。
これは避けなければならない。

エンディングでは、続き物をわざと残す。
別の物語につなげるために。

【2】2つ目は「ストーリーマッピングをはじめよう」では、ストーリーは3種類ある。
「コンセプト・ストーリー」「オリジン・ストーリー」「ユセージ・ストーリー」の3つ。

【2-1】コンセプト・ストーリーとは、製品概念の物語。
Concept=構造、全体像。
顧客が製品に感じる印象を元に、課題解決する。
新製品や新機能の開発に取り組む時に利用される。

例は、ジョブズがiPhoneを始めて紹介したプレゼン。
Slackというコミュニケーションツールを最初に紹介したプレゼン。

注意点は、平坦な展開は避ける。
物語を支える要件を見極める。

【2-2】オリジン・ストーリーとは、潜在顧客が初めて購入する物語。
Origin=発端、起点。
製品概念を知った後で、製品を実際に使ってもらう。
よって、顧客のチャネルや顧客接点が重要になる。

目的は、新規客を獲得し、リピート客にConvertする。
顧客接点を起点にあの手この手で販促する。
物語はプロモーションかな。

マーケティング部、営業部、広報部が、オリジン・ストーリーを主体的に作る場合が多い。
つまり、技術部がメインではなく、潜在顧客をマーケティング部などがイメージして、ストーリーを作り出す。

注意点は、物語をどう終わらせるか?が大事。
物語をストーリーにマッピングできないと、クリフハンガーが発生し、せっかくの見込客が離れてしまう。
Webシステム上のユーザの導線を計測して、クリフハンガーを特定し、対策を取る。

どんなアフォーダンスをユーザに示すか?が大事。
つまり、Web画面上の手がかりをユーザに認知させること。
ストーリーの概念としては、Call To Actionが大事で、たとえば、ボタンという機能を作り込むのが大事。

【2-3】ユセージ・ストーリーとは、顧客がステップごとに製品を使っていく物語。
Usage=利用、使い方。

プロットポイントごとにユーザの実行動がマッピングされる。
カスタマージャーニーを構造化したもの。

ユセージ・ストーリーには、長い旅もあれば短い旅もある。
大冒険型ストーリーなのか、連続ドラマ型ストーリーなのか。
物語のスケールを決めるのが大事。

Core Task(=Item)が中心になる。

クリフハンガーを解決するストーリーがテーマになる。
物語を視覚化すると、クリフハンガーがはっきりする。

たとえば、初期のTwitterはユーザ同士がつながるだけで、その利用シーンをユーザはイメージできず、クリフハンガーが発生していた。
そこで、ツイートしてメリットが出るユセージ・ストーリーを作り、それをTwitterの導線で実現することで、現在の爆発的な利用につながった。

【2-4】3パターンのストーリーのいずれもターゲットである顧客行動をKPIで計測する。
具体的には、SaaSであれば、Webログからユーザのアクセス履歴は全て追跡できる。

目的は、ストーリーの効果を測定すること。
クリフハンガーを特定し、ストーリーとWebシステムのギャップを探し出し、Webシステムを改良していく。

これにより、購入率やCVR、成約率を向上できるし、顧客満足度を高めることもできる。

【3】3つ目は、ストーリーマッピングの技法は、経営戦略の分析・策定や行動方針にも適用できること。

ストーリーマッピングをはじめよう」にはいくつか例がある。
ギャップ分析では、ストーリーを使って、クリフハンガーや平坦な物語と、ユーザや企業が目標にたどり着ける物語の差(ギャップ)をクリフハンガーとして視覚化する。

Webシステムや製品に対し、ユーザの行動分析にストーリーを使って、ユーザがどのように利用しているのか、クラスタリングみたいに複数のユーザの特徴を洗い出す。
それにより、製品の改良に役立てる。

要件評価では、バックエンドのシステム要件、フロントエンドのシステム要件をストーリーマッピングで視覚化し、ストーリーを評価する。

SWOT分析では、カスタマージャーニーや製品のSWOT分析をストーリーで語らせる。
ストーリーマッピングにより、物語の全体像が視覚化できる以外に、足りない所、機能していない所、可能性が眠っている所を明確にできる。

【4】「ストーリーマッピングをはじめよう」を読んで改めて思い浮かぶことは、なぜ、ストーリーが要件定義や企画フェーズで重要な役割を果たすのか? という問題だ。

ストーリーは実はロジカルに構成できるから。
実際、ストーリーという物語形式は、アリストテレスの悲劇論の歴史から始める三幕構成というロジカルな形式で表現される。
普通の日本人が思うような起承転結みたいな浅はかな構成ではない、と思う。

プロット (物語) - Wikipedia

ストーリーは課題解決に適用できるから。
課題解決の構造は物語の構造と一致している。
現状とあるべきゴールに対し、ギャップが問題として発生し、その問題を解決する。
状況設定の後、主人公が達成すべき目的となるインサイト・イベントが発生し、苦難の旅を経て、目的を解決する。

ストーリーは顧客から要件を引き出せる。
ITに詳しくない発注側のユーザ、情報システム部門から、要件を引き出したり、要件を議論するには、ストーリーで語ると共通理解が捗る。

ストーリーはKPIで測定できる。
WebシステムのKPIはAARRRの他にもたくさんある。

要件定義されたストーリーは、プロダクトバックログ(PBL)に蓄積される。
PBLから実際のリリース計画にマッピングする時には、ユーザーストーリーマッピングの技法を使えば、時系列と優先順位の表にユーザーストーリーをマッピングできる。
よって、ユーザ体験を重視したストーリーを実現するために必要な機能要件は、ユーザーストーリーマッピングの表から、MVPとなる対象機能を抽出でき、開発チームは、スプリントの襦袢に実装していけばいい。

こういう流れを理解すると、ストーリーによる要件定義はSaaSととても相性が良い。
そして、SaaSはアジャイル開発にピッタリのシステムであり、ビジネスモデルでもある。

昨今、DXが日本企業でも流行しているが、僕は、DXとは、ソフトウェア開発のビジネスモデルを持たないレガシー企業が、既存事業をSaaSとして展開するための仕組みづくり、と理解している。
従来のようなレガシーな基幹システムの開発スタイル、要件定義の手法とは、全く違うやり方ではないか、と考える。

このストーリーによる要件定義手法については、今後も色々考えてみる。

| | コメント (0)

2021/01/14

管理職に求められる能力はPM理論そのものではなかったのか

管理職に求められる能力の記事を読んでいたら、三隅二不二のPM理論そのものではないか、と感じた。
ラフなメモ書き。
浅い考えなので後で直す。

【参考】
管理職に求められるものとは─新世代リーダーへの条件─(前編)【ONE JAPAN CONFERENCE 2020レポート:PEOPLE④】|ONE JAPAN|note

(3) akipiiさんはTwitterを使っています 「これって、昔のPM理論そのままじゃないか!管理職の職能は不変なんだなと思った。“管理職に求められることは今も昔も変わらず、パフォーマンスとメンテナンスです。” 管理職に求められるものとは─新世代リーダーへの条件─(前編)【ONE JAPAN CONFERENCE 2020レポート:】https://t.co/XFNjuiTutr」 / Twitter

【1】(引用開始)
基本的に管理職に求められることは今も昔も変わらず、パフォーマンスとメンテナンスです。パフォーマンスとは、部門の業績を管理することで、メンテナンスはそのために多様なメンバーをマネジメントすることです。

しかし、管理職は組織の中間点にいるので、この2つに加えてダイバーシティや働き方改革、DX(デジタル・トランスフォーメーション)などあらゆる組織の問題が、すべて管理職にしわ寄せが来てしまっています。

さらに経営層からは、新規事業や新しい価値を作ってくれとオーダーされたり、現有の戦力の中で、多様な部下の強みを引き出して、なるべく早く革新的な成果を、しかもリモートで出してくれと命じられています。
(引用終了)

「基本的に管理職に求められることは今も昔も変わらず、パフォーマンスとメンテナンス」ということは、まさにPM理論そのままだなと思う。
成果を求めるパフォーマンス(P)と、チームビルディングなどのメンテナンス(M)の2つ。

PM理論 ? リーダーシップインサイト

PM理論by三隅二不二 | EARTHSHIP CONSULTING

PM理論とは ~理論から理解するリーダーシップとその変遷~|人材育成・社員研修|ラーニングエージェンシー

【2】そう言えば、PM理論は別名、パパママ理論とも呼ばれるらしい。
「業績:目標達成機能」(Performance)はパパ、「維持:集団維持機能」(Maintenance)はママに相当するように覚えると理解しやすかった。

(引用開始)
当時はまだまだ男が稼いで奥さんが家を守るという雰囲気の世の中だったので、このPM理論はパパ・ママ理論とも呼ばれ、厳しく子どもを育てるお父さんと、子どもの気持ちに寄り添うお母さんのイメージをあてて、このPM理論を説明していた。
(引用終了)

【研究ノート1】リーダーシップ理論(その1)「PM理論」|鈴木康宏|note

【3】「管理職に求められる能力はPM理論そのもの」という意見から気づいたことは3つある。

1つ目は、リーダーシップには成果(P)を求められること。
採用基準」本に「リーダーシップとは成果を求めること」というフレーズがあったが、たぶんそのことを指しているのだろう。
問題解決のためには、リーダーシップを発揮して、周囲を巻き込みながら、あるべきゴールへ到達するルートをとにかく進んでたどり着く。
まずはそういうスキルがなければ、話にならない。

2つ目は、ファシリテーション能力が10年以上前から重視されている理由は、メンテナンス機能の特徴の一つであること、そして、リーダーシップを補完する機能であるためだろう。
管理職に成り立てのマネージャは、部下に仕事を回すよりも自分でやった方が速いので、どうしてもマイクロマネジメントになりがち。
そういう時に、プロジェクトファシリテーションのようなスキルがあると、結果を出すチームを形成できるようになる。
スクラムマスターという役割も、メンテナンス機能を重視しているのではないか、と思う。

3つ目は、上記の記事では、管理職には新規事業を提案することまで求められてはいない、と記載されていたが、優秀な中間管理職ほど、新しい事業アイデアを実現したくてウズウズしている。
誰だって、上から言われた仕事をそのままやるのがモチベーションではない。
自分で実現したいアイデアや夢があって、それが会社の方向性と一致していれば、やる気も上がるし、そうなるように仕向けたいと思うからこそ、職務や権限を利用して動く。

特に、日本の組織では、名君と言われる経営トップは必ず、優秀な中間管理職をブレーンとして持ち、自由に采配が振れるように配慮してくれるものだろう。
たとえば、幕末から明治維新の頃は、薩長の下級武士がそういうトップに引き立てられて、彼らが原動力となって時代を変えていったように。
たぶん、日本は、経営トップが独裁的に振る舞うような欧米・中国のやり方ではなく、中間層のリーダーがリーダーシップを発揮するような、そういう組織文化なのだろう、と思う。

| | コメント (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)

2021/01/02

カンバンはステータス名が大事

カンバン仕事術」を読んで、気づいたことをメモ。

【1】カンバンの運用では、ステータスはどんな観点で作るべきなのか?

カンバンはチケット管理と相性が良い。
なぜなら、カンバンのステータスはチケットのステータスと同じだから。
チケット一覧をタスクボードでビジュアライズすれば、障害修正プロセスのどの工程でボトルネックが発生しているのか、一目で分かる。

では、カンバンのステータスはどんな観点で作るべきなのだろうか?
一般に、Redmineのワークフローでは、新規→進行中→解決→完了 がデフォルトだが、現場で運用する場合は必ず変更した方がいい。
チケットのステータスと同じ、と言っても、それぞれの現場でワークフローはかなり違う、という経験をしてきた。

たとえば、デフォルトステータスのまま運用すると、実は、ステータスに対応する担当者がいない時もあれば、複数人もいる時がある。
たいていの場合、SIの開発プロセスはインフラ基盤・デザイナー・アプリ開発・DB基盤・設計レビュー担当のように部門ごと、役割ごとに縦割り組織になっているので、割と複雑だ。
よって、ステータスが組織と対応付けられていないと混乱しやすい。

では、カンバンのステータスはどんな観点で作るべきなのか?

【2】カンバンのステータスは、役割やチームごとに割り当てる

カンバン仕事術」のイントロでは、Jiraを例として、カンバンのステータスを決める場面がある。
最終的には、ToDo→分析→開発→テスト→受入→運用待ち→本番 に決まる。
決め方は、各ステータスに役割ごとの担当者がアサインされる。

最後に「完了」ステータスがない理由は、チケットのタスクを実装して運用待ちになっても、リリース作業は別のベンダーが担当するので、自分たちで本番リリースしてバグがなかったことを見届けられないからだ。
本番リリースしたとしても、バグが出れば、また戻ってくるので、完了という呼び名が合わない、とチームで決めたからだ。

この場面を読んでいると、カンバンのステータスは、作業の役割ごとに決められる点だ。
開発プロセス、組織構造の部門ごとに、作業の役割は細分化されるので、その単位ごとにステータスが対応付けられる。
Redmineのデフォルトステータス「新規→進行中→解決→完了」ではステータスが少なすぎる場面が現実では多い。

経験上、メーカーのように生産工程が、生産計画部・製造部・品質保証部などのように縦割りになっている場合、ステータスの個数が増える傾向が多い。
メーカーの生産工程を模倣したWF型開発や、ソフトウェア工場のプロセスでは、通常のソフトウェア開発よりもさらにステータスが多くなりがち。

たとえば、開発者がバグ修正してコミットしても、テストサーバーにアップするには、構成管理担当者に連絡してアップしてもらい、別のテスターに検証してもらう、といった手間がかかる場合は、「構成管理担当者によるリリース待ち」「リリース終了・テスト検証前」のようなステータスがないと、誰がボールを持っているのか、混乱しやすい。

とは言え、現状を表したステータスをつけて、ワークフローを作るべき。

別の話では、リーン開発の考え方により、バリュ・ストリーム・マッピングの手法を使って、複雑になりすぎたワークフローをリファクタリングしてプロセス改善しましょう、というやり方もある。

【3】ボトルネックになるステータスの前に、キューを置け

役割ごとにステータスをアサインして実際に運用すると、ボトルネックとなる作業者の前に仕掛作業が滞留し、ボトルネックとなる場合が多い。
その原因を探ると、単純に、WIPが少ないからだけではない。

たとえば、受入ステータスのWIPが4になっているが、常に受入可能なチケットが埋まっているわけではない。
基本は、受入可能なチケットがあれば、担当者はすぐに検査・テストして、リリース可能と判断できれば、運用待ちステータスへ流す。
しかし、WIPが4より小さいと、テスターは常に張り付いて作業しないといけないが、出張や会議などで不在の時は対応できない。
一方、WIPが4より大きいと、テスターがフィードバックを戻す前に、開発者は別の作業に仕掛中になってしまって、すぐに対応してくれなくなる。

よって、受入フェーズでは、バッファとなる「準備完了」と、実際の「作業中」でステータスを分ける。

つまり、何らかの理由で制約がある工程の前にキュー(バッファ)を置くことで、ワークフローの一連の流れが停滞しないようにする。

キューの役割は、作業の流れを平準化することだ。
すなわち、フローの中で、流量(つまりタスク)のばらつきを抑える役割を果たす。

一般にキューは、ボトルネックとなる作業の前後で置かれる場合が多い。
たとえば、ToDo、開発準備完了、開発完了、テスト待ち、リリース待ち、レビュー待ち、受入待ち、などの呼び名がある。

キューの有無を判断するには、ステータスの入出条件、退出条件から考えればいい。

【4】カンバンは奥が深い

キューは、アルゴリズムの基本の一つ。
FIFO。
ワークフローを作る際に、流れが悪い場面で使う事が多いと思う。
ふりかえりでプロセス改善する時に、思いつきやすいと思う。

カンバンが面白いのは、2つある。
一つは、ワークフローの改善に役立つこと。
もう一つは、メトリクスやKPIを採取しやすいので、プロセス改善の材料に簡単に昇華できることだ。

なぜなら、カンバンはフロー管理に特化しているので、流量を速度にたとえれば、チケットの枚数で計測化しやすい。
完了ステータスとなったチケットはアウトプットなので、生産性にたとえられる。

カンバン仕事術」では、下記のKPIを紹介している。

リードタイム:1枚のチケットが最初のステータスから最後のステータスに入るまでにかかった時間
スループット:一定期間(例:1週間)ごとに完了したチケット数

こういうKPIはグラフ化すると分かりやすい。
たとえば、チケット完了日xチケットのリードタイム で散布図をプロットすれば、問題解決について、色々議論しやすい。
なぜ、このチケットはこんなに時間がかかり過ぎたのか?
そこからどんな原因が分析できるか?

たとえば、リリース週xスループットを折れ線グラフにすれば、納期遵守の工夫が見つかるかもしれない。

つまり、これらのKPIを開発プロセスにフィードバックすることで、各ステータスのWIPを減らしたり多くしたり、ステータスを統合・分割する解決法が見つかり、プロセスを改善する行動につなげられる。

元々、Redmineはカンバンと相性が良いので、どのKPIがプロセス改善に役立つのか、そういうノウハウも蓄積できるはずだ。
いろいろ考えてみる。

| | コメント (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)

より以前の記事一覧