« 2022年3月 | トップページ | 2022年5月 »

2022年4月

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

オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった

オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かったのでメモ。
ラフなメモ。

【参考】
オープンソースERPパッケージに対する派生開発手法の提案~開発プロジェクトの事例をもとに~ - AFFORDD

オープンソースERPパッケージに対する派生開発手法の提案~開発プロジェクトの事例をもとに~ - 経験論文

オープンソースERPパッケージに対する派生開発手法の提案~開発プロジェクトの事例をもとに~ - スライド資料

オープンソースERPパッケージiDempiereはいつか、仕組みを習得して、ERPはこういうものですよと自分なりに理解したいと思っていた。
ネット上の情報から、普通にインストールできる。
PostgresSQLのDBの中身を見ると、テーブル数は1千個を越えるので、OSSのわりに作り込んでいるERPだと思う。

こういうOSSのERPを自社開発、受託開発したい場合、必ずカスタマイズが入る。
その時に、どんな方針でカスタマイズすべきか、という問題が出てくる。
無造作にカスタマイズしていくと、開発基盤のバージョンアップに追随できなくなるし、今後の運用保守もやりにくくなるからだ。

そこで、ERPのカスタマイズに派生開発手法であるXDDPを用いて解決してみよう、という流れは自然に理解できる。
基本方針は、カスタマイズする場合、標準機能をラッピングまたは継承する形で、独自ロジックを実装する。

上記の資料で興味深いと思った点は、OSSのERPのカスタマイズで発生する問題として、標準機能の知識習得が難しいこと、派生開発により基盤である標準の品質を損ねること、という2点があげられたことだ。
そして、その解決方法として、教育環境の整備、開発規約の整備、開発体制の強化があげられていた。

意外だなと僕が思った理由は、派生開発のプロセスやiDempiereの開発基盤のアーキテクチャに焦点が当たると思っていたからだ。
しかし、よく考えれば、プロセスや技術面よりも、技術の習得や教育の方が長期的な問題なのだ、と理解すればいいのだろう。

得られた情報や検索した情報は、社内のRedmineで一元管理して共有している点も面白い。
Redmineを組織のナレッジ資産として使っているわけだ。

今後の課題として、XDDPのトレーサビリティマトリクスを利用して技術上の課題を解決していく点があげられていた。
iDempiereはOSSとはいえERPなので、相当な機能数があるから、すべてを理解するのが難しいのだろう。
そのために、XDDPのトレーサビリティマトリクスを利用したいのだろうと思う。

| | コメント (0)

2022/04/23

Rによる計量経済学/計量政治学を読んでいる

「Rによる計量経済学/計量政治学」という書籍があったので読んでいる。
Rによる計量経済学 第2版」「Rによる計量経済分析」「Rによる計量政治学」「Stataによる計量政治学」の本だ。
門外漢なのでラフなメモ。

【1】計量経済学という学問の存在は「統計学が最強の学問である」で知ったが、計量「政治」学という学問があるとは知らなかった。
でも考えてみれば、ITと統計学を駆使して、あらゆる人文科学を自然科学の基盤の上に打ち立てようとする方向性は納得できるし、そういう事が可能になった時代なので、ちょっと才能がある人が一攫千金を求めて大量流入しているのだろうと思う。

「計量経済学」「計量政治学」という学問で最も興味があるのは、これらの学問の根本問題は何なのか、これらの学問の前提となる武器について制約条件はあるのか、という点だ。


【2】「Rによる計量経済学 第2版」を読んで、計量経済学では、最小二乗法が自然科学のようにそのまま扱えない問題があり、その問題を解決するために色んな統計理論を編み出して、経済学を分析するツールを整備している、という印象を持っている。
その内容は以前書いた。

計量経済学における統計上の根本問題: プログラマの思索

データ分析の面白さはどこにあるのか: プログラマの思索

データ分析の課題はどこにあるのか: プログラマの思索

結局、母集団が正規分布になっているという直感を元に普通の理論は打ち立てるわけだが、現実はそうとは限らないので、色々苦労している、ということなのだろう。

様々な確率分布は正規分布のバリエーションに過ぎない: プログラマの思索

【3】「Rによる計量政治学」「Stataによる計量政治学」では、政治学を自然科学のような実証科学の基盤として打ち立てるために、計量政治学の正当性を書籍の冒頭に述べている。
この部分が非常に素晴らしいと思った。

政治学を含む社会科学では3つの問題がある。

【3-1】1つ目は実証的問題。
つまり、定量データを収集し「事実から真実を語らせる」。
「経済の発展は民主化を促進するか」「国民は民主党を指示しているか」など。
実証的問題では、価値判断を行わず、事実に語らせる。
だから「良いと思う」「悪いと思う」「すべきである」という感想を付け加えるときもあるが、そういう結果は出せない。

