Agile

2020/11/23

組織は記憶能力を持つのか~トランザクティブ・メモリーという概念

世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」を読んでいて、組織は記憶能力を持っているのか、組織は学習する能力を持つのか、という問いがあった。
内容がとても面白かったのでメモ。

せきねまさひろぐ: 『世界の経営学者はいま何を考えているのか』

「世界の経営学者はいま何を考えているのか」で明かされた9つの意外な事実 | netgeek

【新連載・入山章栄】経営理論は“モヤモヤ”を言語化する武器。「思考の軸」をつくる教養を磨け | Business Insider Japan

「世界の経営学者はいま何を考えているのか」書評と要約:旧・本を聴く日々:So-netブログ

トランザクティブ・メモリーとは | 人事のプロを支援する | HRプロ

トランザクティブメモリーとは?組織の知を最大化する方法 | BizHint(ビズヒント)- クラウド活用と生産性向上の専門サイト

トランザクティブ・メモリー・システムとは何か(村瀬俊朗)|英治出版オンライン

組織のラーニングカーブは存在するのか?
組織は経験から学習するのか?

個人は経験から学習して、個人の能力を高めていく。
人は経験から記憶する。
組織も同じだが、その構造は異なる。

100人がばらばらに学ぶ場合と、100人が一つの組織で学習する場合、組織で得られる知の総量は違うのか?

結果は異なる。
組織は、トランザクティブメモリという、誰が何を知っているのか、という知識を蓄積することで、より多くの専門知識を持つことができる。
つまり、組織内の個人は機能別組織として、その専門性を発揮するが、ばらばらの専門性の知識は、組織内の権限と責任の一致によって、組織内の専門知識に自由にアクセスできる構造を持つ。

組織は、自然に形成されたトランザクティブメモリを持つが、それを新しい組織構造に変換して無理にゆがめると、組織内の軋轢を引き起こし、組織内の記憶力は著しく落ちていく。

このトランザクティブメモリの概念を、ソフトウェア開発に適用するとどのように解釈されるのか?

たとえば、専門性を持つ技術者が集まったチームが生産性を発揮しても、そのチームを一度解体してしまうと、組織の記憶力は低下し、組織の生産性も著しく落ちてしまう。

スクラムではチームを重要視する。
チームはブラックボックスとして扱い、プロジェクトマネージャのマイクロマネジメントは許さない。
チーム内ではメンバーの専門性は最大限発揮できるような環境が提供されている。
つまり、トランザクティブメモリが発揮できるような仕組みをスクラムは開発チームに提供している。
そういうトランザクティブメモリがスクラムチームに自然に埋め込まれているならば、困ったときに、専門性を持つ人に声をかけて支援してもらい、問題解決することが可能になる。

ソフトウェア開発では、長年保守してきたシステムの知見、技術、業務の知識を持つ技術者が非常に重要だ。
そういう属人生を排するような仕組みを組織的に作り出そうと四苦八苦してきたが、むしろ、そういう技術者が能力を最大限発揮できるような仕組みを作り出すほうが重要ではないだろうか?

トランザクティブメモリの豊かな組織では、組織が記憶力を高めて、組織の学習能力を高めてくれる。
ここで、組織の記憶力はあくまでも、専門性を持つ人の情報を共有する点に着目していること。
単に、Wikiで情報共有すればいい、というわけではないのだ。
誰が何を知っているのか、という暗黙知が知のインデックスカードのような役割を果たしている。

トランザクティブメモリのおかげで、知の探索、つまり、試行錯誤しながら新しい知見を蓄積しいていく試みが可能になる。
つまり、アジャイル開発を実践するには、組織にトランザクティブメモリという性質が必須要件なのかもしれない。

世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」には、ほかにも面白い話がいくつかあるので、その内容も別でメモしておく。

| | コメント (0)

2020/11/19

増刷記念「ここはウォーターフォール市、アジャイル町」の裏話の感想~日本人はフレームワークが苦手でいつも振り回されている


増刷記念「ここはウォーターフォール市、アジャイル町」-執筆者と編集者と書籍の表側と裏話と- - DevLOVE | DoorkeeperをZoomで聞いていた。
沢渡さんの発言がすごく面白くて、色々連想させられた。
ラフなメモ書き。

【1】日本人はフレームワークがすごく苦手。
ISO9001から、CMMI、DX、SDGsに至るまで、こういうバズワードに振り回されている。
スクラムも良いアジャイル開発のフレームワークだが、日本人はアジャイル開発は理解できるのに、アジャイル開発のフレームワークを使いこなせているとは到底言えない。

その理由は、フレームワークは問題事象を抽象化した枠組みなので、抽象的思考のまま具体的に考えようとして、本来の目的を忘れてしまうのではないだろうか。
本来は、ISO認証が目的ではなく、品質改善が目的のはずなのに、本来の問題意識を忘れてしまい、いつの間にか手段が目的に変わってしまう。

こういうバズワードが会社の提案書に出てきたら、日本では要注意。
書いた本人も、その提案書を受け入れる経営者もたぶん、フレームワークを使いこなせないので、すぐに目的や問題意識を忘れて、道具を磨くことばかりに注力してしまう。

akipiiさんはTwitterを使っています 「#devlove 日本人は、フレームワークと言う道具が使いこなせない弱点がある。ISO認証もSDGsも、フレームワークに使われるだけで、本来の問題解決にならない。フレームワークに呑まれるな!!」 / Twitter

akipiiさんはTwitterを使っています 「#devlove 日本人はフレームワークに使われてしまうのは、手段が目的化する弱点があるせいだほう。ISO認証、CMMU、スクラム、そしてDX、SDGsまで、全て、日本人は振り回されてる。」 / Twitter
「手段を目的化するのは日本人の病」という記事もあったな。

手段を目的化するのは日本人の病: プログラマの思索
スクラムも開発プロセスのフレームワーク。
フレームワークだからこそ、全てのルールを受け入れることで、こんな問題にはこういうルールや道具が使えるのか、という新しい気づきを毎回得ている。それが面白いのだ、という講演者の言葉に惹かれた。

akipiiさんはTwitterを使っています 「#devlove スクラムはやるたびに、すげーと思う。問題解決のたびにスクラムの道具が使える。スクラムのフレームワークを全部入れると、こういう問題で使うのか、と気づきがある」 / Twitter

