メトリクス分析のコツは良いIssueを見つけること

メトリクス分析のコツは良いIssueを見つけることと思う。
ラフなメモ。

【参考】
DXの本丸は「データ」にあり　「問い」からはじめるデータ分析とその活用法 - ログミーBiz

データ分析から導き出す「強い野球チーム」のつくり方　映画『マネーボール』で学ぶデータサイエンス - ログミーBiz

akipiiさんはTwitterを使っています: 「ソフトウェア工学のメトリクス分析の考え方にも適用できるので参考にする。データ分析から導き出す「強い野球チーム」のつくり方　映画『マネーボール』で学ぶデータサイエンス - ログミーBiz https://t.co/ZmCzuVEIUy」 / Twitter

akipiiさんはTwitterを使っています: 「データ駆動はイシュー駆動。良い問いが解決策を生み出す。メトリクス分析も同じだな。DXの本丸は「データ」にあり　「問い」からはじめるデータ分析とその活用法 - ログミーBiz https://t.co/XRe7ceo6u0」 / Twitter

【1】問題解決を図るときに、定量データを扱うのは有効だ。
最近は、Webログやスマホ履歴のようにビジネスの副産物として簡単にデータを集められる。
すると、溜まったデータをいかに活用するか、が大事になる。

『マネーボール』という映画では、貧乏球団が強いチームを形成するのに必要な問題は、「出塁率の最大化」だった。
そこに問いの価値がある。
選手の人間性、選手の組み合わせ、とかそんな観点の問題ではなかった。
問いを「出塁率の最大化問題だ」と立てられたら、あとは、バッター個人のデータを分析して、確率論に持ち込めばいい。

つまり、良い問い（Issue）を把握するのが大事。
良いIssueは数字で答えたくなる。

良いIssueを探るには何が必要なのか？

顧客行動の理解ならカスタマージャーニーを使う。
お客さんがその商品を購入したいと思うタイミングとか、ファンになるまでのステップごとに定量データを集めて分析する。
そうすれば、どこでユーザが離脱するのか、どこでユーザの満足度が低いのか、が浮き彫りになってくる。
これを業務システム開発に置き換えれば、一連の全体の業務フローを描いて、それぞれのステップごとに分解することになるだろう。

次はこれをどうやって定量化していくか？

KPIツリーによる指標分解を使う。
売上＝客数ｘ客単価。
顧客数を＝認知人数×購入率、みたいに分解していく。

掛け算か足し算で異なる。
掛け算では、2つの指標を独立だとみなす。
足し算はセグメントに分ける。

基本は、カスタマージャーニーマップのステップごとにKPIツリーで分解していく。
この辺りのプロセスは、ECサイトの分析であるAARRRの手法と全く同じ。

【2】ソフトウェア開発プロセスのメトリクス分析でも、同じような考え方を適用できる。

たとえば、WF型開発のPJであれば、工程ごとにゲートがある。
各ゲートに着目してQCDの観点でメトリクスを作ることはできる。

では良いIssueとは何なのか？
Issueをどうやって解決するのか？

良いIssueを見つけるのが大事。
「イシューから始めよ」の通り、質よりも量で頑張ると、生産性が非常に悪い。
大量にアウトプットを出しても、正解にたどり着くルートはせいぜいそのうち5％ぐらいしかない。
そうならば、事前に本来のIssueを絞り込んで、生産性を高めるべき。

メトリクス分析では、良いIssueを立てて、そこからKPIツリーで分解した各要素のどこにインパクトがあるのか、を見るのが大事。

Javaのenum型はシングルトンクラスみたいだ

Javaの最新版に触れてみたら、enum型にコンストラクタやメソッドを持たせることができると分かった。
ちょっとびっくりした。

(2) よしけーさんはTwitterを使っています: 「enum にメソッド持たせるのは effective Java あたりを読まないと気がつけない気がする。。 #ドメインモデルパターンに挑戦する苦労ばなし」 / Twitter