【3-2】2つ目は規範的問題。
いわゆる「べき論」。
研究者の価値判断に依存しており、規範哲学や政策議論で一般的に見られる。
「死刑は廃止すべきか」「民主主義は裁量の政治形態か」「中絶は認められるべきか」など。
価値判断というバイアスが入るために、客観性に疑問が残る。
しかし、規範的問題を実証的問題に変換することで、間接的に科学的証拠で根拠を示すことは可能らしい。

規範的問題を実証的問題に変換する仕組みはこんな感じだ。
1つは参照枠組み(frame of reference)を変える。
「今の日本は美しい国か?」という問題は規範的問題だが、「日本国民は、今の日本を美しい国と考えているか」という問題に置き換えれば、実証的問題として検証できる。
実際、世論調査を行えばいいだけの話だ。
つまり、問題のフレームを実証的問題に変換してしまえばいい。

もう1つは、規範的問題の背後にある前提条件に注目すること。
例えば「消費税を減らすべきだ」という規範的問題に対し、その背景にはいくつかの前提条件が隠れている。
つまり、「消費税を減らせば、経済を刺激して消費が伸びる」「消費が伸びれば雇用が増えて好景気になる」「好景気になれば税収が増える」という因果関係が隠れている。
これらの実証的問題に変換して、個人の価値判断なしにその真偽を検証すればいい。
つまり、「消費税を減らせば、経済を刺激して消費が伸びるのか?」「消費が伸びれば雇用が増えて好景気になるのか?」「好景気になれば税収が増えるのか?」という実証的問題に変換すればいい。

3つ目は分析的問題。
現実に起こっている事実よりも抽象度の高い命題の妥当性を検討する。
数学の証明問題に近い。

【4】「パズルを探す」というアイデアは、計量政治学だけでなく、一般の自然科学にも使えると思った。
「パズルを探す」とは、「常識的にはAなのに、Bになっている」という不思議な現象を指す。
たとえば、欧米の民主主義国では、地方選挙よりも国政選挙の投票率が高いのに、日本では逆になっている。
また、アジア各国の国家予算に占める軍事費率を時系列的に見ると、殆どの国では外圧要因によって割合が上下するのに、日本では1%以内にとどまり一定である。
それらはなぜなのか?
そういう研究が色々あるらしく、面白い。

【5】「Rによる計量政治学」「Stataによる計量政治学」では「理論と仮説」という説明がある。
内容は、実証分析を行うためにはきちんとしたリサーチデザイン(研究設計)が必要であるという主張だ。
リサーチデザインのプロセスはこんな感じ。

パズルを見つける。
パズルを説明するための複数の前提条件を使って理論を作る。
理論から作業仮説を作る。
作業仮説を検証するためのデータを集める。
データを使って作業仮説を検証し、理論の妥当性を確かめる。

理論とは「原因と結果についての一般的な記述」である。
理論を作るためには、前提条件、つまり、本当かどうか分からないがとりあえず本当と考えることをいくつか想定する必要がある。
つまり、理論とは、「複数の前提条件の束」である。
理論構築という作業は複数の「もし」という仮定、前提条件のもとに成り立つ。
だから、説得力のある前提条件を設定する能力が必要になってくる。

良い理論の条件は、4つある。
誤りの可能性があること。
観察可能な予測が多いこと。
具体的であること。
単純であること。
これらは下記のように言い換えられる。

理論はその誤りを指摘され、反証されながら修正されて頑健になること。
つまり、反証可能性が高い理論の方が良い。

観察可能な予測が多いほど、反証可能性は高い。
予測が具体的であるほど、観察可能な予測が多くなり、反証可能性が高くなる。
社会現象を単純な因果関係にまとめることで、反証可能性が高くなり、良い理論の条件を満たす。

科学的には理論と仮説に違いはない。
ほとんどの理論は、とりあえず受け入れられた仮説である。
作業仮説とは、理論を検証するために理論から引き出された、特定の変数に関する論述である。
「もしこの理論が正しければ~のはず」と記述される。
作業仮説は理論よりも具体的で、理論から引き出される観察可能な予測について述べている。

作業仮説を作る作業化とは、理論の中の変数を計量かつ観察可能なより具体的な変数に置き換えること。
作業化において大切なことは、理論で使われている説明変数と応答変数にできる限り近く、それぞれの概念を適切に測定知る変数を選ぶこと。

【6】上記の内容を読んで思うのは、政治学や経済学のような本来は規範的問題を解決する学問をいかに実証科学に近づけようと苦労しているなあ、と思う。
確か、以前読んだ哲学入門の本で、「規範的問題はザイン(存在)からザルレン(あるべき)は出て来ない、規範的問題はザルレンから出発すべきだ」という一節を読んだことがある。

