2005 6 7 8 9 10 11 12
2006 1 2 3 4 5 6 7 8 9 10 11 12
2007 1 2 3 4 5 6 7 8 9 10 11 12
2008 1 2 3 4 5 6 7 8 9 10 11 12
2009 1 2 3 4 5 6 7 8 9 10 11 12
2010 1 2 3 4 5 6 7 8 9 10 11 12
2011 1 2 3 4 5 6 7 8 9 10 11 12
2012 1 2 3 4 5 6 7 8 9 10 11 12
2013 1 2 3 4 5 6 7 8 9 10 11 12
2014 1 2 3 4 5 6 7 8 9 10 11 12
2015 1 2 3 4 5 6 7 8 9 10 11 12
2016 1 2 3 4 5 6 7 8 9 10 11 12
2017 1 2 3 4 5 6 7 8 9 10

ホーム

2009年07月25日1

コミュニケーションなんて、本質的に割り込みなんじゃ
ねぇの?

まぁ、アポ取ったりするのもあるけど、自分が重視する
のは非公式なコミュニケーションだし。その場、その
瞬間で伝えないと、伝えたいものもどっかにいっちまう。

節度はあるとしても。それでも、自分は、割り込みを
恐れて人を避けるよりも、コミュニケーションを通じて
充実した時間を過ごしたい。

本家Permlink


2009年07月25日

セオリーに裏打ちされたテクニックを学び、実践し、
経験を積む。これを繰り返すことによって己を高める
という心構えを持つ。

* セオリー
* テクニック
* 学び
* 実践
* 経験
* 心構え

プロというのは、結局そういうことなんじゃないだろうか。

本家Permlink


2009年07月23日

ここで書いてることを、実際に現場で話すこともあって、
当然ながら。

でも、こっちがいいたいことが伝わってるか、わかんない
ときも多いんだよね。

まぁ、自分の伝え方が悪いっつーのもあるのは自覚してる
んだけど。

いきなり話しかけるからね。しかも、一方的にしゃべるだけ
しゃべって、それで終わるっていう。

で、そういう話をすると相手はキョトンとするんだよね (笑)。
いや、まだそれならいいほうで。なんか半笑いされる
ときもあるんだよね (笑)。

いや、突然話振られて戸惑ってるのかもしれんけど。

でも、そういう話に慣れてないっていうかな。

  見積もりってのは、日数出すことが目的じゃないんだよ。
  だいたい、日数出そうとする時点で見積もりは甘くなる。
  人間っていうのは見たくないものは見ない生き物なんだから。
  『あれもある、これもある、ああ、また日数が増える』
  なんて考えちゃう。そうすると、やんなきゃいけない
  ことなのに意識・無意識を問わず、見ないようになる。
  だから、やんなきゃいけないことに集中しなきゃ
  いけないんだよ。それで最後に日数っていうもんが出る。

まぁ、相手にしたら『いきなりそんなことをいわれても』
って思うかもしれない。

でも、そこで返さなきゃダメなんだよね。返さなきゃ
議論がはじまらない。

『返す』っていうのは反論でもいいし、あるいは見積もりに
ついての他の質問でもいいし、自分の過去を振り返っても
いい。とにかく『ハイ』だけじゃダメなんだよね。一番
面白くない反応。

返すことでようやくオレと同じ土俵に上がれるわけだよね。
いや、返すことで自分の土俵にオレを引きずりこむこと
だってできるわけ。話を振った以上、オレにはそれに
つきあう義務があるんだし。

そういう議論を通じて仕事についての理解を深めていきたい
わけ、オレは。『オレの背中を見ろ』とか、そういう
ムチャなことはいわない (笑)。

--

うまい返しが打てるのは、普段からそういうことを考えてる
からなんだよな。

全然考えてもなかった話をいきなり振られても、なかなか
うまく返せるもんじゃない。

--

そうそう、新人がさ、『見積もりの精度を高めたい』
っていったんですよ。で、ソイツは自分とは関係ない
部署だったから、上の話は自分とこの新人に振ったのね。

まぁ、それで、上みたいな反応だったわけだけど (笑)。

でさ、『見積もりの精度を高めたい』って、みんな
いうでしょ?

