astahによるUMLモデリング

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/09/04

GSNや因果ループ図を本番障害のなぜなぜ分析に使うアイデア

GSNや因果ループ図を本番障害のなぜなぜ分析に使えるのでは、と思った。
アイデアをメモ。

【参考】
SysML要求図をGSNと比較する

astah* GSN - Goal Structuring Notation描画支援ツール

astahGSNのメモ: プログラマの思索

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

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

因果ループ図(いんがるーぷず):情報システム用語事典 - ITmedia エンタープライズ

システムのリリース後に本番障害が出ると、必ず原因分析と再発防止策を作る必要がある。
その時の分析手法として、GSNは因果ループ図を使えないか?

本番障害の原因分析にはなぜなぜ分析を使う時が多い。
5回のなぜで深掘りする。
しかし、実際は使いにくい。
なぜなぜ分析する時の観点、フレームワークが事例ごとに個別なので、どこを切り口として深掘りすればいいかわかりにくい。
原因を洗い出してもそれが因果関係として正しくても論拠として浸かるか、本当に真因なのか、疑問が残る。
たいていは、設計書を残らず書く、テスト漏れをなくす、PJメンバーに経験者を入れる、みたいなありきたりな再発防止策になりやすい。

GSNを使う利点は、障害の原因分析の論点、因果関係を明確にしやすいこと。
論拠とデータがセットになっているのもよい。

因果ループ図を使う利点は、悪循環の構造を明確にしやすいこと。
QCDが悪化した状態は、何らかの悪循環のループがシステムとして埋め込まれて、そう簡単には壊せない。
本番障害が出るということは、原因分析や再発防止策をきちんと行わなければ、必ず二度目も起きる。
その構造を浮き彫りにできる。

一方、これらのツールにも課題はあると思う。
GSN、因果ループ図を扱えるツールが少ないこと。
この課題は、astah GSN、astahの因果ループ図プラグインで解決できる。
あるいは、GSNは所詮、ロジックツリー構造なので、マインドマップでも代用できる。

GSNで描くと、20個以上の要素がたくさん出てきて、複雑化しやすい。
ロジカルシンキングと同じで、因果関係はすごく丁寧に書き出す必要があるから、どうしても要素は細かいレベルになりやすい。
すると、20個、50個と要素が出てきて、整理するだけでもかなり手間取る。

因果ループ図は、悪循環の構造を表現する要素をうまく抽出しないと、肝心の解決策を見出しにくい。
ループになっている要素のどこかを変化させることで、ループを弱めたり、別のループを生み出すように解決させていくので、要素が真因であるように見出すのが大事。
実際はそれが難しい。

この辺りは色々アイデアが浮かぶのでこれから整理してみる。