いくら、実証データで規範的問題を解こうとしても、人文科学では、時代と地域に依存する真理しか見いだせないと思う。
そういう数多くの困難な状況の中で、何とか規範的問題を実証的問題に変換して、ITと統計学を駆使して実証科学ぽく真理を見出そうとしているのだろう、と思っている。

実際、統計処理によって因果関係を真理として見出す技術も直近30年くらいで出てきているようなので、そういう技術を使って、計量なんとかという学問をどんどん生み出しているのだろうと思う。

機械学習で反実仮想や自然実験が作れる: プログラマの思索

経済学は信頼性革命や構造推定により大きく変貌している: プログラマの思索

| | コメント (0)

戦略/組織/人事と組織の経済学シリーズを読んでいる

「戦略/組織/人事と組織の経済学」という書籍があったので読んでいる。
戦略の経済学組織の経済学人事と組織の経済学・実践編という3冊の本だ。
リンクをメモ。

どの本も枕にできるくらい分厚い。
中身も濃い。
専門外の分野なので、サラッと読んで理解できる部分だけつまみ食いしている。

僕は、戦略論や組織論を経済学の理論で分析しようとする流れが好きだ。
理由は2つある。

1つは、経済学という人文科学の中でも最も自然科学に近く、理論に基づいて仮説検証して実証科学に近づけようとする姿勢に共感できるから。
もう一つは、経済学の理論や武器を導入することで、大量の実データに基づいて、プログラミングと統計分析を駆使することで、有益な結果を得やすいこと。
特に、R言語やPythonなどの統計処理、あるいは機械学習や深層学習モデルを適用できるので、色んな可能性を秘めていること。
特にプログラマであれば、すでにAPIやライブラリは揃っているので、実データさえあれば、こういう本の理論に従って、新たな知見を生み出すこともできる。

面白い世の中だなと思う。

組織論の背後には経済学の概念があるという仮説: プログラマの思索

データ分析の面白さはどこにあるのか: プログラマの思索

データ分析の課題はどこにあるのか: プログラマの思索

統計学の考え方に関する感想: プログラマの思索

IT企業が経済学者を雇い始めた理由が面白い: プログラマの思索

経済学は信頼性革命や構造推定により大きく変貌している: プログラマの思索

ビジネスの基本戦略には規模の経済があるのではないか: プログラマの思索

機械学習で反実仮想や自然実験が作れる: プログラマの思索

Pythonデータ分析試験、Python基礎エンジニア試験に合格した感想~Pythonの機械学習や深層学習が目指すのは因果推論ではないか: プログラマの思索


| | コメント (0)

2022/04/21

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

プロジェクト管理の基本はテーラリングだと思う。
そして、Redmineはプロセスをテーラリングするツールだと思う。
ラフなメモ。

【1】プロジェクト管理の基本的な考え方は何だろうか?

QCDのコントロール、課題管理、スケジュール管理とか、色々あるだろうが、僕は、標準プロセスを各案件、それぞれの現場にテーラリングする能力が問われている、カスタマイズする能力が問われていると思う。
なぜならば、現場にあるプロジェクトはどれもバラバラであり、過去の経験と全く同じプロジェクトはありえない。
そこで、標準プロセスを元に、過去の経験やベストプラクティスのいずれかを、それぞれの現場の案件に適用して、プロジェクトの成功を目指すことになる。

つまり、案件の特徴を見抜いて、標準プロセスから、案件に合ったベストプラクティスを適用して効果を引き出すわけだ。
プロジェクトマネージャは、案件を自分のコントロールの配下におくために、自分の手持ちの武器のうち、有効な武器だけを抽出して、プロジェクトごとにカスタマイズして適用しているわけだ。

すると、2つの疑問が湧いてくる。

【2】1つは、標準プロセスがなければ、そもそもテーラリングができないので、テーラリングという考え方が合っているのか、という点。

PMBOKのようなプロジェクト管理の基本知識では、予実管理が基本だ。
つまり、標準が前提としてあって、実際の実績が標準からどれくらい離れるのか、を測定して制御するイメージ。

しかし、標準プロセスが事前に定まっている環境は、大企業や歴史の長いSIなど、それなりに自分たちの開発の歴史を持って、そこから標準プロセスを作り出した人たちだろう。
そうでない場合は、標準プロセスがあいまいか、そもそも存在しないかもしれない。

そういう状況は、カオスと言えるだろう。
案件を受注するたびに、いつも初めてのプロセスを自分たちで作って運用していかないといけない。
それはあまりにも大変すぎるし、失敗しやすい。

アジャイル開発がそんな場面で利用されやすいだろうが、スクラムのようなきちんと決まっている最低限のフレームワークを用いることで、そういうカオスを制御しようとしている。
スクラムから離れて自分たちのアジャイル開発を見出すのは、スクラムの守破離のうち、守りをきちんとマスターした後でいい。

だから、何らかの標準プロセスが前提にあるのが基本ではないかと思う。

