モデリング

2022/09/18

「ソフトウェアアーキテクチャの基礎」本はアーキテクトが読むべき本だった

ソフトウェアアーキテクチャの基礎」は良い本と思う。
アーキテクトが読むべき本だったと思う。
ラフなメモ。

【1】ソフトウェアアーキテクチャの定義とは何か?
以前の定義は、ソフトウェアアーキテクチャとは後から変更することが難しいモノだった。
しかし、今は、マイクロサービスの出現により、変化しやすい設計を指すようになって、ガラリと変わった。

【2】アーキテクチャの重要な要素は、トレードオフの決定だ。
品質、コスト、スケジュール、スコープのバランスから、一番最良のものを選ぶ。
それぞれの要素を最大限にするのではなく、トータルでバランスが取れているものを選ぶ。

【3】アーキテクトに期待されている役割。

アーキテクチャ決定を下す。
アーキテクチャを継続的に分析する。
アーキテクチャの最新のトレンドを把握している。
アーキテクチャ決定の順序を徹底している。
様々な技術に精通している。
事業ドメインに詳しい。
対人スキルや政治力を持つ。

【4】ソフトウェアアーキテクチャを語る上で、XPの偉大さがある。

XPでは、プロセスよりも経験的に知られていたプラクティスを重視した。
たとえば、テストが多いほど品質が良くなる経験から、テスト駆動を生み出した。
継続的インテグレーション、コードの共同所有、継続的デプロイなど。

【5】ソフトウェアアーキテクチャの法則は2つ。

1つは、トレードオフが全て。
トレードオフが見つからないならば、分析が不十分な事実を知るべきだ。

2つ目は、HowよりもWhyが大事。

【6】モジュール性とは何なのか?

モジュール分割するアーキテクチャのテクニックの利点は分かる。
しかし、モジュールの実現方法はあまり知られていない、とメイヤーは言った。
この話は、コンポーネント志向につながる。

Javaならば、当初のJDKはパッケージで分割した。
しかし、それだけでは扱いづらいので、Jarというコンポーネントが導入された。
しかし、Jar同士でパッケージ名が衝突する場合があるから、module systemがJava9から導入された。
つまり、Javaもモジュール性の実装方法に苦労している。

【7】本の途中のコラムがとても参考になる。

【7-1】スウェーデンで軍艦ヴァーサ号を製造したが、初めて処女航海に出ようとした時に、すぐに港で沈没した話。

失敗の原因は、アーキテクチャ特性を全部盛り込みすぎて、軍艦が重すぎてしまい、バランスが取れなくなり沈没した。
数多くの利害関係者の要求を最新鋭の軍艦に盛り込んだために、軍艦として実現できなかった。

今のソフトウェアアーキテクチャの話も同じ。
ユーザのたくさんの要望を盛り込みすぎると、結局使い勝手の悪いシステムになってしまうし、それ以前にスケジュールが伸びすぎて永遠にリリースされないシステムになるリスクすらある。

【7-2】ドメイン駆動設計の意義は、境界づけられたコンテキストという概念により、アーキテクチャ設計手法が大きく変わった点にある。

ドメイン駆動設計の出現以前は、組織内の共通エンティティは再利用を重視していた。
しかし、再利用を重視しすぎて、ビルドが困難になり、チーム間の調整が難しくなり、ソフトウェアの複雑さが増大し、多くの問題を引き起こした。
たぶん、ソフトウェアプロダクトラインの話も同じ。

ドメイン駆動設計の出現後、境界づけられたコンテキストの考え方により、各エンティティは局所化されたコンテキストの中で最もよく機能すればいい。
つまり、組織全体の共通エンティティは不要であって、問題領域ごとにエンティティを自由に作り、その中で最適化されたエンティティを作ればいい。
問題領域のドメインの境界上で調整すればいい。
つまり、この考え方がマイクロサービスにつながるわけだ。
マイクロサービスの実装言語はGo言語が主流である。

各ドメイン内のシステムはRailsだったりPythonだったりPHPでもよく、複数のプログラミング言語で作られたシステムとGo言語によるマイクロサービスがAWSのようなクラウド上で動くアーキテクチャが多いわけだ。

【8】コンポーネント設計では、分割の観点は何か?

コンポーネント設計とは、アーキテクチャの分割であるという考え方。
レイヤーアーキテクチャがよく使われる。
たとえば、Javaの依存性注入(DI)、DLLやJarなどのコンポーネント。