じゃあ、具体的にどういうやり方で高めんのよ?
オレに教えてくれよ。

何度か書いてるけど、自分らの仕事っていうのは、過去に
やってないことをやるわけね。似たようなことはやった
ことがあるかもしれんけど、まったく同じことは二度と
やらないわけ。

過去のデータを使い回せないんだから、精度を高めるっ
つっても限界があるわけ。100%はムリなわけ。

100%がムリなんだから、統計的に解決するしかないわけ。
それが科学的態度ってもんだろ。そこで、『なんとしてでも
100%に近づけます!』なんていうんじゃ、ただのカルト
だろ?

統計的に解決するっていうのは、揺らぎを認めるっていう
ことなわけ。揺らぎっていうのは、遅れることもあれば、
早く終わることもあるっていうこと。

でだ。その揺らぎを、できるだけコントロールできる
範囲に収めたいわけだよな。そのために、予測する
アイテムをできるだけ小分けするわけ。そうすれば、
Aっていうアイテムでは2日オーバーするかもしんないけど、
Bっていうアイテムでは2日早く終わるかもしれない。
そうなれば、揺らぎが相殺されることになる。
アイテムがたくさんあればあるほど、そういう相殺が
期待できることになる。それが『大数の法則』って
呼ばれるテクニックなわけだ。

それと、似たような見積もりを長期間繰り返すうちに
精度が上がってくることも考えられる。アイテムごとの
揺らぎが小さくなるわけだよな。そうなると、全体
としても見積もりの精度も上がることになる。そういう、
時間とともに揺らぎが小さくなっていく現象を
『不確実性のコーン』と呼ぶわけだ。

だから、見積もりの精度を上げるには:

  * やることをできるだけ細かく洗い出す
  * 経験を積む

っていう2つしかないわけ。簡単な話だよな?

--

そこで『じゃあ、どれだけ細かければいいんですか?』
って返せたら合格。

アイテムの粒度だけど、これもまた『経験を積むしかない』
っていうのが答えになる (笑)。

やるべきことを洗い出すのも開発者にとって重要な技術で、
一朝一夕にできるようなもんじゃないんだよね。

だから、見積もりを出したら、つまりやんなきゃいけない
ことを洗い出したら、先輩に見てもらうといい。
見落としがないか、注意すべきポイントはどこか、
教えてくれるはずだよ。

--

もう1つ書いておこう。

『小分けしたアイテムの相対的な難易度は変わりにくい』

AとBという、それなりに関連するアイテムがある。
そのとき、Aっていうアイテムは2日かかると見積もった。
一方、Bっていうアイテムは3日かかると見積もった。

でも、実際にAをはじめてみると4日かかっちゃった。
そうしたとき、Bのほうは3 * 2で6日かかると予想できる。

これを、教えてもらった人にちなんで『咳算の法則』と
呼ぶ。

本家Permlink


2009年07月22日

プログラミングっていうのは、君が思ってるよりも
ずっと知的な仕事なんだよ。

ここでいう『知的』の反対は何かわかる?

行き当たりばったりなんだよ。

創造に試行錯誤はつきものだ。でも、試行錯誤するに
しても、観察して仮説を立てて実証する、ゴールを
決めてそこへの道筋を考える、そういう知的な態度が
求められるんだよ。

目についたものにすぐ飛びついて、こっちのコードを
いじって、あっちのコードをデバッガで追ってなんて、
そういう知性のかけらもない仕事の進め方をするんじゃ
ない。

本家Permlink


2009年07月21日

優秀なプログラマになることと、素敵な女性になることとは
矛盾しない。

ここでは、仮に、素敵で優秀な女性プログラマのことを
ステキプログラメと呼ぶことにしよう。

以下にステキプログラメの条件を書く:

* ステキプログラメは思いやりがある。

    XPの価値の1つは「リスペクト」、すなわち思いやりである。

* ステキプログラメはおしゃべり好き。

    XPの価値の1つは「コミュニケーション」である。

* ステキプログラメはきれい好き。

    4Sの1つは「清潔」である。

* ステキプログラメはダンドリ上手。

    XPのプラクティスに計画ゲームがある。

* ステキプログラメはねばり強い。

    カイゼンにはねばり強さが必要である。