【3】もう一つは、プロマネが標準プロセスからテーラリングできる自由度の範囲はどれくらいあるのか、という点。

PMOの立場では、標準プロセスを策定して、各案件のプロマネに提示して使ってもらう。
しかし、案件ごとに特徴がバラバラだから、標準プロセスをそのまま100%当てはめるて運用は難しい。
だから、プロマネには、基本は守ってもらうけど、ある程度カスタマイズして、プロジェクトをスムーズに運用してください、とある程度のカスタマイズお自由は手渡す。

では、どれくらいの自由度がプロマネにはあるのだろうか?
この自由度は、その会社のプロマネの能力レベルに依存する、という身も蓋もない話。

プロマネの能力が高ければ、標準プロセスを元に、担当案件ではこの部分をカスタマイズして、プロジェクトを運用しやすくします、と宣言して進める。
プロジェクトをコントロールするには、この部分のカスタマイズが必要だと彼らは分かっている。
彼らは、カスタマイズする根拠を説明して、ステークホルダーに納得させるだけの能力を持っている。

一方、プロマネの能力が低い場合、彼らは、プロジェクトの実績の妥当性を標準プロセスに求めたがる。
こういう運用をしているのは標準プロセスに即しているからです、開発を委託したベンダの成果物の品質が悪いのは標準プロセスに従ったからです、などと平気に言う。
つまり、プロマネは、案件の遂行の妥当性を第三者に説明する根拠として、標準プロセスを使おうとする。

すると、PMOは、標準プロセスが現場にフィットしていないからそういう意見が出てくるのだ、と判断して、標準プロセスをどんどん詳細化し、ガチガチに決めていく。
そうすることで、テーラリングの自由度が下がり、プロマネが自由に運用できる裁量が狭くなる悪循環に陥る。
自分で自分の首を絞めている感じ。

そういう現象も多いので、標準プロセスの策定では、プロマネにどんなインセンティブを与えれば、彼らが良い方向にカスタマイズしてくれるか、を考える時が多い。

その気持ちは、まるで法律家みたいだ。
政府が定める法規制によって、市場や社会を良い方向へ誘導しようと計画するが、実際は、生身の人間は小賢しいので、その意図をすぐに行動に反映して自分の利害に合うように変な方向にカスタマイズする、みたいな感じ。
マクロ経済学で言えば、ルーカス批判。
量子力学で言えば、不確定性原理みたいなものか。

【4】他方、Redmineを使うと、標準プロセスとテーラリングのバランスをある程度保証して、プロマネに運用してもらうことができると考える。

Redmineはとても自由度が高いプロジェクト管理ツールだ。
とはいえ、Redmineも汎用ツールなので、Redmineに埋め込まれた機能によって、プロセスの自由度はある程度限られる。
つまり、Redmineで提供する「プロジェクト」ごとに、スクラッチのシステム開発やパッケージ製品導入、サポートデスクなどのドメインで、ワークフローやチケット管理などをテンプレート化しておく。
そのドメインのテンプレートをプロマネに手渡し、そこから先はプロマネに自由に運用してもらう。

つまり、ドメインごとのテンプレートで標準プロセスは固めておき、それから先の運用はプロマネの自由裁量にある程度任せる。
もちろん、チケット起票やチケットの完了条件については、Redmineの機能で制限することは難しいから、運用ルールで縛ることになる。
ただし、各案件ごとに、開発者のスキルが違っていたり、開発やリリースの手順が違う時もあるだろうから、チケット管理にテーラリングを当てはめて、ある程度の自由裁量で運用ルールを変更する余地は残す。

そうすれば、Redmineで標準プロセスを元に、プロマネがテーラリングして、案件ごとに合った運用ルールを策定できて、プロジェクトを成功させる確率を高めることができるはず。

ただし、この運用の前提条件は、プロマネがRedmineの機能やカスタマイズできる範囲を理解し尽くしておくことだ。
つまり、Redmineをプロセスのテーラリングに使うツールとして用いることができる能力を前提としている。

そうでなければ、プロジェクトのテーラリングをRedmine上で実現できないからだ。
個人的には、Excel手順書で運用ルールを逐一テーラリングするよりも、ある程度ツールで標準プロセスを遵守して、ツールの基板上でテーラリングする方が、コントロールしやすいのではないかと考えている。

| | コメント (0)

2022/04/18

物理学を攻略するためのマップ

物理学を攻略するためのマップを見つけたのでメモ。

初心者向けガイド - 物理 攻略 Wiki

物理学は一つの認識論: プログラマの思索

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

『ものづくりの数学』の感想 #もの数: プログラマの思索

理系脳かどうかの分かれ道は、物理学が好きかどうか、物理学を習得できているかどうか、だと思う。
なぜならば、いくら数学ができたとしても、その数学テクニックを実際の自然科学の場で使えなければ意味がないからだ。
化学や生物学などの根底には物理学の理論があるので、最終的には物理学がわかっている必要がある。
物理を習得できれば、小難しい数学の理論を実際にどのように使っているのか、理解しやすい。

