心のおもむくままに

Radio.meowings.comでジュディー・コリンズの小特集をやっています。10月5日までです。
4枚のCDから12曲をセレクトしました。
もともとは、「青春の光と影」を聴きたくて、CDを買ったのですが、その澄んだ歌声にノックアウトされました。
それに若いころは、澄んだ大きな瞳のほんとにきれいな人だったのです。
今でも元気に活動しています。
遅ればせながら、ファンの末席に・・・。

ずいぶん前からデスクトップPCはデルを使っています。
きっかけは、今はもう廃刊になった「日経バイト」のレビューで評価が高かったからです。
最初のマシンは Pentium 90MHz でした。（蛇足ですが、今、このマシンはピース・ボートに乗ってブラジルに渡り、スラムの貧しい人々に使われたはずです。）
デルのいいところはOptiplex等に標準でつている、3年間、オンサイト翌営業日修理のサービスです。
このスピーディーなサービスに、今まで2度、助けられています。
先日も単体で買ったディスプレイが、若干色むらが出て、連絡したら、3年間保証で、在庫があるので、すぐ送る、と、翌々日に届きました。
こういう対応は実に素早い。
一方で、マニュアルに載っていない、前例のないケースについては、まず、やってくれません。
今まで、2度そういうことがありました。
1度目は、アウトレットで買ったOptiplexを縦置きにしたかったので、スタンドだけ手に入れたかったのですが、これがどうしてもダメ。
2度目は、メモリ増設で、仕様を電話で聴いて、スロットが4つということだったので、もう2つ入るな、と思ってメモリを購入したのですが、開けてみるとスロットは２つで、もう埋まっている。何とかメモリ購入費用を返してもらいたかったのですが、言った言わないの議論になり、上司まで出てきたのですが、どうしてもダメ。
こういうとき、ノードストロームのように、従業員に、柔軟な権限を与えて、ある程度の額なら自由に使えるくらいの度量が必要だと思います。
そういうわけで、コードアニマートの社則は、ノードストロームと同じにしました。
「どんな場合でもあなたがベストと思える判断をしてください。それ以外に規則はありません。」

登記が終わった後、まだやるべきことがあります。
税務署への届け出、都道府県税事務所・市町村役場への届け出、社会保険事務所への届け出、労働基準監督署とハローワークへの届け出、銀行口座の開設です。
このうち、税関係は、依頼した行政書士の方の提携した税理士の方が無料でやってくれます。非常にありがたいです。
後は自分でやることになるのですが、なんとかなりそう。
当初考えていたよりも後処理が大変です。
それよりもなによりも、事業を軌道に乗せることが、最重要課題なわけですが、相変わらず、本を読み、ネットを調べ、マインドマップを発展させて戦略を作っています。
今日、読んだのは、有名な神田昌典の「あなたの会社が９０日で儲かる！」です。たった１，５７５円の投資で、これだけの情報を手に入れられるとは、非常にお勧めです。おかげで集客までのストーリーが見えてきました。

法人化した時の名刺を考えています。
坂上仁志さんの「日本一わかりやすい　会社の作り方」を参考にしているのですが、ここに坂上さんの素晴らしい名刺の例が載っています。
顔写真を使う、裏面も使って情報を目いっぱい詰め込み、忘れられない名刺を作るのです。
限られた文字数で、キャッチコピーや事業内容や、PRポイント、考えていること、商品の説明、実績、経歴、趣味などを詰め込みます。
名刺を作るプロセスは、自社について考える非常にいい機会です。
坂上さんは、10回以上、作りなおしたそうです。
また坂上さんが利用した、名刺作成会社、VistaPrintは安価で、自由に編集もでき、本当に素晴らしい会社です。現在、通常の価格の半額で作れますが、ユーザ登録することで、さらに半額になります。お薦めです。
文章は大体できたのですが、写真がちょっと問題。
近所の写真館で撮ったのですが、表情が硬い。
なんとかいい写真が撮れないかとネットでカメラマンを検索したのですが、当然のことながら、かなり高い。
WEBの素材を作ってもらっている、Nさんに相談したところ、NTさんというカメラマンを紹介していただきました。
交渉の結果、かなり安い料金で、撮ってもらえることに。
でも撮影用にシャツとか何枚か買ってきたので、その費用もかかりました。
10/5の会社設立になんとか間に合うか、というところです。