フレームワークは抽象化した枠組みなので、あらゆる具体的な事象から抽出した本質を確実に捉えている。
一つのアイデアや理論をいろんな観点で徹底的に分析し、そこから、これが本質なのだ、という一つのメッセージを取り出す。
欧米人の自然科学の本、社会科学の本、歴史学の本を読んでいると、こういう分析が上手いなあ、と思う時がある。
膨大な具体例を述べながら、一つのメッセージを一貫して補強するように論理的に組み立てて説明するのが上手い。

論文作成の技法part1~論文の構造: プログラマの思索

【2】アジャイル、という言葉は現場で使わないでいい。
問題解決にアジャイルの技法を駆使して使って解決して、最後に、今までやったのがアジャイルというものなんだよ、といえばいい。
この言葉にはしびれた。
ちょうど、好きな女の子に手取り足取り尽くして支援して、信頼関係を築いて、最後に振り向いてもらって、最後に好きだったんだよ、という感じ。
違うか。

akipiiさんはTwitterを使っています 「#devlove ウォーターフォールの環境ではアジャイルと言う言葉を使わずに問題解決したい。Issue Drivenが基本であり、問題解決の道具が偶然アジャイルであってゴールを達成したとき、今やった事をアジャイルと言うんだよ、と言ってやりたい。よく分かるなあ」 / Twitter

akipiiさんはTwitterを使っています 「#devlove 問題解決で上手くいってテンションが上がってる時に、実はこれがアジャイルなんだよ、と切り出すと効果的。このテクニックは他にも使えそう」 / Twitter

akipiiさんはTwitterを使っています 「執筆では、沢渡さんはスーパープログラマなので、プロセスや方法論も関係ない。アジャイルは、そういう能力のある人を最大限発揮するプロセスと言うオチかな?  #devlove」 / Twitter

【3】問題解決に名前をつけよう。
そうすれば、名前のついた問題に対して、周囲の人達と同じ景色を見ることができる。
その言葉に共感できれば、問題解決のファンを増やしていける。
問題会計角ファンがどんどん増えれば、勇気づけられるし、問題解決できるリソースも選択肢も増えるメリットがある。

akipiiさんはTwitterを使っています 「#devlove 半径五メートル以内の問題課題に名前をつけよう。表現するとイメージできて解決に近づく。そして、問題解決のファンを増やすのが大事。同志になるし、動機付けになるので心強い。うん、コミュニティ誕生やコミュニティ運営も同じだ」 / Twitter

【4】執筆には、まず目次を書こう。
目次が書けるならば、その目次から、ストーリーが思い浮かぶはず。
こんな物語にしたいんだ、という思いが出てくる。
そして、決め台詞を入れたい。

この物語には、このフレーズを使いたい、このメッセージを伝えたい、みたいな。
このフレーズを使いたい、という時は、伝えたい内容にフォーカスしている。
このメッセージを伝えたい、と言う時は、そのメッセージに自分の気持が含まれている。

akipiiさんはTwitterを使っています 「執筆で大事なのは、目次を書く事。目次が書ければ、ストーリーに発展できる。自分の体験や知見をそこに埋め込める。 #devlove」 / Twitter

akipiiさんはTwitterを使っています 「目次は先に書くが、このフレーズは使いたい、このメッセージは伝えたい、と言う言葉は事前にメモして、目次に入れ込んでおく。このやり方は真似よう #devlove」 / Twitter

akipiiさんはTwitterを使っています 「#devlove システム運用で誰も読まなかったマニュアルを、ダイアローグ形式にしたら、すぐに広まった経験がある。そういう形式に変えるやり方は面白いな。FAQ方式みたいにするのか」 / Twitter

【5】チケット駆動のいい所は、一体感が出くること。
チケットをキャッチボールみたいにやり取りするうちに、相手はどんな反応をしてくるのか、待つようになってくる。

akipiiさんはTwitterを使っています 「#devlove チケットでやり取りすると一体感が出てくるよね、と。なるほど。」 / Twitter
一体感が出てくるとは、組織論の言葉では、バーナードの組織成立の3要件である「組織の共通目的」が誕生していることだ。
つまり、そこには、単なる人という物体の集まりではなく、心理的関係を持つ組織集団が暗黙的に生まれたわけだ。


<br

| | コメント (0)

2020/11/11

「製造業アジャイル、静岡での実践!」を聞いてRedmineはコミュニケーション管理ツールなのだと気づいた #devlove #静岡ギルド

今夜行われた「製造業アジャイル、静岡での実践!」を聞いてRedmineはコミュニケーション管理ツールなのだと気づいた。
ラフなメモ書き。

【参考】
静岡ギルド(準備中)勉強会「製造業アジャイル、静岡での実践!」 - DevLOVE | Doorkeeper

詳細は上記ページの通り。
1回目は、POもSMも開発チームもScrumの初心者だった。
やる気はあったが、やはり色んなトラブルが出て、POや開発チームのコミュニケーションも悪くなり、進捗遅延で増員されるたびに開発案件がどんどん膨らんでしまう。
最後に、SMの役割を果たせず、案件から抜けてしまう。

再起を期した2回目はいろんな工夫をした。
その話を聞くと、ポイントは2つあると思う。
それは、組織構造と組織文化の2つ。

組織構造の面では、POを2人体制にしたり、開発チームに進捗報告担当のトラッカーを立てたり、SMも時には開発に入ったり課題管理に直接関わったりしたこと。
Scrumの本来の姿ではないかもしれないが、各人の役割と責任に対し、権限と責任が一致できていないならば、補佐を立てて強化したり、あるいは自ら作業に加わったりする。
目的は、Scrumを運用することではなく、開発案件を成功させることなのだから。

組織文化の面では、TeamsでPOと開発者が頻繁にコミュニケーションする。
コメントに、いいねやハートのアイコンをつけることで、ちょっとしたニュアンスを伝えられた。
TeamsのPlannerでPBIを書いて5つのステータス(ToDo、Ready、Doing、Reviewing、Done)でかんばん風に管理したり、TeamsのPlannerで書き足りない内容はRedmineのチケットに詳しい仕様や課題を管理し、Sprint計画はRedmine上でロードマップ画面を使った。
スプリントレビューのデモでは、Teamsのカメラ機能を使って、実際にスマホアプリの動作をステークホルダーに見せて、その場でフィードバックをもらえた。

