ERP・財務会計・経済学

2022/05/15

Pythonで微分積分や統計の基礎を理解しよう

みんなのPython勉強会#81 - connpassに出たら、『Pythonで微分積分の基礎を学ぼう』という講演が良かった。

みんなのPython勉強会#81 - connpass

Pythonで理解する微分積分の基礎:書籍案内|技術評論社

Pythonで理解する微分積分の基礎 (Python × Math)の著者が話されていたのは、高校数学はPythonで理解してしまいましょう、ということ。
微積分にたどり着くまでに、三角関数、指数関数、対数とか色々出てきて、訳が分からないという学生も多い。
しかし、Pythonならば、関数をグラフで表示できて直感的に理解できるし、計算はプログラムに任せてしまえばいい。
簡単な線形微分方程式も、Pythonなら簡単に解を導いてくれる。

つまり、小難しい理論から理解するのではなく、具体例をPythonで色々プログラムを書いて試して、そこから理解した方が速い。

この話は僕も共感する。
例えば、統計学の理論は十分に揃っているのだから、Webログのようにビジネスの副産物として簡単に採取できるのだから、後はプログラムでいくらでも分析しまくればいい。
最近の心理学や経済学の動向は、コンピューティングパワー抜きではその発展の歴史を追跡できないだろうと思う。

また、こういう人文・社会科学系の理論を使って、組織論や人事制度、経営理論を試す話も最近多くなった。

直近の経済学の雑誌「経済セミナー2022年4・5月号 通巻 725号【特集】「職場」の経済学」をふと読んでみたら、あるべきリーダーシップやモチベーション向上、あるべき組織や人事制度の話があって、興味を惹いた。

あるべきリーダーシップやモチベーション向上、あるべき組織や人事制度の問題を実証的問題に変換し、アンケートを使ったランダムテストなどを使ったりして、社会科学上の問題の本質を探ろうとしている。

プログラミングという武器があれば、現場にある眼の前の個人の心理や集団の行動や意思決定にかかわる問題を統計で分析することで、本質的な変数を見出し、因果関係を見出したり、さらには予測することもできるわけだ。

そういう意味では面白い時代になったのだろうと思う。

Rによる計量経済学/計量政治学を読んでいる: プログラマの思索

戦略/組織/人事と組織の経済学シリーズを読んでいる: プログラマの思索

| | コメント (0)

2022/05/06

超高速開発でアジャイル開発を実現する話に違和感がある

超高速開発をやってます、これでアジャイル開発を実現しています、という話を聞いて違和感があった。
その違和感が何なのか、考えてみた。

違和感を感じた理由は3つある。
1つ目は、超高速開発ツールを使って短納期で少ない工数で開発できることをアピールしているのは違うでしょ、と思うから。
話を聞いてみると、要件定義さえ固めれば、後は設計を開発基盤に落とし込んで、超高速開発ツールという開発基盤を使えば、即座に動くアプリが作れる。
だから、顧客の現場でSEが常駐して、要件をヒヤリングして固めて、作った機能のユーザテストを定期的に行っています、と言っている。
大きな目で見ればアジャイル開発と言えるのかもしれないが、現場でユーザにヒヤリングしながら要件定義を固めること、そして、超高速開発ツールで短納期に開発するのがアジャイル開発と言えるのか、正直疑問に思った。

2つ目は、最近のアジャイル開発の風潮では、アジャイルコーチがきちんと指導したチームでアジャイル開発を回しているのでなければ、アジャイル開発とは言いにくい状況があることだ。
一般に、認定スクラムマスター、認定プロダクトオーナーなどの資格を持ち、スクラムの知識を熟知した技術者がチームを形成しているか、そういう資格を持ったアジャイルコーチが開発チームを指導しているか、を見なければ、アジャイル開発を実践しているか判断できないと思う。

他方、そういう認定資格を持っていない技術者やチームでアジャイル開発をやっています、と普通のソフトウェア企業が公開していたら、見知らぬ技術者は、この会社はアジャイル開発をやっているんだ、と勘違いして入社して、そのギャップに幻滅するのではないか。

