モデリング

2021/02/25

関西IT勉強宴会の感想~コロナワクチン接種管理システムのデータモデリング

関西IT勉強宴会で、コロナワクチン接種管理システムのデータモデリングを解説されていたので、聞いていた。
ラフなメモ。

実際のデータモデリングは、Youtubeの動画を是非見て欲しい。
ITエンジニアであれば、解説の内容や説明の意図はすぐに理解できるはず。

【参考】
緊急開催「新型コロナワクチン接種管理システム」をローコード開発してみた - connpass

「新型コロナワクチン接種管理システム」をローコード開発してみた<第82回IT勉強宴会inZoom> | IT勉強宴会blog

「新型コロナワクチン接種管理システム」のデータモデル公開: 設計者の発言

(1)やっぱりデータモデリングができる人は要件定義に強い。
業務をヒヤリングしただけで、どんなデータモデルが必要なのか、どんな業務フローになるのか、業務のどこにボトルネックが発生するのか、をデータモデルから推測しているし、その根拠を明確に説明している点がすごい。

(2)渡辺さんがメーリングリストで、エンジニアであるならば、要件を聞いて実際にプロトタイプを作って、見せることで理解するよりも、データモデルを作っただけで理解して欲しい。
それがプロでしょ、という意見が本当に切れ味が鋭い。
データモデルが描ければ、データモデル上の制約条件から、業務フローも画面内容も画面遷移もほぼ一意に決まるし、それくらいの内容はエンジニアなら連想して欲しい、と。

| | コメント (0)

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/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/11/05

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

2020/12/12土の夕方に、SEA関西プロセス分科会 「モデルベースシステムズエンジニアリングの活用」が開催されます。

私も関わっているastah関西コミュニティの高井さんをお招きして、SEA関西にて「モデルベースシステムズエンジニアリングの活用」の講演2本が実現しました。

特に、自動車業界などで組込みソフトウェア開発を担当している技術者やアーキテクトに対し、上流工程におけるモデリング技法並びにモデリングツールを活用した設計技法のお話は参考になると思います。
興味のある方はぜひご参加ください!

講演の見所を少しだけメモ。

【申し込み】
第73回 SEA関西プロセス分科会 「モデルベースシステムズエンジニアリングの活用」 | Peatix

(引用開始・一部入れ替え)
開催日時: 2020年12月12日(土)16:00~18:00

開催形式: オンライン(ZOOM)

講師: 高井 利憲 氏(株式会社チェンジビジョン)

講演1:モデルベースシステムズエンジニアリングにおける形式手法の効果的な活用
 最近のシステム開発では上流工程での検証の必要性が高まっています。
 本講演では、モデルに基づくシステムズエンジニアリングアプローチと形式手法を組み合わせて活用する方法について、自動車分野のシステム開発を例に、ツールによる支援可能性を中心に議論します。

講演2:モデルベースシステムズエンジニアリングにおけるシナリオ生成手法の効果的な活用
 最近のシステム開発においては、シナリオベースの検証や妥当性確認を求められることが多くなってきています。
 本講演では、自動運転車の安全規格の一つであるISO21448(SOTIF)や同じく自動車分野のセキュリティ規格であるISO21434(車両サイバーセキュリティ)を例に、システムズエンジニアリングにおける効果的な実施方法を紹介します。
 講演1と同じ例題モデルを用いることにより、モデルの再利用可能性についても議論します。

本講演1及び2は名古屋大学倉地亮先生とdSpace藤倉俊幸様との共同研究の結果に基づいています。

主催: ソフトウェア技術者協会(SEA)関西支部

プログラム:
 15:30 アクセス受付開始
 16:00 講演1「モデルベースシステムズエンジニアリングにおける形式手法の効果的な活用」
 16:30 質疑応答
 16:45 講演2「モデルベースシステムズエンジニアリングにおけるシナリオ生成手法の効果的な活用」
 17:15 質疑応答・フリーディスカッション
 18:00 閉会

 閉会後、オンラインでの懇親会を持ちたいと思います。
 お時間の許す方は、お好きな飲み物をご用意の上、お気軽にご参加ください。

定員:
 100名
 お申し込み順です.定員になり次第受け付けを締め切ります.

