astahによるUMLモデリング

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)

2021/09/26

astahのセミナーレポート「サンプルモデル図で解説、MBSEの流れとモデルの役割」の感想

astahのセミナーレポート「サンプルモデル図で解説、MBSEの流れとモデルの役割」の記事と動画が公開されていたのでメモ。
参考になった。

【参考】
セミナーレポート「サンプルモデル図で解説、MBSEの流れとモデルの役割」 | astah in 5 min

電気ケトルを題材にして、SysMLと安全性の観点からモデルを描いて詳細化していく流れ。

重要な考えは、モデル種類x検討した観点のマトリクスでSysMLのモデルを使い分けること。
モデル種類には、用語、構造、接続性、状態、プロセス、シナリオの6種類がある。
前半がブロック図、後半は状態遷移図、アクティビティ図、シーケンス図に対応する。

検討した観点には、Usage、Function、Implementationなどがある。
順に詳細化していく感じ。

気づきは、SysMLのそれぞれの図は関連していること。
動画を見ると、ブロック図やユースケース図の要素にハイパーリンクがあって、リンク先にブレイクダウンしたシーケンス図やステートマシン図がある流れだった。
こういう風にモデルがトレースされて作られていくならば、説明しやすいし理解しやすいと思う。

ブロック図の使い方は分かっていなかったが、利害関係者を含むコンテキスト図やハードウェア部品構造、機能とハードウェア部品の関係に使うらしい。
SysMLではブロック図が一番重要なモデルに思える。
ちょうど、UMLではクラス図が一番重要であるように、SysMLではハードとソフトが関係するモデルとしてブロック図が設計図に相当するように思えた。

個人的には、モデリングのプラクティスみたいなものも資料に添えられたら役立つだろうと思った。
たとえば、オブジェクト指向設計でも、SOLID原則、GRASPパターンのような基本プラクティスがあり、そのプラクティスを使うことで、クラス図の責務割当がスムーズに行くからだ。
SysMLでも、オブジェクト指向設計のプラクティスは使えるだろうが、SysML特有のプラクティスや組み込みソフトウェアならではのプラクティスが知りたいところだった。

この辺りは色々調査してみたい。

| | コメント (0)

2021/07/23

値オブジェクトの設計がオブジェクト指向モデリングの最初の登山口

先日7/14に開催された「アジャイル開発におけるモデリング活用実践セミナー」のオンライン動画を見ていて、興味深かった。
羽生田さん、増田さん、原田さん達の会話が面白かった。
気になった発言をラフなメモ。
自分の感想も混じっていて、全くロジカルでない。

【参考】
「アジャイル開発におけるモデリング活用実践セミナー」(2021.07.14開催) - UMTP 特定非営利活動法人UMLモデリング推進協議会

ドメイン駆動設計が好きで、ベンチャー企業のWebサービスの開発で使っている

最近は、基幹系システムのリプレースでドメイン駆動設計を使いたい、という話も多く来ている
すごく難しいけど、やりがいもあるし面白い

オブジェクト指向モデリングのワークショップでモデルを書こうとすると、みんな、フレームワークが前提でモデルを書いてしまう
ドメインの外側ばかり話している
肝心のドメインをプログラミングしようとすると、意外に誰も書けない
まずは値オブジェクトから始めよう
みんな、値オブジェクトでプログラミングできない
増田さんのオブジェクト指向モデリング本「現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法」は、値オブジェクトから書こうとしているのでお勧め

intやStringのデータ型だけではトランザクションスクリプトみたいに書いてしまう
値オブジェクトが大事
オブジェクト指向では、Immutableな値オブジェクトから始まる
関数的プログラミングとも相性がいい
ドメインに特化してプログラムを書こうとすると、必ず値オブジェクトから始まる
値オブジェクトの設計がオブジェクト指向モデリングの最初の登山口

