Redmine4.2のER図が公開されているのでメモ。
これはとても役立つ。
ワテさんの力作。
テーブルを見て、自力でソースも見ながら外部キーのリレーションを見たりして、全て書ききったらしい。
すごいね。
データモデリング屋にとって、ER図があれば、そこから画面はどれだけ必要なのか、どんな機能が必要なのか、はほぼ分かる。
そこから、ER図が表現する業務の内容はほぼイメージできる。
ER図のリレーションから、業務の制約条件も分かってくる。
astah*を使えば、RedmineのDBをリバースエンジニアリングしてDB仕様書は作れるのだが、Railsの弱点は、外部キーや複合キーの設定がテーブル構造の情報だけでは取れないこと。
結局、Railsのソースを読まないと、テーブルのリレーションが分からない。
こういう力作は参考にして、Redmineの特徴を見てみたいと思う。
本日、RedmineJapan vol.2が開催されました。
RedmineJapan vol.2 2022/2/25 - Togetter
REDMINE JAPAN vol.2 オンライン開催 - connpass
Redmine Japan - Redmine Japan Vol.2 ?明日の仕事を変えるために必要なモノ?
参加して良かったです。
とても参考になった講演は、市谷さんの仮説検証アジャイル開発の講演、和田さんの開発プロセスの話。
Redmineに関係ないです、と二人とも語っていたように、Redmineとは無関係の話でしたが、アジャイル界隈、テスト駆動開発の界隈では超有名人なので、話は面白いです。
また、RedmineAwardを私も受賞させていただきました。嬉しかったです。
今後もRedmineコミュニティを緩く長く続けたいと思います。
文庫本「V字回復の経営」をふと読んで、ようやく、なぜ米国企業はことあるごとに、自分たちの経営手法の源流にトヨタ生産方式をあるのだ、とトヨタ生産方式を礼賛するのか、理由が分かった気がした。
一言で言えば、戦前の日本の敗戦と同じく、米国人に日本の経営の手の内は完全に読み取られただけなのだ。
適当なラフな感想。
【1】「V字回復の経営」を読むと、日本企業が官僚化して、世界の潮流から遅れてしまった原因は、設計→製造→販売というサプライチェーンが社内で分断されて、リードタイムが長くなっているからだ、という点に尽きると思う。
だいたい、日本人は、チームワークよりも、専門家として能力を発揮しようという考え方が強いと思う。
実際、大企業として組織の規模が大きくなると、設計→製造→販売の一まとまりのプロセスを一つの組織に任せるのではなく、設計だけの組織、製造だけの組織、販売打系の組織、という形で専門分化しがちだ。
なぜなら、図体だけ大きくなりすぎるから、機能別に組織を細かく分けて、それぞれの専門性を発揮させようとするからだ。
その方が規模の経済を活かしやすく、人も組織もスケールしやすい。
また、専門性を持たせるような組織の方が、仕事の中身が限定されるので、組織のトップとしても人事制度が組みやすいし、戦略も立てやすい。
しかし、大企業になるほど内部組織が専門分化すると、官僚制組織になってしまう。
日本政府のように、コロコロ変わる政治家を無視して、各省庁が勝手に動いて決めて、その結果、戦略性のないまま、あらぬ方向に暴走しやすくなる。
日本の組織論の失敗事例を分析し尽くした本である「失敗の本質」に、その有様が詳しく多面的に書かれている。
【2】では、米国企業は80年代に日本企業に負けた後、どうやって90年代に復活したのか？
米国人は、日本的経営手法を丸裸にして分析し尽くした後、リエンジニアリング、シックスシグマ、サプライチェーン、アジャイル開発など、手を変え品を変えて、その概念を経営戦略やソフトウェア開発に適用してきたのだ。
「V字回復の経営」によれば、米国人によって日本の手の内は完全に読み取られた。
米国人は自分たちで、日本解体新書を作り上げてしまった、と。
ちょうど、戦前の日本が、日清戦争・日露戦争で一躍世界に躍り出たものの、第二次世界大戦では日本の暗号を米国に完全に読み取られて、最後は完全にやられてしまったのと同じように思える。
【3】では、米国企業は日本の手の内をどのように分析し尽くしてきたのか？
「V字回復の経営」を読むと、4つの観点があると思う。
それは、プロダクトポートフォリオマネジメント、かんばん方式は時間の戦略であると見抜いたこと、バリューチェーンで経営戦略を類型化したこと、ITを駆使して設計も生産も販売も経営も全てリードタイムを短縮化できると見抜いたこと、の4つだ。
【4】プロダクトポートフォリオマネジメント（PPM）
20世紀後半に日本企業が急激に成長したメカニズムは、PPMの発想と同じ。
つまり、日本企業は米国企業と違って、短期的な利益よりも、長期的な観点で、まずは市場シェアの拡大を狙う。
すると、市場シェアの拡大→売上増加→経験曲線効果により単位あたりのコストは低下→低コストの強みを活かしてシェアを拡大する、という一連の拡張ループが生まれる。
米国人のコンサルがこのアイデアをPPMという世界初の経営戦略理論を生み出したわけだ。
【5】かんばん方式は時間の戦略である
米国企業は、日本企業の強さに生産現場での高品質、効率化にあると分かったが、なかなか真似ることはできなかった。
米国の労働者は能力にばらつきがあるし、QCサークルやワイガヤみたいにチームの一体感を生み出すことも難しい。
しかし、米国人のコンサルは、トヨタ生産方式を分析して、かんばん方式の本質は在庫減らしではなく、時間の価値という新しい戦略要素を追求する手法と見抜いた。
企業は時間の戦略によって、新たな競争優位を生み出せる、と導いた。
一般に、ビジネスとは、設計→製造→販売という一連のプロセスから成立する。
ここにカンバン方式が生み出した時間の戦略を当てはめれば、設計→製造→販売というプロセス全体のリードタイムをいかに短くするか、という問題に置き換えられる。
つまり、企業戦略の要素であるヒト・モノ・カネ・情報の次に、時間が大事だと見抜いたわけだ。
この発想は、ビジエスプロセス・リエンジニアリング、サプライチェーンマネジメントからアジャイル開発に至るまで、その背後にあるように思う。
日本の大企業を見ると、組織の図体が大きくなると、設計→製造→販売というプロセス全体のリードタイムが長くなりがちなので、設計だけ、製造だけ、販売だけ、というプロセス単体の効率化に走る。
すると、各プロセスに特化した設計事業部、生産事業部、販売事業部という機能別組織を新たに作ったり、あるいは、設計だけ、生産だけ、販売だけの子会社をたくさん分社化しがちだ。
実際、日本の家電メーカーや自動車メーカーを見れば、生産と販売が分社化されているのがほとんどだ。
今では、家電メーカーも自動車メーカーも、派遣や委託という形で、製造すら、どんどん外部へアウトソースしている場合がほとんどではないか。
すると、どの組織もタコツボ化されてしまい、自分たちの製品を受け取る顧客からどんどん遠くなるので、顧客のことを考えなくなる。
まったく顧客志向ではない。
一方、米国企業は、時間戦略が重要と概念化し理論化することで、スピード重視の経営スタイルに変革した。
そのやり方は、たとえば、業務プロセスを改革しリードタイムを短縮させるというリエンジニアリングだったり、原材料の仕入れから設計、製造、販売までのプロセスでリードタイムを短縮するサプライチェーンマネジメントだったり、ソフトウェア開発ならばユーザーストーリーで要件をまとめて設計からプログラミング、テスト、リリースまでを一気通貫に開発してしまうアジャイル開発だったりするわけだ。
つまり、製造業の生産プロセスのリードタイムを短縮するという手法を、一連の供給連鎖、価値連鎖、ソフトウェア開発まで一般化することで、よりスピーディに対応できるようにしたわけだ。
【6】バリューチェーンで経営戦略を類型化
一方、ポーターはバリューチェーンを提唱した。
そこから、経営戦略は、ポーターの基本戦略であるコストリーダーシップ戦略、差別化戦略、集中戦略に類型化される。
ポーターの基本戦略からの結論は、99％の企業は差別化戦略しかありえないことだ。
すると、企業は市場においてポジショニング戦略を取ることで、差別化したポジションを取り、競争優位を生み出そうとするわけだ。
【7】ITを駆使すれば設計も生産も販売も経営も全てリードタイムを短縮化できる
他方、90年代から現代まで急激に進化したものは、ITを駆使すれば、設計→製造→販売という一連のプロセスだけでなく、あらゆる業務のリードタイムを短縮できることだろう。
ブルーカラーの生産現場だけでなく、ホワイトカラーの生産性も同様に、トヨタ生産方式を導入することで同じように効率化できる。
たぶん、アジャイル開発がその典型例だろう。
日本のソフトウェア開発では、今もウォーターフォール型開発が典型的であり、請負契約や準委任契約というビジネス慣習の制約もあるために、なかなかアジャイル開発を実践しにくいのが一般的だろう。
IPAの資料にも、アジャイル開発が偽装請負にならないように気をつけるべき注意点を公開していたと思う。
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021 － Publickey
ソフトウェア開発ビジネスが他の生産や販売のビジネスと異なる点は、ソフトウェアは販売後でも簡単にリリースした機能を変更できること、製造やコピーというプロセスがないので素早くリリースできて大規模に販売できる点だろう。
この特徴を生かしているのがSaaSであり、GAFAが展開しているプラットフォームビジネスだろうと思う。
そして、アジャイル開発のやり方を自動車業界に展開しようとしているのがテスラであり、彼らは、Appleが「電話ができるコンピュータ」であるスマホを生み出して携帯電話もデジカメも駆逐してしまったように、「移動能力を持つコンピュータ」である電気自動車を生み出してガソリン車やハイブリッド車を駆逐しようとしている。
中島聡さんのメルマガを読んでいると、自動車業界はソフトウェア開発をベースとしたビジネスへ置き換えられるように変わっている時代なのだ、と気付かされる。
テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること: プログラマの思索
特に直近30年間では、日本人は世界標準から見てソフトウェアに弱いと思う。
日本ではソフトウェアビジネスやビジネスモデルの基盤にソフトウェアをおくことができていないと思う。
今も日本人はソフトウェア開発とソフトウェア開発に向いた組織づくりに苦闘しているように思える。
【8】そんなことを思うと、日本人がトヨタ生産方式を徹底的に分析できず、米国人にそのアイデアを経営手法やソフトウェア開発手法まで洗練化させて概念化して理論化できたのはなぜなのか、と思ったりする。
なぜ、日本人は融通が効かず、新しいアイデアや環境を取り入れられないのか？
なぜ、日本人は時間戦略を採用できないのか？
日本人は抽象的な思考能力が低かったからなのか？
正直良くわからない。
【追記】
アジャイル開発の有用性が分かっているにも関わらず、日本人が運用以前に導入できない原因は、「リーダーシップ不足」「生産性が著しく低い」「リスク許容度が著しく低い」点にあるのではと考えた。
リーダーシップ、生産性、リスク許容度は一般的な日本人の典型的な弱点だから。
現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ: プログラマの思索
テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること、というツイートを見つけたのでメモ。
自分は理解できていないので、疑問点も一緒に自分用のメモ。
以下は自分の直感を適当に書いたので、論理的ではない。
【参考】
akipiiさんはTwitterを使っています 「中島聡さんのメルマガでテスラの凄さをよく解説されてるがピンとこなかったが、このスレッドで意味がすこし分かる気がした」 / Twitter
テスラが従来の自動車メーカーと異なるところ - Togetter
【0】中島聡さんのメルマガも合わせて考えると、テスラが自動車製造にソフトウェアを持ち込んだメリットは3つあると思う。
週刊 Life is Beautiful ２０２２年２月８日号：自社製チップと粗利益率 - まぐまぐ！
【1】1つ目は、メーカーにも関わらず、売上高粗利益率が圧倒的に大きいので、どんどん新設備に投資できる財務基盤があること。
普通の自動車メーカーの粗利益率は10％台であり、トヨタですら16％くらい。
一方、アップルは40％、テスラは30％の粗利益率を持つ。
ソフトウェア専業のマイクロソフトは80％の粗利益率らしい。
売上原価には、1台の自動車を作る部品、原材料、人件費、設備の減価償却も含む。
もちろん、外注した部品代金、外注した車載半導体、外注した車載プログラムの開発費用も含まれる。
ソフトウェアの売上原価は、所詮、電気代とサーバーの減価償却と人件費くらいなので、製造業に比べれば圧倒的に低い。
中島聡さんのメルマガによれば、テスラやアップルはハートメーカーでありながら、自社で製品設計して、その製品を圧倒的に安く作るために韓国や台湾の製造専業メーカーに製造委託する。
だから、圧倒的に安く作れるので、売上原価は小さい。
一方、自社では、M1チップ、あるいは、自動運転の学習エンジン専用の半導体まで製造する。
そこで、アップルなら自社のOSやiTuneプラットフォーム、テスラなら自動運転のソフトウェアをオプションで付けて、安いハードに付加価値を付けて高く売りつける。
ユーザは、その利便性を求めるし、顧客満足度を高めることにより、ブランド価値を高めて、ロイヤルティを持たせる。
だから、メーカーでありながら粗利益率が圧倒的に高い。
でも、財務基盤の仕組みが分かっていたとしても、ソフトウェアの技術力が高くなければ、そう簡単に真似できないだろう。
ソフトウェア開発は、優秀な人材に依存するものであって、マネーの資本を注ぎ込んでも規模の経済は働かないから。
【2】2つ目は、工場の生産ラインそのものもソフトウェアでバージョンアップしやすくすることで、生産性が圧倒的に高いことだと思う。
この辺りは僕は詳しくないのでよく分かっていない。
OEM生産といえば、スーパーがよくやるプライベートブランド商品を外部メーカーに委託する生産のイメージ。
テスラの生産ラインは1～2年でどんどん進化するらしいが、トヨタのような自動車メーカーの生産ラインは4～5年おきのように古いままなのだろうか？
今、スマート工場や工場のDXが叫ばれているが、日本の工場は古い製造ラインを数年も放置したまま製造しているのだろうか？
そんなに日本の工場はアナログなのだろうか？
このツイートが正しいならば、フォルクスワーゲンのようなドイツ企業、GMのようなアメリカ企業も同様に、彼らの工場の生産ラインは古くて生産性が低いのだろうか？
【3】3つ目は、EV製造に関わるソフトウェアは、いろんな事業とシナジー効果が大きいこと。
自動運転のソフトウェアの開発の為に、機械学習専用の半導体チップを製造したり、バッテリや充電施設を強化したり、果てはスペースXのような宇宙事業にまで、シナジー効果がある。
中島聡さんのメルマガでは、人間は2つの目というカメラで運転しているのだから、自動運転技術はカメラだけで十分であって、LiDARにまでコストを掛ける必要もない。
LiDARをつけたソフトウェア開発は余計に複雑になるから、と書かれていて、なるほど、と納得した。
このツイートもよく分かっていない。
OEM生産のラベリングとは、所詮、プライベートブランド商品に製造ラベルを貼り付けるだけだと思う。
自動車メーカーのラベリングは数ヶ月もかかるような手間がかかるものなのか？
ラベルを大量生産する仕組みを今まで作っていなかったのはなぜなのか？
【4】このツイートを読んで思うことは、ハードに対するソフトウェアのメリットは、プログラムの頻繁なバージョンアップによって機能強化できることにより、ユーザにとっては、古いハードであっても、いつでも新しい機能を使えて利便性が高まることだ。
つまり、ハードは一度リリースしたら変更できない。それは当たり前。
一方、ソフトは一度リリースしても、ファームウェアのアップデートやソフトウェアのバージョンアップによって、手持ちの製品がいつでも最新版の製品に生まれ変わることだ。
それにより、ユーザの生産性もどんどん上がる。
そういうソフトウェアの特徴を生かして、工場の生産ラインにも反映して、生産ラインを制御するソフトウェアをどんどん進化できるような仕組みを作っているのだろうと思う。
だから「工場も一つの受注製品」という主張が成り立つわけだ。
DevOpsやアジャイル開発では、コミュニケーションが大事とよく言われるが、僕はそんな所にイノベーションとか価値があるわけではないと思う。
むしろ、製造とリリース後の保守も含めて、全てをソフトウェアで一貫して制御することにより、1人のプログラマが全ての工程をコントロールできるようになったことが大事だと思う。
従来であれば、各工程の専門家による分業体制でしか製造できなかった製品が、たった1人あるいは数人のソフトウェア開発チームで製造できるようになったこと。
ビジネスモデルは、規模の経済からソフトウェアによる少人数のチーム開発へ変革された。
たぶんそこに、ソフトウェアが従来の製造業と異なる価値をもたらしているのだと思う。
平鍋さんのツイートで、Python の numpy の裏では FORTRAN で書かれたライブラリが動いているよ、という資料のリンクがあったのでリンクしておく。
参考になる。
線形代数演算ライブラリBLASとLAPACKの基礎と実践 (I)BLAS, LAPACK入門編
興味深い点をメモしておく。
行列の使い道 → 連立一次方程式
量子コンピュータは無限次元の線形代数≒Hilbert空間論
コンピュータでの数値計算に再現性はあるか?
違う結果が出る場合がある。最近のコンピュータはマルチスレッドで、足し算の順序がコンピュータの都合で変わることがある。従って、結合法則が成り立たないことがあることより、違う結果が出る場合がある。
自作して失敗する例:連立一次方程式をクラメールの公式で解く
→理論的にはクラメールの公式を使ってプログラムを作ると、コンピュータで解ける。
→しかしながら、行列のサイズ n が大きくなるとすぐ解けなくなる
あっというまに宇宙時間より長い時間が必要になる。
立場によって観点が違う。
・数学者の意識 : 原理的に可能, 解の存在のみ興味ある場合が多い
・情報系の数学より : アルゴリズムが多項式程度なものを考えたがる
・自然科学系研究者 : ともかく答えが求まる方法なら何でも良い。問題が出るまで放置。よく指数関数的なアルゴリズムを意識せずにゴリ押しする。
・HPC or 数値解析系研究者 : 1 clockでも速い方法 1bitでも転送量が少ない方法、1桁でも精度の良い方法などから選択する。アルゴリズム重視？
⇒数学者は解の存在だけ分かればいい。
⇒情報系学徒は、計算量オーダーが多項式程度しか興味がない。プログラムが実行できないから。
⇒自然科学者は、とにかく実際に計算できればいい。計算量オーダーの問題が出てくるまで計算ゴリ押し。
連立一次方程式をどう解くか？
・数学者の意識 : 行列式が0でないなら解ける。終わり
・情報系の数学より : LU分解も逆行列求める方法もオーダーは同じO(n^3)なので違いはない、クラメールはO(n!)なんで論外。
・自然科学系研究者 : とりあえず逆行列求めとこう。LU分解って何? 解きたい問題は別だし他に考えるべきことが多いし後まわしにしよう。
・HPC or 数値計算系研究者 : LU分解経由一択。基本であるdgemmだからキャッシュヒットも高いし、逆行列を使うより誤差も少ない。よってLU分解経由以外あり得ない。クラメールは誤差も大きい。
⇒数学者は理論1本だけ。
⇒科学者や情報系学徒はQCDのトレードオフを考える。情報系学徒は計算量オーダーが大事。
コンピュータで線形代数演算するならBLAS+LAPACKを使いましょう。
品質、信頼性がとても高く、無料で入手できる。
BLASはBasic Linear Algebra Subprogramsの略。
基礎的な線形代数の「サブ」プログラム Level 1 ～ 3まである。
FORTRAN77でさまざまなルーチンの仕様を提供している。
BLASのルーチンを「ブロック」にしてより高度なことをする。
LAPACKとはBLASをビルディングブロックとして使いつつ、より高度な問題である連立一次方程式、 最小二乗法固有値問題、固有値問題、特異値問題を解くことができる.
下請けルーチン群も提供する: 行列の分解(LU分解, コレスキー分解, QR分解, 特異値分解, Schur分解, 一般化Schur分解)、条件数の推定ルーチン, 逆行列計算など。
BLAS, LAPACKを利用したソフトウェアには、Ruby, Python (numpy), Perl, Java, C, Mathematica, Maple, Matlab, R, octave, SciLabがある。
⇒Numpyにも使われているのは面白い。
諸問題を組織論に持っていくのは目的を手段化していないかと気づいたのでメモ。
(1) 杉本啓さんはTwitterを使っています 「僕が、コンウェイの法則をあまり好きじゃないのも、この辺が遠因。」 / Twitter
「DXとは組織論である」みたいな論調が最近はやたら多い。
確かにその傾向はあるだろう。
DXを実践するには、IT化した業務、ソフトウェアを基盤にしたビジネスモデルが必要だから、それを実行できる人や組織が必要だ。
しかし、その本質は、「組織は戦略に従う」というチャンドラーの経験則に過ぎないと考える。
なぜなら、DXを実現する経営戦略が先にあって、その戦略を実行できる組織が必要だよ、という事実が、たぶん、どこにでも普遍的に見られるだけだからだ。
だから、色んな諸問題を組織が悪いから実行できないのだ、だから組織を何とか変えよう、という動きに進んで、それが自己目的化していないだろうか？
本来は戦略を実行するのが目的なのに、組織を変えることが目的化してしまっている、みたいな場合が日本では割と多いのではないか。
そして、なぜ、色んな諸問題を組織が悪いから実行できないのだ、という論点にすり替わってしまうのか、という問題の原因も見えてくる。
実は、「組織（構造）は戦略に従う」というチャンドラーの経験則とは逆に、「戦略は組織（文化）に従う」というアンゾフの経験則がある。
たぶん、会社の偉い人が意思決定した戦略に社員を従わせたいのに、実際はうまく行かない原因は、社員が従わないからだ。
それは組織文化にあるからだ、ということなのだろう。
特に官僚組織では、その組織形態そのものがなかなか変わらないので、長年の慣行が組織文化として固まってしまう場合が多いだろう。
野中郁次郎先生の「失敗の本質」を読むと、日本人は、「組織（構造）は戦略に従う」「戦略は組織（文化）に従う」という経験則に振り回されているような印象を受ける。
本来は、組織は戦略を実行するための仕組みの一つに過ぎないのに、その仕組が暴走自動車みたいにハンドル操作が効かなくなり、勝手にあらぬ方向へアクセルを踏んで自爆した、みたいな感じ。
一方、特に米国のMBAの参考図書に上がっている組織人事論の本とか読んでいると、彼らは、組織を動かすための能力やスキルへ抽象化して、誰もが身につけられる普遍スキルに仕上げているように思える。
リーダーシップ論などは特にそう思う。
最近のコメント