* ステキプログラメはマナブが好き。

    いわずもがな。

* ステキプログラメは直感が鋭い。

    「リファクタリング・ウェットウェア」では直感の
    重要さが強調されている。

--

直感っていうのは「センス」という言葉に置き換える
こともできるだろう。センスっていうのは、即座に
正しい判断を下すことなんだから。

--

「感情」も、プログラミングにとって悪いことじゃない。
直感やセンスっていうのは、感情からもたらされるもの
だから。

もちろん、感情が悪い方向に作用することもある。
けれども、感情抜きに人間は生きられないし、感情抜きに
仕事を進めることもできない。

--

人の話を聞くのが好きだっていうのも立派な
「おしゃべり好き」だよね。

--

プログラ女と書いてプログラメと読む。

プログラ男と書いてプログラメンと読む (笑)。

本家Permlink


2009年07月20日1

たまたま、ビルドできない、というか、ビルドしても
意味がない状態に陥って。じゃぁ、しょうがないから、
次やるストーリーの下調べでもするかとなって。

『ああ、この関数をいじんなきゃいけないな』とか、
『ああ、このクラスに新しいメンバ変数追加しなきゃ
いけないな』とか。隣の人が『このコンフィグ見る
みたいだよ』って教えてくれたりとか。

で、この業界は、こういう作業を言い表す言葉を
生み出してない気がするんだよな。分析? 設計?

たとえば設計と呼ぶとしても。でも、咳さんがいってる
ように、こっちが知りたいのは主に『何をやんなきゃ
いけないのか』なんだよね。じゃあ、それは設計って
いうよりToDoの洗い出しに近いじゃんっていう。

そうした『やんなきゃいけないこと』の積み重ねで
見積もりが出せるんだし、計画が立てられるんだよね。

クラスよりも、メソッドよりも、やんなきゃいけない
ことを洗い出せ!

--

まぁ、やんなきゃいけないことを洗い出して
組み立てることを『方針』とか『作戦』とか
呼んできたわけど。

ひょっとすると『だんどり』っていったほうが
若い人には馴染みやすいかもしれない。

本家Permlink


2009年07月20日

なんか、お姿を拝見するたびに(う)さんは細くなって、
ebanさんは太くなってるような気がする (笑)。

--

hotlinksなんだけど、江渡さんのを張るんなら:

http://d.hatena.ne.jp/eto/

にしてくれませんか。

eto.comのほうは、ここ数年更新された覚えがない (笑)。

それと「パターン、Wiki、XP」のWikiはどっかにないの?

本家Permlink


2009年07月18日

『パターン、Wiki、XP』(江渡浩一郎、技術評論社)

  (p.45)
  パターンランゲージによる建築は、表面的な言葉だけをとらえると、パ
  ターンを組み合わせて建築するのだと思いがちです。ある意味、レゴブロ
  ックを組み合わせて建築を作り上げるように、それぞれのパターンに適す
  る実体があって、それを単につなぎ合わせるようなイメージを生じさせま
  す。しかし、それはアレグザンダーが言おうとしたことの正反対です。あ
  らかじめ部品を用意してつなぎ合わせるだけといった考え方は、彼が最も
  反対した考え方なのです。

  (p.46)
  建築計画では、往々にしてそれまであった古い建物を取り壊して更地に
  し、その上に新しい建物を建てるというスクラップ&ビルドの考え方がと
  られます。しかし、古い建物を活かし、新しい建物と有機的な関係を保ち
  続ける方法を模索し、そのための手段をさまざまに講じることが、パター
  ンランゲージの目指す方法論です。

本家Permlink


2009年07月15日1

朝会とかでもさ、プロジェクターの画面ばっかり見るん
じゃなくって、しゃべってる人の顔もよく見るんだよ。

特に不満や不賛成を表明した人の表情。議論が進んだ
ときに、そうした人たちが納得した表情をしてるか
どうか。

ちょっとした読心術といえるかもしれないけど、でも、
人の表情を読むっていうのは、フツーの人間なら誰でも
持ってる能力なんだよね。だから、差があるとすれば、
見るかどうかの差でしかないし、見て何か違和感を
感じたときに声をかけるかどうかの差でしかない。

「それで納得できたの?」「それでスッキリしたの?」

