MySQLはやはり手軽だ。システムとしてシンプルだし何より軽い。これが、Webアプリケーションの後ろで手軽に動かすのに好都合(現場の部門等でとりあえずデータベースサーバでっち上げちゃえという場合、マシンパワーが貧弱なものしかない、というのが現実だ。え？うちの会社だけ？）、というのがMySQLに目を向けさせる一番の理由だろう。でも、MySQLって最近のバージョンだと、トランザクションサポートしたんだっけ？今までは、これがネックで僕はRDBが必要になった場合は、PostgreSQL派でした。トランザクションが実装されたのであれば一考の価値ありだと思います。
今やってるプロジェクトで設計レビューを実施したのだが、レビュー会場に向かう前に、上司から
「レビューでは、優しく対応してやってくれ。そうでないとボスのところにクレームが来てるんだ。頼むよ。」
と釘をさされた。
「それは手を抜けってことですか? 他社の一線で活躍するソフトウェアエンジニアさんをプロのエンジニアとしてのプライドをもった人として扱うな。新人のように丁寧に扱え、ってことですか？それって相手をバカにしてません？」と聞き返すと、
「いやいつも僕と対応する時のようにやさしく言葉を選んでくれればいいだけだよ」
「ああ、エンジニアとしてではなくド素人だとして対応しないといけない、ってことですね。だったら、僕は出ない方がいいですよね。僕は出なくてもいいでしょ?」
「いや、出て欲しい。」
「なんじゃそりゃ？」
「出て、ちゃんと気づいたところを指摘して欲しい。いてくれないと僕が不安なんだ」
「手を抜け、って言っておきながら、結果としてmoneyも了承したレベルのクオリティのアウトプットを期待してるだけじゃん。言ってること分からないですよ。どうせ僕が参加しても進捗阻害要因にしかならないですよ」
当然ながらレビューではいろいろと怪しいところというか、「何考えてんだ？」ってなところが見つかり結果的にいろいろ指摘した。
「なんで、わざわざ、ちゃんと決まってる仕様をわざわざ崩して曖昧な表現に書き換えるんだ? そんなことしてるから後々問題が見つかるんだ。何考えてんだよ？」とか、「てめえで判断できねえんだったら、できる奴連れて来い」とか。(言葉尻はもう少し丁寧です。)
その後の休憩時間中に、若い同僚からご指摘を頂いた。
「moneyさん、リトルリーグ相手に大リーグが剛速球投げてはいけません。相手が打てないのはもちろんのこと、味方のキャッチャーすら取れないじゃないですか。」
「いや、おれは、少なくともソフトウェアを作る、ということで飯を食ってるプロ同士だから、お互いが同じプロ野球のマウンドに立ってると考えている。だから、自分のベストの球を投げないと、相手に対して失礼だろ。」
「それ、間違ってます。じゃ、moneyさんが仮にプロ野球だとしましょう。相手は高校野球ですらありません。リトルリーグです。これは、親善試合なんです。ガチンコじゃない。だから相手が打ち返せるレベルの球を投げてあげないといけないんです。moneyさんの指摘したことは全て正論です。正しいです。本当はそうあるべきです。でも、誰も分かってないですよ。うちの連中も相手側も。誰も理解できてないです。だからどうせ、まともな試合になんかならないんです。手を抜かなきゃだめ。どうせ、いくらがんばっても相手の100％のレベルにしか到達できないんです。ここでプロ野球レベルの剛速球を投げることになんの意味もない。それを取り入れて成長することすらできないレベルです。大人気ないだけ。その辺、ちゃんと分かってください。」
つまり、別に誰もちゃんとレビューすることを求めているのではなくて、結果としてレビューを実施した記録が残っていればいいだけなんだ。僕は勘違いしてました。レビューとして実りあるものにすべきだと思ってました。ソフトウェア開発ごっこができればいいんですね。とても反省してます。。。。
＃いいのか？これで。 てｔいいんだろうなぁ、きっと。
あなたが最初にインストールする10のプログラムは何? コメント、トラックバックどうぞ。
面白い！順不同ですが。
1. Lhasa (Archiver)
2. Firefox (Browser)
3. cygwin (shell)
4. Meadow (Editor)
5. JRE (Java Runtime)
6. smartdoc (Document Formatter)
7. AltIME(キーボードカスタマイズ)
8. Acrobat Reader (PDF Viewer)
9. MSN / Yahoo Messagner( IM )
10. FFFTP (FTPクライアント）
-----------------------------------
番外編：
11. SSH(SSH, SFTPクライアント)
12. DiCE(Dynamic DNSクライアント)
13. TeX関係、WinShell(Document Formatter)
ってな感じかな?偏りすぎてるな。改めてこうしてみると、エンジニアじゃなくなってるな...つーか、Windowｓ上ではコードは書かない主義なので(と、逃げておく)。
あ、あと最近だと、iTunes はジュークボックスとして必須。
「携帯番号持ち運び制度」ってなんだ？と思ったら、ナンバーポータビリティのことか。いや、確かに少し考えれば分かるんだけど、しっくりこないなぁ。せめて、キャリア独立番号精度とか。もっとわからんか。
お誘いいただいたのでサブスクライブしました。機能的には、Orkutとほぼ同じ。友達を集めていくのも、グループ作ったり、掲示板があったり、など。でも、人と人とのつながりを可視化するという点で、Ｏｒｋｕｔはネットワークモデルなんだけど、Ｇｒｅｅ.jpはテーブルモデルという違いがある、ような気がした。なんとなく、だけど。あと、学校の卒業生つながりがとても目につく。結局はこうなるのか。 しばらく遊んでみようと思います。 invite欲しい方は個人的に連絡くださいまし。
見ましたねぇ、電子立国。日本の半導体メーカの工場とか、シリコンバレー発祥のフェアチャイルド社の話とか。その後、LDで全部そろえちゃったし。この以前社内Webサイト向けに書いてたコラムでもコンピュータのハードウェア向け教材としても指定したこともある。でも、二匹目のどぜうを狙ったソフトウェア編はつまらんかった。唯一記憶に残ってるのは、インタビューを受けているスティーブウォズニャックの後ろで動いていたMacの画面のスミにあったゴミ箱が、大きなゴミ袋になってたことだったりする。
イントロの翻訳版を公開してから多くの方にアクセスいただいています。きっと需要があるのでしょう。結構話題にはのぼるのに、日本語ドキュメントあんまりないし。
ってことで、Springフレームワークへの入門手順。
1. Introducing to the Spring Fremeworkに眼を通す。
2. Spring Padにも当然当たっておく
3. koichikさんによるSpringフレームワーク入門ライブ版を追いかけながら手を動かしてみる。
4. 必要に応じて、Spring Framework Reference Documentationに当たる。
なんて感じで進めていくのがよろしいのではないかと。
あとは、日本語リファレンスなんだけど、こっちは時間ください。なんせ、量多いし。
Spring Frameworkのリファレンスを眺めてたら、「Dependency Injection」という言葉か結構使われている。元々Springって「Inversion of Control(IoC)」という言葉を使ってたはずで、これをオレはそれを「Dependency Injection」と呼ぶねと言ったのはマーチンファウラーだったはず。 ひょっとしてロッド・ジョンソンもこのファウラーのアーティクルを読んで、呼び方を変えたんだろうか?
と思ったら、ちゃんとこのリファレンスに、マーチンと話して、名前を変えることにした、みたいなことが書いてあった。 やっぱり皆さん、仕事が早い。
あなたは...
明治維新の道を開いた日本史上最大のヒーロー
坂本龍馬
応用の天才にして優柔不断話し上手の聞き上手。どんな相手をも饒舌にさせてしまう乗せ上手。やや独創性に欠けますが、相手の長所やアイデアを次々引き出し、それをヒントに新しいものを提案したり、コーディネートするのが得意。薩長同盟や体制奉還論も、龍馬の発案でありません。日本初の総合商社・亀山社中（のちの海援隊）も設立。組織も資金力も持たない龍馬は、人の心を読む鋭い洞察力で人間関係をとりもつ潤滑剤の役割を果たしました。
頭脳・知性
話がうまく、自然とよく動く二枚の舌で相手をいい気分にさせる器用さがある。交渉ごとに長ける。既存の材料にちょっと味付けして、新しいものに変えていくのが得意。センス
なにごとにも物おじせず、「なんとかなるさ」とどんなピンチも乗り越えていく図太い神経の持ち主。これだけは絶対に譲れないみたいな頑固な一面もあるが、ふだんは鈍いフリをしている。感情
初対面の人には愛想が良く、平和的・友好的態度で接するので第一印象のポイントはかなり高い。相手の懐深く飛び込んでいけるから、安心感や親しみを与える。ホントは内弁慶。外見・言葉
主義主張に一貫性がないのは、人の影響を受けやすいから。天然ボケも少し入っている。メモはとらないし、とってもメモ用紙をなくしてしまう。なのに、笑って許されてしまう得な人。行動
大器晩成を予感させる逸材。熟考してから行動する慎重派だが、面倒なことが大嫌いなので案外ドタキャンも多い。名より実を取るタイプ。おいしいポジションにこだわりがある。
うーん、合ってるのか合ってないのかよーわからん。少なくとも、「メモを取らん」とか「優柔不断」とか「なんとかなるさ」とか「鈍い」とか単語的には合ってるような気はするが...
ロッドジョンソン氏ご本人からも快諾いただきましたので、Introducing the Spring Framework@TheServerSideの翻訳を公開します。いつものようにコメント、感想、励まし、誤訳指摘、投げ銭(未対応)等大歓迎でございます。
では、お楽しみください。
Spring Frameworkの紹介[HTML版]
Spring Frameworの紹介[PDF版]
仕様書の是非がテーマ。なんか、僕からしたら仕様書というものに対して真面目に取り組みすぎてるような気がする。もちろん、仕様書というものをないがしろにしろ、と言ってるわけではない。あくまでも仕様書は仕様書でしかない、ということだ。
この人は、かなりプログラミング技術に長けたいわば職人的なタイプなんだろう。仕様書作成が無駄だと言い切り、社内会議をくだらないと切り捨てる。こういう人はおそらくプロジェクトとしてはお荷物なんだよね。仕様書とか会議の本質が、コミュニケーションにある、ということが理解できていない。もちろん、これを作れば完璧です、なんて仕様書なんてありえないし、そういった仕様書を作ることも不可能だ。別に100％の完璧な仕様書なんてものを目指す必要はない。所詮、仕様なんてころころ変わるんだ。8割方できてれば十分なんではないだろうか。その辺の「いい塩梅」具合を調整するのが腕ってもんでしょう。（前略）それになにより、無駄な仕様書作成やらくだらない社内会議などは貴重な時間を浪費させ「楽しいものづくり」を楽しくないものにしている。これらは無能な管理職が、自分が仕事をしたつもりになって自己満足に浸るだけの道具に過ぎず、本来は必要のないもの。
この人もおそらくモノを作る側の立場にたったｋとがないからこんなノンキなことを言ってられるのでしょう。本題からそれますが、「無駄な仕様書」など存在しません。無駄だと思うのは、仕様書としての機能を満たしていないからではないでしょうか。仕様書を作成することではなく、「仕様書作成の仕方」に問題があるように思われます。
さて、仕様書というとすごくあいまい(だと思う）ので、分けて考えたい。まずは、発注者側のウィルを書いたもの、これをここでは「要求記述」と呼ぼう。 それに対し、その要求記述に記述されたものをさらに具体化、限定化し、「何を作るか」を記述したもの。これを「ゴール記述」と呼ぼう。 おそらく発注者が「こんなん作って欲しいんやけど〜？」というものを「要求記述」に書き、それを受けて開発側が、「つまり、これを作ればいいんですな」という回答を「ゴール記述」として書く。世の中の「仕様書」と読んでいるものはおそらくこの両方が様々な粒度がごちゃ混ぜに一つのドキュメントとして記述されてあるものだと思う(僕の経験上からも）。例えば、Webアプリのようなもので考えると、「要求記述」には、「24時間365日連続運転」というものが記述され、それに対し、「ゴール記述」には、「MTBF＊＊分、稼動率９９．９％を確保する」みたいなものが書かれるようなイメージ。
この2つのドキュメントをやり取りすることで、お互いの「求めるもの」と「その求めたものに対しての応え」が取り交わされる。まず、ここをはっきりさせずに先に進捗を進めようとするからあいまいになってしまう。つまり、発注、受注というものを2つのシステムとして考え、それらの間をいわゆる「仕様書」というプロトコルでネゴシエーションを取るようなイメージ。以前にも「仕様書」というものをインタフェースとする「発注者」「受注者」というアクターを考えた。ここでの議論のネックは、「ビジネス」という観点における、「リスクヘッジ」と「責任の所在」であった。つまり、現状の「仕様書」という1つのドキュメントをやり取りすることで、発注者は、この「仕様書」を最大限に拡大解釈したがるものだし、受注者は、その反対に限定的にその意味を捉えようとする。つまり、これは、「仕様書」という1つのドキュメントで合意を取ろうとするからこそ発生する問題だ。であれば、その仕様書を2つに分ければいい。
ってなところで、続きはまたの機会に。
マーチンファウラーに会ってきた。僕のようなソフトウェア屋にとっては現人神にも等しい。そんな彼に話し掛けた。彼が焼きそばを食ってる手を止めさせた。挨拶をした。自己紹介をした。あんたの「アジャイルオフショア」を訳したのは俺だと伝えた。覚えてくれていた。翻訳を公開する際に許可を得るためにメールをやり取りしたのだ。ついでに、彼のサイトからもリンクを張っていただいている。神と対話をした。 神と握手をした。 神の手による教典に直筆サインをもらった。 訳しててよかったー、と思った雨の降る新宿の夜であった。
もうかなり前になるが、社内のWebサイトにこんなコラムを書いた。
重大事件に学ぶ「危機管理」の教訓72 文春文庫 佐々 淳行 (著)を読了。
国家安全保障の要職を歴任してきた著者によるリスクマネジメント論。さすがに国家規模の様々な危機に面し指揮をとってこられた方だけにとても重い教訓が次々と放たれる。特に「組織力を発揮する」という点の氏の考えは組織に属すものとしては必読ものである。
本書に繰り返し登場する人物に、氏が尊敬する上司、後藤田正晴氏、その人である。世間では、カミソリ後藤田と恐れられた中曾根内閣の官房長官である。中曾根内閣で創設された内閣五室制度発足の場で五室(内政審議室、外政審議室、安全保障室、情報調査室、広報官室)の各室長に対して与えられた「後藤田五訓」は、ソフトウェア開発プロジェクトという組織はもとより会社という組織に属するものとして知っていて損はない。
・「省益を忘れ、国益を想え」
・「悪い本当の事実を報告せよ」
・「勇気を以って意見具申せよ」
・「自分の仕事でないと言うなかれ」
・「決定が下ったら従い、命令は実行せよ」
こういう当たり前のことを言える上司に仕えることができた筆者は幸せである。
また、後藤田氏が会議嫌いだった、というエピソードを語る中で、スタンドアップミーティングを実行してた、というくだりがあったが、知らず知らずにXPを実践してた、ということだ。
なお、本書で、扇元国土交通大臣を見直しました。実はリーダシップがなんたるかがよく分かってる人だった、ということが分かりました。
キャッチボール―Ichiro meets you イチロー (著), 「キャッチボール ICHIRO meets you」製作委員会 (編集), 糸井 重里イチロー選手と糸井さんの対談をそのまま活字にしたもの。エッセンスはほぼ日の特集にまとめられているんだけど、これを読んだ人でも買ってもいいんじゃ？
で、この中でのイチロー選手の印象は、野球という世界における修行僧。常に自分を客観的にみつめ、自分の信ずるままに、自分が理想とする結果を得ることに全力をかける。首位打者の成績を残していようが、チームが優勝していようが、自分の描いているイメージのバッティングができなけりゃ、それはスランプだと。こういう仕事人的な考え方、けっこう好きです。
先日、職場の同僚にこう指摘された。「moneyさんは、技術的な議論になったり、エンジニアとしてこうあるべき、という話になるとガチンコでむちゃくちゃ厳しいのに、それが交渉事とか人間関係とかって話になると、途端に優しくなる。なんでそこでぶち切れないんだ？」と。
僕がエンジニアに対して厳しいのは、同じ「コンピュータで飯を食うプロ」としての敬意を表してのことです。例えば自分以上のキャリアを持った人には容赦しません。少なくとも自分よりも経験年数が多い以上、自分よりもスキル、知識、経験、洞察力において優れているという前提で接します。手を抜く、あるいはどうせわからないだろうから、と技術レベルを落として接するのは失礼だと考えるからです。でも、いったん技術を離れると、そこまで強くいえないんだよなぁ。 なんでだろう？まだまだ私自身、精進が足りませぬ。
先日、用事があって、吉祥寺から井の頭線で渋谷に向かっていたときのこと。ちょうど昼休みにオフィスそばの本屋で調達したこの雑誌を何気に開いた。特集の1つめは、要求工学に絡んだ話で、ぱっとページを開くなりエクセルの画面が目に入ったので、ひとまず後回し。特集2に、「ソフトウェア開発で幸せになれる人、なれない人」というタイトルが目に飛び込み、「こりゃ、新人用研修のネタにでも」と思いながら読んでいた。そこへ途中の駅から乗ってきた見るからに新入社員らしき女性3人ばかしが僕の隣に座った。彼女たちは、その日の研修でもらったのであろう、なにやらコピーを開いて3人して同じものを読んでいる。そこからしばらくして異変に気づいた。何気なく、隣に座ったその新人さんの手元を見た。なんと、今自分が開いている雑誌と同じ記事ではないか。さては、こいつら、技術系の会社の新入社員。で、講師が「読んでおきなさい」とか言って本記事のコピーを配布した。そして今、それを読んでいる。という演繹推論が0.037秒の間に僕の頭の中で処理された。その直後、僕のCPUから発せられた命令は、「雑誌を閉じる」というものだった。なんで、ちゃんと雑誌を買って読んでる奴が、コピーを回し読みしてる奴に遠慮せにゃならんのだ？と憤慨しながら僕は眠りについた。 さて、研修用のネタ、さがさにゃぁ。
科研費に「情報学」という領域ができたらしい。
いまだに情報学＝情報科学/工学という日本の常識（＝世界の非常識）を打ち破ることができるか！？
でも、山形さん,仕事速すぎ。出版流通に乗らないものをあれだけ訳していながらこう次から次へと。読むのが追いつきません。