生きるということは自己表現の連続なのかなと思うことがある。
ある人は文章で、ある人は絵で、ある人は会話で、ある人は動作・たたずまいで、ある人は仕事で、ある人は人間関係・コミュニティで、ある人はプログラミングで。
何のご縁なのか、合気道は僕にとって表現方法の一つになった。
そして、もう一つ幼いころから頭に描き続けて歳を経て出会ったプログラミング、これを大事にしたいなと思う。
どうも、自分が尊敬する人々（アンドリュー・ハント、デビッド・トーマス、ジョエル・スポルスキ、カル・ヘンダーソン、ポール・グラハム、マーチン・ファウラー、トム・デマルコ、ティモシー・リスター、エド・ヨードン、ラリー・ウォール、etc）はみんなプログラミングを重視している。少なくとも自分の手を動かすことのインパクトを過小評価していない。みな書き続けている。マネジメントの大切さを訴え、そのノウハウを書いていても、同時にプログラミングに時間を投入することを忘れていない。プログラムを読み、書く力はたぶんソフトウェア開発の基礎体力、土台にあるものだし、それ自体広大な問題空間を持つものだと思う。プログラミングをしていく中で、設計スキルが洗練され、要件定義スキルが洗練され、プロジェクトマネジメントスキルが洗練されていくことは「ありえる」と僕は思っている。そうじゃないと彼らの経歴と現在の素晴らしい活躍を説明できない。逆を考えてみる。プログラミングができなければ、良いソフトウェアは作れない。うん、やっぱり自明だ。
ソフトウェアを最終的に形にするのはプログラミングで、最終アウトプットはプログラム。これは自明なわけだから、プログラミングを重視することはイコールアウトプット重視ということで、価値あるソフトウェアを作るという観点から最短距離を走ることになる。もちろん、設計がいらないわけじゃない、要件定義がいらないわけじゃない、マネジメントがいらないわけじゃない、企画がいらないわけじゃない。でも、それは考え方としてはプログラマが設計をやり、要件定義をやり、マネジメントをやり、企画をやるという考え方にするべきだと思っている。プログラマがプログラミング意外も価値あるソフトウェアを作るために必要なあれこれがあるから、それをやる。それが正しいんじゃないかと感じてしょうがない。
だから自分は自分のことをプログラマと称したいし、そのために、毎日必ずプログラミングに時間をとる。
道場の運営や、技の解析も確かに大事だけど、だからといって実際に稽古することをしない合気道家、武道家はいない。これは至極当たり前のことだ。そうなってしまったら終わりだ。こんな当たり前のことが、ソフトウェア開発の現場では見落とされている。
ふぅー。やっとアナウンスできる状態にできた。
寝ずに聞け！ 第７回放送です。
「寝ずに聞け！」 第七回 2009年06月 - 寝ずに聞け！
http://www.nezunikike.net/2009/06/bcast-7th.html
次回ゲストを放送内で募集しています。
フォームから応募頂いた方、先着一名様がゲストです。
感想のところに「ゲスト希望」と一言書いてもらえればＯＫ。
Skypeによるリモート参加もＯＫです。遠方の方も気軽に応募すればよいと思います（笑
まぁ、いっても気軽には無理だろうと思ってますけどね、僕らも＾＾
放送の中でも言ってますが、もし誰も応募がなくても僕らは「もう、すごかった応募が。大変」
って言い張りますから。ゲストも無理矢理用意しますから。きっと＾＾；
あ、普通に感想だけのもすっごく嬉しいので、是非是非。
ほんとに、ここ一週間程前からPCのキーボードのカーソルの左移動のキーが反応しなくなって、えらい難儀してます。
前に戻って修正したいときは、マウスでクリックしなおさないといけないという苦行。この状態でMTのテンプレートをいじるのは人間の器を試されますね。
今使っているノートパソもだいぶ長く働いてくれているしなぁ。そろそろ引退かもしれない。
Joel on Softwareで有名なジョエル・テスト。
Joel on Software - ジョエル・テスト
http://japanese.joelonsoftware.com/Articles/TheJoelTest.html
- ソース管理システムを使っているか？
- １オペレーションでビルドを行えるか？
- 毎日ビルドを行うか？
- 障害票データベースを持っているか？
- 新しいコードを書くまえにバグを修正するか？
- 更新可能なスケジュール表を持っているか？
- 仕様書を持っているか？
- プログラマは静かな労働環境にあるか？
- 買える範囲で一番良い開発ツールを使っているか？
- テスト担当者はいるか？
- プログラマを採用するときにコードを書かせるか？
- 「廊下での使い勝手テスト」を行っているか？
ジョエル発案の簡単に開発組織の質をチェックできるテストで、Yes/Noで回答して10点以下ならその組織は問題があるという話。もちろん、これが全てじゃないけれど－たとえば6番とか（これは顧客の性質に寄るところも多いだろうから）、10番とか（チームメンバーが10名に満たない場合にテスト専任はコスト面で厳しいだろう。Joelの理屈はわかるが上を説得できませぬ）－愚直に達成していこうと思っている。
ところで、驚いたのは
いいアジャイルと悪いアジャイル
http://www.aoky.net/articles/steve_yegge/good_agile_bad_agile.htm
の記事。
Googleでは
- ガントチャートや、日/タスク/担当者が書かれたスプレッドシートや、そのほか何であれ、目に見えるプロジェクト管理を示すものは見たことがない。
らしい。衝撃だ。その理由はつまり、
作っているソフトウェアについて前もってアナウンスする習慣があるなら、一般の人々はそれがいつ頃になるのかを知りたいと思い、それは日付ということにな る。私の考えでは、これがGoogleが前もってアナウンスをしないことが多い理由なのだ。いい料理を手早く作ることはできず、赤ちゃんを手早く産むこと はできず、そしてソフトウェア開発を手早くやることはできないということを彼らは知っているのだ。
これらの3つの例外が日程によって駆動されているのでないなら、何が彼らを駆動しているのか? ある部分では、それは創造への欲求であり、何かを作りたいという欲求だ。すぐれたエンジニアがみんな持っているものだ。
(中略）
違うのは、Googleは物事にどれくらいかかるか分っていると主張するほどばかでも傲慢でもないということだ。
ということらしい。うん、確かに、自分と自然の摂理に嘘をつかない生き方を考えればこうなるね。
未来は予測できないということは賢い子は幼稚園児ぐらいから自覚する自明の定理なわけだけども、これを諦念とともに受け入れて適応すべきか、戦いをいどむべきか。どちらが大人な態度なんだろうか。
「スケジュール？そんなもんいらねーよ。俺を駆動するのは俺自身のモチベーションだけだ！」
なーんて言い出したら、ご飯が食べれなくなっちゃう人がいっぱい出てくるからなかなか大声ではいえないわね。
非難轟々でしょうなぁ、きっと。
マネジメントって本質的に、上手くできない、稼動する気のない人達、その件に興味のない人達をなんとかその気にさせるってことだと思うので、そんな人がいないなら、または充分に少ないなら、その組織ではマネジメントっていらないんだろうな。どこかでマイナス面を解消するためのコストが解消によって得られるコストを上まるポイントがあり、ここを越えてまで管理するのはナンセンスだろう。だから、やる気のある人を雇うのはマネジメントコストを抑えられるのでお得って話になる。逆に言えば、「いい人材さえいえば！！」という渇望は、マネジメントの敗北ともいえる。
ただ、ここのロジックの穴は、人のステータスを静的にとらえてるってところで、人のやる気だの能力だのは変化するので、やる気のない人というのが定常的にあるというのも実は危うい発想なんだよな。正確にはやる気のある時もない時もあるし、環境にも多分にそれは影響されるってことで、その辺りに実はマネジメントの骨法があるような気がする。マネジメントはだから、何かを作れば（仕組、ガイドライン、懲罰、報償、etc・・・）それで終わりというものではなくて、家事のように、毎日し続ける、終わりのないメンテナンスタスクの総称なんだろう。だから、マネジメントがいらなくなることはない。家事がいらなくならないように。でも、同時に家事はできれば最小化できれば、楽だよね。
ここ２、３日の話を箇条書きでメモしとく。細かいところはまた後で。
・始業が9時からなので、6時半に家を出てもあまり余裕がない罠。ので、仕方なく最近４時起きが定着気味。すると、午後４時過ぎにめっさ眠くなる。18時過ぎると頭が完全に使い物にならない。だれか、FRISK１年分ちょうだい（笑
・カミサンとの交換日記計画発動。ラジオでも話しているのだが、ラジオをフォームをセットしてからちゃんとアナウンスしたいなーなどと考えている内に月日は流れ、カミサンに言い出すタイミングもつかめぬままという始末。思い切ってメールで打診（笑
・朝の時間が足りず、小説も面白いので（←おぃ）、ラジオの公開がめっさ遅延する。フォームはA-Form使おうと思ってます。さくっといれろよ、自分。今回、ゲスト募集しているので、フォームがないとアレなのです。
・土曜はアウトプット勉強会。「V字回復の経営」が課題本。ざーさんとはじめてお会いし、そのファシリテートスタイルに学ぶべき点が多く感じる。あまり多くを話されるタイプではないが、淡々とまとめていて、ざーさんタイプのファシリテートなら自分もできるかなと思った。ただし、人数が１０名越えなければ。やっぱり、8～10名ぐらいの規模が一番楽しい。みんなそれなりにしゃべれるし、和気藹々とする。とても楽しかった。勉強会の細かい感想は別エントリーに書くことにするけど、一つだけ。自分はタスクフォースには入りたくないなぁ、しんどそうだし（笑 したらば、mixiで、zeemoreさんが似たようなこと書いてて著しく共感しました。そうですよねー、経営者マインドを持った従業員って、考え方によっては経営側にとって非常に都合のいい存在ともいえますよね。従業員マインドを持った（というか理解できる）経営者も大切だと思うのだけど、あまり言われないよなぁ。
・合気道の話。剣杖が２週間ほど前からスタート。日曜の稽古で、杖を使った転身の動きで激はまる。理屈がわからない。ひじの内側が若干はる、それが受けていて大事っていうのはわかるのだけど、そっからどうして身体が動くときと動かないときがあるのかわからない。これ読んでるひと、さっぱりわかんないと思うけど許して（笑 自分メモだから、ここは完全に。力学的に解析したくてしょうがない今日このごろ。つーか、やってみよ。
エンジニアとして伸びて行くために、何を、いつまでに、どのようにやっていくか。
最近、よく考える。
今までは、あまり体系的な知識を入れずに、よく言えば臨機応変に柔軟に、悪く言えばいい加減にやってきた。
あたられた環境下で期待されたパフォーマンスを付け焼刃でもなんででもなんとか出していくということに関しては、ずいぶんやってきたように思う。けれど、この辺りで一度、体系的な知識を入れて、自分の経験もその体系の中に位置づけて整理するのがいいのかなと感じている。いまはそういう時期なんだろうなと。
だから、具体的には、応用技術者試験、プロジェクトマネージャ（またはPMP（Project Management Professional））の合格を目指して勉強してみようと思ってる。資格自体にそれほど意味があるとは思っていないけれど、体系的に知識を身につけて整理するには資格勉強を利用するのが向いてる。そう思うので。
昨日、エコピのオンラインMtgに出てしみじみ思ったのは、社外のデキる人とつながり続けていないとダメだっていうこと。
もちろん、社内にもできる人はいる。その人達から学ぶべきことは沢山あって、どきどきわくわくしている。
ただ、組織の文化というものがどうしてもあって、それは中にいるとわからない。異文化と接触して、はじめて、良いことも、悪いことも見えてくる。自分のおかれた前提条件が見えてくる。環境のバイアス、それも負のバイアスに対抗するためには、外部のデキる人との接触がかかせない。そう強く感じる。
合気道のＹさんが「社内でいくら評価されててもダメ。外でいかに評価されて、そしてコラボレーションできるかだ」みたいなことを仰るのだけど、ほんとにそうだと思う。井の中の蛙になっちゃいけない。