最初は、TeamsのPlannerでストーリーカードをかんばん風に管理して、詳細化したタスクカードをRedmineのチケット管理で実現したと思っていたが、TeamsのPlannerにはたくさんの情報を書き込みできないなどの不便があったので、Plannerはステータス管理に注力し、Redmineチケットのリンクを書いておいて、課題や状況の管理はRedmineで行っていたらしい。
後で、Redmineのチケットパネルプラグインを入れたら、親チケットはチケットパネル機能でかんばんで管理し、詳細なタスク管理は子チケットで管理するといいのでは、と提案してみた。

そんな話を聞くと、RedmineやTeamsはコミュニケーション管理ツールなのだと感じた。
ガチガチの進捗管理をツールで実現するのはすぐに可能だが、実際はそう簡単には回らない。
一方で、チーム内のコミュニケーションを活性化するには、POやメンバー同士の信頼関係が前提条件だ。
そのために、デイリースクラムではSMはメンバーに進捗遅延を責めることはしないし、POは開発メンバーに見積もりが多すぎるのではとあえて口を挟む権限を付与したりする。
つまり、お互いに本音で言い合える関係をツールで実現することが重要だと感じた。

もちろん、ツールさえあれば開発案件が成功するわけではない。
自分の経験を振り返ってみると、結局は、ソフトウェア開発案件は開発者とリーダーの能力にすごく依存する。
開発者とリーダーの能力を最大限に発揮するには、プロジェクトの体制図という組織構造で権限と責任を明確にし、権限と責任を一致させて、各メンバーの意思決定を迅速させることが重要だし、メンバー全員が最終ゴールを認識していて、その実現のために目標達成意欲を高揚させる雰囲気作りが大事だ。
そして、コミュニケーションを円滑に進める基盤として、RedmineやTeamsのようなツールがあるわけだ。

組織構造を整える部分は、プロジェクトの体制図を決める時に決まるから、おそらくプロジェクトの立ち上げ時に既に決まっている。
組織文化を整備する部分も、RedmineやTeamsを事前に整備しておく必要があるから、プロジェクトの立ち上げ時に既に決まっている。
そんなことを考えていると、Scrum云々というよりも、プロジェクトマネジメントという基盤の考え方が使えるのかな、と思ったりもした。


| | コメント (0)

2020/10/31

アジャイル動画「私もアジャイルに飛びこんだの! -- 『品質重視のアジャイル開発』の誉田さんインタビュー」がいいね

アジャイル動画「私もアジャイルに飛びこんだの! -- 『品質重視のアジャイル開発』の誉田さんインタビュー」がいいと思ったのでリンクしておく。

私もアジャイルに飛びこんだの! -- 『品質重視のアジャイル開発』の誉田さんインタビュー ? アジャイル動画

「私もアジャイルに飛びこんだの!」というフレーズがとても可愛いのだが、誉田さんはNECでCMMIレベル5の導入運用に携わった人と聞いているので、そのギャップの違いに惹かれた。

『品質重視のアジャイル開発』を書いた動機は、色んな人から、アジャイル開発では品質保証はどうやっているのか?と聞かれて、その解答を自分から答えようとしたこと、と聞いて、すごく納得した。

実際、『品質重視のアジャイル開発』では、P.32で「顧客が納得するアジャイル開発の品質保証方法は確立されていない。本書は、その課題の解決に挑戦している」という言葉がある。
この言葉にすごくしびれた。

上記の動画では、誉田さんは、私は2010年頃からアジャイル開発に携わったので、平鍋さん他皆さんとはそこまでアジャイル開発の経験を持っていないと謙遜されていたが、『品質重視のアジャイル開発』の内容はとても充実していると思う。

上記の動画の最後でも紹介されているが、アジャイル開発はミニWF型開発ではない。
アジャイル開発はミニWF型開発とみなしてしまうと、必ず大火傷を負う。
それはなぜか?

アジャイル開発の特徴はとにかく期間が短いことだ、と著者は言う。
WF型開発では半年かけて、各工程にゲートを設けて品質チェックし、品質を担保していく。
そのやり方をアジャイル開発にそのまま適用しても、短期間の制約があるから、必ず現場が混乱する。

一方で、WF型開発の品質保証で得られた知見である「プロセス品質」「プロダクト品質」の考え方はアジャイル開発にも通用する。
アジャイル開発でもその考え方を適用する。
プロセス品質では、技術プラクティスを習慣にし、開発チームの構成に配慮すること。
プロダクト品質では、Done判定を出荷判定基準とみなし、バックログの順番に頻繁に品質保証していくこと。

個人的には、「Done判定を出荷判定基準」とみなす観点は有効な知見だと思う。
ソフトウェア品質保証は、WF型開発でもアジャイル開発でも、同じような概念や観点は共通で存在するし、その背景には、品質はどんな開発プロセスであれ必要なのだ、という思想があるのだと思う。

また、『品質重視のアジャイル開発』では、アジャイル開発にもWF型開発のメトリクス分析を適用しようとして、色々苦労されている内容がある。
結論は、定量データを用いてアジャイル開発のプロセスを分析するのは難しい、ということだ。
理由は、アジャイル開発では、短期でリリースするので、スプリント単位の開発規模は小さいために、メトリクスのばらつきが大きくなるからだ。
すなわち、開発規模やチームの生産性のばらつきが大きいために、Velocityで複数チームの生産性を比較するのは有意味なりにくいし、各チームの開発状況を分析するのが難しいのだ。

考えてみれば、規模が小さいのでばらつきが大きくなる、というのは当たり前なのだが、結局、短期間リリースと定量データ分析はトレードオフなのかな、と感じる。

また、『品質重視のアジャイル開発』本は、品質保証の観点で噛み砕いて解説してくれているので、WF型開発バリバリのプロジェクトリーダーがアジャイル開発に取り組む時に役立つと思う。

| | コメント (0)

2020/09/27

リーン製品開発はアジャイル開発に何となく似ている