たとえば、微積分なら微分方程式を使いこなすことだろうし、微分方程式を使いこなせれば、古典力学の現象をほぼすべて表現できる。
解析力学がその最終到達点になるだろう。
たとえば、線形代数やベクトルは、電磁気学、相対性理論、量子力学などで実際に使えば分かる。

しかし、高校物理では微分方程式を扱えないので、古典力学や電磁気学などでは、やたらと公式を覚えざるを得なくなる。
だから、高校物理の受験問題にフィットしすぎると、本来の物理が理解しにくくなると思う。

その現象はちょうど、私立中学受験で鶴亀算のテクニックを極めすぎて、連立方程式や線形代数の理解を妨げるのと同じだ。

また、理論物理学の範囲は非常に広く、さらに奥深いので、なかなか習得しにくい。
量子力学を習得する前に解析力学も必要になるように、前段の理論や知識を習得しておかないと前に進めない。

そんな時に、物理学を攻略するためのマップを見つけて、こういうマップを事前に知っておけば良かったと思った。
なぜならば、物理学を制覇するためにはどんなルートを通る必要があって、どれくらいの難易度があるのか、を物理攻略マップからある程度概観できるからだ。

僕個人の考えでは、理論物理学を習得したいならば、量子力学と相対性理論はマスターする必要があると思う。
換言すれば、量子力学と相対性理論という2代巨峰を習得できれば、その他の物理の専門分野は理解しやすいだろう。
ちょうど、量子力学と相対性理論という2代巨峰から、その他の山々を見下ろす感じみたいに。

| | コメント (0)

2022/04/17

初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ

初中級プロマネがIPAデータ白書の統計情報をどんな観点で活用できるか、説明した利用事例がとても良かった。
理解できた内容をラフなメモ。

【参考】
初中級プロマネのための 現場で活かせ!統計情報1

初中級プロマネのための 現場で活かせ!統計情報2

「ソフトウェア開発分析データ集2020」の発行:IPA 独立行政法人 情報処理推進機構

「ソフトウェア開発データ白書」のダウンロード:IPA 独立行政法人 情報処理推進機構

初中級プロマネのための現場で活かせ!統計情報  2019年4月19日| CITP Community

CITPアニュアルレポート2018を公開しました | CITP Community

【0】「ソフトウェア開発分析データ集2020」をIPAデータ白書と呼ぶことにする。

【1】IPAのソフトウェア開発データ白書を使いたい動機は2つある。

1つ目は、プロマネとしてシステムの企画書や提案書を書いている時に、見積もりの妥当性を説明するために、日本の他社事例の数値を元に遜色ないことを理由として、見積もり工数や金額は妥当です、とロジカルに説明したいこと。
もう一つは、プロマネとしてリリース判定会議で、システムの開発やテストの結果が、日本の他社の成功した事例と遜色ないことを理由として、品質は妥当です、とロジカルに説明したいこと。

プロマネは、経営層が考えた戦略を受けてその内容をシステムとして実現する時に、自分が考えた企画内容の妥当性を説明したい。
その時に、経営層から聞かれるのは、投資効果が見込める妥当性はあるのか、初期投資の金額の妥当性はあるのか、という点だ。
この根拠を作るために、実際に業務システムの無駄な問題点を工数や金額で事前調査したり、削減できるコストがこれだけあるとか、売上や利益がこれだけ伸びるとか、色々話を膨らませる。

特に難しいのは、初期投資としての見積金額が本当にこれで妥当なのか、という点だ。
まだ実際に作ってもないし、あいまいな調査を元に機能一覧を洗い出して、その積み上げで工数を算出し、人月単価を元に見積金額を弾くわけだが、それを各工程に分けて積み上げて、本当に正しいのか、と言われると、正直難しい。
実際は、色んな前提条件をたくさん置いて、こうなります、という説明しかできない。

そんな時に、日本のSIで成功した事例では、こういうデータがあるので、工数や金額に妥当性があると言えれば、自分たちの会社も日本のSIで普通のレベルだと仮定できれば、こんな数値になるのは妥当でしょう、と言える。
そういうロジックに持ち込みたい。

つまり、プロマネの勘や度胸のような直感に頼らず、利害関係者にロジカルに説明するための根拠づくりに、IPAデータ白書を使いたいのだ。

【2】IPAデータ白書には、日本のトップレベルのSIが収集したソフトウェア開発における数多くの統計データが掲載されている。
その統計データが膨大であるために、どのように使えばよいか分かりにくい。
僕も正直悩んでいた。

しかし、初中級プロマネのための 現場で活かせ!統計情報1を読むと、初級者・中級者のプロマネはIPAデータ白書をこういう風に使うと役立つよ、という指針を書いてくれているのでとても役立つ。