(引用終了)

実は、過去に高井さんの講演や資料を見聞きして、刺激を受けた部分がたくさんある。
一つは、モデリングツールを経由して、開発プロセスと成果物のトレーサビリティを保証する仕組みを作り出すお話は面白かった。

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

ソフトウェア開発に置いて、開発プロセスが重要な理由は、単に手順を標準化して、作業の効率化を図るだけではない。
作業と成果物の間でトレーサビリティを保証することで、プロダクト品質とプロセス品質の両方を保証することだ。
例えば、ソースにバグがあれば、過去の変更履歴からどこでバグが埋め込まれたのか、どんな変更理由や要件の変更があったのか、を探れる。
あるいは、たった一つの仕様変更がどれだけの範囲のソースに影響を及ぼすのか、ということも追跡できるはず。
つまり、作業と成果物のトレーサビリティは、ソフトウェア構成管理に直結する。
ソフトウェア開発では、ソフトウェアの構成管理こそが、開発プロセスの本質ではないか、と思う。
そういう仕組みの実現に、実はastahというモデリングツールが一役買っている、という話が興味深かった。

2つ目は、SysMLというモデリング言語が、組込みソフトウェア開発において、メーカーのプロダクトオーナー、ハードウェア技術者、ソフトウェア技術者、自然科学者の間で、共通のコミュニケーション言語になっている、という講演も面白かった。

第2回astah関西の感想 #astahkansai: プログラマの思索

特に、組込みソフトウェア開発では、ハードウェア技術者が設計したハード機器に対して合うようなソフトウェアを開発するために、ソフトウェア技術者はどうしても弱い立場になりやすい。
そして、ハードの仕様変更や要件の理解不足などで、どうしてもソフトウェアの品質を担保するのは難しい。
その真因には、ハード技術者とソフト技術者の間で、コミュニケーションが不足しているから、ということがあるだろう、と思う。
ハード技術者にも理解してもらうために、UMLではなく、ハードの構造も表現できるSysMLを使うことで、ハード技術者とソフト技術者がSySMLという共通言語で会話できるようになった。
さらに、製品を市場にフィットさせる責任を持つプロダクトオーナーや、ハードに電気・流体・機械などの自然科学の制約を与えるドメインまで、すべての話をSysMLで会話できる。

多様なドメインを持つ製品開発では、こういう人工的なモデリング言語があるからこそ、ソフトウェアも含むハードを開発できるという点が面白い。
つまり、モデリング言語が我々の思考そのものを規定し、効率化させる部分があるわけだ。

今回の講演1本目は、モデルに基づくシステムズエンジニアリングと形式手法を組み合わせて検証する時に、astahというモデリングツールを使った事例を紹介してくれる。
モデリングツールによる検証方法の実装がどれだけ実現性があるのか、興味がある。

講演2本目は、自動運転車の安全規格などについて、システムズエンジニアリングにおける効果的な実施方法の事例を紹介してくれる。
自動車業界は今、ガソリンエンジンから電気自動車に大きく変更しつつある時代なので、こういう機能安全規格をいかにモデリング技法で実現するか、は、色んな観点で興味を引くはず。

最近、「モデルに基づくシステムズエンジニアリング」も読んでとても面白かったので、感想はまた今度書く。


| | コメント (1)

2020/09/28

課題は問題点をひっくり返す表現だけで良い場合もある

問題と課題の違いをメモ。

【参考】
リスクと問題と課題を再考: プログラマの思索

問題と課題の違い【改善活動の基礎講座-カイゼンの基本編:第3章】|カイゼンベース

「問題」と「課題」の違いとは?書き方や解決への対策も紹介 | TRANS.Biz

僕は、課題は問題解決のアクションと捉えていた。
問題は、現状とあるべき姿のギャップから発生した症状のこと。
問題はネガティブな表現、課題はポジティブな表現で書くべき、と考えていた。

しかし、課題は問題点を抽象化したもので書くべき、と言われた時があって混乱した。
その観点では、問題点と課題は同じ現象を少しだけ言い換えているに過ぎないので、問題と課題は同じ意味になってしまう。