昨今の風潮では、アジャイル開発と言えばスクラム一色なので、スクラムの認定資格を持っていない人がアジャイル開発をやっていると言う時、特に公的な場で表現するのは信憑性があるのかな、と疑問に思ってしまう時がある。
他方、スクラムはアジャイルコーチという職業を生み出し、認定資格によって、運用する人たちの資質や品質を担保する仕組みを整備したのはビジネス的に上手いな、と思う。

AgileTourOsakaでSCRUMMASTER THE BOOKの裏話を聞いた: プログラマの思索

3つ目は、超高速開発ツールを使っていると言いながら、データモデリングの技法を重視していない状況だったからだ。
単純に画面と帳票を設計して、それを超高速開発ツールの基盤に載せて、アプリを作っているだけだった。

一般に、超高速開発を標榜する人たちはデータモデリングの技術を背景にして、超高速開発ツールを自分たちで作り込んでいる。
彼らは、業務プロセスをデータモデルやDFDできちんと設計しているから、RDBさえ固めれば、後は画面と帳票のパターンを組み合わせて作るだけ、という方針でやっている。
しかし、超高速開発でアジャイル開発をやっています、という人たちの話を聞くと、確かに業務フローは書くけれど、データモデルが十分に考えられているとは見えなかった。
後で手直しできるから、と割と安易に作っているようにも見えた。

ちょっとそんな現場を見る機会があったので、超高速開発でアジャイル開発を実現しています、という話には気を付けた方がいいな、と思った。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine

チケット駆動開発のプロセスとチケット管理システムの全体像はこんなイメージではないだろうか?

【1】チケット駆動開発とは、チケットを起点として、業務の活動をすべてチケットで追跡する仕組みでありプロセスだ。

具体的には、リリース計画を作成して、チケットを一括登録したり、チケットを随時登録する。
登録されたチケットは担当者によって日々更新されたり完了されて、その進捗状況は、ガントチャートやロードマップなどのチケット集計機能によってリアルタイムにモニタリングできる。
管理者はこの情報を使って日々の意思決定やリスク管理に適用する。

リリースバージョンでグルーピングされたチケットが全て完了になったら、そのバージョンはCloseされて、成果物がリリースされる。
ソフトウェア開発ならば、バージョンつまりスプリントやイテレーションがCloseされると同時に、そのバージョンのモジュールがビルドされてデプロイされてリリースされる。

リリースされたモジュールや成果物は開発者が検証したり、ユーザが実際に使ってみて、開発者が見つけた障害修正やユーザの改善要望が管理者へフィードバックされる。
管理者はそのフィードバック情報を元に、次のリリース計画をブラッシュアップして、次のスプリントを開始する。

すなわち、チケット駆動開発とはアジャイル開発を実装したプロセスの一つとみなせる。

【2】一方、チケット駆動開発はチケット管理ツールという具体的なソフトウェア製品よって支えられている。
このソフトウェア製品という特性と実際の運用をまとめたものをチケット管理システムと呼ぶことにしよう。

【2-1】チケット管理システムの具体的な中身は何か?
基本はPMBOKが言うPMIS、つまりプロジェクト管理情報システムだ。
すなわち、チケットというインプット情報をPMISへ食わせた後、PMISがいろんな観点で加工して、PJ管理に必要な各種レポートをアウトプットして吐き出す仕組みだ。

第三者の観点から見れば、チケット管理システムはすごく単純だ。
なぜなら、インプット+プロセス+アウトプットという逐次実行の仕組みに過ぎないからだ。

【3】しかし、チケット管理システムというPMISの機能を解剖すると、単純な機械でありながら強力な機能を持っていることが分かる。
PMISの主な機能は、フロー管理とストック機能の2つだ。

【3-1】まず、フロー管理は、チケットを流通媒体とみなし、タスクをサクサク流すことに力点を置く。
MS Plannerのタスクカード、Agile開発やカンバン駆動開発のストーリーカードやタスクカード、申請承認ワークフローの申請書に相当する。
フロー管理では、作業のリズムを重視する。

【3-2】次に、ストック機能は、チケットを記憶媒体とみなし、日々の作業結果を記録していくことに力点を置く。
障害管理票や課題管理票、WBSなどの記録媒体。
過去の作業履歴、得られた経験や知識はチケットに記録されているので、チケットが蓄積されるほどナレッジ資産になる。
ストック管理では、ナレッジ基盤を目指す。

