「とりあえずソースコード読んで仕様理解して。」「無理です。」

「とりあえず教科書丸暗記してテストで100点取ってきて。」「無理です。」

バカ正直に受け取ってソースコードを最初から最後まで読んでも何も分からなかった。

自分でシステムの特定部分に興味を持ち（きっかけは仕事で依頼されたからでも良い）、自分の手で資料を手繰りソースをgrepして現場の暗黙規定を周りに聞き回り、世間話に紛れ込ませた話の切れ切れから人間模様を想像し、システムの歴史を時間の許す範囲で遡り、それでようやく、何とかシステムのほんの一部を自分の血肉に出来る。「仕様を理解」して、「Why」に答えられるようになる。

「ソース読めば分かるだろう」という人は、大抵はそのシステムに長く（「長く」の程度は様々だろうが、少なくとも新参よりは長い）携わっている。
システムにどんな人が関わり、どういう経緯を経て諸々の機能が実装されたのか知っている。
例えるなら「漫画日本の歴史」「漫画世界の歴史」を読み込んでるようなものだ。人物関係や事の経緯・背景、一連の流れが頭に入ってドラマとなっているのであれば、教科書や文献資料は、正確な記述を求めるためのソースコードでしかない。

システムを理解する為に、ソースコードを読むよりは効果的な方法がある。取り扱うデータのデータ構造と状態遷移。それとコンポーネントの配置図。別にUMLでなくともよい。殆どの場合、それらは絵と図で構成されているだろう。そして、ソースコードという文章の羅列よりは余程脳に優しく、素早く浸透していく。

だから自分は、他人よりは多少、絵を描く。Excelで描く。大雑把でも良いので描く。言葉も混ぜる。ドキュメントは無駄じゃない（場合もある）。ソースコードは電子計算機をプログラミングするものだ。対して仕様書・説明書・ヘルプマニュアルを始めとするドキュメントは、人間の（＝読み手の）イメージをプログラミングする。イメージのプログラミングに効果的なのが、図と絵、表であり、その現場で標準となっている文書フォーマット（フォントサイズやヘッダーフッター・マージン、WordかExcelかなど）だ。

人月の神話（新装版）, フレデリック・Ｐ・ブルックス, Jr, ピアソン・エデュケーション

第９章　五ポンド袋に詰め込んだ十ポンド
（中略）
表現はプログラミングの本質である
（中略）
しかし、データやテーブルの表現をやり直す事で戦略的突破が実現される場合の方がはるかに多い。ここにこそ、プログラムの真髄がある。私にフローチャートだけを見せて、テーブルは見せないとしたら、私はずっと煙に巻かれたままになるだろう。逆にテーブルが見せて貰えるなら、フローチャートはたいてい必要なくなる。それだけで、みんな明白に分かってしまうからだ。

もし「とりあえずソースコード読んで仕様を理解して」と言う人がいて、真実、そのやり方で全く何の問題もなく仕事をこなしてきたというならその人は相当頭が良いに違いない。だけど自分はそこまで頭は良くない。弄って壊さないと分からないし、例え一部分を血肉に出来たところでその他大部分は闇の中だ。多分その人と同等までシステムを理解するには、半年から１年はかかるだろう。それだって、偶々仕事の担当上まんべんなくシステムを見る事が出来た場合で、担当の割り振りによってはずっとシステムの一部分しか知らなくても問題ない場合もあるかも知れない。

だから自分はとりあえず諦める事にした。勿論可能な限り調べて理解しようと努めるが、それでも漏れは生じる。
そうした漏れに対して、「なんで理解できなかったんだろう、気づかなかったんだろう」と自分を責めるのを止める事にした。
理解できないのが、漏れが生じるのが普通なのだ。ソースコードを読むだけで仕様を理解できるなんて、きっと余程頭の良い人間に違いない。上司は/リーダーは「とりあえず〜」と言ってきた以上は過去自分もソースコードを読むだけで仕様を理解してきたのだから、頭が良い人間に違いない。
でもだからといって自分を責める必要は無い。責めたところで頭は良くならないし。
もしそれが原因で仕事を解雇されたなら、自分程度の頭でも働ける別の場所を探すしかないけど。

頭が良くないから、だから自分は多少、絵を描く。Excelでざっくり描く。UMLのパチモンでも良いので描く。時には、真っ白な紙にお気に入りの黒ボールペンと赤ボールペンで書き連ねる。そういうやり方でしか、システムを把握できない。システムに対する認識が他者と相違ないか信じる事が出来ない。
図・絵・表を多用すれば、言葉を連ねるよりは余程他者の脳内に素早くイメージを構築できる。

救いは仏陀に求めるので、ご意見を乞う。