ソフトウェア工学

2021/02/13

トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め

プロジェクトをリードする技術 / Project Leading is Skill - Speaker Deckを読んで、特に「トランザクティブ・メモリー」が良かった。
良い資料と思ったのでメモ。

【参考】
akipiiさんはTwitterを使っています 「良いスライド資料だなあ。進捗管理で、ボトルネックを常に移動させることは僕も感じていた。プロジェクトをリードする技術 - kakakakakku blog https://t.co/vB5toW5fSy」 / Twitter

プロジェクトをリードする技術 - kakakakakku blog



【1】プログラマ上がりのプロジェクトリーダーは、プレイングマネージャーだと思う。
すると、一人でプログラムを書いたり、自分でバグ修正した方が速いわけだが、それではチームは回らない。
いかにチームを回すか?

上記の資料で良いと思ったのは、アジャイル開発でやればいいんだ、みたいな一本調子ではなく、バランスが取れている所。
たとえば、「計画が得意=クリティカルパスの見極め」は、ガントチャートでも、バックログ管理でも、スプリント管理でも重要だ。

以前、どこかの本で、MSProjectでいちばん重要な機能はガントチャートではなく、PERT図だ、と喝破した記載があって、同意する。
優れたリーダーは、タスクにばらした時に、ネットワーク図をイメージして、どのパスが最短ルートなのか、を頭の中でイメージしている。

ソフトウェア開発が難しいのは、日々の状況によって、クリティカルパスがどんどん変化することだろう。
たとえPJ計画当初にガントチャートを作っても、初めての技術、コロコロ変わる要件、仕様への落とし込みで、クリティカルパスはコロコロ変わる。
つまり、ボトルネックは常に推移していく。
駄目なリーダーはガントチャート保守でボトルネックを見出そうとするが、その作業に追いつかずに破綻する。

【2】チームビルディングも重要な技術の一つ。
タックマンモデルとか色々あるけど、「トランザクティブ・メモリーを大切にしよう」という言葉は僕も同意する。
メンバーの役割分担をリーダーだけでなく、メンバー全員が知って、リレーのバトンを渡すように上手く回す。
そのためには、誰がどんな専門スキルを持ち、誰が暗黙知を持っているのか、を知っておけばいい。

「トランザクティブ・メモリー」は僕は以前は知らなかったので、もっと早く知っておけばよかったと思う。

「トランザクティブ・メモリー」という言葉は、「ビジネススクールでは学べない 世界最先端の経営学」ではなく「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」を読んで僕は初めて知った。

【3】「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」では、トランザクティブ・メモリーの社会実験でこんな話がある。

交際期間が3ヶ月以上の大学生のカップル60組を集めた。
そのカップルの半数はそのまま、残りはランダムな組み合わせのカップルにする。
そして、それぞれのカップルに、記憶力ゲームを試してもらう。

具体的には、科学、歴史、食べ物、テレビ番組などのカテゴリの文章を、カップルは自分の判断で選択して記憶し、どれだけ正確に記憶できていたかを試す。
カップルごとの合計点で評価する。
つまり、記憶作業は1人で行うが、パフォーマンスの優劣はカップルの合計で決まる。

この実験のポイントは、カテゴリ選択時にカップルが相談できないこと。
つまり、カップルはお互いに相手がどんなジャンルを覚えているのか、知らない。

さらに、交際していたカップルと赤の他人同士のカップルをさらに半分に分けて、もう一方には、男性は歴史、食べ物、テレビ番組、女性は残りのカテゴリと指定しておく。

つまり、
①交際しているカップルでジャンル指定のないカップル、
②他人同士でジャンル指定のなかったカップル、
③交際していて男女それぞれが覚えるべきジャンルを指定されたカップル、
④他人同士で男女それぞれが覚えるべジャンルを指定されたカップル、
の4つでランダム化比較試験を行うわけだ。

その結果はどうなるか?

①のカップルの方が②のカップルよりも結果が良くなった。
交際していたカップルの方が記憶力がいい、というのは常識の範疇。
なぜなら、交際していたカップルは、彼と彼女の強みの部分をお互いに知っているので、強みを発揮できるジャンルをお互いに選べばいいから。

しかし興味深いのは、③のカップルよりも④のカップルの方が結果が良かった。
つまり、あらかじめ記憶するジャンルを指定されてしまうと、交際していたカップルよりも、赤の他人同士のカップルの方が記憶力が良かったのだ。