第11章　安定的ソフトウェア工学の構成要素
しかし最終的にはなすべきことを知るだけでは十分ではない。ソフトウェア障害の最大の原因は、管理層の性格と人格の障害であって、こうしたあまりにも人間的な障害が組織的変革を制限している。階層組織における管理者の職権故に、彼らの小さな愚行すら文化変革の最善の努力を水泡に帰してしまう。管理者は適合的に行動する必要があり、そうでないかぎり結果は破局に到る。
構成要素は根本的なだけに、改善をたやすいものと思ってはいけない。多くの組織で、改善を目指すソフトウェアプロセスを吟味する試みは、強い政治的反対に遭遇する。権力構造が専断的であればあるほど、あからさまな検討がもたらす脅威は大きい。
第12章　プロセス原則
テストの省略や後工程への遅延を許すな。工程周期の終りのほうへ押しやられたものはなんであれ、スケジュールのために犠牲にされる。
統計的プロセス制御は、ソフトウェア制御に適用できないと主張する人々を信用するな。彼らに欠けているのは、そうした制御を適用する正しいレベルととるべき適切な行動である。たとえば、彼らはコードの欠陥を計測するかもしれないが、その情報を設定されたしきい値を満足しない個人を責め苛むために用いるのだ。
どんな事柄でも不可視になるのを許すな。要件も、設計も、コードも、とくにテストはいけない。予防は治療よりもはるかに容易なのだ。
第13章　文化とプロセス
長い目で見て社会の強さは、ふつうの人々が自主的に行動するしかたに依存する。ふつうの人々は非常に大勢いるから重要なのであり、始終すべての人びとの監視などできないから、自主的な行動が重要なのである・・・。この自主的な振舞いこそ、わたしのいう「文化」なのだ。—-J.ファローズ
管理層が伝達するすべての主題が意図的だとは考えられない。今日のソフトウェア組織に共通する主題は、意思決定してもそれを遵守できないことである。この主題は、管理層がする何かによってではなく、ほとんどは管理層がしない何かによって伝達される。
中間管理者が、自分の仕事を適切にしている場合、何がなされるかではなく、どのようになされるかにかかわっている。つまり彼らは、実際になされる事柄の背後にある理想モデルにかかわっているのだ。
フィル・フーラーの示唆：「わたしが組織文化に使用するリトマス試験は、別種の問題に遭遇した時の彼らの生産性である。たとえば、あるスイッチングシステム開発組織は非リアルタイム・クリティカルシステムにどのように取り組むだろうか？彼らに、新しい状況にどのように取り組むか尋ね、それから学習にどんなプロセスを用意するか注視すれば、多くの事柄を発見できる。」
第16章　要求定義プロセスを改革する
多くのソフトウェア組織にとって、高品質実現の主要な障害は不十分な要求定義（要件）プロセスである。
要件文書はソフトウェア製品によく似ている。それはソフトウェアのように情報製品であるから、
・可視化しなければならない
・安定させなければならない
・制御可能にしなければならない
粗悪な管理状況下では、要件の可視性はコードのそれより低くなったりする。プロジェクト内の人びとは少なくともコードについて考えるが、往々にして要件のことは忘れてしまうのだ。もっともよくあるタイプの要件欠陥はおそらく、プロジェクトの内の誰もある分野の要件について考慮しなかったというものである。よく忘れられる要件はたとえば、性能、操作性、保守性、セキュリティ、現行データの変換、現行システムとの統合、そして製造へのカットオーバーである。
管理者が要件落ちのないように保証する最も効果的な方法は、疑いもなく、要件開発をちょうどソフトウェア開発のように現実のプロジェクトに仕立てることによって可視化することである。
第17章　プロジェクトを正しく開始する
プロジェクトを制約する意思決定につながる一連の高レベルの交渉が、すべてのプロジェクトに先行している。情報が揃っていてかつ適合的な交渉でなければ、プロジェクトは開始以前から命運が尽きている。
以前この企業の「計画作業」たるや、リスク問題を提起した者全員がすでに策定済みの「計画」にこみっとするまで、焼きを入れるという意味だった。
問題はしばしば、明確化に対する組織の恐怖に根ざしている。顧客は明確な要求定義を文書化すると、文書化した要件を満たすシステムが現実の必要を満たさなくなる場合、変更を発案した責任を負わなければならなくなる。開発者のほうは明確な要件を文書化すると、それを満たす説明責任を負わなければならなくなる。コストとスケジュールの見積りが不正確だとわかってしまうと、自らをリスクにさらす可能性がある。したがって。顧客と開発者は正反対の動機で動いているにしても、暗黙のうちに共謀して、「成熟度モデル」の要件管理慣行の履行を阻止しかねない。
注力時間報告をプロジェクト追跡に用いるな：それは単なる入力の計測であって、出力の計測ではない。努力ではなく成果を計測せよ。
管理レビューは、管理層への輝かしい報告ができないプロジェクトを懲罰する方法として、非難文化において愛好されている。
第18章　プロジェクトを正しく持続させる
計画は、敵の最初の一手までは有効である。—-チェスの格言/軍事の格言
プロジェクト途中の管理者の仕事の多くは、不測の事態に対処するために一種類のスラック（余裕）を他の種類のスラックと交換することなのだ。
逆説的だが、人びとはスラック（余裕）を時間の浪費と考えて嫌悪するが、ほとんどのプロジェクトは、スラックを許容したほうが速く進捗する。
第19章　プロジェクトを正しく終結させる
これらのプロジェクトはスターリンの産業化政策の特徴だった。それは、小規模のプロジェクトよりも巨大プロジェクトを、安全性よりも成果を、人間よりも技術を、現場の自発性よりも硬直した中央集権的計画を、批判的論争を犠牲にする密室的意思決定を、そしてとりわけ狂気じみた猛進を重視したのであった。—L.R.グラハム
おそらく良い管理者の最大の挑戦と試練は、終結すべきプロジェクトを終結すべきときに終結する能力である。
「レビュー可能でない」ということは、それ自体が一つのレビュー結果である。もしレビューできていないなら、それが正しいわけがないし、出荷すべきではない。
ほとんどの遅延プロジェクトは、コーディングがかなり進捗するかもしくはテスト作業が始まるまで、日程通りにいっているように見える。そのとき、早期に行ったあらゆる便法的作業がテスト作業を遅らせて行き詰まり、プロジェクトが頓挫する。欠陥予防あるいはインスペクションを通じて早期に品質管理をしたプロジェクトは、テスト作業を一気に通過する。—ケイパース・ジョーンズ
士気は、プロジェクトの成功確率についての全メンバーによる総合評価と考えることができる。
第20章　小さく構築し、構築を加速する
構築プロセスの加速に活用できる基本戦術が二つある：
・構築能力を増強する
・構築規模を縮小する
結論からいえば、スケジュール延長が遅い時は、必ず少なくとも2週間は無駄になると覚悟したらいい。つまり、スケジュールを2週間延長しても、読者にとって何にもならないということだ。もしそれが読者への最良の提案でも、それを呑むな。スケジュールと資源の余裕（スラック）は、問題を増幅させるためではなく問題を解消するために、許容しなければならない。読者がもっと早くに延長すれば、こうした影響は軽減される。事実人びとは、おそらく予定日の2か月前ならばわずかな延期は気にもとめない。
後から出てくる要件を追加するために、わずかな追加時間をやすやすと受け入れる罠にはまるな。システム規模のダイナミックスは非線形だから、後から出てくる要件の影響の見積りにあたっては、かなり気前よく構える必要がある。
これらすべてを勘案すると、当初計画が200人日のプロジェクトは、所要規模が10パーセント増加すると、うまくいっても250人日以上にはやすやすと延長しかねない。既に100日経過した後で新規案件が出てきた場合は、その撹乱効果のために延長分はもっと大きくなる。
「人助けモデル」を銘記せよ：ほとんどの場合、見かけによらずすべての人びとは協力的たろうと心がけている。一般的に、顧客はただソフトウェア品質ダイナミックスを理解していないだけであり、それは読者の専門で彼らの専門ではない。
第21章　情報資産を保護する
通常、標準の影響は多くの小さな節約からなるため、標準の資産価値はややもすると見落とされる。読者に標準があれば、すくなくとも管理すべきコードがはるかに少なくなるので、構成管理ははるかにやさしくなる。
多くの開発者は、コードを書いているときはかなり慎重でも、単体テスト作業のときには修正作業に熱中して、原バージョンが保有していた設計完全性をすべて破壊してしまう。この過程で彼らはまた、モジュール履歴についての価値ある情報も破壊する。
「予知」（パターン4）組織を創造するには、読者は過去を知らなければならないが、それは他に未来予測法がないからだ。マシン上で開発したものはなんであれ、アーカイブに格納できるし格納すべきであり、アーカイブはたえず更新しアクセス可能にしておくべきである。
第22章　設計を管理する
プロセスエラーもまた管理の悪い組織では深刻であるが、ほとんどの欠陥は要件と設計で発生する。重複作業、完全消去、更新不履行、そしてソースコードの版管理のようなプロセスエラーは、開発プロセスが原因となっている。これらの多くはプロセス改善で対処でき、それはまさに管理の責任である。
良い設計が本質的であるのは当然として、管理者たる読者はそれについて何をすべきか？一つはっきりしているのは：読者自身が設計者たらんとはしないことである。もし読者がそうしたいなら、管理者をやめて第一線に戻ることだ。しかしちょっと努力すれば、組織が最悪の設計ミスを予防するのに少なくとも手を貸すことはできる。
人びとに修正モードの思考を強要するな。圧力をかけるな。そうすればシステム寿命は長くなる。これが単体テスト作業をコーダーにさせない一つの理由である。
性能の最後の10パーセントが、コストの3分の1と問題の3分の2をもたらす。
読者があるホテルにいるとしよう。誰かが火事だと叫ぶのを聞く。消火器のところへ走り、警報気を引いて消防署を呼ぶ。全員外に出る。消火活動はホテルを改善しない。それは品質の改善ではない。それは消化なのだ。
設計にスラックを許容せよ。設計を限界までプッシュするな。スラックを性急に譲歩するな。スラックは鬼札のようなものだ：ほとんどどんな手でもそれを使えばよくなるが、一度使えばそれきりである。
要求を小さく、スラックを大きく保つことによって、要求と可能性のギャップをなるべく大きくせよ。多くのソフトウェア企業の没落は、これまでつねに、自社製品にすべての種類の機能を搭載した結果、2年の遅れをきたしてマーケットシェアを失ったことが原因だった。
設計が障害を起こしてしまう環境を三つ考えつかなければ、その設計についてまだ検討が足りないのだ。
設計が解決しなければならない矛盾（パラドックス）がまるっきりないなら、あなたは問題を理解していないのだ。
第23章　技術を導入する
必要なのはツールを増やすことではなく、またツールを特効薬と信じる管理者を増やすことでもなく、入手するツールからもっと多くの利益を引きだす管理方針なのだ。
ＩＶ　エピローグ
誰もが自分の運命を自分なりのやり方でまっとうしようとしており、親切で寛大で忍耐強くある以外に、誰しもそれを手伝うことはできない。—ヘンリー・ミラー