この考え方を進めると、開発スタイルはコンウェイの法則に縛られることになり、複雑な組織構造が反映された複雑なアーキテクチャになってしまう。
だから、逆コンウェイ戦略という考え方が出てきた。

一方、コンポーネント設計とは、ドメインによる分割であるという考え方。
これはドメイン駆動設計であり、マイクロサービスアーキテクチャにつながる。

ドメインごとに開発チームを作ることにより、コンウェイの法則のリスクを避けられる。
逆コンウェイ戦略をそのまま実現しやすい。

【9】アーキテクチャスタイルとは、アーキテクチャのパターン集。

モノリシックアーキテクチャと分散アーキテクチャに分かれる。

モノリシックアーキテクチャ:

レイヤーアーキテクチャ →TCP/IPとか。
パイプラインアーキテクチャ →Unixとか。
マイクロカーネルアーキテクチャ →コアシステム+プラグインの構造。Eclipse、Jira、Jenkinsとか。

分散アーキテクチャ:

サービスベースアーキテクチャ →フロントエンド+バックエンド
イベント駆動アーキテクチャ →デスクトップアプリ。非同期システム。
スペースベースアーキテクチャ →ロードバランサー。インフラの仮想化。クラウド。
オーケストレーション駆動サービス指向アーキテクチャ →よく分からない。使われない。
マイクロサービスアーキテクチャ →ドメイン駆動設計とか。

分散アーキテクチャが今の流行だが、8個の誤信がある。
ネットワークは信頼できる。
レイテンシーがゼロ。
帯域幅は無限。
ネットワークは安全。
トポロジーは決して変化しない。
管理者は1人だけ。
転送コストはゼロ。
ネットワークは均一。

他にも、分散ロギング、分散トランザクションなどもある。

これらの観点をトレードオフとして考えるべき。

| | コメント (0)

2022/06/17

組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンク

組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンクがあったのでメモ。

【参考】
組み込みUMLでの、分析モデリングでのクラスの識別アプローチについて文献まとめ - 千里霧中

組込みソフトウェア開発と設計をちょっと調べている。
やっぱり設計手法にはUMLを使っている方が僕は理解しやすい。
それに関する書籍のリンクの記事があったので、メモしておく。

【1】組込みソフトウェア開発のためのオブジェクト指向モデリング (組込みエンジニア教科書) | SESSAME WG2

この本はとても分かりやすかった。
湯沸かしポットを題材として、実際にクラス図、状態遷移図まで落とし込んでくれている。
この本の感想は以前書いた。

組み込みソフトウェアの根本問題~対象物の状態遷移を記述できれば、制御が可能だ: プログラマの思索

組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」を読んでいて楽しい: プログラマの思索

【2】リアルタイムUML―オブジェクト指向による組込みシステム開発入門 (Object Oriented Selection) | ダグラス,ブルース, Douglass,Bruce Powel, 博之, 渡辺, 株式会社オージス総研

【3】リアルタイムUMLワークショップ | ブルース・ダグラス, 鈴木 尚志

持っているけど理解できていない。

【4】組み込みUML―eUMLによるオブジェクト指向組み込みシステム開発 (OOP Foundations) | 博之, 渡辺, 和人, 堀松, 政彦, 渡辺, 和記, 渡守武

古本屋で見たことがある。
今度読んで見る。

【5】UML動的モデルによる組み込み開発―分析・設計・実装・テスト | 政彦, 渡辺, 哲史, 石田, 康二, 浅利, 周作, 飯田, 修二, 山本 | Amazon

今度読んで見る。

【6】オブジェクトデザイン (Object Oriented SELECTION) | レベッカ・ワーフスブラック, アラン・マクキーン, 株式会社オージス総研 藤井 拓, 株式会社オージス総研 藤井 拓, 辻 博靖, 井藤 晶子, 山口 雅之, 林 直樹

オブジェクト指向設計のうち、責任の割当に注力して書かれている。

【7】実践UML 第3版 オブジェクト指向分析設計と反復型開発入門 | クレーグ・ラーマン, 依田 智夫, 今野 睦, 依田 光江