この実験が意味していることは、「ある程度の交際期間を経たカップルは、お互いにどんな強みや弱みを持っているのか、というトランザクティブ・メモリーを自然に持つようになる」ということだ。
たとえば、彼が映画に強いけど彼女は弱い場合、彼女は彼に聞けばいい。
一方、彼女は美味しいレストランはよく知っているが、彼は知らない場合、彼女に聞けばいい。

つまり、Who knows What、誰が何を知っているのか、誰が組織内で特定分野の専門知識や経験を持っているのかを知っていること、というトランザクティブ・メモリーの重要性を示す。

他方、カップルとして自然に形成されたトランザクティブ・メモリーを新しい枠組みで無理に歪めると、非効率を生み出し、カップルの記憶力は著しく落ちてしまう。
むしろ、赤の他人同士のカップルの方が、ジャンル指定だけに基づいて記憶するので、トランザクティブ・メモリーを歪められてしまった交際カップルよりも、はるかに効率的に記憶できたわけだ。

この実験の話を読んで連想したのは、暗黙知を重視する、トランザクティブ・メモリー型の組織文化を故意に歪めた事例は割と多いのではないか、と思った。

たとえば、自社でソフトウェア開発しないユーザ企業やSIでは、大量の派遣プログラマを案件ごとに短期間に総動員してはリリース後に切り捨ている。
すると、案件のプロマネは、トランザクティブ・メモリーに依存しない、属人性のないPJ管理、属人性のない技術で管理したくなる。
そのやり方は、メーカーの単一製品の大量生産方式のように、単純労働者が多い場合には、トランザクティブ・メモリーを重視しなくても、効率的なオペレーション管理を重視すれば成功しただろう。

しかし、ソフトウェア開発のように、暗黙知があまりにも多いビジネスでは成り立たない。
むしろ、苦労して開発してリリースにこぎつけた時、数多くの暗黙知は派遣プログラマに残っているが、彼らが解き放たれたら、そのチームに得られた暗黙知は雲散霧消してしまう。

たとえば、M&Aで買収した企業の社員を、買収元の経営者が勝手に異動させてバラバラにさせてしまうと、せっかく買収先の企業の社員の中であったトランザクティブ・メモリーが破壊されて、M&Aの相乗効果が得られなかった、とか。

うまい例が思いつかないが、トランザクティブ・メモリーを有効活用していない組織や企業は、日本に割と多い気もする。

なお、「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」も「ビジネススクールでは学べない 世界最先端の経営学」の本もお勧め。

| | コメント (0)

2021/02/12

信頼度成長曲線の落とし穴

@MadoWindaheadさんの信頼度成長曲線の記事を読み直して、色々感じたことがあったのでメモ。

【参考】
信頼度成長曲線を語る夕べに参加 | マドびっ! Madosan's View

信頼度成長曲線については、過去に、SRATSのようなツールを試していた時もあって、色々考えていた。
個人的には、信頼度成長曲線は品質管理の中で華のような技術の印象を持っていた。
なぜなら、その他の品質管理の技法よりも、見た目は美しいが実際の中身は統計処理が含まれて割と複雑なので、研究するのにお手頃だから。

また、テストの収束傾向やテストの終了条件の判定に最終的に使うので、リリース判定というタイミングで使われるから、品質管理の中ではかなり重要な位置を占める。

いつテストを終わらせるか?: プログラマの思索

SRATSの使い方: プログラマの思索

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアに対する信頼度成長曲線の論文が面白い: プログラマの思索

テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索

アジャイル開発はメトリクスが取りやすい: プログラマの思索

忘れ去られた日本のIT技術~DOAと品質管理: プログラマの思索

しかし、上記の記事の書いてある通り、信頼度成長曲線は前提条件がある。
前提条件とは「単位テスト時間あたりの検出される不具合の数はテスト期間中を通じて一定している」こと。

信頼度成長曲線は別名、バグ収束曲線でもあるから、バグの発生傾向やバグの発生頻度が重要な観点になる。

僕の理解では、信頼度成長曲線の前提では、テスト作業プロセスそのものにバラツキはないと想定する。
つまり、「単位テスト時間あたりの検出される不具合の数はテスト期間中を通じて一定している」。