| | コメント (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/04/26

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る

SECIモデルの状態遷移図を描いて、ようやくSECIモデルを理解できた気がする。
ラフなメモ。

【1】2014年頃に、SECIモデルでパターン言語を理解しようと考えていた。
確かにパターン言語と相性は良いが、SECIモデルのイメージがまだピンときていない気がしていた。

SECIモデルは、PDCAみたいなマトリクスよりも、知識・経験の状態遷移図で描く方が理解しやすいと考えた。
形式知=知識、暗黙知=身体による経験。

【2】知識を使って身体に落とし込むのが内面化。
スポーツ、楽器、お絵描きなどの訓練が相当するだろう。

一方、身体で経験した内容を知識でまとめるのが表出化。
一流のスポーツマン、学者、音楽家、宗教家、哲学者たちは、自分たちの体験を何とか知識として言語化し、みんなに広めようとする。
走る哲学者と言われる為末大さんみたいな感じかな。

他方、形式知を組み合わせて新たな知識を創造するのが連結化。
感覚的に情報を受け取って暗黙知を高めるのが共同化。

【3】知識は経験よりも大切なのか?
経験は知識よりも勝るのか?

僕は両方を経験している。

IT技術者であれば、たくさんのプロジェクトで新技術や業務システム開発を経験した後で専門書を読み直すと、ああ、そういうことだったのか、と気づく時が多い。
中島聡さんは、プログラミングとは、座学で勉強するものではなく、実際にアプリ開発して体験した後で専門書で答え合わせするものだ、と言われていた。
そんな内容と似ている。

実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

僕がRedmineにハマったきっかけも、XPやアジャイル開発の本はたくさん読んだが、何か腑に落ちることがなくて、Redmineでいろいろ試して初めて分かったという事があった。
知識がいくらあっても、やはり体験しなければ、本当に理解できた、という感覚がない。
肌感覚では分かった気にならなかった。

一方、IT企業やプロジェクトという組織形態では、いつもイライラするものがあって、その原因がなにか分からない時があった。
組織文化はトップが作るのか、ボトムアップで作られるのか、いつも疑問に思っていて、アジャイル開発の影響から、組織文化は現場からボトムアップで生まれるのだろうと思っていたが、診断士の先生に聞いたところ「組織文化を生み出す責任は社長にある。もっと社長が汗をかけ!」と言われて、ハッと気づいた時があった。

制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索

組織文化はトップが作るのか、ボトムアップで作られるのか: プログラマの思索

同様に、組織論、経営戦略論、経済学などを勉強してみて、メンバーに応じた教育方法ならSL状況理論やPM理論を使ってみたらいい、とか、プロマネとPMOの微妙な対立関係はエージェンシー問題に似ているな、とか、知識を使って、自分なりに理解が進んだ気がした。

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

ITの地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

また、RedmineでRubyのソースコードは適当に触っていたがRubyはちゃんと理解できてなかった。
RubySilverやRubyGoldを勉強してみて、Rubyはオブジェクト指向言語を徹底しているんだな、と改めて理解し直した。

Ruby技術者認定試験の感想: プログラマの思索

そんなことを考えると、知識と経験の相互作用として、SECIモデルの内面化、表出化を行ったり来たりしながら自然に実践している。
そして僕はたぶん、実際に色々体験して、失敗を繰り返さないと腑に落ちないみたいだ。
そういう感覚はSECIモデルの状態遷移図で整理できるんだな、と改めて感じた。

| | コメント (0)

2022/01/01

ITの地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること

ITの地殻変動はどこで起きているのかを2022年現在で考えてみる。
ラフなメモ書き。
特に後半は、ロジックが飛んでいるが、自分のアイデアを書き残すことに重点を置く。

【過去の記事】
ITの地殻変動はどこで起きているのか?~2006年: プログラマの思索

ITの地殻変動はどこで起きているのか?~SeasarとRuby、そしてPF: プログラマの思索

ITの地殻変動はどこで起きているのか?~チケット駆動開発はなぜ生まれたのか・2009年: プログラマの思索

ITの地殻変動はどこで起きているか?~Agile2.0をサポートするチケット駆動開発: プログラマの思索

ITの地殻変動はどこで起きているのか?~チケット駆動開発が進むべき道: プログラマの思索

ITの地殻変動はどこで起きているのか?~アジャイルへの流れと設計技法の違和感: プログラマの思索

ITの地殻変動はどこで起きているのか~アーキテクチャ設計技術にクラウドが必須になった時代: プログラマの思索

ITの地殻変動はどこに起きているのか~ソフトウェアの複雑さをどのようにして手なづけるか?: プログラマの思索

ITの地殻変動はどこで起きているのか~技術革新の流れはWebから機械学習やデータマイニングへ: プログラマの思索

【1】コロナ時代でのソフトウェア事業の問題点

ソフトウェア開発やソフトウェア事業を中核としたIT事業は、2000年頃から大幅に広がり、コロナ時代に入るまでに、GAFAに代表されるように全てのビジネスの中核となった。
ソフトウェアこそが今は、すべての事業の中核システムにある。
コロナ時代になって、対面での営業、対面での人間関係が厳しく制限されて、全ての人間関係がオンライン上で実行せざるを得ない環境に追い込まれて、ソフトウェアはビジネスだけでなく、人々の生活インフラの中核にまで覆い尽くした。

従来の製造業、小売業などの従来型のビジネスモデルは、ソフトウェアを基盤とした事業モデルに大きく変革を強いられた。
それは、業務を単にIT化するだけではない。
単なる業務のペーパーレス化、情報の一元管理が目的なら、コスト削減が目的であり、それはERPというパッケージ製品の導入と同じだ。

では、どんな変革を強いられたのか?
それは、ソフトウェアで作られたシステムを基盤として、企業が提供する価値とそれを購入して消費する顧客をつなげるバリューチェーン全てをシステムで一元管理することだ。
今風に言えば、それはプラットフォームビジネスであり、DXであり、SoEとも呼ばれるのだろう。

全てのバリューチェーンをシステムで一元管理できるとどんなメリットが出てくるのか?
それは、製造業の生産プロセス、小売業の販売プロセス、在庫プロセスという企業内部の情報を一元管理できるだけでなく、販売した顧客の購買履歴や活動履歴をも一元管理することで、顧客関係性を強化でき、顧客の声を生産プロセスや販売プロセスにフィードバックすることで、自社の業務プロセスを改善できるチャンスが増えることだろう。
しかも、アジャイル開発を適用できれば、1ヶ月間というスプリントよりももっと短いサイクルで業務を改善する仕組みさえ作れる。

このDXというソフトウェア基盤にはクラウドというスケールしやすいインフラがあり、MLやDLのようなAI基盤を使って、顧客が望むものを分析し提示することすらできる。
DXを構成する開発基盤や技術が一通り揃ってきたからこそ、すべての事業をソフトウェアで丸呑みして完全に実現できるようになってきた。

事業を一度ソフトウェアで実装してしまえば、アジャイル開発プロセスに従って、いつでも方針の変更が容易になるし、顧客の情報をより簡単に入手できて分析できるから、ビジネスのKPIに適用して、ビジネスそのものの診断ツールにも使える。

しかし、製造業も小売業もその他の業界の事業も全てソフトウェアで実装してしまえばいいだろうが、実際にはその転換は従来のビジネスモデルを構築した企業ほど難しい。
なぜ、ソフトウェア事業へのビジネスモデルの転換は難しいのか?

【2】DXとは「逆コンウェイ戦略を適用する」組織論である

ソフトウェア事業へのビジネスモデルの転換は難しい理由は、ソフトウェア事業に向いた組織を作るのが難しいからだろう。
チャンドラーは、組織構造は経営戦略に従う、と言った。
つまり、ソフトウェア事業に向いた組織構造を構築する必要がある。

一方、コンウェイは、ソフトウェアは組織構造に従う、と言った。
複雑な多重階層構造を持つ組織は、ソフトウェアをより複雑化させる。
人月の法則の通り、ソフトウェアの本質は複雑性にあり、ソフトウェアの複雑性を飼いならすのは非常に難しい。
つまり、ソフトウェア事業に向いた組織構造を作ろうとするが、従来の組織に単にソフトウェア開発を担当させるだけでは上手く行かない。

特に、ソフトウェア開発は、規模の経済が適用しづらく、少数精鋭の優秀な人材の開発チームで実行する方が成功しやすい。
だから、従来の製造業や小売業のように、大規模な設備、大量の人員を用意していても、ソフトウェア開発には向かない。
人月の法則の通り失敗しやすい。

そこで、コンウェイの法則の逆張りを考えて、逆コンウェイ戦略を取ってみてはどうか、という話になる。
つまり、ソフトウェア開発は少人数の開発チームの方が適しているなら、システムの構造に従って、開発チームを構成し直して、そこから組織を作ればいいのでは、となる。
たぶん、今、ScrumがIT企業だけでなく、製造業や小売業など他の業界にも適用されて浸透しようとしているのは、そういう理由があるのではないか。

たぶん、そういう動きは一部の企業に過ぎないだろうが、ソフトウェア事業が中核になれば、従来型の企業もそういう流れに傾いていくのだろうと思う。

DXとは組織論である: プログラマの思索

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

【3】今後の課題は、ソフトウェア事業におけるエージェンシー問題を解決すること

他方、会社という大きな集合体の中で、ソフトウェア事業を委託する人と、ソフトウェア事業を実行するの間には、利益が相反する緊張関係があると思う。

株主や経営者、生産プロセスや販売プロセスに従事する事業部門の人達は、プリンシパル(=委託者)になる。
彼らはソフトウェアやITに詳しくはないので、専門技術を持つエンジニアに、事業のソフトウェア化を実現するために、事業システムの構築を依頼する。

一方、エンジニアは、プリンシパルのために代理で活動する代理人をエージェント(=受託者)になる。
彼らは、ITの専門家として、プリンシパルの目標や要望を聞き出し、彼らの期待を実現する為に働く。
彼らは、事業のソフトウェア化を実装するために、業務システムだったり、Webシステムだったり、スマホアプリだったり、機械学習基盤だったり、クラウド基盤だったり、いろんなソフトウェア基盤を構築してリリースする。

しかし、経営学で習ったプリンシパル=エージェント理論では、エージェントがプリンシパルにとって望ましい行動を行わないというエージェンシー問題が必ず発生する。
一般に、エージェンシー問題が生じる要因として、「プリンシパルとエージェントの利害の不一致」と「情報の非対称性」の2点がある。

組織運営支援|マーサージャパン

ソフトウェア事業でも、委託する人達はシステムのことが分からないので、結局は、委託者であるSIの言いなりになってベンダロックインされやすい。
製造業や小売業などの発注者も、システムのことは分からない、システム開発をコントロールする難しさは体験済みなので、一括請負契約を結ぶことでシステム開発リスクをSIに全て押し付けようとするが、どうやってもベンダロックインされやすい。
その理由は以前書いた。

一括請負契約はソフトウェア開発にやっぱり向いていない: プログラマの思索

【4】ソフトウェア事業におけるエージェンシー問題を解決するための組織構造とは何か?

従来型の生産プロセスや販売プロセスを持った事業をおなっている会社が、ソフトウェア事業を中核に据えようとする場合、下記のようなイメージで、ホールディングスの持株会社を作り、親会社と事業子会社とシステム子会社がそれぞれ役割分担と制御構造を持つ必要があると考える。

親会社(ホールディングス会社)の役割は、企業グループの全体戦略を策定することだ。
その全体戦略に従って、個別の事業の戦略を策定し、その事業に必要なIT戦略、つまりシステム投資の計画を策定する。

事業子会社は、親会社が策定した事業戦略に従って、その事業に合った業務プロセスを構築し、その業務を実行する。
事業を支える業務には、業務システムが使われるため、自分達の事業に合った業務システムの要求や要件をシステム子会社に提出したり、一緒にIT計画を策定することになる。
事業子会社の成績は、事業のROIで測定されるので、事業のROIを親会社に毎年報告することになる。

システム子会社は、親会社が策定したIT戦略に従って、個別の事業を支援する業務システムを構築し、保守していく。
彼らは、事業子会社の事業戦略に従って、いつまでにリリースする必要があるのか、どれだけの開発予算が必要になるのか、をシステム計画としてまとめて、システム計画を事業子会社と親会社に承認してもらってから、実行に移すことになる。
つまり、システム子会社の主な仕事は、事業を支える業務システム構築とその保守になる。

ここで重要な点は、事業は外部環境や市場の変化によってどんどん変わるので、事業を支える業務システムは一定期間しか使われないという前提で、リプレースする期間と計画を事前に策定する必要がある点だ。
たぶん、減価償却が5年間という制約条件とか、外部環境の変化で事業の寿命は5年とか、そういう単位で、業務システムは定期的に破棄されて、新規に再構築されるように計画しておく。
そうすれば、事業小会社の事業では、たとえば5年おきに新しい業務システムに支えられるので、その時代の最新技術が使えたり、その時代の要件に合ったシステムを使えるようになる。

このように、定期的にシステムはリプレースすべきだ、と親会社も事業子会社もシステム子会社も事前にIT戦略に埋め込んでおけば、時代の変化にあった事業に対応できるはずだ。

さらに、上記のような三者の組織構造があれば、システム子会社は親会社や事業子会社に定期的に報告する義務が生じることで規制をかけられるし、システム構築の目的が親会社や事業子会社の要件に合うように考えさせられるので、システム子会社が暴走するリスクも小さくなるだろうと思う。

【5】事業を支えるシステムの企画は誰が責任を持つのか?

一般の日本企業では、メーカーであれ、ユーザ企業であれ、SI企業であれ、予算駆動だから、システムが必要になったら、その企画フェーズが必要で予算取りの根拠を作らねばならない。
では、その企画フェーズを担当する最終責任者はいったい誰なのか?

ソフトウェアPJの企画フェーズの責任者は誰なのか?: プログラマの思索

本来は、システムの企画フェーズでは、親会社や事業子会社が主導権を持って、事業に必要なシステムの要求や要件を企画すべきである。
なぜなら、彼らが使いたいシステムなのだから。

しかし、僕の経験でもそうだが、ITやシステム開発を経験していない人達がシステム企画を担当すると、割と揉める。
いろんな要求や要件は出てくるが、その時代に合ったIT技術を組み合わせて、品質・コスト・スケジュールのトレードオフに落とし込む作業が難しいのだ。
結局、システム子会社を持たない発注者は、SIやITコンサルに丸投げして、だめなシステムを計画してしまいがちになる。

システム子会社を持っていても、彼らがソフトウェア開発部隊を持っていなかったり、クラウドやAIなどの新技術に関するソフトウェア開発の経験がなければ、SIベンダに丸投げするリスクがある。
結局、企業グループの中核にシステム子会社を持ち、彼らが一通りの技術力を常に研鑽しておかなければならないのだ。

だから、システム子会社の開発者が企画プロセスに入り込んで、彼らが主導権を握る場合が多い。
そして、親会社・事業子会社のユーザと、システム子会社の開発者の間で、対立関係が発生する時もある。
AsIsはユーザが詳しいが、ToBeはユーザでは作りにくい。
開発者がToBeを作ることが多いが、ユーザが果たして納得してくれるのか?

こういう問題にどう対処するか?
たとえば、匠メソッドの匠モデルではこたつモデルを持ち出す。
ユーザ・開発者・営業担当者がいきなりToBeモデルを作る。
事業側も開発側も同じゴールを目指すべきという思想で対応するからだ。

たとえば、Scrumでは、プロダクトオーナー1人が企画プロセスを担当するだろう。
プロダクトオーナーがいるおかげで、開発チームは彼を頼りにしてシステム開発に専念できるはず。

Scrumではどのプロセスを誰が担当するのかが明確ではないかと思う。
企画:ProductOwener
開発:Team
プロセス全体の守護神:ScrumMaster
という仮説も成り立つ。

それから、システムはリリースしておしまいではない。
システム投資の予算を立てて投資するのだから、投資対効果もIT計画に盛り込んで、リリース後に半年後、1年後に実際にROIが予定通りなのか検証したい。
そうしなければ、次のリプレースに活かせないからだ。
また、システム投資のROIを測定する作業をシステム子会社に課すことで、彼らにROIの意識付けもできるようになる。

システムの投資対効果(ROI)を検証するプロセスはどんな構造になるのか?

GoalやToBeでは、システム構築の目的にROI向上(工数削減、経費削減、売上向上)があるはず。
たとえば、システム化することで、手作業から自動化されて工数が削減される。
ペーパーレス化されて、経費が大幅に削減される。
システム化されて、新規顧客に利用してもらって、売上拡大を図る。
そんな内容がROIになるだろう。

稼働後に検証しなければ、一連のPDCAが回らない。
投資対効果=ToBe-AsIs で測定することになる。

企画プロセスでToBeを定めているので、リリース後に実際に、工数や経費、顧客数と売上を測定して、その差分を見ればいい。
もちろん、リリースが遅れると、その分、投資対効果が得られる期間が先延ばしになるので、メリットが薄くなる。
システム構築のコストが増えれば、もちろん投資対効果は薄れるし、使いづらいUIだったり、処理が遅かったり、まともに動かないシステムだったら、投資対効果はゼロかマイナスになってしまうだろう。

【6】こういうホールディングス会社、3社の企業構造をもたせれば、ソフトウェア事業におけるエージェンシー問題をかなり和らげて、エージェントであるシステム子会社が暴走したり、システム構築の目的を忘れてしまうリスクを減らせるのではないだろうか?

逆に言えば、IT計画策定やROI測定などの仕組みを課さないと、事業を支える業務システムを構築できないのではないだろうか。

| | コメント (0)

チケット駆動開発のプロセスと開発基盤を再考する #Redmine

チケット駆動開発のプロセスと開発基盤を書き直してみた。

チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine: プログラマの思索の図を改良している。

チケット駆動開発は基本的に、ScrumやXPに似たアジャイル開発のプロセスと同一視される。
なぜなら、ロードマップをScrumのスプリント計画、XPのイテレーション計画とみなして、リリースサイクルに従って定期的にリリースされる仕組みとみなせるからだ。
つまり、チケット駆動開発は小規模リリースを実現するプロセス基盤でもある。

他方、チケット駆動開発というプロセスから発生する情報は、チケット管理ツールに全て集約される。
チケット駆動開発プロセスは、チケット管理システムに支えられて実装される。
チケット管理システムの構造は、Input,Process,Outputという単純なプロセスから成り立つ。
中核となるPMISは、フロー管理とストック管理という2つの機能を持つ。

フロー管理の機能は、チケット管理、チケット集計、ロードマップ、ワークフロー管理などがある。
つまり、チケットは流通媒体であり、ステータスに応じてサクサク流れる。
チケット集計には、ガントチャート、カレンダー、かんばんなどがある。
ロードマップとチケット集計を区別したのは、ロードマップがScrumのプロダクトバックログに似た機能であり、スプリント計画あるいはイテレーション計画で使われる重要な機能だからだ。

ストック管理の機能は、チケット管理、SCM連携、Wiki、トレーサビリティなどがある。
つまり、チケットは記録媒体であり、作業履歴や課題の内容、障害管理票などの帳票として記録される。
ただし、記録される媒体はチケットだけでなく、Wikiもあるし、GitやSVNなどの構成管理ツールにもある。
これらの情報と相互リンクすることで、チケット管理ツールにすべての情報が集約されて、ナレッジ基盤になる。

チケット駆動開発はプロセスであるから、処理が主人公になる。
一方、チケット管理システムは機能から構成されるので、機能を通じて記録されるデータが重要になる。
そのデータの特徴はフローでもありストックでもある。

チケット管理システムは、チケットにフローとストックの両方の意味を故意に持たせることで、幅広い運用が可能になる。
ある側面では、タスクかんばん上でステータス管理できるし、ある側面では、そのタスクや課題のチケットには、数多くの情報が記録されているし、その変更履歴も記録されているので、経緯や意図を把握できる。

このチケットの二重性という特質がチケット管理ツールに豊かな機能や利用シーンを生み出してくれるのだ。

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

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

JIT改善による赤字悪化を因果ループ図で描いてみた

“JIT生産”を卒業するための本―トヨタの真似だけでは儲からないを読んだら、JIT改善による赤字悪化の構造が書かれていたので、それを真似て因果ループ図で描いてみた。

JIT改善のポイントは、ボラティリティをできるだけ減らす為、平準化生産を目指すこと。
自動車のような製品は、最終組立メーカーが需要をコントロールできるので、平準化生産しやすい。
しかし、一般の工業製品、食品加工品、季節モノの衣料品などは、平準化生産をやりにくい。
そんな製品にJIT改善を適用すると、こんな赤字悪化の因果ループ図になるのでは、という構造がよく見える。

astahで簡単に因果ループ図を描けるのがとても良い。

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

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

思考力と注意力のトレードオフを因果ループ図で描いてみた: プログラマの思索

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


| | コメント (0)

2021/12/21

現代の営業プロセスは分業化されている~THE MODELの感想

THE MODEL(MarkeZine BOOKS) マーケティング・インサイドセールス・営業・カスタマーサクセスの共業プロセス」を一気に読んだ。
SaaSをベースとした現代の営業プロセスとはこんなものなのか、ということが分かっただけでなく、営業というものが何なのか、何となくイメージできた気もした。
ラフなメモ。

THE MODEL(MarkeZine BOOKS) | 翔泳社の本

過程を自分のものにすればどんな環境でも再現できる 『THE MODEL』出版記念イベントレポート (1/2):MarkeZine(マーケジン)

営業効率を最大化する「The Model」(ザ・モデル)の概念と実践 | セールスフォース・ドットコム

MQL(Marketing Qualified Lead)とは

理解した事は3つ。
たぶんこんなストーリーだと思う。

【1】一つ目は、現代の営業は商談前に既に終わっていて、その前のリード獲得とリード育成が鍵である事。

この営業プロセスはSaaSのようなサブスクリプションのビジネスモデルに向いているし、SaaSならリードのアクセス履歴から顧客の活動履歴ら顧客満足度まで全てトレースできるのが強みなので、まさにカスタマーエンゲージメントに注力しやすい。

SFAは商談の管理と言う狭いパッケージ製品であり、CRMはリード獲得とリード選別から商談、アフターフォローまで全ての業務を含むパッケージ製品。

日本企業のパッケージ製品はSFAが多い。
それらは、営業マンの日報管理システムに過ぎない場合が多いと思う。
だから、すぐに飽きられるし、そんなに役立たない。

一方、CRMでは、見込み客をLeadと呼んで、受注済みの顧客と区別する。
さらに、LeadをMQL(Marketing Qualified Lead)とSales Qualification Leadに区別し、MQLを発掘する部署とSQLへ育てる部署を分業化する。
MQLを経て見込度を高め、SQLへと育成していき、最終的には商談時に契約を結んで顧客へ導く。

【2】二つ目は顧客フォロー、別名はカスタマーサクセス、カスタマーエンゲージメントが重要である事。

SaaSの営業プロセスでは、顧客に毎月の契約更新を促す必要がある。
顧客満足度を上げるために、どんなフォローが良いのか、どんなプロモーションやキャンペーンが有効なのか?
それらは、顧客の活動履歴を通じて、顧客の不満を読み取り、顧客が満足してくれるような対策を打てばいい。
大量のアクセス履歴をデータマイニングしたり、機械学習や深層学習エンジンに食わせて、彼らの心理構造を見抜き、対策を打てばいい、みたいな感じになるのだろうか。

【3】三つ目は、現代の営業プロセスは分業されていて、プロセス間の移行判定基準とプロセス実行結果であるKPIを準備して、評価されて決まる事。
もちろん各プロセスには部門や担当者がアサインされて、KPIが彼らの業績指標として文字通り評価される。分業されているから、未経験の新人も、プロセス毎に経験を積んでいき育成もできる利点がある。

KPIは、Leadが契約する顧客に至るまでの各プロセスの通過率。
KPIは、各プロセスのフィルタリングみたいだ。
このKPIが低いプロセスがボトルネックなので、その原因をさらに分析して対策を立てる。

たとえば、リード→商談→受注では、商談化率、受注率を見る。

この本の面白い点は、リード→商談→受注の各プロセスで脱落したLeadを将来の見込み客とみなして、「リサイクル」することだ。
つまり、未商談、失注、未フォローの既存顧客は、リサイクルされて、新たなLeadに生まれ変わるようになる。

【4】「THE MODEL(MarkeZine BOOKS) マーケティング・インサイドセールス・営業・カスタマーサクセスの共業プロセス」を理解するために、astahでモデルを色々描いてみた。

THE MODEL(MarkeZine BOOKS) マーケティング・インサイドセールス・営業・カスタマーサクセスの共業プロセス」では、業務プロセスやLeadの概念、組織の関係図などが数多く記載されているので、astahで真似しやすい。
理解した内容はまた今度まとめる。

Photo_20211221223103

Photo_20211221223102

Photo_20211221223101

Photo_20211221223001

| | コメント (0)

2021/11/14

PlantUMLはJSONやYAMLのデータを視覚化できる

PlantUMLはJSONやYAMLのデータを視覚化できる記事を見つけたのでメモ。

PlantUML で JSON データを簡単視覚化

JSONやYAMLはDockerとかAPI連携でよく使うが、文字列の羅列なのでイメージしにくい。
しかし
PlantUMLを使えば、データをER図やクラス図みたいにモデルで図示できるので、全体像を把握しやすい。
こういう使い方もあるんだな、と気づいたので、今後試してみる。

| | コメント (0)

より以前の記事一覧