シンプルなモデルで具体的に考えて理解する方法

雑記 git

新入社員として初めて配属された先は、とある巨大店舗の経理部だった。経理部はいくつかの課に分かれており、さらに課はいくつかの係に分かれている。自分が担当するのは、その中の一つの係である。

新入社員というのは、良くも悪くも前提知識がまったくない。自分が担当する係の仕事内容も分からないし、その係が経理全体の中でどのような役割を担っているのかさえ分かっていないのだ。

それにしても、巨大店舗の売り場では色々なことが起こる。伝票を処理するルールというのは決まっているのだけど、そのルールから外れてしまうのが常である。こちらの想像を超えた予想外のミスをどのように修正すれば良いのか、新入社員であっても電話をでたら、容赦なく問い合わせてくる。（電話の向こうでは、こちらが新入社員かどうかなんて、分からないのだから）

新入社員がそのような問い合わせを受けても答えられるはずもなく、必死で問い合わせの内容をメモして、保留あるいは折り返しにして、先輩社員に確認して、オウム返しに答えるしかないのだ...。

オウム返しと言えども何度も繰り返していれば、似たような質問に対しては過去の記憶を引き出して、答えられるようになる。ちょっと経験を積むと、何だか少しはできるようになった気になるが、現実はQ&Aを丸暗記して答えているに過ぎない。いい気になって知ったかぶって話していると、突然Q&Aにない状況を持ち出されて「少々お待ちください」あたふたと保留して、誰かに確認する羽目になる。結局、頼りの誰かがいないと何もできない社員、という状況はまったく変わっていないのだ。

いつまでも丸暗記ではダメなのだ。業務を理解する必要がある。一つの伝票が作成されて、それが各部署を巡る間にどのように処理され、そのデータがどのような影響を与えるのか、自分の係だけでなく、経理さらには店舗全体に与える影響を知っておく必要があるのだ。そこまで知って、初めて担当業務を理解したことになる。

しかし、巨大店舗の伝票処理は複雑怪奇である。様々な取引が複雑に絡み合う中で、それらのデータの流れを的確に理解するのは途方もなく困難なことのようの思えてくる。実際、新入社員の自分は相当混乱していた。未経験の対応についてはすべて上司に確認するしかなかった。上司が休みの日は、電話の問い合わせがちょっと怖かった。自分の知らない問い合わせがあったらどうしようか？と不安になるのだ。

そんな状況を見て、あるとき上司が面白い例え話で質問してきた。「○○くん、もし1ヶ月の売上が今問題になっている伝票しかなかったとしたら、どうなると思う？金額も細かいのがあると面倒だから、キリよく商品代金も10000円で考えてみて」

や、や、や、衝撃的な質問だった。日々の売上が1億円を超える店舗である。なのに1ヶ月の売上がこの伝票1枚しかないと考えると、どうなるのかと。そのようにして考えてみると、今まで複雑な処理に惑わされて混乱していた思考が、ウソのようにクリアになった。シンプルに具体的な数字を当てはめて考えることで、問題の本質が今までになく明確になってしまった！

それ以降、その上司と自分の会話は問題となる伝票にキリのよい金額を当てはめて、空想実験する話題がめっきり多くなった。そして、幾度かの空想実験を繰り返すうちに、いつの間にか未知の質問にも答えられるようになっていった。未知のことであっても上司に頼るのではなく、関連する部署に確認して、答えを導き出せるようになった。

今考えてみると、このように具体的な金額を当てはめ、シンプルなモデルで思考する方法は、決して特別な手法と言う訳ではなく、会計の世界ではよくやる手法であると思っている。しかし、新入社員の混乱している時期に知ったその思考方法は、とても画期的であり、素晴らしく分かりやすい手法に思えた。以降、自分が未知のことを理解しようとするときは、経理業務に限らず、あらゆることにこの方法を応用して考えるようになったのである。

