IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→起業)

「わからない」を「わかる」にする方法の話

こちらによく書く話に近いんですが、今回はQiitaに書きました。

 

qiita.com

 

13000字・・・・・・

 

言語化して、色々気づきが合ったので良かったと思います。
わからないことをわかるようにするプロセスは案外ルーチンワーク化できるかもしれません。

 

 

 

エンジニアリングにおける「わかる」ためのフロー

はこういう感じだと思います。

https://camo.qiitausercontent.com/cf6d66208075701084d11c755a626ffb6cae0f93/68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f32303738342f64663334366436332d643333332d373361302d346539662d3662326532306137393739322e706e67

 

よくもまあこういうフローを無意識で普段やってますよね。人間って不思議。

 

「わかる」とはどういう状態か

は下図のようなんですが

https://camo.qiitausercontent.com/249bb209f32f5624a78878b9dcba12f2e1e74c59/68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f32303738342f62646664346133342d323836642d393166642d383732332d3039346537343339623230392e706e67

似たことはずっと考えてました。
ここらへん子供の頃から考えてる気がします。

 

otihateten.hatenablog.com

 

目的が生じたときの解決プロセス

言語化できてよかったです。

案外シンプルなんですが、ここに気づくのに結構時間がかかる気がします。

https://camo.qiitausercontent.com/cf6f8cce54baa18ae0e13670fede916d2e93af1d/68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f32303738342f36363061346661362d643062332d633532662d633961332d6433366162623734626265382e706e67

ちなみに現実の業務だと要素が増えます。例えば納期とか予算とか。

 

プログラム、開発で考えると理解しやすい

面白いのは、現実の複雑な振る舞いやプロセスを、プログラムという仮想上で再構築しているので、現実の複雑な振る舞いやプロセスを理解するのに、プログラムで考えると理解しやすいということです。

プログラムもそうだし、開発業務そのものもそうです。
科学的手法というのは残った理想と現実とのギャップを埋めるための最後の武器という感じがします。

プログラミング的思考って多分ここらへんの話ですよね?これを誰かに教えるというのは非常に骨が折れそうです。

 

beneprog.com

 

新人はどのようにしてプログラミング的思考に到達するのか?

こういう技術は高校生までは「小賢しさ」として認識されると思います。
既に体系化された知識を学ぶ勉強・暗記が是ですから。その思想に誰であれ多かれ少なかれ毒されます。

それでもあまり毒されず、科学的手法・実験的手法が好きな小賢しい奴らがプログラマーになってるのではないかと思います。つまりプログラマーになってから覚えてる人は少ないのでは?という疑いがあります。

でもそういう曖昧な部分ってプログラミングという文脈では悪ですよね。詳らかにしていけたほうが良いと思うんですが、如何せんここの領域に興味を持ってる人が少ない感じがします。たぶん新人はまだまだ苦しむのではないでしょうか?

まずこれらを体系化できたとして、新人がマスターできるのかはよくわかりません。どうなんでしょうか。