From the Workshop
システムを構成する多くの要素から
トラブルの原因を探るトラブルシュート
これは
日頃やっている人にしたら当たり前でも
お受験に最適化した人には難しいかもしれません。
それはなぜか？
トラブルとは何かというと
それは「想定外」なわけで
まさか、そんなところに原因があるなんて！
ってなものです。
「想定内」は
トラブルとは呼びません。
対して学校のお勉強は
まず範囲が決められていて
その中から出題されます。
なので想定外なんてことは無くて
指定された想定内だけを見れば良い。
答えはその中にあるのだから。
その中で
さらに細部にフォーカスして
隠された答えを探し出す
そういったアプローチです。
もちろん、そういう経験やスキルは必要です。
しかし、それしかやっていなければ
目に見えない、視野の外をを想像する
なんてことはできないわけで
視野の外にこそ貴重な情報がある
なんてものの考え方はできなくなるでしょう。
トラブルとは情報源であり
失敗とは学びである
そういう考え方が大事なのだと思います。
それは実践から学ぶしか無いのです。
だから頑張れ。
トラブルシュートとは
システムにおける問題の原因を探り、解決することです。
クルマなどの製品の故障とか
技術的なものに適用するのが一般的かと思いますが
そういったものだけがトラブル（問題）なのではありません。
やりたいことができない
叶えたい夢がある
そういった現実になっていないものを実現したい
これも問題なのです。
だって、それらは
実現したいのにできていない
のですから。
「できていない」という問題です。
もっとも、これを「問題」と捉えることができるか否かが
そもそも問題なのかもしれませんが
まあ、それはそれとして。
完成された
といったら言いすぎだけど
トラブルが起きないように設計された環境を与えられて
そこで言われたことをやっていたら
トラブルの発見と解決はできるようになりません。
これ、学校の授業でやる「実験」と呼ばれるものも似てますね。
やると何が起きるか分かっていることをやるでしょう？
まぁ、受講者は分かっていないのかもしれませんが
指導書を読めば、最終的にどうなるか予想が付きます。
でも、そもそも実験ってのは
何が起きるか分からないからやるのですよ。
提供する側からしたら
トラブルの発生しない環境が「良い環境」
当初の設定通りになるのが「良い授業」
なのかもしれませんが
それは、人の成長においては逆です。
トラブルを発見して解決する能力
わけがわからないものを明らかにする能力
が手に入らないのですから。
というわけで
与えられるものを受け取るだけの環境で
夢を実現するための能力は手に入らないのですよ
というお話しでした。
私は日頃、ウクライナとかイランの動向をチェックしています。
別にミリオタではないし
軍事関連の開発をしようってわけでもありません。
目的は、技術の動向と変化のスピードのチェックです。
そこから彼らがどういう開発をしているのかを想像するのです。
ドローンの構造はどうなっているのか
はなぜ、あのようなドローンを、あのようなペースで製造できるのか
そして、それらを迎撃するための技術は、開発のスピードはどうなっているのか
もちろん詳細は分かりませんが
おおよその想像は付きます。
技術の世界に民生と軍用の明確な境界線なんてありません。
多くの技術はデュアルユースでもあるから。
航空宇宙や防衛関係のテクノロジーは
あらゆる意味で最先端であって
それらは遅かれ早かれ民生技術として
我々の手元に落ちてきます。
そして、そのスピードとレベルは
年々向上しています。
当然ながら、将来のエンジニアたる学生達は
そういった動向に適合する必要があります。
一般の学生がそういった環境に適合できるようにするのは
正直難しいでしょう。
教育のシステムがそうなっていないし
変化させるための切迫した事情もありませんから。
なので、せめて夢工房の学生達は
未来に適合できるようになって欲しいと思っています。
近年の動向は
アジャイル（agile）
ですね。
「機敏な」という意味です。
開発手法としても、組織文化としても
そういう方向でしょう。
なので、必要なのは
アジリティ（agility）です。
変化に対して、素早く、賢く、方向転換できる力ですね。
素早くやって
素早く最適化・改善していく
というところでしょう。
勇気もパワーも必要です。
我々は戦争のような切迫した環境にいるわけではないので
何を動機とするかが難しいところなのですが…
レースは最適なのですよ。