昔「彼女がそれで幸せならば」と言って、離婚した人がいたけど、やっぱそれってクールだと思う。
別に彼女だけに限らず、常に相手のベストの状態を思いやるというのは、永遠のテーマかも。
すぐに自分にとってのプラス/マイナスを考え、面倒くさいことは思いっきり嫌がるというのは、性根を入れ換えなければ。
医者が、ただたんに患者の要求する処方箋だけを与えることはありえない。
医者が自分で診断をし、それによって患者に合致した処方箋を与えるのが本来のありうべき姿である。
SEもこれと同様と考えられないか。
ユーザーの言う通りにシステムを作るのではなく、専門家としての判断のもと、ユーザーに提案していくものではないのか。
判断の拠り所としては、
□ユーザーのやりたいこと
□ユーザーのやりたくないこと
□メーカーのやりたいこと
□メーカーのやりたくないこと
□私がやりたいこと
□私がやりたくないこと
□システム的な観点より推奨されること
□システム的な観点より推奨されないこと
□ワークロードの問題
□技術的に実現可能/不可能

私がやりたい/やりたくないは対象外とする。
ユーザーがやりたくても、システム的にあまり推奨されない場合、その理由をユーザーに説明して、リスクを認識してもらうこと。
プロジェクトの管理対象。
・進捗
・ドキュメント
・要員
・お金
・やる気
・仕様
検証レベルの違い、ドキュメント・レベルの違い。
あまり管理されていないシステムの場合、急にしっかりしたドキュメントを作ろうと思っても、それはかえって逆効果となり、またひとつ精度の悪い資料が増えるだけとなる。
1つのことを決めるためには、それに関連したものが決まっている必要があり、それらが幾層にも重なって連携している。そんな状態のなかで決まっていないものを基礎として、いくらそのうえに仮定を積み重ねていっても、それは絵空事でしかなく、かえって混乱を招くもととなってしまう。
そういったケースにおいては、緩み度を大きく取って、物事を進めていく必要がある。

では、その緩み度の幅の違いはどこに跳ね返ってくるのだろうか。
まず考えられるのは、しっかりと管理されたところでは、特定の個人に依存する割合が減る、ある一定の共通スキルさえ保持していれば、誰にでも取り替え可能となることである。
特定の個人に依存しない。
次に、障害発生時のリカバリに対するレスポンスの差が考えられる。管理が行き届いたところでは、障害発生に対する考慮が充分になされているため、迅速に対応することができる。一方、緩み幅が大きいところでは、その都度対応策を練っていくこととなり、またその原因の特定や影響範囲の特定について、一から始めることとなる。
面倒くさいとか、難儀だとかを考えるのではなく、まずはそれが必要かどうかを考えること。
それが必要なのであれば難儀なことだろうと面倒くさいことだろうと、それはやらざるを得ないこと。

最近無性に中上健次が読みたくなって、本日「枯木灘」「鳳仙花」を購入。
なんで急にそんな気持ちになったんだろう?
ピンチと思わずに、あわてず落ち着いて対応するように心掛けるって大事なことかも。
プロ意識ってさあ。
COOLにこなしたいよね。
いつも言っていることなんだけど、何を第一目標とするかによるんだよね。
でもなんだかんだいいながら、いつも対人意識のプライオリティをあげちゃうんだよね。
それと自分が楽したいというか、あまり動きたくないというか。
まずは、そのような意識を除外するところからはじめないといけないと思うんだよね。

でもね、身体が疲れてるとどうしても自分をかばっちゃうんだよね。
やっぱり基礎体力は重要だね。
吉祥寺にあるお薦めのお店にいったんたけど、休みだった。
ついでにLAOXによってiMAC G5を見てきたんだけど、ちょっと大きすぎて、いまいちでした。
な~んにも書く気になれないのよ。
いろいろとあるんだけど、まとめたくなくて。