(2) akipiiさんはTwitterを使っています: 「Effective Javaにenumのパターンが確かに書いてあった。enumでメソッドを定義する発想がなかった。後で読む」 / Twitter

あなたの知らないJava enumの使い方 - SEチャンネル

Effective Java 第３版 第６章enumとアノテーション - Qiita

Effective Java 3rd [Chapter 6] - enum とアノテーション - Little by little and bit by bit - マイペースにこつこつと

【Effective Java】項目３０：int 定数の代わりに enum を使用する - The King's Museum

Effective Java 第３版 「ほぼ全章」を「読みやすい日本語」で説明してみました。 - Qiita

ドメイン駆動設計に関する勉強会で、Javaのenumにメソッドを持たせられるというツイートを見た。
「Effective Java 第3版 | Joshua Bloch, 柴田 芳樹」を読んでみたら、たしかにenumに1章を割いて、詳しく説明されていた。

個人的印象としては、JavaのEnum型はシングルトンクラスみたいだ。
グローバル変数の出し入れに使える感じ。
使い道としては、業務システムのシステムコントロール定数を持たせたい時だろうか。

Javaから離れていたので、最新版のAPIや文法がかなり変わっているのに気づいた。
Javaはオブジェクト指向言語だというぐらいのイメージしかなかったが、RubyやPython、JavaScriptなどの良い面をJavaも取り入れようとしている印象を受ける。
Javaにラムダ式ぐらいを取り入れるのはまだよいが、ストリームAPIは何かやりすぎな感じもした。
気づいたことはまた書く。

プロセス設計はどの範囲を指すのか？～プロマネの仕事はテーラリングにある

とある勉強会で、プロセス設計はどの範囲を指すのか、を議論した。
自分の考えをメモ。
ラフなメモ書き。

【参考】
デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想～CTOの役割とは何ですか？: プログラマの思索

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

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

みんなのPython勉強会#65の感想～社会変革の鍵はIT技術者にあるのかもしれない: プログラマの思索

プログラマとスクラムが社会実装を変えていく　#Findy_GovTech: プログラマの思索

マッキンゼーの報告書「2030 日本デジタル改革」が手厳しい: プログラマの思索

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

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

プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール: プログラマの思索

【1】プロセス設計とは何か？

「SEはプロセス設計する能力が必要」と清水吉男さんは言われていたと思う。
PJ計画時に、担当SEは担当PJでどんなプロセスが必要でどんな成果物が必要なのか、を明確にすべき。
なぜならば、システムの特徴、PJ特性に応じて、プロセスや成果物はどのPJでも微妙に異なるからだ。
それを不明確なまま進めると、じきにプロジェクトの運営がうまくいかなくなる。

イメージとしては、XDDPならばPFDというDFDを描いて、プロセスと成果物のデータフロー図を描くものと思う。

【2】プロセス設計の考え方は標準から各PJへのテーラリングが基本

では、プロセス設計とはどんな構造を持つのか？
きちんとしたSIであれば、社内に標準プロセスがあり、それを担当PJごとにテーラリングしたサブプロセスを定めることになる。
つまり、「プロセス」クラスと「サブプロセス」クラスという型が継承関係にある。

プロジェクト計画が確定すると、「サブプロセス」のインスタンセスが生成される。
PJ実行フェーズで、プロセスのインスタンスをもとに、具体的な成果物（たぶん、設計書などのExcel帳票）が作られていく。

つまり、プロマネは担当PJの特徴、システム特性に応じて、標準プロセスをテーラリングないしカスタマイズする自由度は許されている。
ここにプロセス設計の能力が必要とされる。

プロセスプログラミングとは from akipii Oga

【3】プロセス設計の範囲は、PMO事務局とプロマネで異なる

では、プロセス設計の範囲はどこなのか？
(1)プロセス設計とは、プロセスインスタンスから標準プロセスへ抽象化する手法？
(2)プロセス設計とは、標準プロセスをプロセスインスタンスに具体的に実現する手法？
(3)プロセス設計とは、標準プロセスからサブプロセスへテーラリングする手法？

