「ハリウッドリライティングバイブル」のマインドマップ

脚本術の本の一つ「ハリウッドリライティングバイブル」を読んだ。
映画や小説はどんな構造（ストラクチャー）とストーリー（感情を揺さぶる物語）を持つべきなのか、とても理解ができた気がした。
その時のマインドマップを後で自分が読むためにアップしておく。

「ハリウッドリライティングバイブル」のマインドマップ from akipii Oga

物語を構成する要素はプロットである: プログラマの思索

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

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

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

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

【1】どうやら、直近5年間に脚本術の有名な本がどんどん翻訳されているらしい。
理由は知らないがニーズはあるのかな？

ゲームシナリオにハリウッド脚本術は使えるのか？おすすめ本の紹介とともに｜卍凸凹｜note

(引用開始)
ここ数年、ハリウッドの脚本術の本が色々と出版されています。
ハリウッドで定評のある本は、どれも非常に論理的にわかりやすく説明しており、シナリオを書く人にとっては何かしらの発見がある読み物かと思います。
(引用終了)

僕も、下記の本を読み上げた。
2000年代以前の映画をたくさん見た人にとっては、脚本術の本に載っている映画のストーリーやシーンが分かるから、より一層楽しめると思う。
映画は視覚の芸術だからこそ、小説とは違って、より緻密に構造化されていて、そのおかげで量産化できるようになってビジネスになり、大金をもたらす。
小説家や脚本家になりたい人だけでなく、ロールプレイングゲームを作りたい人にとっても、役立つ本だと思う。

SAVE THE CATの法則 本当に売れる脚本術 | ブレイク・スナイダー, 菊池淳子

映画を書くためにあなたがしなくてはならないこと シド・フィールドの脚本術 | シド・フィールド, 安藤 紘平, 加藤 正人

素晴らしい映画を書くためにあなたに必要なワークブック　シド・フィールドの脚本術2 | シド・フィールド, 安藤紘平, 加藤正人, 小林美也子, 菊池淳子

最高の映画を書くためにあなたが解決しなくてはならないこと シド・フィールドの脚本術3 | シド・フィールド, 安藤紘平, 小林美也子, 加藤正人

ストーリー ロバート・マッキーが教える物語の基本と原則 | ロバート・マッキー, 堺三保, 越前敏弥

【2】脚本術の本に興味を持っている理由は、アジャイル開発におけるストーリーによる要件定義手法を理解したいためだ。

ユーザーストーリー、ユーザーストーリーマッピング、ストーリーマッピングなど、似たような言葉が沢山出てくる。
また、カスタマージャーニーやデザイン思考の背後にも、ストーリーという概念が背後にあるように思える。

たぶん、欧米人が語る「ストーリー」という言葉は日本人が持つ言葉のイメージと違うと直感している。
単に物語という意味ではない。
起承転結という仕組みよりも、アリストテレスによる悲劇の分析で三幕構成が提唱されてからずっと、たぶん彼らは舞台劇や小説を理論化してきていると思う。

実際、「ハリウッドリライティングバイブル」「映画を書くためにあなたがしなくてはならないこと シド・フィールドの脚本術」「素晴らしい映画を書くためにあなたに必要なワークブック　シド・フィールドの脚本術2」を読んでみると、映画のワンシーンという一つのプロットに小さなストーリーを埋め込み、全体の構成の配置、構造化に数多くの原則を彼らは見出している。
欧米人は、脚本術のおかげでプレゼン能力がすごく高いのではないか。

実際、単純な因果関係で説明されても人の心には響かない。
でも、感情を揺さぶる物語形式がバックボーンに埋め込まれていると、堅苦しいプレゼンを聞いているはずなのに、感情を揺さぶられて聞き入ってしまう、そういう感じがする。

アジャイル開発でも、システムの要件定義というIT技術の言葉が氾濫して難しい現場において、システムの詳細を知らないユーザが理解できるように、脚本術でストーリーを持ち込んで、一連のストーリーとして理解できるようにしたように思える。

今後の僕のテーマの一つは、欧米人が理論化した脚本術を、astahを使って、概念モデルやプロセスの構造に落とし込んで理解したいことだ。

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