現在、法人化の最中です。
参考書を2冊買って、当初、自分でやるつもりだったのですが、時間がもったいないことと、何度もやることではないので、勉強してもあまり意味がないことから、プロに任せることにしました。
自分ですべてやるより、10万位割高なのですが、このくらいは、妥当なところだと思います。
10日から2週間で完了してしまうとのこと。今のところ、10月5日を目標です。
でも本当の仕事は、法人化した後ですね。
営業のやり方について勉強中です。
本を読んだり、ネットを調べたり・・・。
集客は、アイディアと発想がすべてということなので、腕の見せ所かもしれません。

またまたF君と食べ放題。
「太陽のごちそう」から数分と離れていない、ちょっと小さめな「わらべ」。
住宅地の中にあります。
2時近くに行ったのですが、かなり混雑していました。
こちらは、野菜類が中心で、タンパク質はあまりありません。
みんな丁寧に作られたお料理です。
F君は、「太陽のごちそう」よりもこちらがいいという。
たしかに、おいしいし、ドリンクバーは込みの料金だし、エスプレッソやカプチーノも飲めます。
デザートのチーズケーキも濃厚でおいしかったです。
「太陽のごちそう」にあった点心がないのが残念。
F君のおかげで、またレパートリーが増えました。
F君、また付き合ってね。

