あるいは Kanazawa.rb meetup #76 に行ってきたよ の話。
割といつも言ってることと同じなんだけど、まぁせっかくなので。
エンジニアが集まると
なんでそんなものになってしまったのか？
みたいな話で割と盛り上がれるわけですよ。
それ要る!?
みたいなやつ。
そういうのを避けるために自分は「インフラは持つべきではない、全部PaaSかフルマネージドにしろ」という選択を数年前にしたんだけど、最近は「バックオフィス業務で独自に開発はすべきでない、そもそも開発を外部に依頼するのは難しいし、独自に作らなきゃいけないものなんてほとんどない」と思っている。
で、これって、結局「余計な失敗をしない」ということなのだろうなぁと思っている。
何か作れば、何かやれば、それには失敗がつきものだ。避けようがない。そしてその失敗をなくすためには実はかなり大きな、時に測定不能なコストが発生する。
なぜか人は何かをやる時にこの「余計な失敗を抑え込むためのコスト」を甘く見積もり、結果として恒常的にリソース不足になっていたりする。そして自分がやってきた自動化は要するにこれらをなくすためのものなんだなぁと思うようになってきた。deploy の自動化、provisioning の自動化、テストの自動化。1
これらはそれ単体では実はそんなに価値はない。でもここで余計な失敗をしないことで何回でも安心して実行できる。上記の何かを「実行する」ということは「何かを新しく作ったり変更したりしている」ということだ。
その「何かを新しく作ったり変更した」結果、それが失敗だったり成功だったりするかもしれない。例えば思ったより全然便利じゃなかったり、思ったより面白くなかったり、そういうことだ。しかし成功だった場合はそれが「価値」になる。この「価値」を生んだり大きくしていくことが事業としての「開発」において最も大切なことだが、その「価値」を見つけるのは実は容易なことではない。
2C なら Consumer, Customer が喜んで使ってくれる、遊んでくれる何かが「成功」だが、それを見つけるには何回も何回もチャレンジが必要だ。そのためには新機能はすぐに追加できてすぐに取り外せた方がよい。
2B なら目先の課題がただの全体の歪みの一部が表出された何かでしかない場合がよくある。本当は全体の歪みの原因を見つけるまではやはり同じように何回でも変更できるようにしたり、まずは既存のシステムに乗せて「実際にやってみることで課題を洗い出す」ということが必要だったりする。既存のシステムに載せるということは、その部分で「開発そのものの失敗をなくし」「本当の要件の抽出の失敗をなくす」ことである。
やってみたこともないのに何が必要で何が不要かを決めるのは実はとてつもなく高度なことで、それそこ失敗して当然である。だからその失敗を許容するために、その他の要らぬ失敗を排除することが大切になる。
で。
最近よく思うのは、こういう話、実際に作り手になったことがない人には通じないんだよなぁということ。結果として、「いやいや、できた結果ダメだったってなったら単に余計なコストが上乗せになりますよ？」という話、全然想像できないどころか、相手の話を真剣に聞いていない場合は想像する必要すら感じてなかったりする。
でもさ、余計な開発は余計なランニングコストを生みますよ。見て見ぬふりしたいかもしれないけど、作っちゃったらもうゼロ円は無理なんですよ。それよりはアリモノを Subscription で使った方が結果安かったりするわけです。
ということで、これからも仕事では「価値を生まないモノ、価値を生まない作業」にコストを掛けすぎてはいけない、それが「本当に価値を生むモノや価値を生む行為」を阻害しないようにすることを意識して、コードを書いたり書かなかったりしていこうと思いましたとさ。
ま、当たり前の話ですね。
あの頃は、単に自分を守るために必死にやっていたけれど。 ↩
※ 2010年3月現在の話。
思い出したように Pear パッケージの話を書くけど、個人的に
どうして PHPer は Pear パッケージを積極的に利用しないのか理解できない
状態が続いている。
これは pear.php.net channel のパッケージをインストールして使うという意味じゃなくて、
せっかく作ったライブラリをなぜ Pear パッケージ化しないのか
という意味ね。分かりやすい例は
spyc - Project Hosting on Google Code
じゃないかな。
これはたぶん PHP でいちばん有名な YAML ライブラリなんだけど、このライブラリは Pear パッケージになっていないので、いろんなプロジェクトで勝手に収録している状態になっている。ライセンス的に問題ないなら別にいいんじゃないの？と思うかもしれないけど、違う。
いろんなライブラリ、いろんなフレームワークが個別に spyc.php を収録すると、require 可能な spyc.php が複数存在する
ことになってしまう。これ、
require_once による再読み込み防止機能が利かず、Cannot redeclare class という Fatal Error が起きやすくなる
というアブナイ状態なのだ。Fatal Error がひとたび起きたらアプリを実行することはできない。つまり画面は真っ白さ。怖いでしょ？
勝手収録するなら spyc.php 本体を直接呼ばせず、代わりに require するためのファイルを用意してその中で
if ( !class_exists( 'Spyc' ) ) {
require '/path/to/spyc.php';
}
みたいに気をつけて書かなきゃいけなくなる。まぁ PHP らしいっちゃ PHP らしいんだけど、これってけっきょく紳士協定だから、守ってないアプリがあればすぐに破綻するのです。
あるいはもう Pear パッケージ化しないライブラリは最初から
if ( !class_exists( 'Klass' ) ) {
class Klass {
...
}
}
で定義するよう義務づけるとか？ 義務って書いちゃうと反感買うかな。優しさって言えばいい？
でも本当は、Pear パッケージ化してちゃんとインストール先のパスを意識してあればこんなのは問題でもなんでもない。PHPer が人力で頑張るのが好きなのは分かるけど、自分はこんなところで頑張りたくないんだよねぇ。
10年を機会に振り返りを行うなんてのは非常にありきたりで面白くはないのだけれど、ふと Twitter に流れてきた [エディタ派閥まとめサイト
10年前の自分は、えーとコの業界的には人から譲ってもらった ThinkPad 530(DX2 50MHz, 20MB/1GB)の上に Win95
- command.com + KI-Shell + Unix-like tools + Vz という環境を作って遊んでいた時期のような気がする2。この時点で恐ろしく時代錯誤な環境ではあったのだが、何しろ Windows を動かすだけでやっとの機械。メーラは電八。ブラウザは Netscape. ちょうど初めてのホームページとやらを作ったのもこの時期だ。意外に遅い。なぜかというとそれまで WWW を GUI で眺められる「自分の機械」がなかったからだったように思う。環境がなかったわけじゃないんだけど、やはり自分のノート PC で自分の好きな時間、好きな場所で作業できることが最も大事だったんだと思う。（ノートをメインマシンにしたのはこの数年前から。）その後はしばらく非力なマシンでどこまでやれるかをテーマにし、Lynx やら何やら、先人の知恵の結晶を数年遅れで追いかけて行くことになる。ただし時間はあったけど頭はよくなかったのでそれで何を得、何をアウトプットしたかと言われると耳が痛い。
コの話から離れるといわゆるお師匠さんと出会った頃で、少しは明るい兆しが見え始めた時期。今の自分を形作った友人に出会うのはもう少し先の話になる3。
その後明るい話ばかりになるのかというとまったくそんなことはなく、平凡な自分は時間をいたずらに消費しただけでたいした成果も出せないまま今に至ってしまっているが、それなりに平静を保てているのでたぶんそれなりに幸せなのだろう。とりあえず身体の調子は10年前よりはいい4し、むかつくことも多々あるが、根本的なやる気を失っていないのはかなり大きな救いだ。
ただ、これからの10年をロクに思い描くことができないのは恐らく幸せではないのだろうな。妄想はできるが、自分の妄想が実現したことなどほとんどないし。ということは課題は妄想と現実の間に橋を架けることか。あるいは橋の設計が可能かどうかを考えることか。
とりあえず nadoka どうするよ、オレ。
なんてネタがあるので出てない情報を知ってる人はツッコんであげよう。
ほぼすべて同意なんだけど、
つまり、僕がニートという言葉に何かもやもやしたものを感じていた理由というのは、この言葉自体が「いい年した男性は結婚して働いているべきだ」という社会的偏見をたっぷりと含んでいるからじゃないのか。
の部分は、「それは自分の中のなんらかの被害者意識がそう思わせている」と思っている。つまり、NIEET という言葉が偏見を含んでいるのではなく、NIEET という言葉に対する自分自身の偏見が、周囲の偏見という形で読み手の中に表れているだけ。簡単に言えば「上の世代はガムシャラに頑張るだけでよかったけど今はそうじゃねーんだよ」とか「都合が悪くなったら絞れるところから絞り取ろうってのかコノヤロウ」みたいな感情が、NIEET という言葉に偏見が含まれていると錯覚させているんじゃないかなと思う。
この言葉の成立過程を勉強したわけじゃないから憶測だけど、この言葉自体は「労働者人口の中に占める非労働者」を手っ取り早く表現しているだけのように見える。たぶん経済を調査、研究している人の中で生まれたんじゃないだろうか。
ただ NIEET という言葉に対する負の偏見をこの人独自のものとは思わない。自分も同じことを感じている。むしろそういったドロドロした感情は自分の方が強いんじゃないかと思う。
学力低下、理科も深刻 中２が６位、小４は３位に (asahi.com)
経済協力開発機構（ＯＥＣＤ）の調査でも学力低下が明らかになったばかり。文部科学省は「平均得点が下がったという事実を厳粛に受け止め、実効ある対策を取りたい」としている。
まー危機感を覚えるのはいいんですけど、もっと問題なのは
２教科の勉強が「楽しい」と答えた子どもは、前回に続き世界最低レベルだった。
じゃないのかなぁ？
むしろこんなに勉強を面白くないと思っているのにも関わらずまだ世界と対等の学力の高さを維持できているのは奇跡的と思えるんだけど。この状況で「下がる」のは当然であって、やはり受け止めるべきは「下がったこと」じゃなくて「日本の子どもは学校の勉強がとてもきらい」「海外では学校の勉強は日本ほどきらわれていない」ということじゃないのかなぁ。勉強を「面白くない」「きらい」と思わせたまま子どもを様々な「門」で振り落とそうとする、あるいは「振り落とされたらやばいと思わせる」からおかしなことになるんちゃいますか。そりゃーストレス感じますよ。そりゃーキレますよ。1
マスコミの方々にはこの辺の偉い人の意識を引き出してほしい。
もうキレるキレないって話は古いのかな？ ↩
がほしい。処理を書きながらクラスに行ったり戻ってきたりするやり方でとりあえず書けたが、できあがって嬉しいってだけでかなり効率は悪かった。
で、今度はクラスをもっと楽に作れないかな、と考えたわけです。UML のツールの Dia は Win32 だとバシバシ死ぬのでこれまた困りもの。X の設定なんか分かんねーし。本を読むかなぁ。開発と UML の本は一応持ってはいるんだが。でもちょっとこれ読んでる余裕は今ないしなぁ。
うーん。
自分の考えていることをインスピや文書で整理するノウハウは身についていると思っているが、開発系の設計能力はかなり貧弱ですなぁ。
[2007-07-31 追記]あとから検索で飛んできた人と昔の自分のためにツッコミ。
「設計」能力だけ抜き出して磨くのはたぶん無理だと思う。少なくとも上で書いているような「クラス」は実装レベルのクラスであり、これは実装してみないと分からない部分がまず間違いなく残る。設計上はこっちの方がきれいなように見える1が、実装上は言語の機能やパフォーマンスなど様々な制約でこっちの方がよい、という事態はよく起きる。2
図を書く練習で図の扱いはうまくなると思うが、実際の設計は結局のところ動くものをどれだけ書くか、うまくできているコードやドキュメントをどれだけ読むかという泥臭い方法で学ぶのがいちばん確実だと思う。あるいは先輩などに教えてもらったりすることは可能だが、文章も絵も自分でかいてみることなしにうまくなることがないように、プログラムもシステム設計も自分でやってみて失敗することなしには恐らく上達しない。
プログラム言語がどれだけ楽に習得できますよと言われても、UML がどれだけ共通語としてコミュニケーションを促進しますよと言われても、それだけで出来上がるものがよくなることはないので、安心してダメクラスを作って怒られたり反省したりすればいい。
もう一つ。自分でコード「も」書く人間にとっては、恐らく設計のノウハウよりも変更に強いコードの書き方のノウハウの方が大切である。3だからまずコードを変更するテクニックを学ぶべきである。wrapper を書いてインターフェイスを変更する、あるいはインターフェイスを変えずにリファクタリングする、長いブロックを短くする、分かりにくい変数名を付け替える、これらの地道な積み重ねはのちに効いてくるはずである。そして小さいコード、オブジェクト指向、テストの自動化とリファクタリングについて学び、絶対にこれらを実践すべきだ4。ダメなコードは勇気を持って捨てることも大切。
plat online に書こうと思ったら会員にならないと書けないことが判明。まー当然か。
急に面倒くさくなってきたので説教講座の方に載せようかななどと思い始める。最近また説教講座の改修を進めているのだが、いつになるのかメドが立ってないのでちょっとつらいかなぁと思わなくもない。ついでに Space Saver のレビューも書いちゃおうか、などと構想だけが膨らんでいく。
やっぱりポインタの動作が実に半端になってしまう。標準のドライバで使うのでマウスを使う場合は軽すぎ、ポインタだと重すぎる。特にピクセル単位の動きに慣れた TrackPoint 使いにはこの半端な動きはけっこうつらい。ウィンドウ位置の微妙な調整にはほとんど使い物にならない。
Home, End が邪魔。カーソルキーの辺りが急に狭くなりすぎるので余計にそう感じる。通常のキーがフルキーボード並みなのにここだけ急に小さいので、指が戸惑う。慣れるだろうが、ちょっと差がでかすぎる気がする。
泣けるという前評判とは裏腹に、まったくそれっぽい感じがしなかった。むしろアメリカっぽい、からっとした明るさがすごく目についた。というか単純に面白かったって感じだ。ほのぼのとした明るい話だと思う。「かわいい子には旅をさせよ」ということですな。