【書評】【フレームワーク】web開発初心者必見？「大人のための算数教室」から思考フレームワークを考えてみた！
となりの席の凄腕エンジニアとへっぽこエンジニアな俺との違いって
Rails知ってる、知らないの前に
開発力というか論理的思考力といったもっと根本的で致命的なやーつじゃないか。。。
そんなことをふと考えていたらこんな本を見つけました。
絵が何ともかわいらしい。
大人のための算数教室
中身はというと難しい言葉をほとんど使われずに、
分かりやすく丁寧に書かれています。
その中でもこの本のベースにある「7ステップ思考法」はweb開発に生かせるのではと
思ったので所感も兼ねて書いて置きたいと思います。
またweb開発に関して書いてあることは個人レベルでの考えなので、
チームレベルでも効果的かは分かりませんので、
ご了承ください！
ステップ１・情報を集める
本書では、このステップについて
「算数の問題は、問題文に与えられた情報だけを組み合わせて解くもの」
である以上、問題文を読み間違えてしまうと、そこから先、どれだけ一生懸命考えたとしても
答えに辿りつくことは出来ないと述べていました。
僕はこのステップをweb開発において
「仕様の読み込み」
にあたるなーと思いました。
ドキュメントに残す、trello(https://trello.com/)に残す、redmine(http://redmine.jp/)に残すといったやり方はいくつかあるとは思いますが「残し方」が大事ではなく、
「途中から参加した新入りエンジニアでも仕様を実現するために必要な情報が全て残っている」
というのを実現することで、
「あれ？作ってる時に気付いたけどこの情報知らないと実装出来なくない？」
といったことも無くなるかなと。
「仮想新入りエンジニア」(ペルソナ)を自分の中で定義して、それをベースに
「途中から参加した新入りエンジニアでも仕様を実現するための必要最低限の項目で構成したテンプレを作成しよう！と思いました。
そして0ベースで一度、確認することで読んだつもりを防止します。
ステップ２・情報を整理する
本書では、このステップについて
「算数の問題を考える時には情報と情報をいかに組み合わせるかが重要」
であり、このステップを踏む事で次のステップの「とっ掛かり」がつかみやすくなるとのこと。
僕はこのステップはweb開発において
「UML(設計)の作成」
にあたるなーと思いました。
前章だけの情報を頭の中だけでやろうとすると、こんがらがってしまう。
残し方はそれぞれあるかと思いますが個人的にはcacoo(https://cacoo.com/lang/ja/)で決まり！
ステップ３・解き方を考える
本書ではこのステップについて
「考える⇒試行錯誤する」ということであり、『この段階ではこの解き方で解かなければならないというものではない』、その逆に
とにかくいろいろと組み合わせてみて、結果として、求めたい値にたどりつくためのステップ」とのこと。
僕はこのステップはweb開発において
「ざっくりした処理の流れを考える」
にあたるなーと思いました。
具体的には
- 「既存機能を改修した方が良いのか、新規で作った方が良いのか」、
- 「既存機能だと、どこどこのviewから情報を取ってどのmodelに投げて。。。」、
- 「新規機能だと、どこどこに新規にviewを作って。。。」
といった感じ。
ステップ４・計画を立てる
本書ではこのステップで
何をどういう順に解決していくのか
どういう方法で解決するのか
この２つを具体的に決めてしまうとのこと。
そして、「算数の出来ない人」はよく、この「計画」を立てずになんとなく
問題文で出てきた数値を組み合わせてなんとなく計算をしてしまうとのこと。
また、計画を立てると言っても、その計画が最終決定でなければならない
ということはありません。
もし、計画通りに計算していて途中で行き詰まったら計画そのものを
見直せばいいだけの話とのこと。
なので見通しというニュアンス。
僕はこのステップはweb開発において
「技術的負債が残らないもしくは増やさないような必要最低限の処理の流れを
メソッド単位で考え、ソース内にコメントを書く」
にあたるなーと思いました。
新規機能の方が良いのか、既存のモジュールであったり機能を回収した方が良いのかといった所から始まり、CRUDで言うとどのviewからどの様な情報をPOSTして、どのメソッドで
DBへ登録するかをあらゆる角度から考えることで、徐々に「現段階でのベストな答え(仕様実現)」
に近づく逆に、遠ざかる(行き詰まる、仕様実現が困難)のならまた
計画そのものを見直しまた、考え直すということを繰り返していこうと思いました。
追記
ここで一旦、有識者もしくは先輩エンジニアに自分の設計で問題無いか確認した方が良いかも知れません。そうすることで実装前にステップ3に戻って再考出来ますし、
二度手間の発生を防ぐことが出来ます！
ステップ ５・実行する
本書では「このステップでは決まったことをやることをやるだけ」とのこと。
なーんだ簡単じゃんかと思っていても、
「本当にこれで合ってるかな？」って疑問を持たずに実行することはなかなか難しく、
その疑問を持ってしまうと集中力が散ってしまい、正確性が下がってしまうとのこと。
僕はこのステップはweb開発において
「コーディング」
にあたるなーと思いました。
思えばコーディング中に思考錯誤していたことがしばしば。。。
今日からいかに
「考えずにコーディング出来るか」
という所に重きを置かねば！
そういえばこんな記事あったなー。
ステップ６・確認する
本書では、このステップについて
確認するというのは単に同じ作業(上記5)を繰り返すことではなく、
出てきた答えを問題文の条件にもう一度当てはめてみる
とのこと。
出てきた答えを問題文の状況にあてはめてみて問題文で与えられている他の情報と
矛盾していないかチェックすることを「確認する」
に該当するとのこと。
またこの確認することは算数の特性でもある
「途中の手順で1カ所でもミスが挟まれば誤った解答になる」
というシビアなものに対して、
ミスをしてしまう機械のように完全ではない人間
との差分を埋めるために、この作業が必要とのこと。
(僕はそのように解釈しました。)
僕はこのステップはweb開発において
「テスト」
にあたるなーと思いました。
ステップ７・アウトプットする
本書ではこのステップについて
ステップの本質はただ回答を書くだけでなく、
「問題文のどの情報とどの情報を組み合わせてどういう情報を作ったか」を
論理的に順序立てて書いていくことであり、
このステップでそれが出来ない、難しいと感じる場合はそもそも、
解答が誤っているかもしれないとのこと
僕はこのステップはweb開発において
「ソースレビュー」
にあたるなーと思いました。
実装した内容を論理的に説明し、相手（大体、PLや先輩社員のはず）に
理解してもらうことで誤ったリリースを防止出来るなーと。
「書いてみたけどこれって考えたらウォーターフォールってやつじゃ。。。」
と思いつつ、個人レベルで「最速リリース」を考えた場合、案外ありだなと。
仕様変更や一部修正要望が入ったとしても、
元々の仕様をステップ７まで行い、その後、仕様変更や一部修正要望を
ステップ1から始めるとすれば良いのではと。
もちろん、その仕様変更自体を失念しなように
何かしら形として残したり、難しければリスケやチーム調整が必要ですが、
個人レベルの思考フレームワークとしては良いかと思いました。
当たり前の内容をつらつらと書きましたが、
同様の悩みを抱えているエンジニアの方の参考になれば幸いです。
この思考フレームワークで結果が出たら本ブログで報告したいと思います！
大人のための算数教室