そういう意図で聞かれた内容を色々考えあぐねた結果、課題は「問題点を改善すること」と言い換えれば良いと考えた。
つまり、課題は問題解決の具体的なアクションまで書く必要はなく、課題は悪い症状である○○を改善すること、とひっくり返した表現でいいみたいだった。

課題を具体的なアクションで書いてしまうと、レベル感が違うように受け取られるようだ。
あくまでも、抽象的なレベルで、課題は問題点をひっくり返す表現で十分であり、その後で具体的なアクションを書けばいい。


| | コメント (0)

2020/09/02

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

問題解決アプローチを見極める『クネビンフレームワーク』を知ったのでメモ。
結論のないメモ。

【参考1】
akipiiさんはTwitterを使っています 「クネビンフレームワークの説明が参考になった。問題のドメインが時代で変化しているからソフトウェア開発プロセスも変化する。非開発者のためのアジャイル開発入門 by @haradakiro #agile #complex https://t.co/2iCYVDeddY」 / Twitter

More Effective Agile ? “ソフトウェアリーダー”になるための28の道標|かず|note

複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework) ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

(引用開始)
カネヴィンフレームワークは1999年にIBM Global Servicesのデイブ・スノーデン(Dave Snowden)らが提唱したもので、状況・問題を大きく4つのドメインに分類するフレームワークです。(上画像)

1.Simple(シンプル):単純
⇒問題の因果関係・構造が明確

2.Complicated(コンプリケーティッド):煩雑
⇒少し分析すれば、因果関係・構造が明確

3.Complex(コンプレックス);複雑
⇒因果関係が複雑、調査・探索が必要

4.Chaotic(カオス):混乱
⇒因果関係が不明確で、状況や問題を理解することも難しい

その他.Disorder(ディスオーダー):無秩序
⇒直面する問題に適切な解決策がない

さらに、1のSimpleと、2のComplicatedを予測可能な問題、3のComplexと、Chaoticを予測不可能な問題と分類することもできます。
(引用終了)

製造業における製品製造の大量生産方式のビジネスと、エンジニアやコンサルタントなどの知的労働者がプロジェクトで仕事するビジネスは、本質的に何かが違うといつも思っていた。
その理由の一つは、問題解決アプローチが全く違う、という指摘を、クネビンフレームワークは教えてくれる。

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

(引用開始)
(クネビンフレームワークが必要とされる)背景としては、「正解がない」多様化した問題と現実解に対しての理解を深めることが第一義です。第二儀としては、アジャイルの必然性の腹落ち感があります。
(引用終了)

アジャイル開発が昨今必要とされる背景には、従来の問題解決の手法が通用しなくなってきていて、新しいフレームワークや考え方による問題解決手法が必要とされているのだろう。
「More Effective Agile ~“ソフトウェアリーダー"になるための28の道標」では、アジャイル開発による問題解決の観点はクネビンフレームワークの「複雑(Complex)」に当たるのではないか、という内容があるらしいので、今度読んでみたい。

【参考2】
複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework) ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

クネビンフレームワーク Cynefin Framework :臨機応変の意思決定手法 ? I & COMPANY / アイ&カンパニー

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

クネビンフレームワークを使ったテクニカルサポートチームの行動指針の立案 | Developers.IO

問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩

(引用開始)
これをエンジニアのロールに置き換える広木さんのツイートはすごいなと思ったので参考まで
(引用終了)

広木 大地/ エンジニアリング組織論への招待さんはTwitterを使っています 「CTO/VPoE/TechLead(スペシャリスト)の仕事って一体どう言う役割分担なの?みたいなことを聞かれる。 これはクネビンフレームワークで捉えるとわかりやすい CTO は Chaoticな問題 -> Complex VPoE/EMは Complexな問題 -> Complicated TechLeadは Complicatedな問題 -> Simple 不確実性が減っていく https://t.co/un1FX3QQ53」 / Twitter

akipiiさんはTwitterを使っています 「クネビンフレームワークでカオスで複雑・複合的な問題を分類する。CTO/VPoE/TechLeadというエンジニアのロールはクネビンフレームワークで整理すると分かりやすいという指摘。 問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩 https://t.co/exz3rCJnfw」 / Twitter


| | コメント (0)

より以前の記事一覧