エンティティを重視するとデータモデリングになってしまう
手続き型プログラミングで、でかいエンティティを書いて、長いトランザクションスクリプトを書くと失敗する
書いていて怖い
データモデリングとオブジェクト指向モデリングは違うと考えた方がいい

エリック・エヴァンスのDDD本「エリック・エヴァンスのドメイン駆動設計」に出てくる例では、OODBを使っていた
昔はデータのストアはOODBでいい、という感じだった
OODBでは性能が出ないので廃れた

業務の複雑さに関するデータのモデリングは、データモデリングの方が一日の長がある

1990年代にモデリングが盛んだったのに、現代ではモデリングが廃れたのは、モデリングが伝承されなかったからではない
むしろ、現代的な課題に対して、長年知られていたモデリング手法のこの部分は今も使えるが、この部分は今は使えない、という交通整理された本がほしいね

2010年代にピアソン本が絶版されたので古いオブジェクト指向モデリング本が手に入らなくなり、エリック・エヴァンスのDDD本「エリック・エヴァンスのドメイン駆動設計」だけが唯一残った
そのために、オブジェクト指向モデリングの歴史に断絶がある

メソッドは3個まで
それができない人は、クラス化、カプセル化が分かってない
入出力処理は手続き型になりやすい

顧客との対話では、UMLを普通に使う
ただし、アクティビティ図、コンテキスト図、データフロー図を使う場合が多い
システム要件に落とす時は、UMLをガンガン使う

要件定義でモックを作るときはHTMLを使う
最近はいい感じですぐにモックデザインが作れる
実データを画面で見せた方が早い

プロダクトオーナーとの対話では、RDRA2.0を使って話する時が多い
システム設計では、UMLを使っている
図を書くのが目的ではなく、会話や意思決定のために使っている

DDDのエンティティはミュータブル?イミュータブル?
Webならイミュータブルが普通でしょ
setter, getterと無関係なモデルにしている
イミュータブルが普通
エンティティに状態は持たせない
void実行でなく、新しい状態のオブジェクト、エンティティを別で返す
Webならイミュータブルが普通
エンティティの状態をSetして変更すると、バグが出そう
イミュータブルだからFreezeしているのでCloneする必要もない

アジャイル開発プロセスとモデリング作業の事例は?

モデリングでも、概念モデルのレベルでプログラミングを書く
合わせてDFDやER図を書く
事業分野の可視化はシステムで書きにくいので、シナリオ、バリューチェーンを書く
バリューチェーンで、どこのプロセスに差別化要素があるか、強みがあるか、を分析する
ビジネスを理解するモデリングとシステムとして動かすプロトタイプの2つを行き来している

増田さんのドメインモデルのサンプルが分かりやすい
パッケージ図でクラス図を分割して、HTMLで一覧にしている
さらに、ユースケースのシナリオからパッケージ図、クラス図まで一気通貫でHTMLにしている
軽量で明快なモデリング
ビジネスモデルとDFD・ER図をつなぎつつ、パッケージ図・クラス図で方にしてHTMLで見せている
増田さんのクラス図は値オブジェクトが中心
取引日、貸し出しも全てクラスになっている
増田さんにとって、モデル駆動とはドキュメント駆動のイメージ
ソースコードとモデルを行き来していて、モデルが自然にドキュメントになっている

Scrumで開発する時に、ユーザーストーリーマッピングを使う場合が多い
このメソッドを実装する時、このメソッドはこの要件から来ていて、この要件はユーザーストーリーマッピングのこの部分に対応する、と辿れる

【感想】
エリック・エヴァンスのドメイン駆動設計現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法を読むと、ドメインのソースコードが値オブジェクトになっている場合が多い。
その理由は、ドメインをプログラミングに注力しているから、と見ると分かりやすい気はする。
オブジェクト指向でプログラムを書くと、状態を持たせるエンティティが頻出して、バグが出やすい箇所はたいていその部分であり、デバッグしないと追跡できない場合が多いのを思い出した。