世界がもし100人の村だったら

以前流行った「世界がもし100人の村だったら - Wikipedia」と思考して、「○○人がこんな状況です」と考える手法も、まさに自分が新入社員の時に知った手法と同じである。シンプルなモデルで具体的に考える手法の奥の深さを感じた。

Ruby on Rails

  • このブログの始まりは、Railsの学習記録であった。
  • ブログを始めた時点で、RailsさらにはRubyの知識も0であった。
  • しかし、Rubyの学習から始めるのではなく、Railsのscaffoldから始めだのだ。
  • Rubyが何かを知らなくても、scaffoldを実行すれば、動くWebアプリケーションができてしまう。
  • 動くアプリケーションのコードを読みながら、少しずつ、Rubyの世界を理解していった。
  • 結果的にその方が、学習するときの時間と労力が節約できたと思っている。
  • 未知の言語を学ぶ時のシンプルなモデルとは、分かりやすいサンプルコードと考えられる。
  • Railsを学習していた2006年当時、発売されていたRails本はすべて購入し、精読してみた。
  • すべての本が何らかの意図を持って、それぞれ独自の観点から、Railsを説明しようとしている。
  • 本を読むほどに、Railsを見る視野が広がり、Railsの理解は深まる。
  • 時間を惜しまなければ、すべての本を精読すれば良いのだけど、
  • 1日はすべての人に平等に24時間しかなく、その中で仕事・生活・睡眠などをやりくりする必要がある。
  • 少しでも効率良く学習しようとすれば、自分に合った本を選択する必要がある。
  • しかし、どうやって選択するべきなのか？
原典は外せない
  • その言語やフレームワークの開発者が書いている本（原典）があるなら、それは絶対に読むべきだと思っている。
    • あるいは開発者が書いていなくても、誰もが認めるその筋の良書と評価されている本が1冊くらいあるはず。
  • なぜなら、開発者の書いた本には、仕様だけでなく、その背後にある設計思想まで語られていることが多い。
  • 入門書として原典が最適かどうかは未知だが、その言語を正しく理解する過程では、原典は最も正確に学べる書である。
入門書から入る
  • 原典を読んですべてを理解できれば、それは理想である。学習効率も最高に良い。
  • しかし自分の場合、知識0の状態で、その筋の原典だけ読んですべてを理解できた試しがない。
  • 原典を読める知識さえないので、その前段階として、より噛み砕いた説明が欲しいのである。
  • では、より噛み砕いた説明とは、どんな説明が良いのか？
  • 実はこの部分こそが、原典以外の多くの本が試行錯誤している部分だと思っている。
  • そして、読者に評価される部分だと思っている。
  • では、評価が高い本を買えば間違いないかと言えば、決してそんなことはない。
  • 多くの本が、訴える対象を明確にイメージして書かれているはずである。
  • その本を読むときの読者が、訴える対象と重なれば、それは評価どおりの良書となるのである。
  • しかし、読者と訴える対象に差があると、読者は評価と違った印象を受けるはずである。
    • Railsをひと通り理解している読者が評価の高い「入門書」を読んでも、それは退屈な本にしか感じられないはず。
  • また、解説の手法が読者に合っているかどうかも重要である。
  • 人が新しいことを理解するとき、おそらくそれまでの経験を拡張させる思考を試すと思われる。
  • 読者がそれまでにどんな経験をしてきたかは千差万別である。
  • 多くの人が分かりやすいと評価していても、それが自分にとっても分かりやすいかどうかは、未知なのである。