プロジェクトマネージャの意思決定プロセスや判断プロセスはどんな仕組みなのか？

「問題解決トレーニング　アタマがよくなるビジネス50題」「1分間でマスター 問題解決トレーニング」の内容をまとめてみた。

プロマネの判断プロセス from akipii Oga

プロマネの意思決定プロセス from akipii Oga

たぶん、すごく新しい考え方ではない。
限られた時間で、どのプロセスを選択するか、その時の条件に従って、処理プロセスを条件分岐させるだけ。
事実や情報が集まって意思決定できるか、情報が少なすぎて意思決定がすぐにできないか。

こんなストーリーかな。

原因が分かって問題解決の手法も明確なら、改善プロセスを選択する。
正攻法なので時間はかかるが、確実に効果を上げる。
30％ぐらいまでの投資対効果を目指す。

時間があれば、仮説を立ててゆっくり考えることはできる。
改革プロセスはそんな感じ。
100％ぐらいの効果を目指すから、今までとは異なるアイデアを持ち出す必要がある。
じっくり計画を立てて、壮大なイメージを十分に練って、トライアルを実行して仮説を試す。

一方、時間がなければ、対処療法的な意思決定を下す時が多い。
まずはパッチ当て。
その後で原因を分析し、根本治療を目指す。

そういう意味ではGTDに似ている。
メール処理みたいに、情報を分類して、条件分岐に従って意思決定を素早く下す。

GTDは箱の使い分けが鍵を握る: プログラマの思索

このやり方でやれば、日々の業務的意思決定は効率的かもしれない。
一方、企画書や提案書をじっくり書き上げたり、機能の実装でどれが一番最善7日考えながらプログラミングする方法には向かないのではないか、と思った。

いろいろ試してみる。

「世界を動かすプロジェクトマネジメントの教科書」の概念図

「世界を動かすプロジェクトマネジメントの教科書」の本を読んだ。
自分の理解を深めるために概念図を書いたのでメモしておく。
ラフなメモ。

世界を動かすプロジェクトマネジメントの教科書　～グローバルなチャレンジを成功させるOSの作り方：書籍案内｜技術評論社

世界を動かすプロジェクトマネジメントの教科書の概念図 from akipii Oga

【1】「世界を動かすプロジェクトマネジメントの教科書」で気づきがあった点は、プロジェクトの立ち上げ・計画フェーズが最重要であることだと思う。
日本企業では誰が最終責任者なのか分からない場面が多々あるが、「世界を動かすプロジェクトマネジメントの教科書」のシナリオでは、プロジェクトマネージャすら不在の場面がある点も驚きだった。

【2】「世界を動かすプロジェクトマネジメントの教科書」の一節に、ソフトウェア企業のSEが、「SIerでは、プログラマ→SE→シニアSE→プロジェクトマネージャのようなキャリアが多いです」と話す部分がある。
僕の経験上、シニアSE→プロジェクトマネージャの断絶は大きいし、仕事内容も大きく変わる。

100人月以上の案件のプロジェクトマネージャの仕事では、もはやPJの細部の作業まで見ていない。
プログラミングや設計書の作成などの実務にタッチしないし、実作業の進捗管理すら、各サブチームのサブリーダーに任せている。
では、プロジェクトマネージャは何をやっているのか？

彼らの仕事の中身を見ると、ひたすらプロジェクトの計画書、見積書、報告書の作成とそれら書類を利害関係者に説明する会議に出ているだけだ。
顧客への説明はもちろん、インフラ基盤や開発、製品端末などを委託したベンダへの説明がほとんどだ。
その会議のための報告書を作成するために、社内の法務部、購買部、部門長、他部門の関係部署、場合によっては役員と交渉している。

第三者が見ると、プロジェクトマネージャは報告書作成マシーンに見える。
その作業だけで手一杯なのだ。
プログラミングや設計が楽しい人から見れば、そういう作業が楽しいのかなと思う時もある。
ひたすらドキュメントを作っているだけだからだ。

【3】一方で、プロジェクトマネージャのレベルになると会社の中では中間管理職に相当するので、それなりの役職を持ち権限と責任を持つ。
すると、会社内ではそれなりのパワーを発揮できる醍醐味もある。
案件に必要なリソースを自由に使えるからだ。