以前、スポーツジムの顧客・スケジュール管理のASP.NETのソフトを作ったのですが、そのスケジュール管理だけを取り出して、ASP.NET2.0で、そしてもっと軽く動作するプロトタイプを作成中。
データベースのテーブルが大きくなるのと、GridViewも列数が半端じゃないので、（しかもASPXファイルの編集が必要）二の足を踏んでいます。
まったく退屈な繰り返し作業が待ち構えている・・・。
単純なプロトタイプではうまくいっているので、動くはずなのですが。
ポイントは、どこまで軽くできるか。
以前のプログラムは、かなり重かったです。データベースのつくり方のせいで、DataGridの表示に時間がかかっていました。（SQL Serverにも負荷がかかっていました。）
今回は、その原因を分析して、データベースを設計し直しました。
連休明けあたりに公開できるかもしれません。

時々、話をする、向かいの畑のおばあさん。
フーちゃんが行方不明になった時も、親身になってくれました。
先日も、買いものから帰ってくるときに出会って、お天気の話とかをしたのですが、おばあさんは、今とってきた、キュウリを2本くれました。
本当にとれたてで、お味噌をつけていただきました。
普段は野菜ジュースくらいしか摂らないのですが、みずみずしいおいしい野菜です。
食感がいいですね。
おばあさんも、犬や猫が大好きということで、いままで、いなくなって悲しい思いをしたことも多々あるようです。
隣の奥さんが、フーちゃんを足蹴にしていた、と教えてくれたのも、おばあさん。
畑仕事をしているときには、わざと挨拶を無視することもあるのですが、見るべきことはちゃんと見ています。
フーちゃんが帰ってきたときにも、本当に喜んでくれて、何か気持ちが通じるところがあります。
いつまでも元気でいてほしい。

昨日の晩、真夜中に、歯が痛くなって目が覚めました。
しばらくしてまた眠ってしまったのですが、今日、早速、歯医者さんに行こうと思ったら、どこも予約がいっぱい。
ダメもとで、駅近くの新しい歯医者さんに直接行って、夜眠れないと困る、と訴えたら、先生本人が出てきて、では、○○時に来てくださいと、ＯＫ。
多分、電話で、受付の女性と話しただけでは、断られたでしょう。
直接行って、訴えることで診察してもらえました。一種のトリアージですね。
肝心の原因は、レントゲンを撮って、どうやら、親知らずが炎症を起こしているらしい。そこでは親知らずの抜歯はできないということで、抗生物質をもらってきました。
そういえば、何年か前、反対側の親知らずを、別の歯医者さんで抜歯してもらった記憶があります。
今度悪くなったら、そこへ行こう・・・。