【3-3】実際は、チケットがフローとストックの2つの意味を二重に持っていることから、PMISはフロー管理とストック管理の機能を自然に持つようになる。
この特徴により、数多くのチケットを集計した結果から有用なメトリクスが得られる。
例えば、ガントチャート、EVM、リソース管理、タスクボードなど。
また、この特徴により、蓄積されたチケットの履歴やチケット間の関係、成果物とチケットの相互関係から、トレーサビリティの機能が生まれる。

【3-4】チケット駆動開発では、ビルドしたモジュールはバージョンというタグがあり、バージョンでグルーピングされたチケットがあり、そのチケットには作業履歴が残っていて、チケットには構成管理ツールの配下に置かれたソースコードや設計書などの変更履歴が紐づくように、運用される。
このトレーサビリティという機能があるからこそ、開発者は自信を持って開発できるし、管理者もリリースしたモジュールの品質を自分でコントロールできるようになる。

【4】チケット管理システムには、その運用を支える数多くのロールがある。
チケット管理をスムーズに運用するために必要なアクターがあることは、Redmineコミュニティで数多く研究されてきた。

【4-1】チケットを起票する現場の人は、PMISを業務のナレッジ基盤とみなす。
自分が入力した作業結果だけでなく、他人の作業結果も参考にして、ナレッジを利用することで自分の作業手順を効率化することに役立つ。

【4-2】管理者は、PMISをメトリクス集計のプロセス黄ばんと看做す。
彼らは、ガントチャート、EVM、リソース管理、タスクボード、信頼度成長曲線など各種の有用なメトリクスを用いて、業務活動の進捗管理、品質管理、要員管理をモニタリングし、日々の意思決定に活かす。

【4-3】お巡りさん(Redmine警察)は、チケット管理の守護神だ。
彼は、現場の人や管理者がチケット管理に困っていたら支援して、チケット管理をスムーズに運用させる。
チケットは生鮮食料品みたいなもので、日々更新されなければ、ただのゴミに過ぎない。
だから、お巡りさんは定期的にチケット管理システムを通じてチケット管理が運用されているか見て、チケット駆動開発を守る人になる。

【4-4】エバンジェリストはチケット管理の伝道師だ。
チケット管理がいかに素晴らしいか、チケット管理を通じて組織をどのように発展させていくべきか、現場の人や管理者を啓蒙する人だ。
エバンジェリストは熱い気持ちを持ち、チケット管理に関わる人の心に息吹や熱気を注入する人だ。

【4-5】PMISは、現場の人達や現場のプロセスに合うようにカスタマイズしたくなるので、マイスターという開発者がPMISをその現場特有のPMISへカスタマイズし、現場のプロセスに局所最適化する。
マイスターはまさにPMISの職人だ。
マイスターから見れば、PMISはPJ管理の開発基盤という側面も持つ。
つまり、チケット管理システムというPMISはプロジェクト管理を実現するソフトウェアフレームワークという開発基盤とみなせる。
すなわち、チケット管理システムはカスタマイズしやすい特徴を持つので、いろんな現場に適用できるように局所最適化しやすい。
だからこそ、改善が大好きな日本人にはチケット管理システムが合うのだろう。

【4-6】活動家は、PMISのログ(Redmineの活動タブ)を見て、現場の人達の活動、さらには組織の活動をモニタリングし、PMISを組織のプロセス改善の基盤として使う。
活動家は、1個のPJや1個の部署だけでなく、複数のPJや部署を横断して、人間の血液診断や健康診断のように、PMISを通じて組織の活動診断を行う人になる。

【5】こういうポンチ絵を描いてみると、チケットで作業も課題も障害も管理する、という単純なアイデアから生まれたチケット駆動開発は、いろんな側面に支えられて、豊富な応用結果を持つことが分かる。
こういうことを考えるのが楽しい。

脱Excel! Redmineでアジャイル開発を楽々管理:エンジニアがお薦めする 現場で使えるツール10選(3)(1/5 ページ) - @IT

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

Redmine警察・マイスター・活動家は導入の立役者 | マドびっ! Madosan's View

Redmineの普及促進にはRedmine警察やRedmineマイスターという役割の人達が必要: プログラマの思索

打ち捨てられていたRedmineが復活するまでの軌跡 - Qiita

| | コメント (0)

より以前の記事一覧