僕は第1版、第2版を読んだ。
第1版では「オブジェクト指向設計の肝はコラボレーション図(協調図)です」という一節がすごく心に響いた。
クラスへ責務を割り当てるときに、UML2.0ならコミュニケーション図を書いて、責務が集中しないように疎結合にしたり、関連する責務は集めて凝集度を高くする、などのアドバイスがあった。

| | コメント (0)

2022/05/06

超高速開発でアジャイル開発を実現する話に違和感がある

超高速開発をやってます、これでアジャイル開発を実現しています、という話を聞いて違和感があった。
その違和感が何なのか、考えてみた。

違和感を感じた理由は3つある。
1つ目は、超高速開発ツールを使って短納期で少ない工数で開発できることをアピールしているのは違うでしょ、と思うから。
話を聞いてみると、要件定義さえ固めれば、後は設計を開発基盤に落とし込んで、超高速開発ツールという開発基盤を使えば、即座に動くアプリが作れる。
だから、顧客の現場でSEが常駐して、要件をヒヤリングして固めて、作った機能のユーザテストを定期的に行っています、と言っている。
大きな目で見ればアジャイル開発と言えるのかもしれないが、現場でユーザにヒヤリングしながら要件定義を固めること、そして、超高速開発ツールで短納期に開発するのがアジャイル開発と言えるのか、正直疑問に思った。

2つ目は、最近のアジャイル開発の風潮では、アジャイルコーチがきちんと指導したチームでアジャイル開発を回しているのでなければ、アジャイル開発とは言いにくい状況があることだ。
一般に、認定スクラムマスター、認定プロダクトオーナーなどの資格を持ち、スクラムの知識を熟知した技術者がチームを形成しているか、そういう資格を持ったアジャイルコーチが開発チームを指導しているか、を見なければ、アジャイル開発を実践しているか判断できないと思う。

他方、そういう認定資格を持っていない技術者やチームでアジャイル開発をやっています、と普通のソフトウェア企業が公開していたら、見知らぬ技術者は、この会社はアジャイル開発をやっているんだ、と勘違いして入社して、そのギャップに幻滅するのではないか。

昨今の風潮では、アジャイル開発と言えばスクラム一色なので、スクラムの認定資格を持っていない人がアジャイル開発をやっていると言う時、特に公的な場で表現するのは信憑性があるのかな、と疑問に思ってしまう時がある。
他方、スクラムはアジャイルコーチという職業を生み出し、認定資格によって、運用する人たちの資質や品質を担保する仕組みを整備したのはビジネス的に上手いな、と思う。

AgileTourOsakaでSCRUMMASTER THE BOOKの裏話を聞いた: プログラマの思索

3つ目は、超高速開発ツールを使っていると言いながら、データモデリングの技法を重視していない状況だったからだ。
単純に画面と帳票を設計して、それを超高速開発ツールの基盤に載せて、アプリを作っているだけだった。

一般に、超高速開発を標榜する人たちはデータモデリングの技術を背景にして、超高速開発ツールを自分たちで作り込んでいる。
彼らは、業務プロセスをデータモデルやDFDできちんと設計しているから、RDBさえ固めれば、後は画面と帳票のパターンを組み合わせて作るだけ、という方針でやっている。
しかし、超高速開発でアジャイル開発をやっています、という人たちの話を聞くと、確かに業務フローは書くけれど、データモデルが十分に考えられているとは見えなかった。
後で手直しできるから、と割と安易に作っているようにも見えた。

ちょっとそんな現場を見る機会があったので、超高速開発でアジャイル開発を実現しています、という話には気を付けた方がいいな、と思った。

| | コメント (0)

2022/04/13

事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべき

ドメイン駆動設計勉強会に参加してみて、事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべきという指摘になるほどと思えたのでメモ。
ラフなメモ。

【参考】
【ドメイン駆動設計勉強会】事業活動を理解して設計しよう! - connpass

増田さんの講演がすごく分かりやすかった。
問題意識は、事業活動をどのようにモデル化していくか?
事業活動をシステム化する時に、どこに注力すればいいのか?

まず、自社と外部の事業活動は、ピクト図で商品やお金の流れをシーケンス図のように表して、モデルにする。
自社の内部プロセスは、ポーターのバリューチェーンを使って、主活動と支援活動に分類する。

ドメイン駆動設計のアプローチでは、バリューチェーンの主活動や支援活動をサブドメインに分割する。
すると、基本は、主活動は企業価値を生み出すコアドメイン、支援活動は管理業務等の支援ドメイン、汎用ドメインになる。