実践をどうするか
  • 順調に入門書、原典、と読み進めて、Railsを理解したつもりになっても、
  • 結局はサンプルコードを修正するレベルの知識しか身に付いていなかったりする。
  • 実際にコードを書くときは、もっと現実的な問題や要求に応えなくてはならない。
  • 例えば、日本語（多言語）環境を扱うならRuby-GetText等が必要になる。
  • しかし原典を読んでも、Ruby-GetTextの取り扱い方法は記述していないのである。
    • Ruby-GetTextはRailsに含まれないので、記述がないのは当然である。
  • そう言った情報は、Ruby-GetTextの開発者のページで確認したり、日本語化を実践した先達のブログなどを読んで学ぶことになる。
    • Rails本の中には、Ruby-GetTextの使い方を解説したものもあった。
  • Ruby-GetTextのように日本語で情報発信されていれば、その使い方は効率的に学べる。
  • しかし、日本人以外の開発者が英語で情報発信していると、英語が苦手な自分はなかなか理解が進まない。
  • 2006å¹´12月にさらに1冊のRails本が出版された。
  • ひたすら、問題提起と、それを解決するコードと解説がある実践的な本であった。
  • Railsの原典まで理解したけど、サンプルコードの改変より先になかなか進めない、と感じていた自分には素晴らしく参考になる本であった。
  • 非常に難解なコードもあり、部分的に何十回も読み直してボロボロになりつつある。
  • その頃の自分にとって、そこに出てくるコードを理解することは、宝を発掘している感覚であった。
  • そのRailsレシピを理解する過程で、すべてがオブジェクトであるというRubyの本質を感じ始めたと思う。
  • オブジェクト指向やメタプログラミングと言われる手法も理解し始めたのだ。
  • すると、難解なRailsのソースコードを読んでも、どんな処理をしているのか、分かるようになったのだ。
  • ソースコードを読めるようになると、理解は飛躍的に進む。
  • 分からないことは、ソースコードに当たって調べるようになる。
  • 英語が分からなくても、ソースコードが読めるので、そこから教えてもらった。
サンプルコードの重要性
  • Railsを学ぶ中で気付いたのが、サンプルコードの重要性である。
  • 自分の場合、こんな仕組みで動くと日本語で理論的に100回説明されるより、サンプルコードを示されてこんなふうに動く、と説明された方が自然と理解が進んだ。
  • これは中学・高校6年間も英語の文法を学んでも英語を話せないが、小学校入学までに多くの子供が文法を知らずに、日本語で会話できるようになることと似た感覚。
  • 何かを学ぶとき、理論が先か、実践が先かと考えたら、圧倒的に実践を先にした方が理解が進むのである。（自分の場合）
    • 実践を知って、あとで、なぜそうなるかを理論的に考える。
    • どちらかというと、学校での学習方法とは逆の順序である。
  • 素晴らしいサンプルコードは、そのコードを読んでいるだけで、その言語の使い方が理解できてしまう。
  • Railsを学ぶときには、そのような素晴らしいサンプルコードが数多く公開されていた気がする。

ソースコードリーディング

  • ソースコードが理解できたときの感動は、数学の図形問題が解けたときの感動に似ているかもしれない。
  • Railsの学習が一段落した後年、興味を持った仕組みが、その裏でどのように動いているか調べている。
  • 最初はまったく意味不明なソースコードが、コードを睨み続けて何日間も対峙することで、Web検索に助けられながら、少しずつその仕組みがひも解かれていくのだ。
  • このソースコードリーティングでも、実際にシンプルなモデルを考えて、引数や変数・レジスタに実際に数値を代入しながら、CPUの動きを追っていくのである。
    • （たぶん多くの方が実践している方法だと思う）

CocoaとObjective-C

  • OSX開発環境の原典と言えば、アーロン ヒレガス著・Mac OS X Cocoaプログラミング である。
  • 2002å¹´6月発行の初版を購入した。その内容は非常に分かりやすいサンプルと言い回しで解説される、名著だと思っている。
  • しかし、その当時挫折していた。解説は分かりやすいのに、肝心な何かが理解できていない感覚。
  • その原因は、オブジェクト指向なプログラミングという手法の意味をちゃんと理解できなかったのだ。
  • オブジェクトとは何か、クラストは何か、Cocoaの中でどのように利用されているのか、正確に理解できていなかった。
  • どんな小さなプログラムコードでも、自分で一から書いてみることで理解は飛躍的に深まる。
  • そして、それが実際に役立つアプリケーションだとなお良い。
  • メンテナンスや改良を通じて理解をより深めることができる。
    • といいながら、2009年と2012年のコメントが、ほったらかしであったことが発覚。（しまった...。あとで返信しておかなければ）