プロジェクトマネージャはコミュニケーションが重要、とよく言われるが、僕はその言葉はあまり本質的ではないと思う。
直接的に言えば、組織から与えられた権力を正当に行使できるし、むしろ、その権力を案件の達成のためにどんどん使って、部下はもちろん、社内の他の部署、社内の経営層、お客様まで巻き込むことだと思う。
だから、政治家みたいに、権力行使が好きな人の方が向いているという気はする。

しかし、たとえば、IT企業であれば、単に役職さえ与えられればプロジェクトマネージャとしてやれるわけではない。
技術力は当然必要だし、PMBOKに代表されるようなプロジェクト管理技法は一通り知っておく必要がある。
その他に、PJの原価や利益などに関する財務会計の知識、請負・準委任契約や知的財産などの法務の知識、部下をコントロールしたりやる気を起こさせるような人事手法やリーダーシップなども当然要求される。
単純に知識さえあればOKというわけではない。

「世界を動かすプロジェクトマネジメントの教科書」を読むと、改めて、IT業界以外のプロジェクトマネージャも別の観点で苦労しているんだな、とか、IT業界では当たり前でも他の業界では当たり前でないんだな、とか、気付きも多かった。

この辺りはまたまとめてみたい。

Redmineにメンション機能が入るらしい

Redmine5.0にメンション機能のパッチが提供されたのでメモ。

akipiiさんはTwitterを使っています 「すごく嬉しい。RT @g_maeda: Redmine 5.0 でメンション機能が入りそう。 https://t.co/NY2SqPQ05P」 / Twitter

Feature #13919: Mention user on comment/description using @user with autocomplete - Redmine

＠ユーザIDでメンションできる機能のパッチができた。
Redmineコミッタ Marius BALTEANUさんが提供しているので、おそらくtrunkに入るだろう。

Twitter、Slack、Teamsでも、メンション機能は当たり前。
この機能がないとすごく不便。
なぜなら、コメントした時に、相手に依頼したり問いかけても、応答しなかったり、そもそも気づかない場合もあるから。

こういう機能改善を見ると、Redmineは古株のPJ管理ツールなので、昨今流行している機能を取り込んで追随していく方向性になるかもしれない。
たとえば、似たような機能で今はない機能として、いいねボタンの機能もある。

とは言え、長年親しんで使い慣れたRedmineだからこそ、こういう細かい機能追加はとてもありがたい。
今後もチェックしていく。

【資料公開】チケット駆動開発の解説～タスク管理からプロセス改善へ #redmine

プロジェクト＆プログラム・アナリシス研究部会で講演した資料「チケット駆動開発の解説～タスク管理からプロセス改善へ」を公開します。

【参考】
お知らせ2点：P&PA研究部会「チケット駆動開発」(1/11)、BOMに関する1日集中セミナー(1/27) : タイム・コンサルタントの日誌から

プロジェクト・マネジメント・システムは存在しうるか : タイム・コンサルタントの日誌から

【1】資料のテーマは、下記の通り。
基本的な前提として、Redmineの経験者を対象としている。

チケット駆動開発は、ソフトウェア開発で使われる障害管理ツールをタスク管理に利用する開発手法を指す。
チケット駆動開発はアジャイル開発と親和性が高いので、アジャイル開発のプラクティスを利用しやすく、チーム運営に役立つ。
チケット駆動開発を支えるチケット管理ツールは、汎用性が高く、とても有用な為、色々な業界の現場のプロセス改善に使われている。
チケット駆動開発の発端、仕組み、事例、プロセス改善に使われる理由を解説する。

チケット駆動開発、チケット管理ツール、Redmineというものを知らなければ、たぶん理解しにくかったかもしれない。

僕は、そういう内容を前提の上で、現時点で、チケット駆動開発とチケット管理ツールがどういう課題を乗り越えて、ここまで進化してきたのか、そして、今後はどんな未知の分野や課題があるのか、を整理して示したかった。
よって、70ページものボリュームになってしまった。

分かってくれる人に理解してもらえれば本望かなと思って公開してみる。

チケット駆動開発の解説～タスク管理からプロセス改善へ from akipii Oga