「開発戦略は「意思決定」を遅らせろ! ─トヨタが発想し、HPで導入、ハーレーダビッドソンを伸ばした画期的メソッド「リーン製品開発」」を読んだ。
製造業の製品開発がメインなのだが、アジャイル開発に似ているなあ、でも違いは何だろう、と思いながら読んでみた。
ラフなメモ。

リーン製品開発の4つの礎石。
セットベース開発、チーフエンジニア制度、流れとリズムの確立、責任ある専門家チーム。

LAMDAサイクルとは、look, ask, model, discuss, act。
PDCAのうち、PとCはLAMDAサイクルで回す。
つまり、PDCAサイクルのうち、PlanとCheckに力点を置く。

セットベース開発は、多数の代替案を平行で評価しながら、徐々に絞り込んでいく。
代替案の収束の時系列図は、不確実性の時系列図に似ている。
たぶん、製品開発でも当初はどの案が自分たちが求めるものなのか分からない状態で、そこから複数の代替案を実験し、試行錯誤を繰り返していくうちに、あるべき姿が明確になってくるイメージなのだろう。
つまり、製品開発も当初はリスクが非常に高いが、経験値が増えるに従って、リスクを受容できるようになり、不確実性はコントロールできる範囲に落ち着く。

チーフエンジニア制度とは、トヨタを真似たもの。
スクラムのプロダクトオーナーに似ているし、スクラムマスターの役割も兼ねているように思える。

チーフエンジニアは、顧客を代表し顧客価値を最大化させることに注力する。
チーフエンジニアは、部品メーカーから工場、生産システムまでの生産バリューストリームを設計する。
チーフエンジニアは、機能別部門の開発者の対立を調停し、トレードオフを主導する。
チーフエンジニアは、インテグレーション・イベントで代替案を披露し、それに向かって開発のプロジェクト管理を行う。
チーフエンジニアは、ビジョンを提供し、開発資源を確保する。
チーフエンジニアは、製品ビジョンを実現するための技術の方向性を示す、技術的リーダーシップを発揮する。

インテグレーション・イベントとは、学習サイクルを管理するために一定期間で行う。
多数の視点から代替案を検討し絞り込む。
各チームが獲得した知識を共有し、将来のために記録する。
開発の計画と実績を対比し、開発ペースを管理し、開発にリズムと流れを導入する。
インテグレーション・イベントは、スクラムのスプリントに似ている。
ただし、インテグレーション・イベントでは、開発段階で得られた知識のレビューに力点が置かれる。

セットベース開発では、開発当初に詳細な仕様を厳密に決めるのではなく、複数の代替案を元に、開発しながら技術的知識が増えるにつれて、徐々に仕様をより細かく、具体的にする。

一方、ポイントベース開発のように、実際に製品の試作品を作り、それから試験して通過すればよいが、試験が通らなければ、出直し設計となり、量産開発に至るまでに膨大な開発コストがかかる。

開発上の技術的知識の多くは、トレードオフ曲線で表現される。
たとえば、ある部品の強度を強くしたら、大きくならざるを得ないとか。
つまり、2つの製品特性に対し、正や負の相関関係がある事実を実験で新たに見出す。

重要なのは、低コストで知識を獲得する工夫を行うことだ。
通常、必要な知識とは、設計パラメータ間の相関関係である事が多い。

製品開発の最大の無駄は、せっかく獲得した知識を捨てること。
蓄積した知識を次の製品開発に利用せず、同じ知識を得るために貴重な開発資源を浪費すること。

セットベース開発では、代替案が棄却されても、そこで得られた知識はチームに残り、A3文書に記録されて、後で再利用される。

あらゆる開発上の知識はA3報告書に1枚に記録する。
ナレッジはA3報告書で蓄積される。

この話で面白いと思ったのは、メーカーの製品開発でも、インテグレーション・イベント(スプリント)単位に設計し、そこで得られた知識はトレードオフ曲線で表現されているので、それらをA3報告書に記録してナレッジを共有する一連の流れがあることだ。
スクラムでも経験主義が強調されるが、リーン製品開発では、製品特性のトレードオフ曲線というナレッジがA3報告書1枚に記録され、失敗した経験から得られた知識も蓄積されていく。
それら技術的知識はチームメンバーに共有されて、インテグレーション・イベントを経るごとに、新製品のあるべき仕様が分かってきて、最終的に固まる。
そうすれば、試験も通過しやすいし、量産体制に入っても、蓄積された技術的知識を活用すれば生産プロセスを改善しやすい。

リーン製品開発を取り入れたハーレーダビッドソンは、リーン製品開発ではなく、知識ベース開発と呼んでいるらしいが、そちらの方が理解しやすい気がする。

リーン製品開発の効果は、競争力のある新製品を従来よりも短いリードタイムで開発できるだけではない。
実は、技術者の士気が大きく向上したらしい。

リーン製品開発に取り組んだ技術者の話が「開発戦略は「意思決定」を遅らせろ! ─トヨタが発想し、HPで導入、ハーレーダビッドソンを伸ばした画期的メソッド「リーン製品開発」」にあるが、その理由はこうだ。
従来の開発手法では、トップダウン式で製品企画が決まり、技術的に意味のないペーパーワークや会議に時間が取られていた。
一方、リーン製品開発では、試行錯誤しながら、問題を発見し、解決方法に関する仮設を立てて、それを実験により検証する、という技術者本来の仕事を中心に進められる。
実際、複数の代替案を作り、大まかな仕様を元に、問題を発見して解決して得られた技術的知識はトレードオフ曲線として表現され、それらはA3報告書に残る。
つまり、仮説検証による技術的問題解決を行っているわけであり、技術者本来の仕事なわけだから、モラールが向上するのは当たり前だ。

そして、できればそこで得られた技術的知識は、学術論文で投稿できたり、特許として認定できれば、技術者のモチベーションももっと上がるだろう。

クネビンフレームワークの複雑系の問題領域では、そもそも問題が何なのか分からない。
専門家が何度も調査して検証して、初めて因果関係が分かる。
その知識は経験として得られるものであり、トップダウンで分かるわけではない。
リーン製品開発も、クネビンフレームワークの複雑系ドメインの問題解決の手法の一つと捉えることはできる。