ビジネスロジックの複雑度や差別化の重要度の観点では、コアドメインが重要であり、支援ドメイン、汎用ドメインの順になる。
一般に、汎用ドメインや支援ドメインの品質は当たり前品質で十分であり、コアドメインの品質は魅力的品質まで高める必要がある。

増田さんの講演でもっとも興味を引いた発言は、増田さんの経験では、事業活動のシステム化では、他社との差別化につながるコアドメインよりも、他社と差別化しなくて良い支援ドメインや汎用ドメインに注力すべき場合が多かった、という内容だった。
なぜならば、他社と同じような業務では、汎用ドメインや支援ドメインで構築すれば安く仕上がるし、その分野の人材も市場から確保しやすいからだ。
そもそもそういう分野では差別化せず、市販のサービスやパッケージをそのまま流用すればいい。

また、自社の弱点として実は、支援活動の業務があるケースが多いらしい。
すると、支援活動のシステム化に注力した方が投資効果が大きいらしい。
なぜなら、支援活動にある総務・財務・人事などの部門の業務は既存のパッケージ製品が多数あるからだ。

一方、本来の自社で価値を生み出すコアドメインは、独自のシステムになるから、コストをかけて当たり前品質以上の魅力的品質まで作り込むべきだ、という流れだと理解した。

一般に、支援活動にある総務・財務・人事などの部門の業務はどこの会社でも似たような内容であり、財務報告も法律で決められた書式で報告する必要があるから、できるだけ汎用ドメインで構築した方が運用が楽だし、コストもかからない。

むしろ、コストを掛けるべき部分はコアドメインであるから、汎用・支援ドメインにはコストを掛けずにメリハリを付けた方がいい。
そんな内容だと理解した。

たぶん、一般に、支援活動の業務は汎用のERPで導入した方が良いのだろう。
今ならば、汎用的なSaaSを導入すればいいのだろうと思う。

普通は、コアドメインに当たる主活動のモデル化に注力したくなるが、むしろ、支援・汎用ドメインに当たる支援活動のモデル化の方に企業の問題がある場合が多く、投資効果が大きいという経験談が面白かった。

| | コメント (0)

2022/03/25

「大国政治の悲劇」の感想~現代はパワーポリティクスの歴史に戻ったみたいだ

大国政治の悲劇 | ジョン・J・ミアシャイマー, 奥山 真司を読んだ。
まさにロシア侵略のウクライナ紛争のタイミングで読むと、彼らがこの本で書いた通りに行動しているのではないか、と思った。
ラフなメモ。

【1】まず最初に断っておくと、この本は672ページという大著であり、注釈だけでも150ページもある。
論文みたいな本だ。
しかし、内容はとてもロジカルだ。
この本のプランは最初の第1章の最後に書かれている。

【2】まず、なぜ国家はパワーを求めて競争するのか、なぜ国家は覇権を求めるのか、という2つの問題を提示し、この問題が国際政治学で重要な根本問題であることを示す。

数学で言えばwell-defined、論文のお作法で言えば、justifyに相当するだろう。
つまり、この本で提示する問題の正当性を示す。

【3】次に、なぜ国家はパワーを求めて競争するのか、という問題を分析するために、2つのことを行う。
一つは、パワーを定義する。
もう一つは、国家が活動する舞台である国際システムにおいて、5つの仮定を置き、そこから国家がどのような行動を取るのか、を導き、最終的に最初の根本問題を解決する。

数学で言えば、公理系を最初に打ち立てて、そこから命題、定理、系を導くやり方に相当する。

僕はこの本を読んでいて、まるで過去に数学を研究していた時のことを思い出した。
数学のやり方はこういう社会科学、歴史学においても使えるのか、と改めてびっくりした。

この本を読んで、気づいた点はいくつかある。

【4】1つ目は、ミアシャイマーが提唱する理論「オフェンシブ・リアリズム」の結論は、国家は機会があれば覇権を求めて行動するので、世界は必ず対立し戦争が起こる。
ただし、その対立構造には、安定した二極世界、安定した多極世界、不安定な多極世界という種類がいくつかある。

【5】2つ目は、ポール・ケネディの「決定版 大国の興亡―1500年から2000年までの経済の変遷と軍事闘争〈上巻〉 | ポール ケネディ」の通り、国家の国力は、軍事力と経済力の2つであり、そのバランスが重要である、ということ。

