メタ認知のヒント: Andy Hunt 「リファクタリング・ウェットウェア - 達人プログラマーの思考法と学習法」

転職するときに、以前の職場の上司からもらった本です。当時はピンとこなかったけれど、今読み直すと理解できるようになりました。同時に、この1年何をしてたんだという後悔も。まあ、後悔は毎日のようにしているので、慣れっこです。なんで、もう一度念入りにおしりを拭かなかったのだろう、とか。

格言とは、その状況に応じて臨機応変に解釈が可能な基本的な 原理・原則です。 (p.11)

レシピと格言とは異なるのもなのですが、混同されていることがあると思います。この本でも、疑わしければユニットテストしろ、というのをレシピと取るか、格言と取るかで、具体的な行動や判断基準が変わってくるとあります。

プロジェクトの終わる瞬間が知力のビークであり、開始時点ではもっとも低いということです。これでも、早い段階で決断を下すのが賢明な判断だと思えますか? (p.113)

アジャイルなソフトウェア開発は不確実な状態での作業を許容する方法論です。 最初のうちはプロジェクトの最終日が本当はいつになるのかわかりません。次の反復でどの機能が採用されているかは100%確実にはわかりません。反復が何回あるのかわかりません。でもそれでまったく問題ないのです。その不確実性に浸る心地よさを味わえるようになればよいのです。進んでゆく過程で徐々に答えが見つかり、最後にはすべての答えが出ています。 (p.114)

時間がたつほうが判断が正しくなり、時間が早いほうが残り時間が多くなります。そのトレードオフであると考えるといいのかも知れません。ういうモデルでプロジェクトを考えてみると、「アジャイルと規律」なんかで言われていることと一致するのかも。

最低限の時間を定期的に投資すると決めてしまうのです。[...] その時問すべてが等しく生産的になるとは限りませんが、定間的に予定に組み込むことで、長い目で見るとうまくいくでしょう。 (p.151)

長い目でみるとうまくいく、っていうのは、安心と自信を与えてくれる。おそれずにやっていこう。

しかし「最初からうまくいく」ことが大切なのでは なく、「最終的にうまくいった」ということが重要なのです。 (p.184)

これは斬新。いままで失敗は悪だと思い込んでいた。最終的にうまくいく過程で、失敗できるようリスクを最小化すればよいのだ。一発成功を狙うほうがはるかにリスクが高い。

と、まあ、Andy Hunt が書いているということもあって、最終的にはアジャイルな話になってきました。それでも、長期的な学習や、そのメタ認知の視点のヒントがありました。実践してうまくいったらものがあれば、また、どこかで書きます。

村上龍 / ラッフルズホテル

本棚を整理していたら、村上龍の「ラッフルズホテル」なる小説が出てきました。あーこれ読んでなかったわーと思って、読んでみたら、読んだことある本だった。後半まで気づきませんでした。

危機が起こったときに備える - エドワード・ヨードン 「デスマーチ第2版」

デスマーチが起こってから、どう対処するか、を、主にマネージャの視点から書かれています。デスマーチが起こることが前提になっているのが、他のマネジメント本と違うところです。プロジェクトマネジメントは計画段階でかくあるべし、と正論を言われても、「いや、もう、プロジェクトはじまっちゃってるし！」ってなりますからね。

しかし、我々が憤れ親しんでき たプロセスに新たにプロセスを追加したり、プロセスを改訂したりする必 要がある新技術を導人するのはずっと難しい。 (p.244)

そうなんだよなぁ。慣れたところから、慣れないところに行くときは、いつもそういうことが起こる。最初から、新しい方法だったらまったく問題は起こらないのに。

納期に遅れたり、予算を大幅に超過したり、プログラマを燃え尽きさせてしまうプロジェクト・マネ ジャーに、プロジェクトを次々と「破滅」させる機会を与えてはどうか？要するに、なぜ、プロジェクト・マネジャーもメンバーも、実際の経験に 備えてデスマーチ・プロジェクトの経験をシミュレートしようとしないの か？ (p.252)

デスマーチの練習、っていいなぁ。デスマーチを避けることは大事なんだけど、現実にそれに近い状態が起きるのであれば、それに備えることは意味のあることであるなぁと思いました。爆弾処理班とか、テロ対策特殊部隊とかって、そういう人たちだもんなぁ、などとも。

# 別に火消しになりたいわけでも、管理に意味が無いと主張しているわけでもありません、念のため。