人生の願望を100個作る。
人生の願望を100個考えて下さいと言われたらどうしますか？
100個って実は結構大変だったりします。
手当たり次第に考えて100個できればいいのですが、なかなかできなかったりするの
で、次のように分けて考えていくとよいようです。
まず、前提として現在の状況や、人間関係などは考えないようにします。
1. 時間でわけて考える。
いつ頃までに達成するかで分けて考えます。すぐに達成できるもの、不可能に近いも
というように考えていきます。
- 1年以内に達成できるもの
-> ブログのランキングで１位を取るなど
- 3年以内に達成できるもの
-> 本を書くなど
- 10年以内に達成できるもの
-> ライブドアを作るなど
- 死ぬまでに達成できること
-> マイクロソフトを作るなど
- 死ぬまでに達成できないこと(ほぼ不可能なこと)
-> どこでもドアを作るなど
2. カテゴリに分けて考える。
6つのカテゴリに分けて考えます。
- お金について
-> 株で一山あてる、100億円欲しいなど
- 自分の存在について
-> サッカー選手になるなど
- 知的好奇心について
-> ノーベル賞を取るなど
- 体、健康について
-> 体操のお兄さんになるなど
- 時間について
-> 遊んで暮らしたい、1年間旅行したいなど
- 人間関係について
-> 好きな芸能人と友達になる。アイドルと結婚するなど
3. カテゴリの一つが完全に自由とする。
カテゴリの一つが完全に満たされている(なにも問題がない)としたら、どうなるかを
考える。
- お金について満たされていると。。
-> 田園調布に豪邸をもつなど
- 自分の存在について満たされていると。。
-> 自分の国を持つなど
- 知的好奇心について満たされていると。。
-> オラクルになるなど
- 体、健康について満たされていると。。
-> 毎晩高級ディナーで
- 時間について満たされると。。
-> 世界旅行に行くなど
- 人間関係について満たされていると。。
-> ビルゲイツと飯を喰うなど
その他、ヒントとしては一つの願望から派生させたり、細分化したりします。世界旅
行に行くより、アンコールワットを観に行くとか目的を考えて、もう少し具体化した
りするといいです。
あと、「1時間以内に考える」というように時間を区切るといいかもしれないですね。
常盤平桜まつり。
今年の花見ということで、近場の桜祭りへ。
会社の元先輩と家族ぐるみで一緒でした。
残念ながら桜の開花が遅れているようで、桜はほとんど咲いていませんでした。残念
桜並木の「さくら通り」は日本の道百選に選ばれているようで、結構長くて桜が咲い
てるととてもきれいだったでしょーねぇ。
出店が結構充実してました。やきそばとかたまりません(^^;
変わったところで、
- ふかしいもじゃないじゃがバター
- おやき
- ばくだん焼き
- スタバの出店
- 日本酒
- サイコロステーキ
- いかめし
- チジミ
- あゆの塩焼き
- キムチ
- きゅうりの浅漬け
ってなのがありました。あゆの塩焼きって値段書いてなかったけど時価？
盆踊りパレードやってたり、なぜか鳥取のキャラクター「鳥ッキー」？(20世紀なし
と鳥を合体させたよーなやつ)ってのがいたり、よく分からないのもあって楽しかった。
。。。でも、まだ桜見てないなぁ(^^;
リソースと品質。
ソフトウェアの品質を向上させるためにはテストを実施します。テストはプログラム
のロジックはもちろん、他の装置との接続部分のテスト、運用時相当の負荷試験など
いろいろな段階のテストがあります。
品質を高めるためにはテストにも時間をかける必要があり、その分コストがかかるの
ですが、多数のプロジェクトにおいて、テストのためのコストを充分に確保できてい
なかったりします。
となると、お客様の要求の機能を作るために、テストのコストを削らざるを得なくな
り、品質を保つことが難しくなります。
では、どうすればいいのでしょう？
もちろん、完璧なプログラムをかけるスーパープログラマによるチームであれば、テ
ストを削っても、バグのないシステムができあがるかもしれません。
でも、現実的にはそのようなドリームチームはほぼ不可能に近かったりします。
XPであれば、従来の滝型に比べれば、テストしながら少しずつ作っていくので、幾分
コストが抑えられると思いますが、テスト駆動開発をチームに導入するにもコストが
かかったりするので、チームの技術レベルが達していないと、なかなか難しかったり
します。。。
XPではもうひとつ、顧客を開発に巻き込む「オンサイト顧客」というプラクティスが
ありますが、これを使うと顧客を早い段階で巻き込んで、一緒に品質を上げていくこ
とができます。
顧客を開発の近くに巻き込んで、顧客からの要求をすぐに開発メンバへ伝え、作った
ものをすぐに顧客に試してもらい、フィードバックをもらって、より顧客の真の要求
に近い機能を実現してきます。顧客にすぐに試してもらい、OKをもらいながら機能を
実現するので無駄がありません。顧客がOKなら、開発側で多少不満足でもOKなんです
から(^^;
通常の開発では、開発側でテストをして「顧客が満足するであろう」機能と品質を
作り上げ、顧客にリリースしたあと、「顧客自身が満足する」ために検収テスト
(受入テスト)を実施します。つまりテストが二重に行われるのです。
顧客を早く巻き込む方法であれば、このテストの重複を減らすことができると言えます。
顧客にリリースする前に品質を確保するか、先に顧客を巻き込んで一緒に品質を上げ
ていくか。どちらを優先するかですね。
開発側でリソースが足りなくて、自分達で品質を作り込むのが不可能なときは、顧客
を巻き込んでしまうという方法はどうでしょう？
本日のファイナンシャルリテラシー(ファンド種別、RR値)
マネージファンド ファンド自体が複数のファンドに分散投資するもの。プロの目で分散投資をして もらえる。
プロパティファンド 不動産投資。日本ではRIETというのがあります。ファンド資金でマンションなど の不動産に投資して、賃料や売却益によるリターンを得ます。
テーマファンド 特定分野に特化して投資するファンド。医薬品やバイオなどに投資するものが あるらしい。日本でアイドルを育てるファンドがあるけど、これもテーマ ファンドかな
RR ファンドのリスクとリターンを測る指標らしい。過去の平均年率からどの程度 の振れがあるかを数値にしたものをボラティリティ(変動率)といい、これを元に RR3、RR4のように表記されます。数値が大きいほどハイリスク・ハイリターンと なります。
長期積み立てのファンド選択。
今日は会社の納会だったので、酔っ払いです(^^;
長期の積み立てにおけるファンド選択で、一つの戦法を教えてもらいました。
ファンドにはリスクとリターンの度合いから、振れの大小があります。振れが小さい
と安定していますが、収益は少なく、振れが大きければ収益が大きくなることもある
が、マイナスも大きくなることがあるというものです。
長期に積み立てる場合はリスク分散されるので、多少振れの大きいファンドを選択
してもよく、最初の頃は振れが大きいものでリターンを狙って持分を溜め、満期に
近づく頃に振れが小さいものに切り換えるというのが、オーソドックスな戦法とさ
れているようです。
なるほどなぁ。φ(.. )
企業とアジャイル。
XPやアジャイルと聞くと反対する人が企業には多いようです。
組織でのソフトウェア開発や、大規模開発には使えないと言われることがあります。
なぜでしょう？
私はアジャイルのとくにXPは、ソフトウェアの性質にもっとも親和性のある開発手法
だと思っています。逆に企業組織とは親和性があまりないのではないでしょうか？
XPによる開発では「人」というリソースを最も重要視します。一方、企業組織では
「数」を重要視します。「いや、うちは人を育成している」という人もいるかもしれ
ませんが、大手企業であるほど「数」を重視しています。
「人」に対する姿勢を見た場合、XPでは「よりよいものを作ろう」という高い意識に
人を集めます。高い意識で集められた人はより密接に協調関係を築きます。そして
さらに高い意識へ。。XPはこの好循環を生み出しやすい手法と言えます。
企業組織では「人」は「数」に変換されます。高い意識、スキルを持っている人でも
「1」です。スキルレベルの低い人も「1」です。人類みな平等です(^^;
そして「数」を重要視することで、「人」は低い意識に収束します。
その結果。。
- 企業はスキルレベルの低い人も使っていかなければならない。したがって、全ての作業を誰でもできるものに落とさなければならない。
- 新規開発などのチャンスなのに、スキルレベルの低い人で適当に作らせるので、プロジェクトで火災発生や、後々のメンテのコストが増大する。
- スキルレベルの低い作業の中では、スキルの高い人の能力を生かす場がなく、火災発生したプロジェクトの火消しなどの雑務に利用される。
- 成長の機会や活躍の場がなくなったスキルレベルの高い人は組織を離れていく。。
- 高いスキルレベルでの蓄積がなされず、組織成長も停滞する。そして歴史が繰り返される。
という悪循環に陥ります。
(とくに中間層の人にはあきらめ感が生まれ、さらに拍車をかけます。。)
とくに大手企業では概ねこんなカンジだろうと思われます。
また、「数」を重視する組織では「人」の個性を無視することで、全ての人がマネー
ジャへの道を進みます。プログラマはマネージャの下と見られているわけです。
つまり、「適材適所」が適用されていないということです。
XPでは適材適所とは言われていませんが、トラッカ、常時結合のためのテスターなど、
役割というものがあり、適材を割り当てやすいと言えます。ペアプログラミングによ
り、異なる役割のノウハウを共有することも容易です。
「人」と「数」。どちらを重要視してるかがポイントですね。
そしてこれが、組織へのアジャイル導入を妨げる根本原因と言えるでしょう。
保険成立。そして解約へ。。
見直しした保険が成立しました。パチパチ。。
さて、古い保険(○生 L○VE ○NE)を解約しないといけないのですが、早く解約する
ためには直接窓口に行くのが一番(担当者とかに頼むと渋られる)。
でも平日15:00までに行かないといけないらしい。。なんだそりゃ。
で、妻に代理を頼むしかないのですが、ここで代理を頼むには「委任状」というもの
を用意しないといけません。(「役所では家族代理できるぞ」と攻めれば、OKだった
というケースもあるようですが)
委任状は保険証券毎に必要らしく、2件だと同じようなものを 2枚書かないといけま
せん。しんどっ
ネットでフォーマット例があったので、これを参考に作成。
こんなカンジ。
委任状
平成○年○月○日
○○生命 様へ
保険契約者 〒○○○−○○○○
東京都○○区○○
電話番号 (03)○○−○○
氏名 生命 太郎 (印)
私、生命 太郎 は、下記１の保険契約の解約手続き、および
解約還付金の受け取りを下記２の委任代理人に委任します。
記
１、保険証券番号 ○○○○
被保険者氏名 生命 太郎
２、委任代理人
住所 〒○○○−○○○○
東京都○○区○○
電話番号 (03)○○−○○
氏名 生命 花子
契約者との関係 妻