一方、システムの機能に依存したバグ数にばらつきがあっても良い。
実際、システムの機能に関係なくバグが機能毎に全て一定の割合で埋め込まれていたら、S字型曲線にはならず、直線になるはずだから。

具体的には、システムテストでバグ出ししていくと、最初はテストは順調に進んでバグもあまり出ないが、途中からバグが出る機能にぶち当たって、大量のバグを検出するフェーズになる。
そして、何とかバグを全て解決して、最後は、全ての機能をテストし終える頃には、潜在バグも残存バグも抽出しきって、バグも収束傾向になって落ち着く、というイメージ。
すなわち、バグ収束曲線はS字型曲線、イメージとしてはロジスティック曲線みたいな感じになる。

そういう経験則が成り立つ状況であれば、開発規模や過去のバグ密度の経験値、システム特性などを元に、信頼度成長曲線の予定曲線をゴンペルツ曲線とか、S字型曲線に似た曲線で予定しておく。
そして、システムテストでのバグ管理の実績を取ることで、信頼度成長曲線の予実管理を行って、バグの収束傾向を見て、残存バグが出し尽くしたか否か、を判定するわけだ。

しかし、実際のシステム開発の経験では、そもそもバグ累積件数はS字型にならない。
むしろ、一直線に発散する感じの場合が多い。
特に新規加入した開発者が多いチーム、過去のシステム保守の経験がないチーム、新しい技術を使った案件などでは、試行錯誤して、ハンドルが荒れた車の運転みたいな感じになるから。

また、横軸にテスト実施日を取ると、テストしない日とか、テストケースの実績が少なければ、信頼度成長曲線は自然に横向きになるが、それはバグが収束した傾向を示すとは限らない。
横軸には、テスト工数を引くとか、テスト作業そのもののバラツキをなくすように、正規化する必要がある。

こういう処理をExcelでやるのはとても面倒。
信頼度成長曲線はBTSがあればデータをExcelにプロットするだけで実現できるのがメリットの一つだが、実際に正確なグラフを描き出すのは面倒。

結局、信頼度成長曲線にせよ、ソフトウェアメトリクスは、安定したプロセスで初めて有意義な意味を持つ。
そういう意味では、一発限りの請負型案件ではとても使いづらい。

Redmineのようなチケット管理ツールは、最終的にはソフトウェアメトリクスを集計・出力するプロセス基盤であると僕は思っている。
しかし、安定したチームで長期間活動するのは、日本のSIではとても実現が難しいので、ソフトウェアメトリクスを効果的に使えた経験は正直少ない。
パッケージ製品の自社開発、長期間の自社の基幹システム保守のように、長期間のPJでは当てはめやすいかもしれない。

| | コメント (0)

2021/01/25

キャズム理論をプロセス導入の問題解決に使うアイデア

「BABOK入門」を読んでいたら、ERP導入の難易度と組織文化をマトリクスで整理していたのが非常に分かりやすかった。
そのマトリクスの考え方の背後には、キャズム理論がある。
なるほど、そういう考えなのか。
適当なラフなメモ。
間違っていたら後で直す。

「BABOK入門」を読むと、キャズム理論は、ERP導入だけでなく、PMOが新しい標準プロセスを導入する時に、どういう対処をすれば運用を拡大して推進できるか、という示唆が得られると思う。

まず、キャズム理論は、ERP導入や開発プロセス導入対象の組織文化のレベル分けに使える。

ビジョナリーは、イノベータなので、最新のERP、最新の開発プロセスに興味を持ち、導入してくれる。
アーリーアダプターは、実利重視なので、自分たちの目的に叶うならば、リスクを背負って導入してくれる。
アーリーマジョリティは、保守的なので、他社が多数導入して、デファクトスタンダードになってから導入し始める。
ラガードは、自分たちの組織文化に誇りを持ち、他の価値観を受け入れないので、そもそも導入しないか、導入しようとしても自分たちの組織文化に合うように、ERPをカスタマイズしまくったり、プロセスをカスタマイズしまくる。

他に、キャズム理論は、ERP導入やプロセス導入の問題解決に使える。
キャズム理論では、アーリーアダプターとアーリーマジョリティの間にあるキャズムを乗り越えるのが重要、と知られている。
だから、ERPであれ、新しいプロセスであれ、キャズムを乗り越える対策が必要。