1つの製品を大勢の人間で作ってるんだから、意見の
違いはあるだろうけど、でも、遠くの目標は共有してる
んだから、みんなが納得できるポイントっていうのは
あるはずなんだよね。

品質を取るか、それとも時間を取るかとか。まぁ、
大抵は時間を取ることになるんだけど (笑)。でも、
時間を取るにしても、みんなが納得してるかどうかで
気持ちが違ってくるし、気持ちが違ってくれば能率
だって違ってくるんだよね。

本家Permlink


2009年07月15日

http://www.atmarkit.co.jp/aig/04biz/traceability.html

う〜む、残念。トレーサビリティはCMMですでに
扱われているのであった。

--

CMMについては:

http://ja.wikipedia.org/wiki/%E8%83%BD%E5%8A%9B%E6%88%90%E7%86%9F%E5%BA%A6%E3%83%A2%E3%83%87%E3%83%AB%E7%B5%B1%E5%90%88

以上のことは知らないんだけど。でも、ザッと
見た感じ:

  3. 定義された状態 (制度化された状態)、プロセスが標準ビジネスプロセス
     として明示的に定義され関係者の承認を受けているレベル。

  4. 定量的に管理された状態 (計測できる状態)、プロセス管理が実施され、
     さまざまなタスク領域を定量的に計測しているレベル。

なんかは、言葉でいうのは簡単だけど、現実には
むずかしい話じゃない?

だって、このあとの(5)で:

  5. 最適化している状態 (プロセスを改善する状態)、継続的に自らのプロセ
     スを最適化し改善しているレベル。

っていってるくらいで、制度あるいは標準っていうのは
変わるし、変えないといけないわけね。つまり、
(3)と(5)は、方向が逆に近いんだよね。

で、計測なんだけど。これも、前から書いてるけど、
計測できるものにどれほど意味や価値があるか疑問
なんだよね。

まぁ、お金とかなら身もフタもなく計測しなきゃダメな
話だけど。

velocityの話もあったけど、計測とか見える化とかは、
何を対象とするか見つけるのがむずかしいし、見つかった
としても、大抵は長期間にわたって記録し続けないと
いけないのが多いし、数字っていうのは人の心理に
強く作用するし、まぁ、労多くして実り少なしみたいな
感じになるんじゃないのかな。

まぁ、好意的に捉えれば、守破離を現代的に解釈したら
こうなりましたってことなのかね。

--

そうそう、いらなくなった計測をいつまでも続けちゃう
リスクもあるんだよね。それが習慣の恐いところ。

--

そうそう、『7つのムダ』の話でさ。8番目を考える
ヤツがいるんだよな、やっぱり (笑)。

で、その8番目が何かっていうと『何もしないムダ』
だってよ (笑)。

頭いかれてるよな。

4Sにしても、5S、6Sにしたがるバカがいるじゃん?
4Sでさえ、ほんとは3Sで十分なのに。

ほんとに、ルールを増やしたがるバカはどこにでもいる
もんで。

もし8番目のムダがあるとしたら『ムダ取りのムダ』
だよな (笑)。ムダを取ることに夢中になって、本業を
おろそかにしてしまうっていう。『何もしないムダ』を
考えるなんてのが、まさにその『ムダ取りのムダ』
だよな (笑)。

本家Permlink


2009年07月10日

まぁ、自分にとっては、ソフトウェア開発は
ビジネスだよなぁ。

貧乏暇なしなもんだから、アートかサイエンスかで
悩む暇なんかないかな (笑)。

--

「マイクロイテレーション型ソフトウェア開発に
おけるトレーサビリティの実現」みたいな感じで
ビジネスモデル特許でも取るかなぁ (笑)。

で、ロイヤリティの徴収はJASRACに頼むと。

というわけで、諸君らがタダでagileできるのも
あとわずかなわけだ。ガハハハ。

--

もちろん、冗談です。

--

まぁ、でも、トレーサビリティっていうのは、
それだけでagileを導入する理由になるほど
重要なことだと思うんだけどね。

もちろん、古典的な開発手法でもトレーサビリティを
実現することは可能だけど、ちょっと現実的じゃない
だろうね。

本家Permlink


2009年07月09日