【6】3つ目は、ハルフォード・マッキンダーが提唱した地政学の理論に似ているな、という点。

ランドパワー - Wikipedia

シーパワー - Wikipedia

オフェンシブ・リアリズムでは、覇権を求める国家はせいぜい地域覇権しか達成できない。
すると、今の世界地図から見れば、米国や英国のような海側から覇権国家を目指す国家と、ユーラシア大陸で覇権を求めるソ連、中国、ドイツ、フランスなどの国家に分別される。
基本は、大陸国家と海側国家の対決構造が必ずあるように思える。

ここで面白い点は、日本は海側国家の立場になり得たのに、実際は朝鮮半島や中国の一部を植民地化して大陸国家を目指そうとしていたことだ。
戦前の日本は、国際システム上では、当初は明治維新の後、西洋列強の植民地にならないように近代化を果たしたが、地域覇権を目指す方向に自然に活動し、最終的には、米国と戦争を起こすという自殺行為で最終的に破綻した。
「なぜ日本は無謀な戦争を決断して負けたのか」という問題は日本の歴史学でいつも問われるが、オフェンシブ・リアリズムの理論では「国際システム上では、国家は必ず覇権を求める行動を取らざるを得ないから、それから逃れることはできない」という結論になると思う。

また、ランドパワーとシーパワーの境目となる箇所がまさに紛争地になるのだろうなと思う。
だから、欧州大陸ではウクライナがNATOとロシアの中間地帯にあるし、朝鮮半島では、朝鮮半島の南部分はシーパワーである米国の影響力の配下にある、という例になるのだろうか。

【7】4つ目は、以前読んだウォルフレンの本「日本 権力構造の謎〈上〉 (ハヤカワ文庫NF) | カレル・ヴァン ウォルフレン」、ハラリの本「サピエンス全史セット【全2巻】 | ユヴァル・ノア・ハラリ」によく似ているな、と思った。

欧米人の歴史学や社会学の本はページ数が膨大で、その内容は非常にロジカルに書かれていて、自分たちの意見もはっきりしている。
しかも、その意見の正当性を示すために、大量の事例や事実を集めて補強しているし、反論されそうな内容は予め予想していてそれに対する反撃の意見と対症療法まで示している。

大国政治の悲劇 | ジョン・J・ミアシャイマー, 奥山 真司でも、米国、英国、フランス、ドイツ、ソ連、日本、イタリアの過去200年間の歴史をふりかえり、膨大な事実を自分の意見の正しさの証明に使っている。
そして、こういうオフェンシブ・リアリズムのような、普通の人間にはあまり心地よくない理論の話には反論したくなるが、それに対して、自分の意見の正当性と正しさを説明するために膨大な文章を使ってロジカルに組み立てている。

僕はこういう本は好きだ。
読むのは割としんどいけれど、メモしながら、ロジックの流れを追いかけてみると、最初の5つの仮定から定理が導かれ、最終的な結論まできちんと抑えられているのが分かる。

論文作成の技法part1~論文の構造: プログラマの思索

論文作成の技法part2~論文作成の観点: プログラマの思索

【8】大国政治の悲劇 | ジョン・J・ミアシャイマー, 奥山 真司では、最終章で「中国は平和に台頭できるか?」を設けて解説しているが、内容は悲観的だ。
まあ、オフェンシブ・リアリズムの立場ではそういう論理的な帰結になるだろうと思う。



| | コメント (0)

2022/03/20

マイクロサービスはアトミックな操作で閉じるべきシステム分割論に基づいたアーキテクチャなのか

渡辺さんのブログを読んで、マイクロサービスはアトミックな操作で閉じるべきシステム分割論に基づいたアーキテクチャなのかどうか、という問題提起をしていると感じた。

アジャイルとマイクロサービスは最悪な組み合わせ - 設計者の発言

データモデリングで考えれば、サブシステム分割の単位は、CRUD操作で閉じるようにシステム分割すべき。
一方、マイクロサービスは僕の考えでは、外部インターフェイスの一つのアーキテクチャに過ぎないのに、ものすごいシステムアーキテクチャみたいな幻想があって、システム分割論と混同する開発者が多いのでは、と思う。

