開発の速度や、開発の品質に問題がある場合に、何が一番のボトルネックになっているのかを見極めよう。
一番のボトルネックに着目すべき理由
一番のボトルネックを解決することが一番効率がよい。
- 例：動作ログが残らない実装の状況では、問題を生じても原因を適切に推定することができない。この場合は動作ログがきちんと取れていないことがボトルネックになっています。
一番のボトルネックをそのままに他の要因を最適化しようとしても、効果は上がらない。
- 例：計測を考えてみます。誤差要因は多数あります。そのような状況では大きな誤差要因から、減らしていくことが大事です。小さな誤差要因の精度を上げようとしても、大きな誤差が残っている段階では、小さな誤差要因について改善できたのかどうかが分かりにくくなります(あるいは、まったく改善しない)。
- 例：値のばらつきが大きすぎる。観測値の分布を見たときにばらつきが大きすぎる場合には、現象をモデル化して残差を最小化することはできない。観測値の分布のばらつきを大きくしている要因(例：電源系のノイズ、機構系のがたつき（もしくは遊び）、測定系の不安定要因、振動、ケーブル線へのシールドの不足、接点の接触不良、電気系のチャタリング、初期設定時の動作にばらつき、.....)は何かを探る必要がある。
- 測定誤差を少なくするのが本質的。測定誤差を少なくするための努力をしつくさないうちに、後処理で何とかしようと思ってはならない。誤差をモデル化して残差を減らそうとするのは、測定自体を改善した後に、それでも残る誤差を削減する場合に限る。
- 誤差を1桁減らそうとすると、考慮すべき要因の数が１０倍になるように思えます。
- 本当に完全なモデルを必要とする枠組みに定式化するのではなく、もっと単純なモデルで定式化することで十分な方法はないのかを考慮してみてください。
ボトルネックになっていたことを改善すると、目に見えて改善が現れてくるので、開発チームの士気が上がりやすくなる。
- 解決を要求する作業の順序を間違えると、「もっと大きな要因があるのに、なぜ自分の担当の部部分だけ向上を要求されてもどうしようもないのに。」といった不満をメンバーに与えることになることがあります。
再現性の乏しいトラブルに苦しんでいる状況では、計測も制御もいい結果にはたどりつけない。
- 多変量解析や時系列解析など、どのようなデータ処理であっても、系のノイズが大きすぎる場合や、再現性の乏しいトラブルに見舞われている状況では意味のある結論に達することができない。制御は、計測結果にノイズが多すぎたり再現性が乏しかったりする状況では、無意味になってしまう。大本のデータの品質につながる要因を改善しない限り無意味だ。
- おそらくはディープラーニングも、系のノイズの大きすぎる状況、再現性の乏しい状況のトラブルに見舞われている状況で用いる限りは、有用な結論に達することはできないのではないかと私は推測する。（ゴミが入ればゴミが出る）
一番のボトルネックとしてあなたが思っていることと、リーダーが思っていることとは食い違っている。
- 一番のボトルネックと考えていることを解決しようとするときには、それを解決するまでの時間を長くしない方がよい。外部にその分の開発を委託する場合でも、解決するまでの時間は短くなるように配慮してください。
- 開発は時間との戦いです。開発の進展速度の低下や、期日までの達成可能性について疑いを生じてしまうことのないように、一番のボトルネックを解決することに力を集中することです。
実験の手順をしっかりメモしておこう。
だれが操作しても同じ品質で実験ができるようにすること。
以下のリンクは、速度上のボトルネックを解決する場合の参考記事のリンクです。
プログラムの実行速度が一番のボトルネックになっている状況は、「ラッキーな状況」と言えます。プログラムが動くようになっていて、正しく動くようになっているからこそ、実行速度がボトルネックと言えるのですから。
記事の中ではサンプルのプログラムがあるので、Linux環境でそのまま手順をたどってみることができます。
この記事の中でも手順がしっかりしているので、何かサンプルプログラムを同じ手順でグラフ化してみるといいと思います。
Pythonの場合
以下の記事がとても参考になります。