IPAデータ白書の主な使い道は、見積り、生産性、品質の3つの観点で使うと良いだろう。

【3】企画提案の段階では、要件定義工程比率や工程別の工数比率、工程別の工期の比率が役立つ。

たとえば、要件定義工程は準委任、設計・開発・テストは請負契約でやる場合、トータルの工数や工期を提案段階である程度見積る。
その時に、要件定義フェーズはこれくらいの工数や工期が必要である根拠として、IPAデータ白書の数値を用いて算出するとよい。
なぜならば、経験上、要件定義フェーズをケチって実施してしまい、実際の開発フェーズに入ると要件がどんどん覆されて遅滞してしまい、最終的にプロジェクトが赤字になるか、失敗プロジェクトで終わってしまうという失敗事例がすごく多いからだ。
やはり、要件定義工程にある程度の工数や工期を割り当てて、メンバーも労力も割いた方が次の開発フェーズはスムーズに進みやすい。

あるいは、設計・開発・テストの各工程の工数別割合をIPAデータ白書の数値を用いて算出し、プロジェクトが成功するならこれくらいの比率の工数が必要だ、という根拠に使う。
なぜならば、開発工程の見積は実際にプログラマが見積もればある程度明確になりやすいので、その工数を元に設計やテスト工程の工数を算出できるからだ。
失敗プロジェクトでは、設計工程は十分に工数を取るが、テスト工程の工数をケチって、実際のプロジェクトで破綻する時も多いからだ。

【4】また、設計や開発工程の見積もりには、生産性の指標が役立つ。

たとえば、SLOC規模あたり設計書ページ数を使えば、プログラム規模を元に設計書ページ数を見積もれるので、設計書の規模感や設計書作成の工数の根拠を算出できる。
あるいは、SLOC 規模別 SLOC 生産性 や SLOC 規模と工数の関係を使えば、プログラム規模を元に各工程の工数をある程度見積もることができる。

つまり、設計、開発、テスト工程の工数の見積の精度を向上させることもできる。

【5】設計・開発工程がほぼ終わり、テスト工程に入る時には、レビュー指摘件数、SLOC 規模 テストケース数、SLOC 規模 検出バグ数を使えば、品質の妥当性をチェックすることに使える。

たとえば、設計工程のレビューの指摘件数を収集できれば、SLOC 規模/工数あたり/ページあたりの数値がIPAデータ白書にあるので、その基準値を元にレビュー指摘件数が妥当であるか、管理図を使って検査できる。
外れ値が出るならば、レビュープロセスに原因があるのか、設計書という成果物が悪いのか、さらに原因分析していく。

あるいは、開発が終わればプログラム行数は簡単に測定できるので、開発規模に応じたテスト工程ごとのテストケース数や検出バグ数を予測することができる。
IPAデータ白書の数値を元に、開発規模から妥当なテストケース数はこれくらいと分かれば、そのケース数から外れ値が出ていないかチェックすればいい。

そして、実際にテストしてみて、バグ数がIPAデータ白書の基準値よりも多く出るならば、品質が悪い可能性があるのでさらに原因分析していく。

つまり、設計・テスト工程の品質の妥当性にIPAデータ白書の数値は使えるはず。

ソフトウェア開発データ白書と定量データの活用方法を参考にすれば、ゾーン分析やトレンド分析、信頼度成長曲線など数多くの品質管理技法を適用することもできるだろう。

「ソフトウェア開発データ白書2018-2019」のご紹介~プロジェクトマネジメントの実践・改善に活かす最新定量データと分析結果~も参考になる。

【6】IPAデータ白書の統計情報はたしかに、見積り、生産性、品質の観点で使えるし、それなりに役立つ。
しかし、いくつかの留意点はある。

1つ目は、WF型開発を前提としたメトリクスであること。
実際に収集した事例の数値では、ほとんどがWF型開発であり、アジャイル開発を前提としたメトリクスではない。

2つ目は、開発言語やシステムの種類、開発フレームワークをすべて混ぜ込んで、グロスで集計した数値であること。
以前は、JavaやCobolなど数多くの言語で分類されていたが、最近は言語の区別もなく、せいぜい、新規開発・改良開発・再構築の開発種別の違いだけしかない。
つまり、色んなシステムのデータを一つの数値でまとめているので、本当に精緻なデータなのか、という疑問はある。

3つ目は、IPAデータ白書に提出した日本の各SIの統計データは、工程の定義や開発規模、テストケース数、バグ数などの定義が各社でバラバラである可能性が大きいことだ。
この点はIPAのFAQサイトにも記載されていて、その点を考慮して色々精査されているみたい。

「ソフトウェア開発データ白書」シリーズに関するよくある質問と回答:IPA 独立行政法人 情報処理推進機構

