Agile

2023/01/22

PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか

@sugimoto_keiさんのツイートを読んで、PM理論ではP志向の方がM志向よりも生産性が高いことを主張していることに気づいたのでメモ。

【参考】
杉本啓さんはTwitterを使っています: 「多くのひとは職場での人間関係を気にし過ぎる。その人が自分を支配しようとして色々束縛するなら、それは人間関係の問題だが、そうでないなら、人間関係は気にしないで自分がやるべき仕事をすれば、ほとんどの場合、解決する。人間関係が気になるのは仕事がうまくいってないから。その逆ではない。」 / Twitter

杉本啓さんはTwitterを使っています: 「昔の経営学で、課業志向と人間関係志向という概念があったが、これは課業志向の考え方。基本的には、課業志向でできることをまずやるのが先決だと思う。人間関係というものは答えがないし、根本的に解決することもできない。」 / Twitter

杉本啓さんはTwitterを使っています: 「多くのひとはたぶん、集団の中で自分の居場所を作ることが重要だと考えているのだろう。それが人間関係志向ということ。それはわかるのだが、そうではなく、何を達成するのか、そのためにどうするか考える。これが課業志向。そうすると人間関係は大して気にならなくなるし、却って良くなるものだ。」 / Twitter

【PM理論とは】歴史や特徴を事例からわかりやすく解説|リベラルアーツガイド

PM理論とは?理論とリーダー育成における活用場面をわかりやすく解説|人材育成・社員研修|ラーニングエージェンシー

PM理論でリーダーを育成する企業は伸びる『事例紹介』 | 識学総研

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

心理的安全性はPM理論のメンテナンスの発展形ではないか: プログラマの思索

組織論で紹介される学者はほとんどが欧米人だが唯一の日本人として、三隅二不二のPM理論がよく紹介されている。
昭和の時代にカイ二乗検定を使って統計的に有意な仮説としてPM理論を打ち立てたらしい。
PM理論の考え方は考えてみれば当たり前のように感じて、あまり気に留めていなかったが、@sugimoto_keiさんのツイートを読んで、PM理論が主張したかった本来の内容は違うのではと思った。

組織におけるリーダーの能力は、課業志向と関係志向の2つがあり、両方とも高いレベルを目指すべきとPM理論は言う。
しかし、実は課業志向の方が関係志向よりも生産性が高いことを言いたかったのではないか。
つまり、リーダーシップは結局成果を出して初めて認められるものであり、成果を重視せず関係ばかりに注力しても問題解決にならない、と。
特に、日本人のリーダーや集団は課業志向よりも関係志向を重視しすぎていて、生産性が高くないのではないか、と。

たとえば、リーダーシップとは成果主義が前提であるという考えは、「採用基準」にも記載されていたのを思い出した。
採用基準」では、成果を求められないリーダーシップに囚われすぎる日本人を批判している。

たとえば、野中先生の「失敗の本質」でも、日本軍という官僚的組織が実は成果主義よりも関係志向を重視していて、リーダー間で忖度し合うことで戦争に負けた経緯が詳しく分析されている。

たとえば、PM理論でリーダーを育成する企業は伸びる『事例紹介』 | 識学総研では、典型的な日本企業である日立でも、管理職のリーダークラスは優秀であっても課業志向ではなく、関係思考が強い傾向があるらしい。

こういう話を踏まえた上で考えると、日本人は集団でリーダーシップを発揮するという考え方や行動に何らかの問題があり、それがずっと弱点になっているのではと思う。

今の日本のアジャイル界隈では心理的安全性という概念がとても好まれているが、実は日本人のリーダーシップには関係志向が強すぎて課業志向が欠落しているのではないか、という考え方も心に留めておく。
たぶんコンテキストや環境によってはこの観点も必要だろうと思う。

| | コメント (0)

2022/12/23

現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ

採用基準」「生産性」を読み返したらいろんな気付きがあった。
ロジカルでないラフなメモ書き。

【参考】
「採用基準」の感想~日本の根本問題はリーダーシップの総量が不足していること: プログラマの思索

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

Slack導入がDXに繋がる話: プログラマの思索

諸問題を組織論に持っていくのは目的を手段化していないか: プログラマの思索

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

失敗の本質―日本軍の組織論的研究の感想: プログラマの思索

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

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

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

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

【1】最近の日本のIT業界を見ていると、主に2つの現象が目につく。
一つは、DXに向いた組織を作ろう、という組織論の話。
もう一つは、DXを実現するためにアジャイル開発をもっと積極的に導入して運用しよう、という話。

この2つの話の背景には、2つの問題意識が真因として隠れていると思う。
具体的には、組織論の話題、アジャイル開発の話題の背後には、日本人はリーダーシップが不足していること、日本人は生産性の意識も言動も非常に低いことだ。

【2】今のビジネス界隈では、DXがバズワードだ。
DXを実現するには、既存の業務であれ、新規の事業であれ、ソフトウェアでコスト削減、さらには売上の創出が求められている。
DXを実現するには、ソフトウェア開発者、そしてそれを取り囲む組織という基盤が必要だ。

しかし、DXに関する組織論のテーマはすごくフワフワとしていると思う。
命令指揮系統ではなくフラットに風通しを良くしよう、心理的安全性が担保されるような組織風土を作りましょう、という組織文化の話題が多い。
だがそういう甘い言葉の背後には、今までの組織文化や事業スタイルを捨てて、新しい事業や新しい組織の関係を作ろうとする原動力が必要なのに、たくさんの壁にぶち当たる怖さが説明されていないように思える。
だから、何となく、現状を批判するだけで何も変わらない、という現象が出ているように思える。

実際は、既存の組織風土を変えるのは、今までの人間関係や組織との関係を変えることであり、自らリーダーシップを発揮して動いていかなければ何も変わらない。
ものすごく自頭の良い人やできる人に従ってやれば問題解決するわけではない。
自らチェンジ・エージェントになり、たくさんの困難な壁にぶち当たるごとに、一つずつ壁を壊したり乗り越えていくパワーが必要になる。

採用基準」では、問題解決には、問題解決スキルだけでなく、問題解決リーダーシップ(Problem Solving Leadership)が必要と主張している。
たとえば、目の前に起こったいじめの問題に対し、MECEやロジックツリーだと言っても何も変わらないし、実際に解決するように行動して初めて、問題解決の方向に動き出す。
それが本来のリーダーシップ。

すると、このリーダーシップの背後には、「自らリスクを取る」という概念が隠れていることが分かる。
自分の思いどおりに変わらない状況に対し、自分と異なる価値観を持つ人を説得して調整したり、自分が持っていない知識やスキルはそいうう専門スキルを持った人たちに働きかけてチームとして問題解決を図ることが必要になってくる。
そういう行動は、思い通りの結果にならないかもしれないリスクに自らチャレンジすることを求める。

しかし、日本人はリスクを取りたがらないと一般的に言われている。
すべてのリスクを回避してリスクをゼロにすることばかりに専念している。
だから、リスクを取ってリーダーシップを発揮するという行為、選択肢が取りにくい人が日本には多いのだろう。

実際、「採用基準」に記載されている通り、日本人はチームプレーでチームに貢献した成果を問われる経験が極端に少ない。
たとえば、小中高校生なら、受験という行動はその人だけの能力測定試験であり、個人プレーにすぎない。
社会人になっても、プロジェクトリーダーや管理職にならない限り、自分だけの仕事の成果しか問われない。
すると、一般職の日本人は一生、チームでの成果を求められる、というリーダーシップ経験を積まずに終わる人が多い。

そんなリーダーシップ経験のない人は、わがままな振る舞いが多い。
チームで成果を出すためにそれぞれの役割を認識せず、自分が一番成果を出しやすい行動に走ってしまいがちだから。
自分が成果を出しやすい個人プレーに走るのは、自分が苦手な場面に行動するリスクを取らないことにも通じる。

そんなことを考えると、リーダーシップ不足という弱点をごまかして隠すことで、組織論というふわふわしたテーマに流れてしまうのだろう。
そしてリーダーシップ不足という日本人論の問題点は、日本人はリスク許容度が低いことに真因があると思う。

【3】アジャイル開発は20年以上前から提唱されているのに日本ではなかなか導入すらされなかったが、ここ最近になって積極的に取り入れようとする流れが出てきた。

アジャイル開発の本質は一体何なのか?
僕は、アジャイル開発とは時間価値を最優先にしたソフトウェア開発だ、と一言で言えると考える。
WF型開発のように、時間も労力もかけて品質を作り込んで、高品質なソフトウェアをリリースするのではなく、小刻みにいち早くソフトウェアをリリースすることで売上もキャッシュも獲得していく戦略を取る。
1年間で1回のリリースではなく、5回リリースできるなら、5回分のフィードバックが得られて、その分、市場ニーズに合ったソフトウェアへいち早く開発できるようになる。
つまり、リリース頻度が5倍多いなら、ソフトウェアの価値も5倍高まるメリットが生まれる。

では、なぜアジャイル開発は日本で受け入れられなかったのか?
アジャイル開発の源流はトヨタ生産方式と言われていて、日本人にも馴染みがあるのに、なぜアジャイル開発は日本人にフィットしなかったのか?
たぶんその最大の理由は、ソフトウェア開発の生産性が低いことが問題だ、という意識が非常に薄いことだと思う。

官公庁みたいな縦割り組織の日本人は生真面目なタイプが多いので、決められたルールに従う方が重要であり、コストや期間を度外視したり生産性を重視する行動に行きやすい。
また、ソフトウェア開発者派遣のような人月ビジネスでは、たくさんの工数がかかるほど儲かるので、生産性を上げるモチベーションがビジネスモデル上生まれにくい。
今の日本の製造業では生産工程の改善により原価低減による付加価値向上を目指すが、3%の生産性向上よりも30%以上、2倍以上の生産性向上を目指すような、イノベーションを取るような行動が生まれていない。

なぜ米国企業は90年代に蘇ったのか~日本の手の内は完全に読み取られた~V字回復の経営の感想: プログラマの思索

生産性が低い現象が問題だ、と考えて、その問題解決を図ることにより、生産性をさらに大幅に向上させるという正のループを作り出せていない。
特に、3%の生産性向上のようなちょっとした改善ではなく、30%や2倍以上の生産性向上を図ろうとすれば、今までのやり方を捨てて、新たなアイデアを試す、といったリスクを取らなければ実現できないだろう。
しかし、今までリスクを取ったことがない人が、いきなりハイリスクハイリターンの選択肢を取るのは非常に難しいだろう。
なぜならば、仕事でもプライベートでも、そういうハイリスクハイリターンの練習を経験していなければ、実践で試すことは難しいだろうから。

日本人の生産性が著しく低い、という点にも、日本人はリスクを取りたがらない、という現象がその問題の背後に隠れている。

つまり、「ソフトウェア開発のように、時間価値が重要な意味を持つビジネスでは、生産性に比重をおいて時間戦略を取るべきだ」という考え方が日本人も日本企業も受け入れられていないからだ。
その真因には、日本人のリスク許容度が低いこと、土建業界やIT業界に限らず自動車業界においても日本のあちこちの業界で多重請負ビジネスがはびこっていることにあるのだろうと思う。

なぜ米国企業は90年代に蘇ったのか~日本の手の内は完全に読み取られた~V字回復の経営の感想: プログラマの思索

【4】リーダーシップ不足や生産性が著しく低いという現象には、リスクを取らないという日本人の気性が出ているのではないか。
あえてリスクを取ることで、大きなリターンを得る、というハイリスクハイリターンの選択肢を最初から捨てている場合が多いのではないか。

リーダーシップがあり、生産性が高い人は、いろんな問題解決に対してリスク許容度が広いので、かなり大きなリスクを自ら選択することができる。
つまり、リスク対応力とその人の問題解決能力は比例しているのだろうと思う。

【5】組織論やアジャイル開発をテーマにしている人たちは、日本人の弱点である「リーダーシップ不足」「生産性が著しく低い」「リスク許容度が著しく低い」という真因におそらく気づいている。
その真因をいろんな角度から、いろんな言葉で、いろんな手段で解決を試みようとしているのだろうと思う。
そういう観点を持って、今のDXにかかわるテーマを取捨選択して聞いてみたいと思う。

| | コメント (0)

2022/12/13

DDPは品質管理に役立つのか

DDP(Defect Detection Percentage)は品質管理に役立つのか、について考えたことをメモ。
ラフなメモなので、間違っていたら後で直す。

【参考】
資格認定ISTQBはソフトウェア・テストの何を変えたのか? ―― ソフトウェアテストシンポジウム 2013東京(JaSST'13 Tokyo)|Tech Village (テックビレッジ) / CQ出版株式会社

バグ密度・テスト密度に依存しない品質保証への挑戦 | DATA INSIGHT | NTTデータ

コード行数を用いない品質分析技術と開発速度を落とさない品質管理手法の提案~NTTデータ ソフトウェア品質シンポジウム2021

テスト / 品質関連メトリクスまとめ | Test-Hack | 3分で理解するIT/テスト技術

【1】
ソフトウェアテスト標準用語集 (日本語版)によれば、欠陥検出率(Defect Detection Percentage (DDP))の定義が書かれている。

欠陥検出率(Defect Detection Percentage (DDP)): あるテストレベルで見つけた欠陥の数をそのテストレベル、及び、以降のテストレベルで見つけた欠陥の総数で除算した値。escaped defects も参照のこと。

テスト / 品質関連メトリクスまとめ | Test-Hack | 3分で理解するIT/テスト技術では、
欠陥検出率(DDP) =検出バグ数÷当初保有バグ数×100
で紹介されている。

DDPの事例としては、コード行数を用いない品質分析技術と開発速度を落とさない品質管理手法の提案~NTTデータ ソフトウェア品質シンポジウム2021が有名なのだろう。

ただし、DDPをよくよく考えてみると疑問がいくつか出てきた。
上記のPDFでは、単体テストで潜在バグをすべて検出できず、後工程である結合テストで流出した単体テストのバグ数を数えて、結合テストフェーズでDDPを算出している。
その内容を見ると、DDP=9/10=90%なのでそれほど流出しておらず問題ないように見える。

しかし、結合テストフェーズでは、3件のバグのうち1件が単体テストから流出したバグなので、前工程から流出したバグの割合は1/3=33%になる。
よって、結合テストでは本来結合テストで見つけるべきバグよりも、前工程から流出したバグが多く見つかっているのではないか、という疑念が生じる。

また、資格認定ISTQBはソフトウェア・テストの何を変えたのか? ―― ソフトウェアテストシンポジウム 2013東京(JaSST'13 Tokyo)|Tech Village (テックビレッジ) / CQ出版株式会社でもそうだ。
ここでは、アジャイル開発でスプリントごとにDDPを算出している。

スプリント1のDDP=40/(40+10)=80%なので、後のスプリントにあまり流出しておらず、スプリント1は品質が良さそうに見える。
しかし、スプリント2では、バグ45件に対し、10件がスプリント1という前のスプリントのバグが見つかっている。
つまり、スプリント2のうちスプリント1が占めるバグの割合は、10/45=22%にものぼる。
前のスプリントで潰しておくべきバグが後のスプリントでたくさん見つかるということは、今実施中のスプリントで本来見つけるべきバグ検出にリソースを集中することができていない疑念がある。

また、スプリント2のDDP=35/(35+25)=58%なので、かなり品質は悪い。
スプリント3でスプリント2のバグが占める割合は、25/80=31%なので、スプリント2の時よりももっと品質が悪くなっている事実を示している。

【2】DDPが高い数値で品質が高そうに見えるが、実は品質が悪かったという状況はどんな時なのか?

それは、前工程や前のスプリントで多数のバグが見つかったケースに相当するだろう。
つまり、たとえば、前工程や前のスプリントで20件、50件、100件のように多数のバグが見つかった場合、後工程で10件流出したとしても、DDPの値は高めに出るので、一見品質は良さそうに見える。
しかし、元々DDPの分母や分子の数値が大きいので、そう見えるだけ。
後工程で、前工程から流出したバグの割合を見れば、多数のバグが流出しているだろうから、前工程ですべてのバグをすべて潰しきれていないことを示しているだろう。

つまり、DDPは前工程のバグの流出を許さないような前提条件で品質を考えている場合、DDPは品質管理に有効とはいえないだろう。
WF型開発やアジャイル開発でも、後工程がお客様という立場であれば、DDPの指標がたとえ高くても、その妥当性は色々分析してみる必要がある。

【3】そんなことを考えると、品質管理に出てくるメトリクスは1つの観点のKPIに過ぎず、品質という抽象的な成果を評価するには多数のKPIをつなげて1つのストーリーを作る必要が出てくる。
したがって、品質に問題がないという説明で納得させるには、いろんなKPIをつなぎ合わせて試行錯誤して、なんとか妥当性の根拠を示すという手間がかかるわけだ。

プロマネはそういう部分で数多くの苦労をしているので、品質管理や不具合分析は胡散臭いと思っているのかもしれない。

【補足】
@sakaba37さんのコメントを追記しておく。
メトリクスには罠が多い。
さかばさんはTwitterを使っています: 「@akipii 開発中は「いつもと同程度なら、いつもと同じようなテストが実施されたと推定できる」以上のことはわからないように思います。」 / Twitter

| | コメント (0)

2022/11/29

UMTPモデリングフォーラムのパネル討論の感想

先週11/24に行われたUMTPモデリングフォーラムのパネル討論だけを聞いた。
ラフな感想をメモ。

【参考】
MF2022プログラム - UMTP 特定非営利活動法人UMLモデリング推進協議会

30、50、100人の壁の正体|山本 正喜 / Chatwork CEO|note

データモデリングの立場の中山さん、渡辺さんに対し、ドメイン駆動設計の増田さん、スクラムの原田さんという割りと立場や意見も異なる人達の討論だった。
話は色々あったが、その中で気になった点は2つある。

1つは、少人数のベンチャー企業から大人数の大企業へ進化する時にどんな壁があるのか?

スパン・オブ・コントロールの原則通り、1人の社長が統率できる人数はせいぜい5~7人まで。
そこから20名、50名、100名、300名と増えるごとに、ピラミッドのような階層構造を持つ組織になっていく。
すると、必ずその会社特有の業務システムが必要になってくる。

興味深かったのは、30名未満の少人数ベンチャー企業が、従業員数よりも多い個数のSaaSを運用している会社があるよ、という話。
おそらく、10名未満の少人数ベンチャー企業であれば、自社だけに作り込んだ業務システムは不要であり、SaaSを導入するだけで十分やっていけるだろう。
しかし、事業や業務がどんどん拡大していき、従業員も増えるが、それ以上に業務が複雑化して、その業務を支えるSaaSを次々に導入して運用してしまった。
しかし、SaaSにインポートするデータは、各事務員がExcelで作りこんで準備して取り込んで修正する作業を行っている、と。
これは、いわゆる「人間バッチ」と同じですね、と。

「人間バッチ」と揶揄する理由は、本来は事業や業務を回すための業務システムを独自に作って自動化する必要があるのに、それをさぼって、事務員が労力をかけて業務データをExcelで作り込んでSaaSに流し込むという手作業をこなっているからだろう。
結局、今はどんな企業であれ、税務会計だけでなく、事業や業務を回すためのシステムも必要になっているわけだ。

そんな状況ではデータモデリングがとても威力を発揮すると思う。
なぜならば、業務を回すための仕組みを分析するには、業務フローだけでなく、事務員が作り込んでいるExcelデータを抽象化したデータモデルが必要になってくるからだ。
そのデータモデルさえきちんと分析できれば、業務フローも画面もバッチも帳票もほぼ決まってしまう。
業務分析とデータモデリングは表裏一体と思う。

もう一つは、データモデリングが業務分析、ビジネスモデルの分析でとても有用なのに、なぜその技術が普及せず、軽んじられているのか?

パネラーの方も色々話されていたが、僕は本当の原因が他にあるような気がした。
単にIT技術者や事務員にデータモデリングの知識が足りないから、だけではないだろう。
データモデリングを習得するモチベーションがそもそもないことに真因があるだろう。

特に昨今のアジャイル開発に興味を持つ人であれば、古臭いデータモデリングよりもドメイン駆動設計の方に惹かれるだろう。
実際、増田さんが主催されるドメイン駆動設計の勉強会にはたくさんの開発者が集まるのに、データモデリングの勉強会はあまり開催されていないし、開催されたとしても正直あまり人は集まらない。

それはなぜなのか?
その理由は僕もわからない。
このテーマは今後も考えてみたい。

【追記】
@sakabaさんからこんなコメントを頂いた。

さかばさんはTwitterを使っています: 「@akipii 開発者がソフトの寿命を短く考えがちなことや、利益が出てから作り直した成功例のあることが根底にあると思います。このため目先の利益を得ることに走りがちで、モデルが後回しになっていると思います。」 / Twitter

ベンチャー企業では売上重視のビジネスモデルなのでSoEのようなWebサービスのシステム開発が中心になる。
一方、大企業になって安定してくると、社内の業務を安定して回す基幹系システム(SoR)が重要な役割を占めてくる。
つまり、ベンチャー企業では、社内の業務システムが必要になる状況になるまでは、基幹系システムは作らないし、作る必要がないと認識しているのだと理解した。


| | コメント (0)

2022/11/16

XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた

XPエクストリームプログラミング入門をオンラインで聞いた。
改めて、XPエクストリームプログラミングは偉大だ、時代がその設計思想に追いついた、と思った。
ディスカッションの内容から感じたことをラフなメモ。

【参考】
XPエクストリームプログラミング入門 - connpass

ITの地殻変動はどこで起きているのか?~チケット駆動開発はなぜ生まれたのか: プログラマの思索

僕は、「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法 」の第1版の方が好きだ。
理由は、荒削りだが内容はとてもシンプルで、当初考えていた直感的な思いが直接的に表現されているからだ。

- eXtreme Programmingの魅力を探るにある「Embrace Change - 変化ヲ抱擁セヨ」のグラフが一番好きだ。

勉強会の内容は放談会みたいで面白かった。

XPはプラクティスありきではない。
プラクティスは具体的な実践方法。
プラクティスは価値を実現したものの一つ。
しかし、価値は抽象的すぎるので、プラクティスと価値の間に原則を置いて、プラクティスと価値を橋でつなぐ。
そういう絵がXPではよく出るが、その意味がようやく分かった。

XPのプラクティスは、そのテーマ単体だけで一冊の本になる。
たとえば、リファクタリングなら、リファクタリング(第2版)
テスト駆動開発なら、テスト駆動開発実践テスト駆動開発
継続的インテグレーションなら、継続的インテグレーション入門継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
見積もり手法や計画ゲームなら、アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
ふりかえりなら、アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き
シンプルな設計なら、エリック・エヴァンスのドメイン駆動設計
つまり、それぞれのテーマはとても奥深いのだ。

たぶん、それらのテーマは重要である、とケント・ベックは直感的に感じていたのだろう。
それを言語化して形式知としてプラクティスで取り上げたのはすごいと改めて思う。

福井さんいわく。
最初はスクラムは好きではなかった。
XPは具体的なのに、スクラムではプロセスはしっかりしているが、実際に実践しようとすると中身が分からない。
でも、今はスクラムは好きですよ、と。
スクラムはスクラムマスターの存在が凄く大きい、と。

アジャイル開発は自動車の運転のようなもの。
到着先は分かっていて、その道順が分かっていても、不確定要素があり、ハンドル操作で変化を受け入れながら進める。
つまり、運転は変化が全くない動作ではないし、変化を受け入れる動作範囲に落ち着くようにする。

時代がアジャイルにやっと追いついた。
アジャイラーは当初は周囲と戦っていた。
いかに導入するか、いかに普及させるか、に注力していた。
しかし、今はお客様からも、アジャイル開発を導入したいと言われる。

WF型開発の権化だったPMBOKがアジャイル開発の考え方を取り入れて、PMBOKの最新版でごっそり変わったのも大きいね、と。
実際、PMBOKは従来の分厚い数多くのマネジメント技法の知識体系だったのに、アジャイル開発の考え方を具現化して、価値や原則が主体のマネジメント体系に変わろうとしている。

アジャイル開発を支える技術が揃ってきたのも重要だろう。
特にクラウドが普及したおかげで、すぐにサーバーを立ち上げて、実際に動かしてみて、動かしながら作っていくのができるようになった。
それもコストをあまり掛けずに、個人ですら開発できるようになった。
つまり、継続的インテグレーション、継続的デプロイ、リファクタリング、テスト駆動、短期リリースなどを支える技術が揃ってきたおかげで、アジャイル開発を実践しやすくなった、と。

一方で、SIがアジャイル開発に追いついていないように思える、と。
発注者は自社で内製開発がしたいので、アジャイル開発を自然に受け入れやすい。
しかし、SIは受託なので、既に自分たちの標準プロセスを持っているし、人月単価のビジネスモデルもあるから、いきなりアジャイル開発に変換するのは難しい。

僕がXPやアジャイル開発に惹かれる最大の理由は、IT業界のきつい仕事から脱出できるための救いとして捉えていた面があったからだと思う。
多重請負の人月単価のビジネスモデルの中で、大量のプログラマや技術者をまるで仕掛在庫みたいに扱って、変動するバッファみたいに扱う手法がどうしても慣れなかった。
アジャイル開発は人重視であり、技術者の専門性を活かしながらチームでアウトプットを出していく、という思想に引かれていたのだと思う。
IT技術者として専門性を高めていくと自然にアジャイル開発に収れんされていくはずだ、と思っていた。
今もその思いは変わらない。


| | コメント (0)

2022/11/06

第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT

第23回r東京Redmine勉強会の感想をラフなメモ。
3年ぶりのリアル会場でハイブリッド開催だった。

【参考】
第23回勉強会 - redmine.tokyo

2022/11/5 第23回redmine.tokyo勉強会 #redmineT - Togetter

Redmine Advent Calendar 2022 - Adventar

【1】リアル勉強会で嬉しかったのは、@yukiaさんと@shinyaさんに対面で会えたこと。

yukiaさんとRedmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論したことがあった。

Redmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論してみた - Togetter

Redmineのトラッカーは一般向けに説明が難しいよね、その原因は何か?
yukiaさんはヘーゲル弁証法の観点で、トラッカーは各人ごとの切り口でバラバラに使っているが、弁証法でより一層抽象化ないしもう一段上の抽象化レベルで議論すれば同じ概念だ、と話。
僕の観点では、フッサール現象学やプラトンのイデア論みたいに、トラッカーという概念は客観的に存在すると思われているが、各人の目線では、帳票設計だったり、チケットの種類だったり、ワークフローだったり、いろんな解釈で存在が認識される、という話。

yukiaさんは「強制エポケー」というフッサール現象学の言葉も知っているので、僕が言いたい内容ももちろん理解した上で発言されている。
懇親会ではあまり話せなかったけれど、この辺りももう一度話しみたい所。

shinyaさんの、塩漬けチケットを一気に却下したツイートを以前コメントしていたら、反応が多かった。
他にも退職者ツイートなど、面白いツイートがあったのですごく記憶にあった。

他にもリアル対面の人を認識できて良かった。

【2】前田剛さんの話では、RedMicaのお話と国民年金基金連合会がRedmineで作られていた話。
これには笑った。

Redmineで構築されている国民年金基金連合会の「他年金調査 事業所回答システム」を調べてみた - ファーエンドテクノロジー株式会社

他年金調査 事業所回答システム

実際にログイン画面を見れば分かるが、どう見てもRedmineだ。
日本企業の事業所は約300万と言われているらしいので、その事業所にいる社員数をRedmineで管理していると考えると、相当な数のレコードがRedmineに蓄積されていて、個人情報の観点でも非常にセンシティブな内容があるだろう。
Redmineなら安全に運用できるという判断があったのではないか。
このあたりの話も勉強会で聞けると嬉しいね。

【3】僕の話はチケット駆動開発の昔話。
あの頃は若かった。
なお、2020年頃からRedmineの勢いに陰りが出て、JiraやBacklogの勢いを感じている。
実際Googleトレンドではそんな感じ。

齋藤さんはTwitterを使っています: 「@akipii google トレンドの話に、興味を持ちました。JIRA / backlog 勢がほぼ同じような動きですね。 実際の日本でのシェアは、どんなもんですかね? #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「@saito0119 #redmineT 詳細は知らないですが、ネットやコミュニティの話を見聞すると、JiraやBacklogの勢いは感じますよね。」 / Twitter

中村さんの話は、Redmineを5.0にVerUpしたお話。
プラグインの互換性確認のために手間がかかったそうだが、@g_maedaさんやプラグイン開発者、パッチ提供者のおかげで無事に乗り切れた、とのこと。
Redmineコミュニティが活発であるからこそ、安心して運用できるわけだ。

@geosanak さんの話は、Redmineプラグインのテスト自動化を頑張っている話。
ビルド管理ツールはJenkinsからCircleCIまで色々あるが、GithubActionを使ったよという話。
詳細をもう少し聞きたかったが時間切れ。

@bowkoba さんのオフショア開発にRedmineを運用した時に、コミュニケーションの問題が発生した話は同感だった。
チーム運営、プロジェクト運営で発生する問題は、結局のところ、プロマネが伝える内容が伝わっていない、指示を仰ぐメンバーが理解できていないことに尽きる。
その問題はコミュニケーション不足の症状として現れるが、その根本原因と再発防止策は、それぞれの現場で異なる。
現在、アジャイル界隈では、DXを実現するための組織論の話が多いが、その観点も、このコミュニケーション不足の問題と同じ構造を持つと思う。
結局のところ、組織文化の問題として出てくるが、本当の真因は、プロセスや組織構造に根っこがあるわけだ。

@t_tsuru さんのRedmineUIの問題点は、従来から問題提起されてきた。
この問題の改善は、今後どんどん重要視されてくるだろうと思う。
他のPJ管理ツールやSaaSでは、チケットのコメントがリアルタイムに表示されたり、UIが今風で使いやすかったりするので、どうしてもその観点から比較されて敬遠されてしまうから。

チケット茶番劇も面白かった。
実際にチケットのやり取りを見るのは楽しい。
チケットを書く人がどんな気持ちでいるのか?
リアルで見えるのはいい。

@yokoba569さんの話では、チケット駆動開発が良かったよ!という話。
チケット駆動が楽しい!
Redmineが実績管理にとても向いていて、実際にデータをメンバー自ら採取して分析し始める。
見積もりと持ち工数の観点でPJ管理をどんどん改善しようとする。

@tohosaku さんはRedmine を railway にデプロイしてみた話。
@agilekawabata さんは、Redmineハンドブックの紹介。
わかりやすくてとても良い本です。

@tkusukawa さんは、Redmineを利用する趣旨のお話。
趣旨を説明するのはいつも大事。

@hiroiwsk6さんは、お役所の問い合わせ管理と帳票出力をRedmineで改善した時に、どんな設計で構築したのか、というお話。
問い合わせチケットのステータスごとに、送信メールが作られるのが面白い。
つまり、ステータスごとに、メールの内容や宛先が微妙に異なってくるので、メールテンプレートをいかに共通化して設計するかが肝なのだろう。

@naitohさんは、勉強会の参加者や利用Redmineの属性分析のお話。
もう8年以上蓄積されているので、Redmineにも波がある。

【3】今回はハイブリッド開催。
会場の参加者は26人くらいで、そのほとんどが常連さんで初めての方もチラホラ来られていた。
その後の懇親会では、久しぶりの再会を皆で喜んだ。

オンライン開催が普通になった今では、確かにZoomでやった方が正直楽だ。
しかし、会場開催の方が、反応を生で感じられるし、いろんな人達と交流できるのが楽しい。
生身の人間と肌感を感じるのがとても久しぶりだったから、本当にそう感じた。

Redmineコミュニティももう11年目で、他コミュニティに比べても古参になった。
スタッフや参加者も入れ替わりがありながら、よく続いているなと思う。
熱量がある人が入れ替わり立ち替わり居続けることで続いているんだと思う。
コミュニティは仲間から生まれて続く。

| | コメント (0)

2022/10/21

Javaのモジュールシステムの考え方をまとめてみた

Javaのモジュールシステムの理解が深まったのでメモ。
Java初心者のラフなメモ書き。

【1】モジュールシステムはなぜJavaで必要なのか?

異なるJarであっても、同一パッケージ名が衝突する問題があった。
モジュールは、パッケージを区別するための仕組み。
パッケージはクラスを包み込み、モジュールはパッケージを包み込む。

Javaはオブジェクト指向言語なので、機能追加したい場合、開放閉鎖原則に従って、既存クラスは修正せず新規クラスを追加する。
Rubyのオープンクラスみたいなもの。
すると、クラスがどんどん増えるので、パッケージでクラスを分類しようとする。
そして、パッケージをまとめたJarを配布して、開発者に利用してもらうようにする。

しかし、Jarファイルもどんどん増えてしまって、異なるJarなのに同一パッケージで衝突する場合がある。
Mavenでこういう依存ライブラリのJarを管理するけれど、名前衝突が多くなるのだろう。

【2】なぜ、無名モジュール、自動モジュールは必要なのか?

Java9以後はモジュールシステムを使う必要があるが、以前のJara8のJarファイルはモジュールに対応していない。
Java8のJarファイルを利用できるような環境としてモジュールが導入された。

基本は、Classpathにある無名モジュールが一般的だが、modulepathにないので、名前付きモジュールから無名モジュールを読み込めない。
そこで、modulepathにJarファイルを置いて、自動モジュールに変更して、名前付きモジュールから自動モジュールを読み込めるようにした。

実際の現場を見ると、Java8までで止まっているWebシステムは割と多いように感じる。
たぶん、Java9以後のモジュールシステムに対応するように、移植するのは難しい場面があるからだろう。

【3】無名モジュール、自動モジュールとは何か?

無名モジュールはJava9以前のJarで、Classpathにある。
以前のコマンドみたいに、java -cp **.jarみたいに使う。

なお、無名モジュールのJarはclasspathにあるので、名前付きモジュールから読み込めない。

自動モジュールはJava9以前のJarで、ModulePathにある。
java --module-path **.jar とか、java -p **.jarみたいに使う。

名前付きモジュール--> 自動モジュール、自動モジュール --> 名前付きモジュールの両方で読み込める。
なぜならば、modulepathに名前付きモジュールも自動モジュールも両方配置されているから。

なお、無名モジュールも自動モジュールも、パッケージのクラスは全て公開されているから、モジュールシステムのように公開の制限はできない。

無名モジュールはJDK9以前のライブラリ。
module-info.javaもMETA-INF/MANIFEST.MFもない。
ClasspathにJarを配置していると、java --module-path **.jarが使えない。

自動モジュールは、META-INF/MANIFEST.MFにAutomatic-Module-Name属性が指定されている or jarファイル。
JDK9以後は、java -p **.jarで実行する。

自動モジュールはできるだけMETA-INF/MANIFEST.MFにAutomatic-Module-Name属性を指定する。
なぜならば、Jarファイル名は書き換えられやすいので間違いやすい。
META-INF/MANIFEST.MFに記述すれば、Jarファイル名が書き換えられても呼び出されるJarは同じになるので安全。

【4】jlinkはなぜ必要なのか?

専用のランタイム用アプリを作りたい。
JDK9以後は、JREがないから。

さらに、クラウドのサーバーレス環境でアプリを実行する時、コンパイルしたアプリのサイズを小さくできる。
クラウドのリソースを抑えられるし、アプリの起動時間(ロード時間)も短くできるメリットが出てくる。
つまり、AWS lambdaみたいに、イベント駆動で多数のプロセスを並行起動するような場面では、アプリサイズが小さいほど性能も良くなるし、デプロイもやりやすい。

たぶん、クラウドの開発に特化するようにJavaも進化してきているのだろう。

クラウド上の開発がJavaに与えた影響は何なのか: プログラマの思索

【5】jdeps --jdkinternal はなぜ必要なのか?

JDKの内部APIでクラスレベルの依存関係を検索するためのコマンド。
古いJava8のJarファイルがどんなJDKライブラリを使っているか調べるために使う。
Java9以後は公開されていないJDKライブラリは排除していくべきという考え方。

Java9のモジュールへ移行する時や、jlinkコマンドで小さい専用ランタイムアプリを作りたい時に利用できるだろう。

【6】なぜServiceLoaderは必要なのか?

ServiceLoaderは、Java9以前で依存性注入(DI)を実現する方法に過ぎない。
たとえば、Sampleインターフェイスだけ公開して、SampleImpl実装クラスは呼び出さないように実装したい。
META-INF/servicesに、実装クラスを記載したテキストファイルを作って、ServiceLoaderが読み込んで動的に切り替える仕組みにしただけ。

Java9のモジュールシステムでは、ServiceLoaderを利用する場合、module-info.javaにprovides~with~でIFを書いて公開する。

「公開IFの提供」をmodule-info.javaで宣言する => provides 公開IF with 実装クラス(SPIを実装)
「公開IFの利用」をmodule-info.javaで宣言する => uses 公開IF名(SPIとして使う)

ServiceLoaderはJDBCドライバの実装にも使われているので、わりと一般的。

【7】Javaのモジュールシステムは、Javaの進化でどのような意義を持つのか?

モジュールシステムは、Javaをクラウド開発に適用したり、デプロイしたモジュールやライブラリの移植性を高めるために必要なのだろう。
しかし、Javaは過去の遺産が多すぎるために、どんどん仕様が複雑になってきていると思う。

実際、Jarの依存性のエラーメッセージの種類が多くなっているために、問題解決するのは大変だろうと想像する。

Javaのモジュールシステムは複雑性をより増している: プログラマの思索

一方、Javaはオブジェクト指向言語だけでなく、関数型言語の一面も持つ。
実際、OptionalやStreamなどのモナドのAPIはまさに関数型言語そのものだ。

Javaが関数型言語の特徴を持つようになった理由の背後には、クラウド上で多数のプロセスを並行で動かす時に、MapReduceの仕組みがあれば、負荷分散をより活用できるメリットを活かしたいからだろう。

Javaはオブジェクト指向言語ではなく関数型言語だった~「[増補改訂]関数プログラミング実践入門」はお勧めの本だ: プログラマの思索

Javaはなぜ関数型言語になろうとしているのか: プログラマの思索

JavaSilverの感想~Javaはオブジェクト指向と関数型言語の2つの性格を持つ: プログラマの思索

そんなことを考えると、20年前にUMLやJavaを使って、オブジェクト指向設計に熱狂していた時代はもう古くなっている。
そういう価値観はもはや終わったように思える。
そして、時代は更に進化しているわけだ。

一方、その進化はどんどんソフトウェアの複雑性を増やす。
ソフトウェアの本質は複雑性にあるが、その複雑性をどのように手懐けてコントロールすべきなのか?
今も昔もソフトウェア開発はこの問題から逃れられない。

| | コメント (0)

2022/09/04

「Googleのソフトウェア・エンジニアリング」の感想

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセスを読んだのでラフなメモ。


「Google社内でときに言われるのは、「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」ということだ。」という文章がとても印象的。
ソフトウェアの複雑性は、積分された面積で表現されるとすれば、保守性や移植性などのソフトウェア品質特性を維持するために、それをいかに増大させないようにするか、という問題につながる。

そのために、コーディングルール、開発環境、テスト自動化、継続的インテグレーション、継続的デプロイ、テスト環境のコンテナ化、など色んな技術とそのノウハウが出てくるわけだ。

スケールとトレードオフ:「Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス」を読んだ - mamo.memo

Book Talk:『Googleのソフトウェアエンジニアリング』をぼくたちはこう読んだ!(前編)|グロービス・デジタル・プラットフォーム|note


| | コメント (0)

2022/08/05

組織を芯からアジャイルにする対談の感想~今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない

組織を芯からアジャイルにする対談で、平鍋さんが話されていた。
感想をラフなメモ。

【参考】
平鍋健児 ? 市谷聡啓 ?組織を芯からアジャイルにする対談? - シン・アジャイル | Doorkeeper

認定スクラムプロダクトオーナー研修の感想: プログラマの思索

平鍋さんの穏やかな口調のお話を聞いていると、そうだよねとうなずくし、勇気づけられた点もあった。

1990年代、2000年代は、プロセスの時代。
仕様に対して、いかに仕様どおりに正しく作るか、品質を担保するか、が問題だった。
そのために、ソフトウェア工場、オブジェクト指向設計、要求工学、ソフトウェア工学などがたくさん出てきた。
そして、アジャイルが出てきて、今までのアプローチは違うのでは、と。
開発者の中でこねくり回すのではなく、顧客と対話したり、市場と対話してシステムを作り上げる。
2010年頃から、リーンスタートアップが出てきたのもその流れではないか、と。

今となっては、アジャイルも日本では普通に認識されるようになってきた。
今の日本では、アジャイルは先カンブリア時代みたいに、たくさんの人達がこれがアジャイルだ、とたくさん実践して公開してきている。
そんな中で、これが本当のアジャイルだ、と言う必要はないと思う。
アジャイル警察はいらない。
もちろん、自分のポジションや意見として、アジャイルはこうだというものはあるけれど、それで対立を煽るような議論はしない。
最近は議論をやめてます、と。

平鍋さんの話を聞いて、何となく救われたような気もした。
僕だけが感じているだけに過ぎないかもしれないが、最近のアジャイルの風潮として、自分はアジャイルをやってますと名乗るには、アジャイル開発の経験だけでなく、スクラムの認定資格を取っているか、認定スクラム資格を持つアジャイルコーチの指導があるのが条件なような気がしていたから。
カジュアルに、アジャイルをやってます、みたいなことが言えない気がしていたから。
顧客とオンサイトで超高速開発ツールを使ってすぐにデモして見せてアジャイルにやってます、みたいな場面があったりして、それは違うのでは、という違和感を感じていたから。

一方、スクラムの研修を受けると、内容は確かによく考えられているし、参考になる概念もすごく多い。
このフレームワークでプロセスの諸問題が解決されるのでは、と思えたりする。
1990年代から2000年代にかけて、たくさんのアジャイルの流派が生まれてきたけれど、2020年代の現在では、それらアジャイルの考え方、プロセスはスクラムへ収斂されていく過程ではないかと思ったりもした。

しかし、平鍋さんの話を聞けば、今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない。
そう思えば、そこまで神経質にならなくてもいいし、自分で経験して理解できたことがあれば、それを普通に表現して、自分なりに解釈してもいい。

他にも気になる話があった。

平鍋さんいわく、市谷さんの書籍は、熱い気持ちや勢いで書いている所があっていいね、と。
自分が思いついたアイデアには旬があり、今ここで書かなければいつ書くのか、みたいなタイミングがある。
特にIT業界の本はそういう傾向がある。
こういうことに気づいて考えたから、今書きたい、という熱いモチベーションがあるうちに一気に書くべき。
平鍋さんが共著で書いた本「アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」も、今書かなくてどうするんだ、という熱い気持ちで書いた、と。
自分も、年末には書きたい本の目次は壁に貼っておいて、そこから書きはじめる時がある、と。

平鍋さんいわく、市谷さんが提唱した言葉「越境」「向き直り」もいいね、と。
市谷さんはネーミングが上手い。
気づいたアイデアに名前付けしてネーミングすることは重要だ。

平鍋さんがプロジェクトファシリテーションでレトロスペクティブを「ふりかえり」という言葉で概念化したが、過去を振り返るだけでなく未来にも目を向けていることを強調できなかった。
だから天野さんと議論した後で、小野小町の見返り美人もそうでしょ、後ろに顔は向いているけれど、足の方向は前向きだから、とフォローしたんだよ、と。

確かに、何かすごいことを思いついた時、そのアイデアを別の言葉でネーミングすることにより、新しい価値や意味をもたらすことができる。
そういう体験を僕も感じた。
その体験はやると病みつきになる感じ。

| | コメント (0)

2022/07/31

製造業の業務にスクラムを適用できるのかという疑問~全てのビジネスモデルにスクラムを適用できるのか?

先日、認定スクラムプロダクトオーナー研修を受けてきた。
その中で最も興味を持ち、そして今も半信半疑で理解できていない話は、「テスラの生産は全てスクラムでやっています」というお話。
ジョー先生から、下記のYoutubeを教えてもらったので見た。
以下、理解できていない初心者のラフなメモ。

【参考】
[日本語と英語] Keynote アジャイルコーチが学んだ「Tesla 真の凄さ」?あなたが学んできたアジャイルとTeslaは何が違うのか? ジョー・ジャスティス - YouTube

認定スクラムプロダクトオーナー研修の感想: プログラマの思索

【日本語訳】A day of Mob Programming Subtitles by Joe Justice [No Audio] - YouTube

なぜ米国企業は90年代に蘇ったのか~日本の手の内は完全に読み取られた~V字回復の経営の感想: プログラマの思索

【1】ジョー先生の認定スクラムプロダクトオーナー研修に出た時に一番興味があり、そして今も完全に理解できていない点は、ジョー先生が話されていたのは、テスラはスクラムで電気自動車を製造しています、という話。

先生曰く、テスラでは調達・計画・製造・品質部門は全てスクラムチームで活動し、すべて生産している。
たとえば、材料や部品を購買するチーム、車体を作るチーム、ブレーキを作るチーム、電池を作るチーム、自動運転ソフトウェアを作るチーム、販売するチームなどがある。
それらスクラムチームをサポートするために、カスタマーサポートのチーム、経理チームなどがあり、他にも、各チームにコーヒーを提供するコーヒーサポートチームもあるらしい。

ジョー先生に、生産計画はどうなっているのか?と聞いたら、そんなものはない。
スクラムチームは生物の細胞(セル)のように自己組織化されているから、と。
各チームはそれぞれの部品を作る責務があり、各チームは他チームに必要な部品や素材を要求するために、各チームのプロダクトオーナーが集まってメタスクラムの中で調整する。
下流工程のスクラムチームから上流工程のスクラムチームへ部品や素材を要求して製造されるので、プル生産になっているので問題ない、と。

他にも色々聞きたかったが、僕が疑問点を言語化できていなかったので、それ以上は質問できなかった。

【2】電気自動車がモジュール化できるだろうと推測できても、本当かなと思うが、たぶん僕が分かっていないだけかなとも思う。
でも、この仕組みで本当に高品質に大量生産できるのか、は別問題と思う。

高品質な規格品を大量生産できる仕組みをどうやってアジャイルに構築して、大量生産できるのか?
単純に考えると、普通の大規模製造業では、相当大規模な資金を使って、工場に設備投資して、生産ラインを作って、部溜まりが安定するくらいに生産ラインの設備機械の稼働率も製造メンバーによる生産プロセスも安定させる必要があるが、それをスクラムで実装できるのか?

一方、ソフトウェア開発は結局、人依存であり、メンバーのスキルや能力に品質が比例するし、技術の習熟度合いも比例する。
ソフトウェア開発には設備は殆どいらない。
ソフトウェア企業での規模の経済は所詮、開発者という人員と拠点となる作業場くらいなので、簡単にスケールできる。
しかし、ハードウェア製品の規格品を作る場合、人だけでなく、膨大かつ大量資金の設備が必要であり、それをすり合わせるのが難しいはず。
テスラが自動運転などのソフトウェア技術が優れているのは理解するが、ハードとして本当に実現できているのか?

【3】製造業の業務にスクラムを本当に適用できるのか?
僕の疑問はこれに尽きる。
この疑問を自分なりに分解してみる。

1つ目は、ジョー先生の話を聞くと、製造業のバリューチェーンにある各機能、つまり機能別組織をそのままスクラムチームに単純にマッピングしただけに思える。
一般に普通のメーカーであれば、仕入→計画→製造→販売という主活動のバリューチェーンがあり、購買部、生産計画部、製造部、販売部のような機能別組織で構成されている。
また、総務・経理・人事・企画などの支援活動のバリューチェーンもあり、総務部、経理部、人事部、企画部という機能別組織が構成されている。
ジョー先生の話を聞くと、機能別組織をスクラムチームに編成するだけで、各チームは自己組織化されるように聞こえるが、それら組織は会社として全体最適化されるのか?

たぶん、普通の会社の機能別組織をそのままスクラムチームにマッピングしても、有機的な触媒が簡単に起きるとは思えず、おそらく何らかの前提条件が数多くあるのではないか、と思う。

2つ目は、製造業の生産ラインで重要な点は、生産プロセスを標準化生産に当てはめて安定化させることだが、スクラムを適用してもそれを実現できるのか?
一般に、トヨタ生産方式でもっとも重要なポイントは、需要の変動をなくして、在庫があまり増減せず一定の範囲に落ち着くように、また、設備の稼働率が大きく変動することなく、設備機械が高い稼働率で安定して動かすために、生産量を標準化するように生産計画を立てる。
そういう生産計画なしで、単に、機能別組織を置き換えたスクラムチームだけで、安定的に生産できるのか?

普通に考えると、各機能の組織は個別最適化するように動いてしまって、ボトルネック工程に数多くの在庫を作り出してしまう罠が発生しがちだ。
なぜなら、生産部門の中で、部品加工を行う部署は、高額な設備機械を持ち、部品加工を効率良く行うための手順を持つので、自分たちの生産性を最大限に上げるように動きがちだから。
スクラムチームは生産プロセスを全体最適化するように自然にバランスを取ってくれる保証はあるのか?
もしそれが実現するならば、どんな原理によって実現されるのか?

おそらく、製造業の業務というビジネスモデルの中でも最も複雑な問題をスクラムで解決できるならば、それなりに何らかのノウハウがあるのではないか、と思う。

【4】とは言え、テスラは自動車業界で最も注目されていて、2022年現在の時価総額がNo.1である。
ジョー先生は、テスラの時価総額は、トヨタなどの日本メーカー、アメリカのビッグスリー、ドイツやフランスや韓国のメーカーの時価総額の合計に等しいくらい大きいです、と言っていた。

注目されている理由は、いくつかあるだろう。
以下は自分の推測。

1つ目は、電気自動車という「移動能力を持ったスマホ」という製品がビジネスとして大きなインパクトと可能性があることだ。
電気自動車というハードウェアを一度所有すれば、自動運転ソフトウェアやユーザインターフェイスがスマホみたいに定期的にバージョンアップされるので、いつでも最新の機能を維持できる。
つまり、従来のメーカーによる製品売り切りではなく、バージョンアップされるソフトウェアのサブスクリプションで売上を確保するようになる。
どこかの話では、アップルやテスラの粗利益率が30%以上もあると聞いていて、その理由は、こういうソフトウェアのバージョンアップというオプション、つまり付加価値がとても大きいからだ、という話を聞いた。
つまり、ビジネスモデルとしては従来の自動車メーカーよりもはるかに財務体質は良いことになる。

テスラが従来の自動車メーカーと異なるところ - Togetter

テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること: プログラマの思索

2つ目は、他の自動車メーカーにも大きな影響を与えているように見えることだ。
たとえば、ドイツのフォルクスワーゲンは、自動車のソフトウェア化では、テスラよりも劣っているが、日本のメーカーよりも遥かに先に進んでいると聞いたことがある。
その理由は推測だが、フォルクスワーゲンなどのドイツ自動車メーカーはディーゼルエンジンの不正により大打撃を受けたので、従来のガソリンエンジンは捨てるしかなく、電気自動車に賭けるしかなかった、ということではないか。

また、テスラがベルリンに製造工場を作った事件もドイツ自動車メーカーに影響を与えているのではないか。
なぜなら、ドイツ自動車メーカーの工場の生産性よりもテスラの製造工場の生産性の方が圧倒的に大きかった、と聞いている。
すると、テスラを見習って、単に電気自動車を製造するだけではなく、電気自動車の付加価値を高めるソフトウェア基盤の開発が重要なはずだ、と考えて、その方向に一気にカジを切ったのではないか?

【5】そんなことを考えると、他業界のビジネスモデルにもスクラムを適用できるのではないか?と思える。

製造業という数多のビジネスモデルの中でも最も複雑な業務にスクラムを適用できるならば、小売、卸、サービス業、官公庁の業務にも適用できるはずだ。
単純に連想すると、経営コンサルタント業務のように、高度な専門知識を持った人が集まって、少人数のチームを形成してアウトプットを出す業務には、スクラムはすぐに適用できるはずだ。
なぜなら、ソフトウェア開発チームの特徴にコンサル業務がとてもよく似ているからだ。
設備はほとんど不要で、必要なものは、各メンバーに高度な専門性を持つ技術があるかにかかっているからだ。
つまり、コンサル業務のチームにスクラムをそのまま適用すれば、今の大規模スクラムのノウハウをそのまま適用するだけで、コンサルビジネスもスケールできるはずだろう。

製造業でスクラムを適用できるならば、小売スーパーや飲食店、理髪店やネイル店、旅館などの中小企業が多いサービス業の業務にも簡単にスクラムを適用できるはずだ。
特に労働集約的な業務には、スクラムチームで編成し直して、メンバーの生産性を高めるように持っていけるのではないか。
スクラムチームはプロダクトオーナー、スクラムマスター、チームメンバーの3つの役割だけから構成されていて、少人数なチームで構成されるので、それらのサービス業のメンバーにも適用できるのではないか。

この辺りも単純なアイデアに過ぎないけれど、たぶん既に他の人達がやっているに違いないと思う。
色々事例を探してみたいと思う。

| | コメント (0)

より以前の記事一覧