「開発戦略は「意思決定」を遅らせろ! ─トヨタが発想し、HPで導入、ハーレーダビッドソンを伸ばした画期的メソッド「リーン製品開発」」のあとがきの一節がとても気になった。
筆者は、TOCという生産改善手法を日本に初めて紹介したり、EMSを紹介したり(たとえば、台湾のフォックスコンなど)、トヨタ生産システムも翻訳したらしい。

いずれも、日本でそのアイデアが生まれて、アメリカ人が徹底的にその手法を分析評価して、フレームワークとして体系立てて、日本に逆輸入されている。
アジャイル開発も結局同じだ。

なぜ、日本人は、自らのアイデアを抽象化したフレームワークにまとめて、誰もが普遍的に扱えるような形にしなかったのだろうか?
なぜ、日本人は、自らのアイデアをアメリカ人にキレイな体系として理論化されたものを、ありがたがって受け入れざるを得なかったのだろうか?

| | コメント (0)

2020/09/24

スクラムは境界を生み出す

@sakaba37さんから言われてハッと気づいたこと。
スクラムはあえて境界を作り出している、と。

「More Effective Agile」で良く出る言葉は、「スクラムチームはブラックボックスとして扱える」ことだ。
チームをブラックボックスとして扱える利点は、2つある。
1つは、外部のプロジェクトマネージャはチームのマイクロマネジメントが不要で、インプットとアウトプットの評価だけでチームをコントロールできる点だ。
これはスクラムチームだからこそ実現できる。

もう一つは、疎結合なスクラムチームを組合せることで、大規模なソフトウェア開発にもスクラムを適用しやすくなる点だ。
スクラムチームは、コンウェイの法則「アーキテクチャは組織構造に従う」の呪縛から逃れられる。

実際、スクラムチームはチーム単体でアウトプットの増分を定期的にデリバリーできる能力を持ち、他のチームに依存する必要性はない。
よって、スクラムチームを一つのコンポーネントに対応付けることで、大規模なソフトウェアを組み立てることが出きる。
昨今、クラウド上の開発が主流になることで、マイクロサービスのアーキテクチャが流行しているが、その理由も、スクラムチームがマイクロサービスと相性がいいためだろう。

よくある駄目な例は、大規模なソフトウェアを開発するチーム構成を、データベースチーム、インフラチーム、アプリチーム、フロントチームのような機能別組織で分割してしまうことだ。
すると、1つの機能を作るために、数多くのチームに依存せざるを得ず、その分、複雑な組織構造を盛り込んだソフトウェアを作り込んでしまう。

これはオブジェクト指向設計と同じ発想で、疎結合なコンポーネントを組合せることで、各コンポーネントは互いにメッセージパッシングし合い、変な副作用を起こさずに大規模なソフトウェアを組み立てることができる。
同様に、疎結合なスクラムチームは、互いにコミュニケーションを取り合うが、変な副作用を起こさずに、大規模なソフトウェアを開発できる基盤をもたらす。

つまり、スクラムチームは専門性を発揮できるチームであり、チーム単体で諸問題を解決できる能力も持つので、そういうチーム設計が可能になるわけだ。
たぶん、Lessはそういう発想で組み立てられているのでは、と想像している。
だから、Lessは暗黙知を重んじる日本人好みなのだろう、と。


| | コメント (0)

2020/09/19

More Effective Agileは良い本だ

「More Effective Agile ソフトウェアリーダーになるための28の道標」を一気に読んだ。
アジャイル開発の古い情報をアップデートできて良かった。
10年以上前のXPとかにハマっていた人にはお勧めと思う。
ラフなメモ書き。

【参考】
『More Effective Agile』を読んでみた感想 - 虎の穴開発室ブログ

More Effective Agile ソフトウェアリーダーになるための28の道標 読了 - nemorineのブログ

クネビンフレームワークについて講演してきました | サーバントワークス株式会社

半日かけて「More Effective Agile」をじっくり読んだ。
線を引いた箇所はかなり多数。
読むたびにインスピレーションが働いた。

この本のキーワードは「クネビンフレームワーク」「複雑系」「スクラム」「ブラックボックスなスクラムチーム」だ。

クネビンフレームワークでは、ソフトウェア開発は複雑系のドメインなので、従来のシーケンシャル開発では問題解決できない。
なぜなら、煩雑系のドメインの問題解決手法であり、複雑系では対応できない。
クネビンフレームワークでは、煩雑系では「把握→分析→対処」、複雑系は「調査→把握→対処」で問題解決の手法が異なる。
だから、アジャイル開発が必要とされる。
クネビンフレームワークは1990年代には概念があったのに、誰もそれを言ってなかったのが興味深い。

「More Effective Agile」では一貫して、クネビンフレームワークの話が出てくる。
クネビンフレームワークの概念のおかげで、ソフトウェア開発の本質は複雑性であることを常に認識させられるメリットがある。
人月の法則本の「ソフトウェア開発の本質は複雑性だ」を思い出す。

「More Effective Agile」では、アジャイル開発とはスクラムと同義だ。
XPなど他のアジャイル開発も紹介されているが、スクラムの「検査と適応」がOODAループと相性が良いことが強調されている。
僕は、調査→把握→対処という問題解決の手法を何度も高速に回すことと同じであり、その経験によって学習して判断能力を高めていくと理解している。

アジャイル開発では雨後の筍のように数多くのプラクティスが提唱されるが、最終的には、スクラムは複雑系の問題解決にいているから推奨されている。
一方、XPは技術プラクティスが残った。
カンバンは煩雑系の作業に向いていて、複雑系の仕事はスクラムの方が向いている、と言う。

この考え方を取り入れると、ソフトウェア開発だけでなく、企画提案系のプロジェクトの仕事は全てスクラムで実施した方が良いだろうと思う。
つまり、一般のビジネスマンもチームで仕事するのが普通だから、スラクムをマスターした方がいいのではないか。

「More Effective Agile」で良く出る言葉は、「スクラムチームはブラックボックスとして扱える」ことだ。
実際、スクラムチームというアジャイルチームは、自律的なチームであり、スプリント単位にアウトプットを必ず出してくれる。
つまり、外部のプロジェクトマネージャは、スクラムチームのマイクロマネジメントは必要ない。
スクラムチームのインプットとアウトプットさえ管理すればいい。
チームをブラックボックスとして扱うことは、チームを大人として扱うことと同じであり、技術の詳細や進捗を逐一管理すべきでないことを示唆している。
よって、プロジェクトマネージャは、スクラムチームにサーバント・リーダーシップで振る舞うようになる。

「スクラムチームはブラックボックスとして扱える」ことは、コンウェイの法則を良い方向に自然に従うことになる。
つまり、オブジェクト指向プログラミングのように、スクラムチームはコンポーネントと同一視すれば、疎結合なスクラムチームを構成すれば大規模なチームを構成して、大規模なソフトウェアを効率良く作れるようになるはずだ。
スクラムチームはコンポーネントのように疎結合であるならば、メッセージパッシングがスムーズであり、無駄なコミュニケーションがないはず。
でも、スクラムチームをオブジェクト指向設計のコンポーネントと同一視できても、チームである限り状態は持つし、副作用を起こすことで、チームは変化するから、不変なコンポーネントとは違うはず。
この比喩はどこまで使えるのか?
この辺りはまだ分かってない。

「More Effective Agile」では、アジャイル開発をいかに大規模ソフトウェア開発に適用するか、というテーマを後半で詳しく説明してくれている。
意外だったのは、大規模アジャイル開発のフレームワークは、LeSSよりもSAFeの方を推奨していたことだ。
僕の身近のスクラム関係者は、LeSSを高く評価し、SAFeを低く評価していたので、どちらが正しいのか、まだ分かってない。

@sakaba37さんのアドバイスでは、プロセス志向がSAFe。
SAFeでは、アーキテクチャ管理、プロセス管理のレイヤが別にあり、基本テンプレートもある。
RUPに似ている。
一方、情報共有がLess。スクラムチームをベースに細胞のように階層化していくイメージ。
Lessの方が状況共有や暗黙知を重視するから日本人向きで、日本人好みだろうね、と。
すぐに作るために暗黙知を重視しているわけであり、暗黙知はチーム内で認識できていればいい、と。

つまり、スクラムチームがブラックボックスならば、チーム内で問題解決できる専門能力を持つだけでなく、暗黙知もチーム内で共有できているから、スクラムチームは強いわけだ。

アジャイル開発がこれだけソフトウェア開発に浸透して使えるならば、ビジネスの観点で計測したくなる。
実際、スクラムは「検査と適応」のサイクルをこなすことで、スクラムチームは経験を深めて、予測可能な振る舞いを行うようになる。
つまり、スクラムチームは計測可能な状態になる。
たとえば、ベロシティのように。
すると、コストやスケジュールが予測可能になってくるので、ビジネスで計画を立てたり、意思決定するのにその予測を使えるメリットが出てくる。

「More Effective Agile」では、最後に規制産業にアジャイル開発をいかに適用するか、というテーマがある。
たとえば、製薬業や医療業界、航空機メーカー、金融機関、政府など、法律による規制が前提にある産業だ。
では、アジャイルやスクラムは規制産業でどうやって支援するのか?
アジャイルの境界を引いて、文書作りやソフトウェア要求やソフトウェアアーキテクチャ設計はシーケンシャル、実装スプリントはアジャイルと分けることを提案している。
よく見れば、これはウォーター・スクラム・フォールじゃないの、と思ってしまうが、たぶんこれが現実的な解決法なのだろう。

最後に、スクラムの導入と社内展開は、キャズム理論に従うという指摘は参考になる。
実際、社内のイノベーターはすぐに飛びついてくれるし、アーリーアダプターは色んな意見を出してくれる。
その後のアーリーマジョリティへの展開が一番大変なのだ。

「More Effective Agile」はまだまだ読み直してみたい。

| | コメント (0)

2020/09/02

問題解決アプローチを見極める『クネビンフレームワーク』のメモ

問題解決アプローチを見極める『クネビンフレームワーク』を知ったのでメモ。
結論のないメモ。

【参考1】
akipiiさんはTwitterを使っています 「クネビンフレームワークの説明が参考になった。問題のドメインが時代で変化しているからソフトウェア開発プロセスも変化する。非開発者のためのアジャイル開発入門 by @haradakiro #agile #complex https://t.co/2iCYVDeddY」 / Twitter

More Effective Agile ? “ソフトウェアリーダー”になるための28の道標|かず|note

複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework) ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

(引用開始)
カネヴィンフレームワークは1999年にIBM Global Servicesのデイブ・スノーデン(Dave Snowden)らが提唱したもので、状況・問題を大きく4つのドメインに分類するフレームワークです。(上画像)

1.Simple(シンプル):単純
⇒問題の因果関係・構造が明確

2.Complicated(コンプリケーティッド):煩雑
⇒少し分析すれば、因果関係・構造が明確

3.Complex(コンプレックス);複雑
⇒因果関係が複雑、調査・探索が必要

4.Chaotic(カオス):混乱
⇒因果関係が不明確で、状況や問題を理解することも難しい

その他.Disorder(ディスオーダー):無秩序
⇒直面する問題に適切な解決策がない

さらに、1のSimpleと、2のComplicatedを予測可能な問題、3のComplexと、Chaoticを予測不可能な問題と分類することもできます。
(引用終了)

製造業における製品製造の大量生産方式のビジネスと、エンジニアやコンサルタントなどの知的労働者がプロジェクトで仕事するビジネスは、本質的に何かが違うといつも思っていた。
その理由の一つは、問題解決アプローチが全く違う、という指摘を、クネビンフレームワークは教えてくれる。

クネビンについて講演してきました | サーバントワークス株式会社

(引用開始)
(クネビンフレームワークが必要とされる)背景としては、「正解がない」多様化した問題と現実解に対しての理解を深めることが第一義です。第二儀としては、アジャイルの必然性の腹落ち感があります。
(引用終了)

アジャイル開発が昨今必要とされる背景には、従来の問題解決の手法が通用しなくなってきていて、新しいフレームワークや考え方による問題解決手法が必要とされているのだろう。
「More Effective Agile ~“ソフトウェアリーダー"になるための28の道標」では、アジャイル開発による問題解決の観点はクネビンフレームワークの「複雑(Complex)」に当たるのではないか、という内容があるらしいので、今度読んでみたい。

【参考2】
複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework) ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

クネビンフレームワーク Cynefin Framework :臨機応変の意思決定手法 ? I & COMPANY / アイ&カンパニー