キャズム理論が教える所では、ホールプロダクト理論が知られている。
ボウリング・ピンのように、主要ターゲットを狙って成功させて、その後は次々にターゲットを定めて落としていく。
同様に、ERP導入でも、プロセス導入でも、主要ターゲットを定めて確実に成功させて、周囲のボウリングピンを一つずつ落として、シェアを高めて、デファクトスタンダードに近づけていく。

アジャイル開発の導入でも、Redmineの導入促進でも、同じような苦労があったことを思い出した。

今、PMOが導入しようとしているフェーズは今どこなのか、自分の足元を確認しながら、進めていくべきなんだな、と改めて気づいた。


| | コメント (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/12/13

第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する

第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想をラフなメモ書き。
適当なメモ。

あくまでも僕の理解なので、論理が端追っていたり、論理が飛んでいる。

【参考】
モデルベースシステムズエンジニアリングの活用 - connpass

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

【1】高井さんの2つの講演「モデルベースシステムズエンジニアリングにおける形式手法の効果的な活用」「モデルベースシステムズエンジニアリングにおけるシナリオ生成手法の効果的な活用」は共に、SysMLと戦略の観点のマトリクスによるモデルから、形式手法などのツールを駆使して、別のモデルを作り出し、その生成技法をastahのプラグインで実装したというお話。

あまり詳しくなければ、昔流行したMDA(モデル駆動開発)とか、超高速開発のようなツールを連想してしまうが、実際に聞いてみると、こういうものを実装したい時代背景や動機が色濃くあることがよく分かった。

実際、高井さんが、モデリング技法(astahなどのモデリングツール)と各種の技法(形式手法Spinなど)がほどよく洗練されてきたので、使いやすくなった、と言っていた。

たとえば、形式手法のSpinの問題点は2つあるが、問題点を薄めやすいという。
一つは状態爆発しやすいことだが、状態遷移図だけでなく、SysMLでは上流工程の要求モデルや他のモデルの情報をもとに、状態遷移を明確にすることで、状態爆発しない程度までに抑えることができる。
もう一つは、Spinで検査式が難しくて書きにくいことだが、SysMLのダイアグラムに制約条件を書き込んだり、他ツールとのトレーサビリティから情報を集めて、検査式を作りやすい。

つまり、モデルベースエンジニアリングによるモデルには豊富な情報が含まれているので、形式手法のSpinに合うような情報を連携すれば、Spinの弱点を解決でき、Spinのプログラムを自動生成できるようになるわけだ。

【1-1】具体的には、上流工程から下流工程までの各種のモデルを生み出す技法と、形式手法を組み合わせて、モデルそのものの検証が行えること。
つまり、モデルをいくら書いても、そのモデル自体の正しさはそのままでは保証できないが、モデルに描かれた仕様や制約条件を元に、形式手法のプログラムへ自動生成できれば、モデルそのものを検証できる。
さらに、モデルのテストケースもSysMLで書いておけば、テストケースそのものも形式手法プログラムの一つになる。

デモでは、モデルから形式手法プログラムへの自動生成とモデルの検証をastahで行い、モデルの検証結果がOKであれば、astah上のテストケースが緑色、検証結果がNGなら赤色に変わるように反映されていた。

この手法を使えば、astahで描かれたモデルの検証ケースをテストケースで全て書き込んでおいて、継続手インテグレーションで回せば、モデル検証を自動テストできる仕組みが構築できる。
そうすれば、上流工程のモデルを修正したり追加するたびに、自動テストを動かして、モデルの整合性や正しさを保証できるように運用できるはずだ。

本来は、astahのモデルではなく、PlantUMLのように、モデルをソースコードで書くようにできれば、SpinやLTSAのような形式手法プログラムでモデル検証の自動テストがやりやすくなるはずだ。

【1-2】あるいは、具体的には、自動運転の自動車部品のセキュリティ対処の為に、セキュリティの穴をつくような攻撃シナリオや防御シナリオをastahのGSNモデルとして描き、そこから、具体的に設計や実装が可能なシナリオを自動生成すること。
おそらく、astahGSNで、自動車部品のセキュリティのシナリオを論理的に書いておき、そこからパターンごとにシナリオを生成するイメージ、かな、と思った。
すると、シナリオを元に、具体的な仕様モデルや実装モデルを設計できる。

なお、Spinのような形式手法プログラムもコマンドライン・ベースで動くので、astahの画面からキックして、Spinプログラムを実行できたり、ログ出力された実行結果を読み取ることができる。
Spinはもう随分枯れた形式手法だが、プログラムのI/Fはコマンドラインのまま古い点が逆に良い点に作用しているのだろう。

そういう話を聞くと、astahは外部から接続できるAPIが公開できていたり、astahのプラグイン実装が可能な点が有効に活用できているのだろうと思う。

個人的には、PlantUMLのようにUMLやSysMLをソースコードで書いて、SpinやLTSAのような形式手法プログラムを自動生成&自動テストを実行できる仕組みを作っておき、一方で、ソースコードで書かれたモデルはastahのようなビジュアルなモデリングツールにいつでも読み込めるようにする手法が運用しやすいのでは、と思う。
モデルがソースコードに落ちていれば、Gitで構成管理しやすいし、I/Fがコマンドラインで実行できるならば、形式手法以外の技法のツールと連携しやすいからだ。

【2】一番興味深かったのは、とある大学の先生の話。

フォルクスワーゲンは「ソフトウェアファースト」を掲げて製造業からソフトウェア業へ本当に変革しようとしていて、実際、2020年には2000~3000人ものソフトウェア技術者をドイツで募集しており、社員の割合もハード技術者とソフト技術者の割合が半々まで来ているらしい。

一方、トヨタも2020年になって社長自ら「ソフトウェアファースト」を掲げて、ソフトウェア技術者を応募しているが、今までのエンジン技術の成功体験もあって、そこまでソフトウェア重視ではないですね、とのこと。

僕は、DXとは、ITが中核事業でない既存企業がソフトウェアを中核とした事業にシフトすること、と思っているので、日本企業がソフトウェアにまだまだ詳しくないからこそ、DXというバズワードが流行しているんだろうな、とか思った。

つまり、DXとは、従来の事業スタイルのメーカーや小売業が、新興勢力のソフトウェア企業に「代替品の脅威」を感じて、何とか自社でもソフトウェアを前提とした事業を打ち出そうと頑張るためのバズワード、と思っている。

すなわち。「DXとは、ソフトウェアが世界を食う脅威に従来型企業が怯えて対抗しようとしている活動」ではないか。

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ: プログラマの思索

ソフトウェアが世界を動かす時代: プログラマの思索

VWがソフトウエア部門を一新、自社開発を大幅に増やす | 日経クロステック(xTECH)

「ソフトウェアファースト」で社会の一部となるクルマづくりへ、トヨタとNTT - MONOist(モノイスト)

【追記】
当日の講演資料が公開されました。



| | コメント (0)

2020/06/17

相殺フィードバックを再考

システム思考で出てくる相殺フィードバックをメモ。

【参考1】
学習する組織 - ごろにゃ~の手帳(備忘録)-パーソナルMBA的な

(引用開始)
強く押せば押すほど、システムが強く押し返してくる
よかれと思って行った介入が、その介入の利点を相殺するような反応をシステムから引き出す現象である。
私たちは誰もが、相殺フィードバックに直面するのはどんな感じか知っている。
押せば押すほど、システムが強く押し返してくる――つまり、物事を改善しようと努力すればするほど、 さらに多くの努力が必要に思えてくるのだ。
(引用終了)

【参考2】
組織は「苦労」や「一生懸命努力すること」を美化してはいけない。 | Books&Apps

(引用開始)
MITスローン経営大学院のピーター・M・センゲは著書「学習する組織」においてこの現象を「相殺フィードバック」と呼ぶ。
多くの企業が、自社製品が突然に市場での魅力を失い始めるとき、相殺フィードバックを経験する。企業はより積極的な売り込みを推し進める―それが今までいつもうまく言っていたやり方だ。宣伝費を増やし、価格を下げるのである。
こう言った方法によって、一時的には顧客が戻ってくるかもしれないが、同時に会社からお金が流れ出ていくので、会社はそれを補うために経費を切り詰め、サービスの質(例えば、納期の早さや検査の丁寧さ)が低下し始める。
長期的には、会社が熱心に売り込めば売り込むほど、より多くの顧客を失うことになるのだ。
(中略)
私が見た現象は、サービスの質を改善せず、全員を「テレアポ」と「飛び込み」などの労働集約的な仕事に邁進させる、というやり方だったが、上と全く結果は同じであった。顧客は流出し、人材は会社を辞め、競合にシェアを奪われたのだ。
(引用終了)

相殺フィードバック: プログラマの思索でも書いたが、IT業界は相殺フィードバックによる問題発生が多い。

たとえば、過去に直したバグ修正が、今の障害の発生原因になっている。
たとえば、以前下した判断や意思決定が、今回の問題の発生原因になっている。
その時は良かれと思ったことが、実は場当たり的な対応であって、より一層症状を悪化させた。

僕の経験上、相殺フィードバックという症状は、ソフトウェア開発で非常に発生しがちと思う。
従来のソフトウェア開発の現場では、元請けのPMと下請けのプログラマが混成チームを形成するが、彼らは顧客と切り離されているので、顧客からのフィードバックを得るタイミングが最初と最後のフェーズしかない。
だから、現在の意思決定がどんな影響を及ぼすのか、想像できない。

ソフトウェア開発は自己目的化しやすい: プログラマの思索

相殺フィードバック: プログラマの思索

僕は、相殺フィードバックをなくすには、システム思考に出てくる因果ループ図のような発想方法よりも、ランダム比較化実験を使って行動経済学の知見を導き出す手法の方が効果的ではないか、と直感している。
最初から、相殺フィードバックにはまらないような意思決定を下すのは難しい。
できれば、傷が浅い程度の失敗は許容できる時期に、2つの意思決定をランダム比較化実験で試して、人間の行動や集団行動がその後にどのような影響を与えるのか、を見極めた方がいいと思っている。

以前はそういう手法が使えなかったが、今はWebアプリはクラウド上で即座に作れるし、スマホ経由でランダム比較実験をしてみるのは易しい。
行動経済学の知見をソフトウェア開発やソフトウェア工学に活用するアイデアは試して見る価値があるように思える。


| | コメント (0)

2020/06/14

SaaSのビジネスモデルがアジャイル開発を促進したという仮説

「ソフトウェア・ファースト」を読んで、改めて、アジャイル開発はSaaSの開発プロセスを発展させたものとみなすのだと考えた。
ラフなメモ書き。

【参考】
ソフトウェア・ファーストの感想: プログラマの思索

【1】「ソフトウェア・ファースト」を読むと、製造業などの一般産業は、SaaSのようにどんどんサービス化すべきだ、という主張が背景にあるのが分かる。

では、SaaSというビジネスモデルの特徴や本質は何だろうか?

この問いに自分なりに考えてみたら、複数の特徴があるように思う。

【2】SaaSはScrumと相性が良い。
たとえば、パッケージ製品ビジネスや大量生産ビジネスでは、たくさん作って販売してそれで終わり。
一括請負契約で作って納品したら終わり。
顧客とメーカーは、クライアント-ベンダー-アンチパターンにはまりやすい。

「クライアント-ベンダーアンチパターン」という根本問題: プログラマの思索

一方、SaaSでは、常にサービスや機能を頻繁にVerUpしていく。
その頻度も1ヶ月に1回ではなく、1日に数十回もざらだ。
SaaSのインターフェイスは、ユーザがスマホやPCで触っているので、すぐにその機能を試してもらえるし、彼らの要望を即座に反映するほど、顧客満足も高まる。
そういうニーズがあるので、頻繁なリリースを実施する動機づけになる。

その場合、社内の開発体制はScrumに似せると開発しやすくなる。
マーケティング担当者や経営者がプロダクトオーナーの役割を担えば、社内に開発チームとスクラムマスターを作れば、即座にScrumが出来上がる。
SaaSの場合、プロダクトオーナーに相当する人が社内に存在し、その能力を持ち合わせている時も多いのがメリットだろう。
その後は、会社の規模やビジネスの規模に合わせて、Scrumをスケールすればいい。

【3】SaaSはDevOpsと相性が良い。
リリースしたら、その後も運用し続けるので、開発と運用保守は一体化すべき流れになる。

一方、普通のSIであれば、インフラチームと開発チームは分離されていて、機能別組織になりやすい。
機能別組織の弱点は、チームや組織ごとに体制の壁ができてしまい、意思疎通が困難になることだ。
コンウェイの法則「アーキテクチャは組織に従う」によって、システムのアーキテクチャは縦割りの複雑な組織構造を反映した形になってしまい、システムはどんどん複雑化してしまう。

もちろんSaaSも、ビジネスが発展すれば肥大化するだろう。
しかし、開発と運用保守は一体化した方がいいというビジネス要求や現場からの要求が出てきやすいので、DevOpsを推進する動機づけになる。

もちろん、技術的にも、SaaSはクラウドと相性が良い。
だから、クラウドエンジニアはインフラエンジニアだけでなく、開発者でもありうるので、事実上、インフラチームと開発チームは一体化しやすい。

また、ここからマイクロサービス・アーキテクチャも実装しやすい。
AWS上でSaaSを運用すれば、LambdaやAurora、AWSの各種サービスを利用することになるだろう。
単に性能改善やスケールメリットが活かせるだけでなく、システム基盤をマイクロサービスとして組み立て直すことにより、SaaSは汎用的なAPI基盤になっていくだろう。
そうすれば、外部サービスと連携できるので、より多種多様な機能を顧客に提供しやすくなるメリットも出てくる。

【4】SaaSはB2Cのプラットフォームビジネスと言える。

アメリカのGoogle、Amazon、Apple、Facebookがそうだし、中国のBATも同様だ。
多数の顧客に対し、プラットフォームを提供することで利便性がどんどん増していく。
そのビジネスの本質は、製造業が持つ規模の経済ではなく、ソフトウェア特有のネットワークの経済という理論が背景にあるはず。
たくさんのユーザが使ってくれるほど、SaaSは重要性を増して、売上を指数関数的増大させていく。
「プラットフォーム革命――経済を支配するビジネスモデルはどう機能し、どう作られるのか」を読むと、プラットフォームのビジネスモデルは独占ビジネスなので、その売上は、そのサービスの市場規模と同等になるまで高められる。
つまり、市場規模と同等だから、小さい国家のGDPよりもはるかに大きな利益を得ることも可能。

SaaSはB2Cのビジネスなので、顧客のフィードバックをすぐに取り込みやすい。
ランダム実験やABテストも実現しやすいので、サービスやビジネスモデルを仮説検証しやすい。
つまり、SaaSでは、念入りに考え抜いた計画を作って数年かけてリリースするよりも、仮設を立てたら、複数のサービスを同時リリースして、ランダム比較化実験でその効果を測定した方が速い。

興味深いのは、米国や中国では、SaaSのトッププレーヤーはB2Cなのに、日本の楽天やモノタロウなどはB2B2Cというスタイルで異なる点だ。
もちろん、LINEのように、日本国民の殆どとつながっていて、その連絡先とつぶやきのようなログデータを既に持っている会社はB2Cだ。
しかし、日本で目立つSaaSプレーヤーはB2Bのクッションを通過した後でB2Cを提供するビジネスモデルが多いように思える。
その理由は分からないので、いつか知りたい。

プラットフォーム革命の感想~プラットフォーム企業は新たな独占企業である: プログラマの思索

規模の経済と経験曲線効果のメモ: プログラマの思索

【5】SaaSでは、大量のログデータがビジネスの副産物として採取される。
データはいくらでもある。
そこから、機械学習やディープニューラルネットワークに大量データを食わせることで、優れたAIエンジンを生み出すことも可能だ。
B2Cのプラットフォームビジネスでは、ユーザの個人情報は特定できるし、その購買行動はプラットフォーム上で全て追跡できる。
よって、ペルソナを仮想的に作って、より購買を促すようなプロモーションを打ち出して、潜在ニーズを掘り起こせる。

「告発 フェイスブックを揺るがした巨大スキャンダル」によれば、Facebookで、個人に68個のいいねがあれば、その人物に関する非常に具体的な情報をモデルから予測できる。
70個のいいねで、そのユーザの友人が知るよりも、その人の多くの個人情報がモデルから推測される。
150個のいいねで、親よりも、その人の多くの個人情報がモデルから推測される。
300個のいいねで、パートナーよりも、その人の多くの個人情報がモデルから推測される。
さらにその多くのいいねを見れば、ユーザが自分自身について知っていると思っている以上の個人情報がモデルから推測される。
つまり、個人の大量のログデータを収集できれば、その個人を丸裸にできる。
その個人情報を他人が知っている情報だけでなく、その個人自身が知らない潜在ニーズまで推測できるわけだ。
すなわち、ジョハリの窓という理論は、AIを使えばほぼ完全に実現できる可能性があると思う。

(それを悪用したのが、ケンブリッジ・アナリティカであり、彼らは、どの個人にどんなプロモーションを送ればどんな選挙行動に移してくれるか、を徹底的に研究して、トランプ効果や英国のEC離脱を生み出したわけだが。)

そんなことを考えると、SaaSは機械学習やニューラルネットワークと非常に相性がいい。
だから、テスラみたいに製造業もどんどんSaaSにシフトしているのだろうと思う。

| | コメント (0)

2020/06/09

なぜなぜ分析、FMEA、FTAの違い

なぜなぜ分析、FMEA、FTA、STAMPの違いをメモ。
間違っていたら後で直す。

「情報処理システム高信頼化教訓集(ITサービス編)」2017年度版公開:IPA 独立行政法人 情報処理推進機構

高信頼化教訓集

なぜなぜ分析は、発生した障害に対し、真因を導き出し、再発防止策を策定する。

FMEA(故障モード影響解析:(Failure Mode and Effect Analysis))は、潜在的な障害(リスク)に対し、製品及びプロセスが持つ潜在的なリスクを主にその設計段階で評価し、そのリスクを未然に排除する。

FTA(故障木解析(Fault Tree Analysis))は、障害(リスク)の発生確率を予測する為に、好ましくない事象(リスク)から原因を分解展開して、定量的に発生確率を把握する。

STAMPは、コンポーネントの信頼性の分析よりも、コンポーネント間の相互作用に着目して、信頼性や安全性を分析する手法。

最近の傾向としては、なぜなぜ分析、FMEA、FTAはかなり枯れた技法で、STAMPが脚光を浴びているイメージかな。
STAMPは、複数の部品を組み合わせた時の影響度合いやリスクを洗い出す手法として使われているイメージ。

| | コメント (0)

なぜなぜ分析と特性要因図の違い

なぜなぜ分析と特性要因図の違いをメモ。

【参考】
なぜなぜ分析と特性要因図 : CMMIを実践するエンジニアのブログ

10 分で理解できる特性要因図|書き方から原因を特定する方法まで

特性要因図は、事象の要因を複数個あげて、その要因を引き起こす要因へ詳細化していき、改善効果のある要因を原因として抽出する。
特性要因図は、原因分析ではなく要因分析である。
特性要因図の目的は、問題(特性)を引き起こしていると推測される要因を洗い出し、最も効果のある要因を原因として見つけ出すこと。

なぜなぜ分析は、事象に対し、事実と原因をセットにして、因果関係で掘り下げる。
なぜなぜ分析は、「事実」に基づきながら問題の原因を掘り下げていく。
なぜなぜ分析の目的は、ある事実に対する原因を発見すること。

この違いが明確ならば、特性要因図で要因を推測しながら洗い出し、原因を洗い出したら、なぜなぜ分析で因果関係にまとめる、というやり方もある、と考えた。


| | コメント (0)

2020/04/23

MLOps(機械学習基盤)のリンク

MLOps(機械学習基盤)の記事が面白かったのでメモ。

【参考】
機械学習システムの設計パターンを公開します。 - Mercari Engineering Blog

mercari/ml-system-design-pattern: System design patterns for machine learning

ゆるふわMLOps入門 - Re:ゼロから始めるML生活

機械学習システムにおける「技術的負債」とその回避策 - Qiita

“Hidden Technical Debt in Machine Learning Systems”

記事を読んで理解したことは、機械学習はアルゴリズムが重要なだけではなく、そのシステムを支える開発基盤の構築に膨大な工数がかかること。
データ収集・分析だけでなく、データや分析結果の構成管理、サーバー・システム監視なども含まれるので、開発もインフラ基盤も両方とも詳しくないと、システムの全体像を把握することすら難しいだろう。
一昔前の業務システム開発よりも、はるかに難易度は高いと思う。

ゆるふわMLOps入門 - Re:ゼロから始めるML生活に紹介されている先進企業の事例が参考になる。
Google、Facebook、Netflix、Airbnb、Uber くらいの大企業であれば、自前で構築して、その基盤を他企業や一般利用者にも使わせることで、サブスクリプションサービスによる売上、エコシステムの拡大を狙っているわけだ。
この辺りの技術も探してみる。


| | コメント (0)

より以前の記事一覧