Gitの学習

  • Gitを知ったのは、RailsがGitHubを使い始めたからであった。
    • GitHubはRailsで作られた、最高品質のWebアプリケーションかもしれない。
  • GitHubを使いこなすなら、Gitを知っておく必要がある。そんな流れで、Gitを学び始めた。
  • しかし、Subversionのインストールはしたが、コード履歴の確認ぐらいにしか使っていなかった身には、けっこう敷居が高かった。
  • 2008年当時にはまだGit本も出版されておらず、Webの情報だけが頼り。
  • Webの情報は決して分かりにくい訳ではなく、Gitチュートリアルの日本語訳は素晴らしく参考になった。
  • しかし、実際に使い始めてみると、現実のこの状況で何をどうやって操作するべきなのか、分からないのだ...。
    • インデックス・リポジトリ・作業フォルダの関係や役割が正確に分かっていない。
    • 間違った操作をしたときの修正の方法が分からない。
    • ファイル名の変更をすると、訳の分からない状態になる。
    • ブランチやマージが怖くてできない...。
  • 典型的な挫折症状である。
  • そこで、チュートリアルで出てくるアリスとボブの例に習って、徹底的にアリスとボブそれぞれの立場になって、試してみようとしたのである。
    • 自分で簡易なサンプルプロジェクトを立ち上げて、実際にやってみたのだ。
  • シンプルなモデルで具体的に考えるというこの試みは、新入社員の昔から慣れ親しんだ方法である。
  • この試みが想像以上にGitの理解を深めてくれた。ならば、忘れないうちにブログに書いておいた方がいい。
  • ブログに書くことで、もう一度書く内容を再確認する*1ので、勘違いに気付いたり、さらに理解を深めることになるのだ。
  • そのような経緯で公開した「アリスとボブのGitシリーズ」は想定外の嬉しい反響を頂いた。
  • そして、その反響は最大瞬間風速として終わることなく、何年もの間少しずつブックマークされ続けるという、息の長い記事となったのである。
  • アリスとボブのGit入門レッスンは、上記のブログ記事が元となり、さらにGitを詳細に分かり易く語ることを狙った本なのである。
  • 自分が何かを学習するときに使う「シンプルなモデルで具体的に考えて理解する」というお決まりの手法が本になっているのだ。
  • 書いている中で、分かり易く説明する、ということは実は相当難しいと感じた。
  • 単なる手順書なら詳細に手順を書けば済む。
  • しかし、シンプルなモデルで具体的に考える理由は、その本質を理解するためである。
  • 手順を知ると同時に、そこにある仕組みを理解してもらわなければ意味がないのだ。
  • また、本質を追究する姿勢は、自分が文章を書くときに心掛けていることでもある。
  • ブログや本でその姿勢を忘れてしまっては、自分が書く意味がなくなってしまう...。
  • どこまでも追求しなくてはならない、という使命感がある。
  • 目指したのは、丸暗記の理解ではなく、応用力の宿る理解である。
  • 分からないことは自ら調べて、理解を深めていく、そうゆう能力を高めていきたい。
  • 果たして、本の中でそれがどこまで成功しているかは、未知である。
  • 単なる初心者向けの入門書で終わらずに、本質を理解するきっかけとなりますように！


そんなことを願いながら、シンプルなモデルで具体的に考える軌跡に想いを馳せてみた。

*1:全世界に向けて、間違ったことを発信してはならない、と思っているので。