4つ目は、この数値を鵜呑みにして使わないように、IPA自身も注意喚起を記載している点だ。
あくまでも参考データであり、自分のソフトウェア企業がこの数値に当てはまるとは限らない。

とは言え、IPAデータ白書は10年以上の歴史があり、その統計データの推移を見ると、そんなに大きく変わっているわけではないようだ。
日本でDXが叫ばれていても、日本のSIではやはりWF型開発が主流であり、それなりの品質データや見積データを収集して蓄積しているみたいだ。

個人的には、日本で少しずつ浸透しつつあるアジャイル開発の統計データが収集されて、実際の統計データとして採用されると参考にしたいと思う。

| | コメント (0)

2022/04/13

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2022/04/10

『ものづくりの数学』の感想 #もの数

今朝、講演会『ものづくりの数学』に参加してきた。
感想をラフなメモ。
全くロジカルでないメモ。

【参考】
講演会『ものづくりの数学』 - connpass

講演会のテーマは、『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』の著者の先生に、企業の技術者と理論物理・純粋数学の科学者という2つの立場から、ものづくりの現場に現代数学をどのように導入して効果を上げるべきか、という内容だった。
内容は相当難しいと思う。

改めて『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』を読み切ってみると、読者の対象は、大学で純粋数学や理論物理、理論化学を学んだ後、社会人では一般企業の技術者や管理者、IT業界の技術者になった人だろうと思う。
大学の理論研究の経験と一般企業でのビジネス経験の両方がなければ、この本の意義は理解しにくいだろうと思う。

なぜなら、『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』の内容はすごく抽象的だからだ。
実際、数式は出てこないけれど、現代数学がメーカーの製品開発の背景にあるという経験がなければ腑に落ちないだろう。
また、ポパーの反証主義、トーマス・クーンのパラダイム論やフッサール現象学、ソシュールの記号論などの概念がふんだんに引用されるので、なぜこの知識が必要なのか、という意図がつかめないだろう。
専門の科学者集団はパラダイムに囚われすぎているという先生の指摘は斬新ですごく面白かった。

僕が感じた感想は3つある。

【1】今の日本の弱点は、ハードウェアに付加価値をつける点では新興国の韓国・台湾・中国に追い越され、ソフトウェアやシステムで付加価値をつける点では、米国に負けてしまっていること。
その問題を解決する時に、現代数学が役立つよ、という主張だった。
その製品開発のフェーズに現代数学を使ってモデル化を図って、理論の裏付けを持った技術に育て上げるような方向性だろうか。

だが、ハードウェアの付加価値に差別化を図ろうとする場合、より尖った製品を開発するのは困難だろうと思う。
そのマーケットがそもそも売上や利益が出るような規模なのか、そこにマーケティングを実施して掘り起こせるのか。
その市場で売上を確保できる期間が十分にあるのか。
今の時代は、世界の工場である中国にほとんど製造拠点を持って行かれているので、日本も米国のように、おそらくAppleのように安いハードウェアにソフトウェアやブランドという付加価値を付けて高値で売るようなビジネスに行かざるを得ないのではないか、と思った。

すると、ソフトウェアやシステムで付加価値をつけるフェーズで、現代数学とコンピュータサイエンスを組み合わせて、技術の差別化やビジネスモデルの構築を図る、みたいな方向性が王道になるのではと思う。
しかし、日本から世界に通用するプラットフォームビジネスを生み出せるのか。
日本で現代数学も使えるようなIT技術者を育成できるのか。

先生のお話を聞くと、日本の大学という制度はもう時代に即していないんだなと改めて思う。
明治から昭和までのやり方を未だに大学で続けようとしているが、令和の時代では違うでしょ、みたいな感じ。

akipiiさんはTwitterを使っています: 「今聞いているけど面白い。今の日本の大学という制度は時代に即していないと先生が言い切るのがすごいね。大学もお金を集めないとやっていけない現状、理論の専門家が企業に必要なのに大学が人材供給できていない現状とか色々あるだろうな。#もの数 講演会『ものづくりの数学』 https://t.co/8ijd5ko08g」 / Twitter

【2】先生のお話で面白かったのは、純粋数学や理論物理などの科学者の専門集団はパラダイムに囚われすぎていて、彼らだけに通じる基準と運用で維持し続けられているが、常にその存在意義の正当性を問われているという指摘だった。
自分も大学で数学の研究に従事していた時があったので、その雰囲気がそういう観点で見られているのが斬新だった。

ものづくりの数学のすすめ 技術革新をリードする現代数学活用法』にかかれているトーマス・クーンのパラダイム論の解釈を読むと、科学者という専門集団は真理を追いかけているように見えるが、すごく閉鎖的な集団なんだよ、という意見に聞こえてしまうのが不思議だった。