| | コメント (0)

2021/07/11

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

組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」を読んでいて、面白いのでメモ。
10年以上も前にかおるんさんは既に読破されているので参考にしている。

【参考】
読了・組み込みソフトウェア開発のためのオブジェクト指向モデリング - ブログ@kaorun55

読了・組込みソフトウェア開発のための 構造化モデリング - ブログ@kaorun55

【1】上記のブログでは、「組み込みとしては、やはりこちら(構造化)の方がしっくりくる。なんとなくオブジェクト指向の方は無理をしている気がしてならない。」という感想がある。
オブジェクト指向モデリング」よりも「構造化モデリング」の方がしっくり来るらしい。

一方、僕は、構造化設計の技法は、データフローダイアグラムとかSTS分割のような古い技法に違和感があって、むしろ、オブジェクト指向設計の方針でクラス図、シーケンス図、状態遷移図からモデルを作り出す方がしっくり来る。
だから、「構造化モデリング」よりも、「オブジェクト指向モデリング」の方が、読みやすく感じた。
なぜなら、オブジェクトで考える方がレイヤ化設計、状態遷移図などのモデルを自然に組み立てられる気がするから。

【2】たとえば、組込みSW開発の経験はゼロだが、組込みSWのモデルをユーザ視点の業務ロジック層と、物理法則やセンサーから検知した情報の制御を含む制御層の2つに大きく分けてモデルを組み立てる方針の場合、オブジェクト指向設計の方がパッケージでソフトェアを分割してレイヤ化しやすい利点があると思う。

以前、astah関西で、高井さんがSysMLを使う利点として、熱力学など自然科学の専門家、自動車や家電機器などの業務の専門家、ハードウェアの専門家、そして組込みSWを開発するプログラマの4種類の人達が、SysMLを通じてコミュニケーションできるようになった、という話もあった。

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

また、状態遷移図とは、一つのオブジェクトに着目してその状態が遷移した過程を表すので、クラス図で洗い出したオブジェクトから自然に状態遷移図で考えるように仕向けられる。

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

【3】興味深いのは、組込みSW開発の要件定義で重要な成果物として、ユーザ視点のユースケース分析だけでなく、イベントリストも挙げられている点だ。
たとえば、「構造化モデリング」「オブジェクト指向モデリング」の例では、電気ポットのソフトウェア要件定義で、ユーザがお湯を沸かすときのイベントだけでなく、ポットの水位やポットのお湯の温度の変化がトリガーとなるイベントも洗い出されている。
考えてみれば当たり前だが、アクターとして、ポットの購入者という利用者だけでなく、ポットという機械を構成するセンサー部品(水位の検知、温度の検知)もアクターになるわけだ。
つまり、組込みSW開発では、アクターの種類が多いので、コンテキスト図を最初に描くのが割と重要と気づいた。

【4】もう一つの「リバースモデリング」は読みかけだが、よくある事例な気がして、興味深く読んでる。
レガシーな業務システムと同じく、組み込みソフトウェアもレガシーになると、設計書はなくなっていて、動くソースコードが仕様そのものになっている。
しかし、数千行、数万行、数十万行のソースコードから本来の設計思想を汲み取って開発するのは至難の業だ。
たとえば、工場の生産ラインとか、長年使われている機械部品とか、そういう例があるのだろう。

リバースモデリング」では、レガシーと化したソースコードからリバースして、モデルを抽出し、本来のあるべきモデルを描き出し、そこから仕様変更や改修を手がけていく、というストーリー。
なかなかうまく行かないだろうが、色んな技法を駆使して、リバースしたモデルを洗練させていくのは面白い。
今なら、XDDPと組合せてやるだろうか?

【5】残念なことに、組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」は、「構造化モデリング」以外は絶版になっている。
3部作全てが復刊されるといいなと思う。


| | コメント (0)

より以前の記事一覧