だから、彼らのいってるトレーサビリティって
いうのは進捗管理の話であり、自分のいう
トレーサビリティっていうのは品質管理の話
なわけだよ。

どっちが世間一般でいうトレーサビリティに
当たるかなんて、いうまでもない。

そもそも、品質と進捗っていうのは、多分に
トレードオフの関係であって。もちろん、
品質を落とさないような進捗にするっていう
のも進捗管理のポイントではあるが、やはり
品質管理と進捗管理は分けて考えるところから
はじめるべきだろう。

--

前にも書いたけど、トレーサビリティっていうのは、
第三者の視点が重要になる。第三者の視点って
いうのは、要は、お客さん本位ってことなんだよな。

これまで、ソフトウェア開発でお客さんっていうと、
要求を出す段階しか関わってなかったし、出荷した
あとだって「保守」なんていう、開発者本位の話に
しかなんなかったわけだよな。

それがXPの登場で、on-site customerとかいわれる
ようになって、開発過程の多くにお客さんが関われる
ようになったわけだ。

トレーサビリティっていうのは、そういう流れの
延長線上で語られるべきものであって。お客さんに
安心して使ってもらえる製品や態勢を作り上げる
ことが目的なわけだ。

まぁ、オレも他人のことはいえんけど、技術バカ
っていうのは、結局は、お客さんのことを置き去りに
するヤツのことをいうんだろうよ。

本家Permlink


2009年07月08日1

あー、トレーサビリティの話、このページでも取り上げた
ことがあったみたい。

羽生田さんがらみで (笑)。

それにしても、羽生田さんのトレーサビリティの話って
いくつかネットに上がってるけど、どれも空しい感じに
なるのはオレだけなのか?

これなんかは羽生田フォロワーらしき人が書いてる
みたいだけど:

http://www.atmarkit.co.jp/im/carc/serial/extend/11/11a.html

トレーサビリティがなぜ重要かってとこから話を
はじめないとダメだろ。

トレーサビリティが重要なのは、事故が起こったときに
原因を追求しやすくするためだよな。

そういうネガティブっつーか、ドロドロした話なんだよ、
ほんとは。

分析から実装まで一気通貫に進めることはトレーサビリティ
とは関係ないよな。紆余曲折しても、その紆余曲折を
記録しておけばトレーサビリティは確保できるんだから。

  ああ、ちなみに、こういうときに『一気通貫』という
  表現を使うのは嫌いです。オッサン臭いから。

で、事故あるいは不具合っていうのは、やっぱりコードから
はじまるわけだろ。現象が起きて『そんなの仕様にない!』
なんていっても意味なんだから。コードから設計、そして
仕様、そして要求といった具合にさかのぼるっていうのが
現実の対応なんだし、それを可能にするのをトレーサビリティ
っていうわけだよな。

だから、こういう流行の言葉だけ借りてきて、その
肝心の精神的な部分を置き去りにするっていうのは、
いかにもIT業界っぽいし、いかにもITバブル、
OOPバブルって感じなんだよな。

ほんと変わってねーよな。

--

いや、上の記事をもう一度読んだたら、世間一般で
いわれるのと違う意味で『トレーサビリティ』っていう
言葉を使ってねぇか?

トレーサビリティいったら:

http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B5%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3_(%E6%B5%81%E9%80%9A)

だろ、jk。

上の記事だと、視点が開発者側に置かれてる気がするん
だよな。でも、本来のトレーサビリティって、第三者に
視点が置かれるもんだろ。だからアカウンタビリティって
話につながるんだろうが。

--

ああ、上の記事でいってるトレーサビリティって、
あの羽生田さんの:

  コンポーネントの完成度について「40%のメソッドは7本のユースケースか
  ら使われており,検証ができています。残りのユースケース3本で必要な特
  別なインタフェースを含む60%のメソッドは未実装です」と報告できます。

っていう話につながってんのか。だとしたら、そんなもん、
トレーサビリティでもなんでもねぇっつの。くっだらねー。
バカじゃねーか?

本家Permlink


2009年07月08日

これも前に書いたことがあると思うんだけど。

ストーリーみたいな短い単位が作業単位になると
トレーサビリティが上がるんだよね。