僕の考えでは、プロセス設計の範囲は、PMO事務局とプロマネで異なる。

全社横断的PMO事務局は、社内の案件に対し、標準プロセスを定めたガイドラインを定義し、その推進活動を担当する。
PMOの作業範囲は、「プロセスというクラス」の部分で標準プロセスの型をガイドラインで定義し、各案件のPMには、標準プロセスは守ってもらうことになる。
一方、プロマネには、PJ特性に応じて成果物やプロセスを取捨選択したりカスタマイズしてテーラリングする。

つまり、PMOが担当するプロセス設計の作業範囲は「プロセスというクラス」になる。
なぜならば、標準プロセスを定めたガイドラインの保守改訂はPMOの範疇だから。

一方、案件のプロマネの作業範囲は「サブプロセスというクラス」でPJのテーラリングを行ったプロセスを取捨選択ないしカスタマイズして決めて、PJ計画の活動で具体的なプロセスと成果物（たぶんExcel帳票）を確定すること（プロセスインスタンス）になる。
なぜならば、プロセスをテーラリングして詳細化する作業は、プロマネの担当だから。

【4】テーラリングはどのように評価されるのか

実際の現場では、PMOとプロマネの間で対立はある。

PMOは、ガイドラインがベースラインなので基本はPMに守ってもらうことが最優先であり、実際の案件とのギャップがあれば、それは吸い上げて真因を深掘りする作業を担当する。
テーラリングの自由度は許される範囲内でプロマネにあるから、プロマネの説明の根拠を一つずつ確認して、問いただしていく作業が必要がある。
実際は、そのテーラリングの妥当性で揉めることが多い。

たとえば、プロマネが案件の予算を申請する時、役員を含めた経営陣やPMO事務局が投資計画の内容を精査して、案件の予算確保と実行承認を決定するだろう。
その時に、会社標準のプロセスに即して投資計画を立案しますが、基本はテーラリングが必ず入る。

テーラリングの例としてはこんなものがある。

・標準では許されない工程の重複や統合、省略を許す
・標準化されていない開発方法、技術を適用する
・メトリクスの許容値を調整したり、代替メトリクスを計画する

たとえば、SAPのようなパッケージ製品の導入であれば、すでに開発プロセスがベンダ製品に埋め込まれている。
社内標準とは異なるベンダ製品のプロセスを社内の体制で実行できるか、などをPMが経営陣に説明する必要がある。

あるいは、機械学習の開発基盤を導入する案件であれば、標準化されていない開発手法を適用することになる。
開発リスクを見込んだスケジュールを作っているか、コストを見込んでいるか、をPMが経営陣に説明する必要がある。

あるいは、品質基準を変更してPJ用にテーラリングしたならば、品質基準を変更した妥当性の根拠をPMが経営陣に説明する必要がある。

プロマネが作った投資計画書やPJ計画書をレビューして、細かく精査すると、コストの妥当性、開発リスクの検討、品質基準の設定が甘い時も多い。
そういうレビューを通じて、投資計画の精度を高めるし、プロジェクト実行時の各ゲートレビューでPJの実行状況をPMOがモニタリングしてチェックすることになる。

【5】とは言え、プロセス設計とその評価プロセスの質は、SIであってもユーザ企業であっても、バラつきが多い。

システムの有効性を知りたい経営者、利用ユーザなどの第三者であれば、こういう仕組みがしっかりしていると、安心してシステム開発を任せられる。
たぶん、日本政府のデジタル庁が目指しているあるべき姿も、この辺りの内容に近いのでは、と推測する。
なぜならば、内製部隊を持てない場合、ベンダに委託する必要があるが、こういうプロセスの仕組みをしっかりすることで、ベンダから提供される成果物が標準化できるし、社内でもユーザ要求や仕様をまとめる能力が高まるし、最終的にベンダロックインを防いだり、プロジェクトの進行状況を適宜チェックする仕掛けができるからだ。

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

