涼しげにしてみた

上の彼は、アクセスする時間帯によって
違う動きをしているようだ。

出すべきか出さざるべきか

シャツの裾をズボンから出すか出さないかは、
僕らが高校生の頃はまだ入れるのが普通だった。
でも90年代前半を境に急に言われなくなった。

それでも、2000年代になってもカジュアルで出勤するときは
上司の目もあるので裾を中に入れていたわけだけれども、
最近は偉い人に会うか、来客でもない限りは出しっぱなしだ。

言い訳に聞こえるかもしれないが、デスクワークで
背もたれの高い椅子に長時間座っているうちに
自然に裾が出てしまっているということも少なくない。

ところで実際には、シャツには出して良いものと良くない
ものがあるという話を聞いたことがある。
もちろんシャツ自体は、その発祥の地であるイギリスでは
下着なので、出す出さない以前に上着を着ろよって
ことになるわけだが、そういうクラシカルなシャツというのは
裾がカーブするように裁断されていて、これは
出すべきものではないらしい。

一方で90年代から見られるようになったシャツは
裾が水平にカットされている。これは出していいらしい。

確かに言われてみると、裾のカーブしたシャツを
びろ～んと出して着るのはだらしなく見える。つまり
今持っているシャツの裾を出しさえすれば
カジュアルになるというわけではなかったらしいのだ。

さて、年とともにウェストがきつくなってシャツを入れたくない
というのは、また別の問題・・・

FireFoxにGoogleToolbar

FireFoxにGoogleToolbarが出ました。

検索のハイライトの仕様が、とても素敵です。

http://www.itmedia.co.jp/news/articles/0507/08/news028.html

だじゃれ？

文献を検索していたら、変なものを見つけた。
題して
「Oncology Ontology」

狙って付けたんだろうか・・・

「ITプロジェクトの実態とは！」より

http://www.projectcartoon.com/cartoon/586
より、この絵の解説を試みたい。

■ 顧客が説明した要件
顧客はその分野のプロフェッショナルなので、
プロなら問題の把握や解決策の提案も
信頼できるかと思いきや、そうでないことが
多いという皮肉。顧客は問題発見や要求定義の
プロではないのだ。
コンサルはその手腕(思考法、分析法)で
相手も気付いていないような問題の掘り起こしや
発見に努めなければならない。

■ 営業(コンサル)の表現、約束
問題に対して一定の解決案を示せているものの
顧客に媚びるあまり誇大であったり、無駄な表現で
周囲を混乱させてしまう。
「大舟に乗ったつもりで」といった感じだ。

■  アナリストのデザイン
アナリストは凝ったものを作りたがる性癖がある。
問題を解決できそうではあるが、
しばしば現実離れしたものを考案してしまう。
アナリストは趣味に走らず、顧客や自分たちの
実力をわきまえて実現可能な提案をすることに
努めなければならない。

■  プロジェクトリーダの理解
プロジェクトリーダは、問題解決の総指揮者。
顧客や営業、アナリストの意見をまとめて
プロジェクトの方向性を決定する。
実現可能でバランスの取れた解決策を
提案できるが、顧客、営業、アナリストの意見を
調整するうちに重要なものを削ぎ落としてしまうことがある(この場合ブラブラできない)。
リーダは必ず問題の本質を押さえて最低限の
要件だけでも満たせるよう努めなければならない。

■  プログラマの実装
アナリストやリーダの示した目標を実現するには
技術が未熟であったり、そもそも人手不足であったり
することがあり、手の届く範囲で頑張った結果、
何か形のあるものにはなっているが顧客の問題を
全く解決できない。最悪の場合、プログラマは
「何だか分からないけど顧客の所に持っていけば
運用でなんとかなるんだろう」ぐらいの意識。

■ ベータ版テスターの受難
ある程度は要件を満たしているのだが、ベータテストの
段階ではちょっと長さが足りなくて、首吊り紐みたいになって
しまっている。もしこれを使用したらひどい目に
合うことは分かっているのだが・・・

■ プロジェクトの書類
成果物が要件を満たせなかったため、ドキュメント
を作成する時間がないという現象。
ドキュメントがあったとしても、実際の成果物の
影くらいしか表現できていない。

■ 顧客への請求金額
プロジェクトリーダは現実的な予算を組み、
営業は安く見積もったり、
アナリストの提案は高価すぎたり、
そもそも問題の理解が不十分なために
度重なる仕様変更で請求額は乱高下。

■リリース時期
リリースが遅れた結果、シーズンを逃してしまい
誰も寄りつかない始末。

■広告
広告だけはクール。

■ 実際の運用
全てがちぐはぐであったため、システムを
適切に設置することができない。できあがった
ものを顧客のところに設置しようと、2本目の縄を
垂らそうとしたとたん、「いや、そうではない」
というクレームが付いて、そこまで止まり。

■ 得られたサポート
使い物にならないので、サポートは
途中でスッパリ打ち切られる。

■障害対策
バックアップ系を用意してある。
ただし実運用に耐えるかは未評価。

■実際の性能
ちょっと蝶のようなものが上に乗ったくらいの負荷で
破損してしまう。

■オープンソースの場合
だいたいみんなが望むものは、一通り無料で
揃ってる。だが、それは顧客にとって必要な
ものかどうかは別の問題。

■パッチの適用後
セキュリティパッチをあてたら、色々と制限が加わって
結局のところ手も足も出ない。

■ 顧客が本当に必要だったもの
顧客の説明は「木からぶらさがるもので、
縄で吊るして、乗ることができて
地面から離れていてぶらぶらできて、
頭をくぐらせられるだけのスペースがあって、
ブランコに似ているけど、でもブランコではなくて」
というようなものだったようだ。

　そして、顧客自身も説明するときに重要な点を
見落としているため本当に必要であったものは
誰にとっても思いもよらないものであったり、
見積もりより遥かに工数が少なくて済むもので
あったりする。

■diggの影響
そんな公共事業が掲示板などで話題になると・・・