誰からの要望なのか、誰が担当したか、仕様、設計、
ソースファイル、ブランチといったものを、1つの
ストーリーに紐づいて管理できる。

もし、これがストーリーより大きな単位で管理されて
いたとしたら、トレーサビリティを高めるのは難しい。

トレーサビリティを上げるためには、やっぱり
ストーリーを電子的に管理したほうがいいということに
なる。

電子的に管理されていれば、ストーリーの検索も楽に
なる。ストーリーには番号が振られる。その番号が
ソースファイルのコミットログに記録される。履歴を
見れば、ストーリーに関連する資料のポインタが見つかる。
だから、ソースコードのコメントは必要最低限になる。

いうまでのなく、トレーサビリティっていうのは、
アカンタビリティにもつながる話なわけ。

本家Permlink


2009年07月06日

生産性にしたっておんなじ話だよ。

生産性を上げたいんだったら、残業止めないと。

時間増やせば生産量が増えるのは当たり前なんだし。

生産性っていうのも統計の産物なわけだし。だから、
1日8時間を日々繰り返して、計測して、それで過去と
対比してはじめて、上がった下がったがいえるように
なる。

逆に、残業しないって決めないと生産性を上げる
気にはならないかもしれないな。

--

管理者の仕事の1つは、そういう統計を取ること
なんだろうな。まぁ、当たり前の話だけど。

--

あわてて作って、
あわてて出荷して、
評価不十分なもんだから客先で不具合出して、
不具合の対応に人手取られて、
開発バージョンの進行が遅れて、
それでまたあわてて作って

って、あまりにもわかりやすい悪循環だろ。

そういう悪循環を断ち切るにはどうすりゃいいかを
考えなきゃダメだろ。

だが、こういう連鎖を一気に断ち切る方法は絶対に
ない。だから、すべての活動において少しずつでも
質を上げてくしかない。

--

まぁ、なんだか、おなじような話ばっか書いてるな。

本家Permlink


2009年07月05日

こないだ書いた話にもからむんだけど。

みんな『見積もりの精度を上げたい』っていうよな?

だったら、残業止めろや。

見積もりってのは統計の産物なんだよ。

で、だ。統計ってのはデータがそろってたほうが
いいわけだよな。

残業ってのは、統計が嫌うデータの揺らぎそのものな
わけだろ。

それともナニか? 毎日1時間残業することに決めてます
ってか? おい、そりゃ不道徳ってもんだろ (笑)。

まぁ、残業が許されてんなら、あんまり厳しいことは
いわねぇけど。でも、こないだ書いたように、仕事を
終わらせる、止める意思がないと、見積もりの精度
なんて、いつまでたっても上がんねぇよ?

本家Permlink


2009年07月02日

ああ、昨日toRubyあったんだけどさ。
池澤さんがRuby関西行ってきたんだって?
女子大生がワサワサいたっていうんでヒジョーに
うらやましかったんだが。
でも、あんまり交流できなかったって、ちょっと
残念そうだったなぁ。

前にも書いたけど、toRubyなんかユル〜い感じよ?
ポジペと称した自己紹介が毎回あって。全員やるから
それで1時間くらい? で、そのあとRubyKaigiの話して。
で、残りは咳さんの本読んで。まぁ、セミナーって
感じじゃないね。司会する人はいるけど。

そんなんだから、新人さんはいつでもウエルカムですよ。
特に女性ね。拡大版以外で女性を見たことがない!
素人さんももちろん大歓迎。つーか、クロートなんて
何もしないでも寄ってくるんだから。

toRubyは、「Rubyで喰っていきたい!」みたいな
人には不向きだけどね。

前にも書いたけど、自分は勉強嫌いだし (笑)。

--

そうそう、こないだの危険予知訓練の話なんだけど。
コードレビューなんかは危険予知なわけだよね。

--

まぁ、ケツ決められちゃったわけだ。

だから、キリがいいとかワリィとかいってらんないわけだ。

結局、キリなんてもんは自分で決めるもんであって。

終わろうとしねぇから終わんねぇだろ?

仕事が残ってんなら、明日スムースにはじめられる
ように準備するだろ? それが終わらせるってことだろ?
それが自分でキリを決めるってことだろ?

クールダウンが大切だっていうのは、そういう意味で
いってんだぜ?

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails