要件4：評価・報奨の仕組みの再設定
AIコンバージェンスの時代には、労働時間に応じて対価が支払われるような仕事の多くは、AIに取って代わられるようになるでしょう。そのため、人間はAIが得意とせず、人間にしかできないところで優位性を生み出していくことが求められるようになります。
人間ならではの優位性が発揮できる領域は、ホスピタリティー、リーダーシップ、クリエイティビティーに関わる仕事に絞られていくと考えられます（本連載「AIコンバージェンス時代の競争優位性--AI活用力は差別化要因となるのか」参照）。
⇧ 現状の「AI」の性能だと、泥臭い部分も人間側が負担せざるを得ない状況なのよね...
「ソフトウェア開発」が特殊なのかもしれませんが...
そして、
クラスター型組織がコンバージェンスを加速する
さらに、イノベーションの具現化のための試行・観察・実装の経過や成果は逐次AIによって分析され、適宜アドバイスが受けられることに加えて、成功・失敗を問わず成果や所見が組織のナレッジとして蓄積されます。
このような情報の循環をいかに仕組みとして組織に埋め込むことができるかが、クラスター型組織の成否を分けることとなるでしょう。
⇧ 人間が活用できる形での「ナレッジ」が蓄積されていない気はしますな...
理想に「AI」の性能が追い付いていない感じがあり、机上の空論と現場との乖離がありますかね...
Pythonだろうと多重ループはパフォーマンスに影響するよね...
久々に「3重ループ」の処理に遭遇して、「Python」だと「多重ループ」における「パフォーマンス」問題とか気にしなくて良いんだっけ？と思ったので、改めて「多重ループ」と「計算量」の関係について調べてみた。
ネットの情報を漁っていたところ、
計算量のめやす
データ量が多くなるに連れて、時間的にも空間的にも計算量は黄にしておくべきかと思います。少ないうちは、そうそう変わるものではないらしいです。
（使っていきたいオーダー）
Ο(1) < Ο(log n) < Ο(n) < Ο(n log n)
（ちょっと遠慮したいオーダー）
Ο(n^2) < Ο(n^3)・・・
（雲の上）
Ο(i^n) < Ο(n!)
⇧ 上記サイト様によりますと、「3重ループ」は可能であれば使用を避けたいといった感じっぽい。
まぁ、「ゲーム」とかの「プログラム」だと「座標計算」とか頻出すると思うので「3重ループ」とか多用せざるを得ないのかもしれないが...
とは言え、「オブジェクト指向」的に「データ」の構造を工夫すれば何とかなりそうな気がしなくもないが...
何故、「多重ループ」になるほど「計算量」が増えていくのかは、
それぞれ、forループが1重、2重、3重になっており、それぞれO(n)、O(n2)、O(n3)と書きます。これをオーダーと言い、O(n)をオーダーn、O(n2)をオーダーnの二乗、のように読みます。
⇧ 上記サイト様のイメージ図が想像し易いかと。
単純に、処理する対象の数が増えていくことになるので、「計算量」も増えていくことになりますと。
参考サイト様のように、n=100の場合、以下のようになる。
| No | ループ | 計算量 | n | 繰り返し回数 |
|---|---|---|---|---|
| 1 | 1重ループ | 100 | ||
| 2 | 2重ループ | 100 | ||
| 3 | 3重ループ | 100 |
指数関数的に「繰り返し回数」が増えていくので、nの値が大きくなると目も当てられないことになるのは容易に想像が付く話かと。
何となくだが、
- 機械学習・深層学習
- ゲームプログラミング
などの「多次元」な「データ」を扱わざるを得ないソフトウェア開発は別として、一般的な「業務システム」であれば、「2重ループ」ぐらいまでで済ませて欲しいお気持ち...
まぁ、外部システムのレスポンスの「データ」の構造上、「3重ループ」を使わざるを得ない場合もあるとは思うが、他に方法が思い付かない場合に苦肉の策としての最終手段ぐらいの気持ちで考えておきたいところではある...
とりあえず、「Python」においても「多重ループ」と「計算量」の考え方は変わらないことが分かったので、極力「3重ループ」を使用しない方法を模索していきたいところですかね...
「パフォーマンス」に影響無いぐらいの「データ」に対する繰り返し処理なら問題ないとは思うのだが...
「4重ループ」とかは論外といった感じになるんかな...
結局のところ、「多重ループ」な実装になってしまうかどうかは、「データ」の構造次第ということですかね...
「JSON（JavaScript Object Notation）」とかだと、入れ子な構造になっていることが多そうなので、「多重ループ」にならざるを得ないということかしらね...
「CSV（Comma-Separated Values）」だと、入れ子にはなりにくいかもしれないが、1行で余分な「データ」が重複することになりますしな...
なかなかに悩ましいところですな...
とは言え、外部システムの「レスポンス」の「データ」構造は、「レスポンス」を受け取る側ではどうしようもないですしな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