ホールディング会社の役割とIt企画・構築プロセス from akipii Oga

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

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

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

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

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

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

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

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

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

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

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

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

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

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

今度読んで見る。

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

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

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

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

「完全独習 統計学入門」は良い本らしい

ある勉強会で、「完全独習 統計学入門」は統計学の初心者に良い本だ、と勧められた。
「t検定の原理を理解して使いこなせれば、統計学の免許皆伝だ」と言われるらしい。

【参考】
統計学挫折者にオススメという「完全独習 統計学入門」を読んでみた | ゆとって生きたい。

統計学をはじめて学ぶ方におすすめ：完全独習 統計学入門: 教育機関向けソフトウェア　アカデミック・ソフト・プラス

(引用開始)
▽本書は、
●統計学を初めて学ぶ人
●統計学を改めて学び直したいという人
●何度も挫折して、いまだに身についてない(と感じている)人
●今まさに落ちこぼれつつある人
に向けた、統計学の超入門書です。

(1)「これ以上何かを削ったら、統計学にならない」という、最小限の道具立て(ツール)と簡単さで書かれた「超入門書」

(2)確率の知識はほとんど使わない。微分積分もシグマも全く使わない。使う数学は、中学の数学(ルートと1次不等式)までだから、高校数学がわからなくても(忘れてしまっていても)大丈夫

(3)毎講に穴埋め式の簡単な練習問題がついているので、独習に最適

(4)第1部では初歩の初歩からスタートしながらも、「検定」や「区間推定」という統計学の最重要のゴールに最短時間で到達することを目指す

(5)第2部では、第1部の内容に厚みをつけ、統計学での免許皆伝でともいえるt分布を使った小標本の検定・区間推定に最も効率的にたどりつく。基本が理解できれば、相当なところまで理解できる

(6)標準偏差の意味が「体でわかる」よう、簡単な計算問題や具体例で徹底的に解説する

(7)株や投資信託などへの投資のリスクを、統計学から理解して金融商品にも強くなってもらう

▽本書は、「これ以上何かを削ったら、統計学にならない」というギリギリの道具立てと簡単さで書かれた「超入門書」です。

本書は2部構成となっています。第1部では初歩の初歩からスタートしながらも、「検定」や「区間推定」という統計学の最重要項目のゴールに最短時間で到達することを目指します。

▽「統計学」を効率よく、1ステップずつ理解するために、本書のスタンスは以下のようになっています。

●本書では、標準偏差(S.D.)を最も重要視する
●本書では「確率」をほとんど扱わない
●「95パーセント予言的中区間」を用いて説明
●数学記号も数学公式もほとんど使わない(出てくるのは中学数学だけ)
●穴埋め式の簡単な練習問題で独習できる
(引用終了)

「完全独習 統計学入門」がお勧めの本と言われる理由は3つあるらしい。
一つ目は、中学生の数学レベルなので、微積分を知らなくても計算できる。
2つ目は、t検定で出てくる「区間推定」や「信頼区間」などを詳しく解説してくれていること。
3つ目は、穴埋め式の練習問題が豊富なこと。これが一番重要らしい。

先生曰く、統計学を習得するときには3段階ある。
最初は、統計学の概念を理解する。
次に、数多くの例を実際に手を動かして計算して習得する。
最後に、実践の場で統計学を使ってみる。

しかし、統計学を習得しようとする人を見ると、概念を理解するために理論的な本を読んで挫折したり分かった気になったりしている。
実際に具体例で手を動かしていないから使えない。

あるいは、いきなり実践の場で必要になったので、とにかく現場で使いまくるが、基礎が分かっていないので、正しくない結果を出したり、導かれた結果から結局何が言えるのか説明できない。

つまり、いずれも、実際に手を動かして計算して、統計学のコツを掴むのが重要ですよ、と言われた。

そんなわけで、この本をじっくり読んでみたいと思う。