カネビン・フレームワークで問題解決策を見極める

クネビンフレームワークを使ったテクニカルサポートチームの行動指針の立案 | Developers.IO

問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩

(引用開始)
これをエンジニアのロールに置き換える広木さんのツイートはすごいなと思ったので参考まで
(引用終了)

広木 大地/ エンジニアリング組織論への招待さんはTwitterを使っています 「CTO/VPoE/TechLead(スペシャリスト)の仕事って一体どう言う役割分担なの?みたいなことを聞かれる。 これはクネビンフレームワークで捉えるとわかりやすい CTO は Chaoticな問題 -> Complex VPoE/EMは Complexな問題 -> Complicated TechLeadは Complicatedな問題 -> Simple 不確実性が減っていく https://t.co/un1FX3QQ53」 / Twitter

akipiiさんはTwitterを使っています 「クネビンフレームワークでカオスで複雑・複合的な問題を分類する。CTO/VPoE/TechLeadというエンジニアのロールはクネビンフレームワークで整理すると分かりやすいという指摘。 問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩 https://t.co/exz3rCJnfw」 / Twitter


| | コメント (0)

2020/09/01

OODAループはScrumにどんな考え方を注入し、影響させたのか

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術」では、OODAループが紹介されていた。
ラフなメモ書き。
考えがまとまっていない。

【参考】
アジャイルの源泉、OODAループとは何か? - Qiita

米空軍パイロット撃墜王の研究 「OODA ループ」 は、ビジネスにも示唆があり興味深い|多田 翼 - #ビジネスセンスを磨くノート|note

OODAループの歴史:世界の軍事戦略を全面転換 ? I & COMPANY / アイ&カンパニー

OODA について講演してきました | サーバントワークス株式会社

【1】OODAループの本質は何だろうか?
OODAループはScrumにどんな考え方を注入し、影響させたのか?

OODAループは、従来のPDCAサイクルと何が本質的に異なるのか?

【2】「スクラム 仕事が4倍速くなる“世界標準”のチーム戦術」では、Scrumを生んだサザーランドがベトナム戦争のパイロット経歴を持ち、こういう軍事経験を元にScrumを編み出した、という歴史の方が興味深かった。
生死の境にいる現場で、生き抜くために、どんな考え方や意思決定が必要なのか?
いくら軍事戦略や戦術が優れていても、戦場は刻一刻と変化して、今までの経験を多用できない。

米空軍パイロット撃墜王の研究 「OODA ループ」 は、ビジネスにも示唆があり興味深い|多田 翼 - #ビジネスセンスを磨くノート|note

(引用開始)
空軍の空中戦では、いかなる状況でも必ず敵機を撃ち落とす「撃墜王」と呼ばれるようなパイロットが現れます。
アメリカ空軍の研究目的は、空中戦での撃墜王は他の一般的なパイロット比べて何が違うのかを知ることでした。
研究結果から、パイロットが敵機を見つけてから攻撃、または回避行動をするプロセスで、優秀なパイロットとそうではないパイロットを比較すると、3つのことがわかりました。

研究結果
・敵機の観察段階 (Observe) で統計的に有意な差はない
・状況判断 (Orient) と意思決定 (Decide) の速さに有意な差がある
・行動 (Action) では有意差はない
つまり、状況判断と意思決定で、パイロットの優秀さが決まるという研究結果です。
(引用終了)

敵の意思決定より早い意思決定を行い、そこから行動することで、相手の意思決定を鈍らせる。
つまり、動く的に対し、優れた観察眼で、状況判断と意思決定を素早く行い、行動に移す。

OODA について講演してきました | サーバントワークス株式会社

(引用開始)
プロダクト開発では、正解がわかっていない状況下で推進することが多く、アジャイルに代表される実証により、経験的に推進していくことが多くなってきています。
そこでは、反復的かつ漸進的なアプローチとなるのでOODAループがそれに似ているとも言えます。
スティーブ・マコネルは著書の中で、スクラムの「検査と適応」はOODAループととても関連があると述べています。
(引用終了)

【3】PDCAサイクルとScrumの違いは、計画駆動なのか、観察駆動なのか、という違いもあるだろう。
PDCAサイクルでは、計画にすごく時間をかけて、計画と実績の予実管理によって、リスクを測定し、判断を下す。

一方、スクラムは「経験主義」と言われる。
つまり、スクラムは実践で得られた経験を元に、あるべき方向を見極めて、意思決定を下し、そのフィードバックを経ながら軌道修正していく。
スクラムでは、最初からベストプラクティスがあるわけではない。
観察して経験していきながら、より良い対処を探していく。

スクラムガイドをきちんと読もう - Qiita

(引用開始)
スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。
スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。
経験的プロセス制御の実現は、透明性・検査・適応の 3 本柱に支えられている。

透明性
経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。
(中略)
検査
スクラムのユーザーは、スクラムの作成物やスプリントゴールの進捗を頻繁に検査し、好ましくない変化を検知する。ただし、頻繁にやりすぎて作業の妨げになってはいけない。スキルの高い検査担当者が念入りに行えば、検査は最大の効果をもたらす。

適応
プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査担当者が判断した場合は、プロセスやその構成要素を調整する必要がある。調整はできるだけ早く行い、これ以上の逸脱を防がなければいけない。
(引用終了)

| | コメント (0)

2020/06/14

SaaSのビジネスモデルがアジャイル開発を促進したという仮説

「ソフトウェア・ファースト」を読んで、改めて、アジャイル開発はSaaSの開発プロセスを発展させたものとみなすのだと考えた。
ラフなメモ書き。

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

【1】「ソフトウェア・ファースト」を読むと、製造業などの一般産業は、SaaSのようにどんどんサービス化すべきだ、という主張が背景にあるのが分かる。

では、SaaSというビジネスモデルの特徴や本質は何だろうか?

この問いに自分なりに考えてみたら、複数の特徴があるように思う。

【2】SaaSはScrumと相性が良い。
たとえば、パッケージ製品ビジネスや大量生産ビジネスでは、たくさん作って販売してそれで終わり。
一括請負契約で作って納品したら終わり。
顧客とメーカーは、クライアント-ベンダー-アンチパターンにはまりやすい。

「クライアント-ベンダーアンチパターン」という根本問題: プログラマの思索

一方、SaaSでは、常にサービスや機能を頻繁にVerUpしていく。
その頻度も1ヶ月に1回ではなく、1日に数十回もざらだ。
SaaSのインターフェイスは、ユーザがスマホやPCで触っているので、すぐにその機能を試してもらえるし、彼らの要望を即座に反映するほど、顧客満足も高まる。
そういうニーズがあるので、頻繁なリリースを実施する動機づけになる。

その場合、社内の開発体制はScrumに似せると開発しやすくなる。
マーケティング担当者や経営者がプロダクトオーナーの役割を担えば、社内に開発チームとスクラムマスターを作れば、即座にScrumが出来上がる。
SaaSの場合、プロダクトオーナーに相当する人が社内に存在し、その能力を持ち合わせている時も多いのがメリットだろう。
その後は、会社の規模やビジネスの規模に合わせて、Scrumをスケールすればいい。

【3】SaaSはDevOpsと相性が良い。
リリースしたら、その後も運用し続けるので、開発と運用保守は一体化すべき流れになる。

一方、普通のSIであれば、インフラチームと開発チームは分離されていて、機能別組織になりやすい。
機能別組織の弱点は、チームや組織ごとに体制の壁ができてしまい、意思疎通が困難になることだ。
コンウェイの法則「アーキテクチャは組織に従う」によって、システムのアーキテクチャは縦割りの複雑な組織構造を反映した形になってしまい、システムはどんどん複雑化してしまう。

もちろんSaaSも、ビジネスが発展すれば肥大化するだろう。
しかし、開発と運用保守は一体化した方がいいというビジネス要求や現場からの要求が出てきやすいので、DevOpsを推進する動機づけになる。

もちろん、技術的にも、SaaSはクラウドと相性が良い。
だから、クラウドエンジニアはインフラエンジニアだけでなく、開発者でもありうるので、事実上、インフラチームと開発チームは一体化しやすい。

また、ここからマイクロサービス・アーキテクチャも実装しやすい。
AWS上でSaaSを運用すれば、LambdaやAurora、AWSの各種サービスを利用することになるだろう。
単に性能改善やスケールメリットが活かせるだけでなく、システム基盤をマイクロサービスとして組み立て直すことにより、SaaSは汎用的なAPI基盤になっていくだろう。
そうすれば、外部サービスと連携できるので、より多種多様な機能を顧客に提供しやすくなるメリットも出てくる。

【4】SaaSはB2Cのプラットフォームビジネスと言える。

アメリカのGoogle、Amazon、Apple、Facebookがそうだし、中国のBATも同様だ。
多数の顧客に対し、プラットフォームを提供することで利便性がどんどん増していく。
そのビジネスの本質は、製造業が持つ規模の経済ではなく、ソフトウェア特有のネットワークの経済という理論が背景にあるはず。
たくさんのユーザが使ってくれるほど、SaaSは重要性を増して、売上を指数関数的増大させていく。
「プラットフォーム革命――経済を支配するビジネスモデルはどう機能し、どう作られるのか」を読むと、プラットフォームのビジネスモデルは独占ビジネスなので、その売上は、そのサービスの市場規模と同等になるまで高められる。
つまり、市場規模と同等だから、小さい国家のGDPよりもはるかに大きな利益を得ることも可能。

SaaSはB2Cのビジネスなので、顧客のフィードバックをすぐに取り込みやすい。
ランダム実験やABテストも実現しやすいので、サービスやビジネスモデルを仮説検証しやすい。
つまり、SaaSでは、念入りに考え抜いた計画を作って数年かけてリリースするよりも、仮設を立てたら、複数のサービスを同時リリースして、ランダム比較化実験でその効果を測定した方が速い。

興味深いのは、米国や中国では、SaaSのトッププレーヤーはB2Cなのに、日本の楽天やモノタロウなどはB2B2Cというスタイルで異なる点だ。
もちろん、LINEのように、日本国民の殆どとつながっていて、その連絡先とつぶやきのようなログデータを既に持っている会社はB2Cだ。
しかし、日本で目立つSaaSプレーヤーはB2Bのクッションを通過した後でB2Cを提供するビジネスモデルが多いように思える。
その理由は分からないので、いつか知りたい。

プラットフォーム革命の感想~プラットフォーム企業は新たな独占企業である: プログラマの思索

規模の経済と経験曲線効果のメモ: プログラマの思索

【5】SaaSでは、大量のログデータがビジネスの副産物として採取される。
データはいくらでもある。
そこから、機械学習やディープニューラルネットワークに大量データを食わせることで、優れたAIエンジンを生み出すことも可能だ。
B2Cのプラットフォームビジネスでは、ユーザの個人情報は特定できるし、その購買行動はプラットフォーム上で全て追跡できる。
よって、ペルソナを仮想的に作って、より購買を促すようなプロモーションを打ち出して、潜在ニーズを掘り起こせる。

「告発 フェイスブックを揺るがした巨大スキャンダル」によれば、Facebookで、個人に68個のいいねがあれば、その人物に関する非常に具体的な情報をモデルから予測できる。
70個のいいねで、そのユーザの友人が知るよりも、その人の多くの個人情報がモデルから推測される。
150個のいいねで、親よりも、その人の多くの個人情報がモデルから推測される。
300個のいいねで、パートナーよりも、その人の多くの個人情報がモデルから推測される。
さらにその多くのいいねを見れば、ユーザが自分自身について知っていると思っている以上の個人情報がモデルから推測される。
つまり、個人の大量のログデータを収集できれば、その個人を丸裸にできる。
その個人情報を他人が知っている情報だけでなく、その個人自身が知らない潜在ニーズまで推測できるわけだ。
すなわち、ジョハリの窓という理論は、AIを使えばほぼ完全に実現できる可能性があると思う。

(それを悪用したのが、ケンブリッジ・アナリティカであり、彼らは、どの個人にどんなプロモーションを送ればどんな選挙行動に移してくれるか、を徹底的に研究して、トランプ効果や英国のEC離脱を生み出したわけだが。)

そんなことを考えると、SaaSは機械学習やニューラルネットワークと非常に相性がいい。
だから、テスラみたいに製造業もどんどんSaaSにシフトしているのだろうと思う。

| | コメント (0)

より以前の記事一覧