アジャイル開発というプロセスでは、特にスクラムでは、プロセスに特化していて、ソフトウェア技術や設計アーキテクチャの話はあえて避けていると思う。
だからこそ、スクラムという開発プロセスのフレームワークはIT業界のあらゆるプロジェクトに適用できるし、製造業など他の業界でも使われるようになった。
しかし、それですべての問題が解決できるわけではない。
実際、XPやScrumを生み出した人たちのキャリアを見ると、ソフトウェア開発の経験がとても豊富で、オブジェクト指向設計、テスト駆動開発、継続的インテグレーションなど数多くのベストプラクティスを生み出している。
彼らは技術的要素を軽視しているわけではない。

マイクロサービスはSaaSのようなWebシステムでは、外部インターフェイスの公開APIとして優れている技術と思うが、それですべての問題が解決できるわけでもないし、この辺りの技術の実装はとても難しいと個人的に思っている。
なぜなら、こちらが仕様を準備して想定しているような使い方を、外部APIを利用する人たちはしない時が多いとか、非機能要件のうち性能要件やセキュリティ要件の実現が非常にシビアだったり、割と罠が多いからだ。

この辺りの技術は色々考えてみたい。

| | コメント (0)

2022/02/02

諸問題を組織論に持っていくのは目的を手段化していないか

諸問題を組織論に持っていくのは目的を手段化していないかと気づいたのでメモ。

【参考】
(1) ひさてるさんさんはTwitterを使っています 「エンジニア意識高くなると組織論みたいなとこに興味出てくるのはそうなんだけど、技術とドメインにこだわることから離れてマネジメント手法こそが最優先みたいな思想を見ると、いくらアジャイルのプロセスなんだぞと言ってても、やはり人は大地から離れて生きていくことはできないのという気持ちになる」 / Twitter

(1) 杉本啓さんはTwitterを使っています 「本当にそう。組織論にかぶれると、あらゆることが組織の問題に見えてくる。コンサルティング会社にいたころ、同じプロジェクトにアサインされたコンサルタントに、問題構造分析で、すべての問題構造図で「根本の問題」の箇所に「組織が悪い」と書く人がいて、辟易した。 https://t.co/jNsklAq4a7」 / Twitter

(1) akipiiさんはTwitterを使っています 「チャンドラーの、組織は戦略に従うの経験則に、暗黙的に流れてるのだろうと思う。こういうビジネスが必要だと思っても、人や組織がマッチしてないじゃないか、と分かって、組織づくりばかりに専念してる感じかな?」 / Twitter

(1) 杉本啓さんはTwitterを使っています 「僕が、コンウェイの法則をあまり好きじゃないのも、この辺が遠因。」 / Twitter

DXとは組織論である」みたいな論調が最近はやたら多い。
確かにその傾向はあるだろう。
DXを実践するには、IT化した業務、ソフトウェアを基盤にしたビジネスモデルが必要だから、それを実行できる人や組織が必要だ。

しかし、その本質は、「組織は戦略に従う」というチャンドラーの経験則に過ぎないと考える。
なぜなら、DXを実現する経営戦略が先にあって、その戦略を実行できる組織が必要だよ、という事実が、たぶん、どこにでも普遍的に見られるだけだからだ。

だから、色んな諸問題を組織が悪いから実行できないのだ、だから組織を何とか変えよう、という動きに進んで、それが自己目的化していないだろうか?
本来は戦略を実行するのが目的なのに、組織を変えることが目的化してしまっている、みたいな場合が日本では割と多いのではないか。

そして、なぜ、色んな諸問題を組織が悪いから実行できないのだ、という論点にすり替わってしまうのか、という問題の原因も見えてくる。

実は、「組織(構造)は戦略に従う」というチャンドラーの経験則とは逆に、「戦略は組織(文化)に従う」というアンゾフの経験則がある。
たぶん、会社の偉い人が意思決定した戦略に社員を従わせたいのに、実際はうまく行かない原因は、社員が従わないからだ。
それは組織文化にあるからだ、ということなのだろう。
特に官僚組織では、その組織形態そのものがなかなか変わらないので、長年の慣行が組織文化として固まってしまう場合が多いだろう。

野中郁次郎先生の「失敗の本質」を読むと、日本人は、「組織(構造)は戦略に従う」「戦略は組織(文化)に従う」という経験則に振り回されているような印象を受ける。
本来は、組織は戦略を実行するための仕組みの一つに過ぎないのに、その仕組が暴走自動車みたいにハンドル操作が効かなくなり、勝手にあらぬ方向へアクセルを踏んで自爆した、みたいな感じ。