akipiiさんはTwitterを使っています: 「問題解決者よりも問題定義者が重要。学会はパラダイムに囚われすぎている。ビジネスの現場で抱えている問題は既存の学会や理論で解決できるとは限らず、むしろ無い場合が多い。現場の問題に忠実に認識してその問題を数学で分解して定義し、その一つを大学へアウトソースして解決してもらうとか #もの数」 / Twitter

一方、ビジネスマンは企業の現場で解決したい問題がすでにある。
その問題は理論や学術面で意義は小さいかもしれないが、その現場ではすごく価値がある。
そういう問題を解くのに現代数学という理論を使うとより効果的だよ、と。
そして、大学での理論研究と企業の現場の違いを認識して上手く利用したほうがいいよ、と。

akipiiさんはTwitterを使っています: 「ビジネスと理論のような大学の場の双方を知るような人材をどうやれば育てられるか?先生曰く。ビジネスマンは大学の弱点や問題点を知るのが大事。そんな話を聞くと、日本の大学は時代に即していない感じがするね。 #もの数」 / Twitter

特に、理論と技術の間にはタイムラグがある。
このタイムラグはいわゆる、死の谷、魔の川、ダーウィンの海に相当する。
すると、理論を研究したり使う時も、その技術がビジネスに使えて実際に威力を発揮できるには、いくつかのハードルを越える必要がある。

akipiiさんはTwitterを使っています: 「#もの数 フィリップスを作ったカシミールの考え方。科学と技術は違う。資本主義企業が科学を引っ張るというモデルを経営者は持つがそうではない。量子力学が生まれた時、ビジネスとも関係なく、半導体やコンピュータのビジネスに繋がることは誰も知らなかった。」 / Twitter

【3】なぜ現代数学の理論が企業の技術者やIT技術者に求められるのか?
その理由は、現場の問題を解決しようとする時、既に知られている技術や小手先の知識だけでは対処できず、20世紀以後の現代数学の理論を最終的に使わないといけない場面が出てきているからだろう。

例えば、線形代数の利用シーンが連立方程式や固有値計算だけではなく、代数・幾何・解析・確率論などの色んな場面で使われている。
特に、線形代数の理論は、ニューラルネットワークや機械学習のモデルの計算ではよく使われている。

akipiiさんはTwitterを使っています: 「先生曰く。現代数学は線形代数化している。現代数学は幾何学化している。代数幾何学も線形代数にすぎない。色んな所で線形代数が出てくるのにどの書籍にも解説していない。だから出版した、と。 #もの数」 / Twitter

akipiiさんはTwitterを使っています: 「平鍋さん曰く。行列はAIや機械学習で解きたいデータを表現していて、それを線形代数の理論で解くものと思っていた。なるほど、そういう見方で考えれば画像認識技術にAIが使われる意味が分かる気がする。 #もの数」 / Twitter

先生の話では「位相」という言葉がよく出てきて、どういう意味で使っているのか、当初は理解しにくかった。
ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』を読んでみると、いろんな事象を分類する基準、その構造の近さを同値関係で表していると思った。

akipiiさんはTwitterを使っています: 「位相とは何ですか?という質問に先生曰く。数学者は点ではなく部分集合で考える。だから、関数単体で考えるのではなく、関数の集合で考えて、εδ論法でその構造の近さを同値関係で測定して、同じ・違うで分類するわけか。工業化学をやった人はこの考え方が分かってないと言われた。 #もの数」 / Twitter

代数幾何学が楕円曲線をドーナツの形で分類するように、いろんな事象を数学で捉える時、点ではなく部分集合でカテゴリ化して、εδ論法でその構造の近さを同値関係で測定して、同じ・違うで分類するという発想と思えた。
たぶん、現代数学を知らない人向けにそういう意味で使っているのかな、と想像した。

【4】『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』はとても良い本と思うけれど、現代数学の知識を適用する場所は、メーカーの現場の問題よりも、経済学に関する問題の方がよりインパクトがあるのではないかと僕は思っている。
なぜなら、数学者や物理などの科学者は1990年代頃から経済学や金融にシフトしていること、数学の理論を使えばIT技術と経済学や金融がすごく相性が良いことが分かってきたからだろうと思う。

講演会の参加者には、データサイエンスに詳しい方が割と多い気がしたけど、その人達のバックグラウンドはむしろ、経済事象やマーケティング事象などの社会科学の方が近い気がする。

IT企業が経済学者を雇い始めた理由が面白い: プログラマの思索

計量経済学における統計上の根本問題: プログラマの思索

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

経済学は信頼性革命や構造推定により大きく変貌している: プログラマの思索

機械学習で反実仮想や自然実験が作れる: プログラマの思索

経済数学の直観的方法の感想: プログラマの思索

「推計学のすすめ」「経済数学の直観的方法~確率統計編」の感想: プログラマの思索

僕の問題意識はちょっと別の方向にあるかもしれない。

| | コメント (0)

« 2022年3月 | トップページ | 2022年5月 »