一方、特に米国のMBAの参考図書に上がっている組織人事論の本とか読んでいると、彼らは、組織を動かすための能力やスキルへ抽象化して、誰もが身につけられる普遍スキルに仕上げているように思える。
リーダーシップ論などは特にそう思う。

| | コメント (0)

2022/01/23

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


| | コメント (0)

2022/01/22

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

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

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

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

こんなストーリーかな。

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

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

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

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

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

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

いろいろ試してみる。

| | コメント (0)

2021/12/26

リーダーシップの要は抽象的思考とトレードオフだ

「リーダーシップの要は抽象的思考とトレードオフ」という言葉をメモしていた。
この言葉は何を意味しているのか?

【1】プロマネの仕事は、プロジェクトを完遂するために必要な意思決定を行うことだ。
プロマネがリーダーシップを使ってプロジェクトを回す時に必要な要素は、抽象的思考とトレードオフの2つであると言っていると思う。

その意思決定の要素が2つあると考える。

抽象的思考とはモデリング能力を指す。
たとえば、PJ内の作業の業務フローを描いて、どこを効率化すればいいのか、どこに問題があるのかを探る。
たとえば、問題が発生した時、その問題の解決策をロジックツリーで分解して、その効果のインパクトや実現可能性を比較する。
たとえば、問題が根深く、悪循環のシステムから問題が発生しているなら、因果ループ図で悪循環ループを描いて、その構造を壊す仕組みを考える。

つまり、目の前の問題を見える化するために、モデルを描く。
モデルを描くことで、問題の解決策を見出して、意思決定の根拠を持つことで自身を持って意思決定できる。

トレードオフは、複数の意思決定の代替案を評価する能力を指す。
あちらを立てればこちらが立たず、みたいなものだ。
品質を保つためには、リソースをもっと投入する必要があり、それはコストを増やす。
最悪の品質を現状許されるレベルに上げるには、スケジュールを延ばすしかない。
そういうQCDのトレードオフはプロジェクト運営のあちこちで見られる。

意思決定するときには、そこそこの品質でそこそこのコストに抑えて、納期を守るようなBetterな対策を選ぶ。
科学者とエンジニアの違いは、エンジニアはトレードオフの思考と意思決定ができることだ。
現実的に実現可能なレベルの代替案の中で、より良い意思決定を下す。
一方、科学者ならば、真理の世界に生きているので、妥協する必要はない。
ひたすら、自分の思索を脳内で突き詰めればよい。

つまり、プロマネがプロジェクト運営する時、抽象的思考であるべき姿や問題解決をモデル化して解決を目指す。
その解決案の選択では、QCDのトレードオフを考えて、線形計画問題のような考え方で、最善の案を選んで意思決定を下す。
その意思決定の連続が、最終的にプロジェクトのゴールを目指す。

【2】抽象的思考とトレードオフのことを考える時、僕はほぼ日手帳に手書きでラフな絵を描く。
とにかく手で書き出す。
外資系コンサルの知的生産術」では「数学の問題を解く時はとにかく手を動かしなさい」「数学は手で解く」「マーケティングではとにかくグラフにしなさい」「統計はとにかくグラフにしなさい」というアドバイスがよく出てくる。
つまり、手を動かすことでアイデアがどんどん閃く。

その後、手書きの絵を元にastahで清書する。
astahで描いたら、その後は色々微修正する。
ロジックを整理して推敲していく感じ。

そういう意味では、抽象的思考にはastahというモデリングツールは必須。
モデリングツールastahがなければ、的確な意思決定はできないだろうと思っている。

【3】個人的には、astahは好き。
astahのメリットは、モデリング作業のうち、ロジックツリー、フロー分析、因果ループ図による構造分析が操作できること。
これだけモデルを描ければ、大抵のアイデアは表現できる。

astah*の因果ループプラグインがいいね: プログラマの思索

snytng/inga: astah* plugin to analyze a usecase diagram as causual loop.

astahの唯一の弱点は、マトリクス型の表記がやりにくいこと。
アクティビティ図で代用できるが、縦軸の軸名を縦列に表示できないので読みにくいのが唯一の欠点と思う。
そこだけ解消できれば嬉しい。


| | コメント (0)

より以前の記事一覧