心のおもむくままに

・NHK 連続テレビ小説「ちりとてちん」面白いです。1日4回見ることもあります。1回見ただけではわからないような、凝った伏線がほんとに楽しい。落語にもはまりそう。「辻占茶屋」「次の御用日」とか聞いてみたいです。
・クロスバイク 今日も天気が良かったので、家の周りを30分ほど走ってきました。この程度では運動にならないですが、とにかくいい気持ち。F君からは、手賀沼のサイクリングロードを強く勧められているのですが・・・。ちょっと遠くて躊躇しています。
・Saecoで出したエスプレッソは日に４－５杯は飲んでいます。もう止められません。Nespressoは全く使わなくなってしまいました。
・ダンベル体操再開！あまりまじめにではないのですが、毎日やるように心掛けています。ああっ、今日はまだだ！
・アルファ＝リポ酸は、もう長いこと摂っていますが、体重を維持できているのは、これと、質素な食事のおかげと思っています。（体脂肪計で、代謝年齢20歳とか出ることがあります）
・ポカリスエットは、ドクターから勧められた最近の習慣。お風呂上がりとかに粉末とミネラル・ウォーターから作って飲んでいます。

最近のメールマガジンで2度、編集後記で、「眠い」とか書いている人々がいて、優雅だなあ、と思う一方、少々怒りがこみ上げてきました。
私には、とても眠気を感じている余裕などありません。
でも考えてみれば、眠くても眠れないとは、不幸ですよね。
そんな、能率の上がらない時間を過ごさなければいけない境遇とは、幸運にも決別できました。
自分で自分の時間をコントロールできるのがありがたいです。
会社勤めを、1日中、腕立て伏せをしているようなもの、といった人がいますが、私は、ストレッチをし、集中し、筋肉を鍛え、循環器に負荷をかけ、休憩し、またストレッチをし、というような感じでしょうか？
ルールは自分であり、「就職先は自分の会社」です。

今週のRadio.Meowingsの小特集は、Emerson, Lake & Palmerです。
高校時代に初めて、タルカスを聞いた時の衝撃は、今でもはっきりと覚えています。
それまでは、アメリカの明るいポップス、ロックに慣れていた私は、イギリスの暗い、しかも、こんなにストレートに感情に訴える音楽に大感動しました。
最近の若い人は、J-POPを聴いて、元気づけられたとか言う人がいますが、歌詞なしで、感動させるのが、本来の音楽の力だと思います。
この、Emerson, Lake & Palmerで、音楽の本来の魅力を堪能していただきたいと思います。

今日は、雨で、クロスバイクは、庭でカバーをかぶっているのですが、昨日は太陽のごちそうまで車の少ない道を選んでいきました。
いやあ、久しぶりにスピードを出して風を切って、ホントに爽やかでした。
一度、前輪だけブレーキをかけて、前につんのめりそうになりましたが。
快適でした。
こんなことなら、もっと早く買うのだったな。
サドルの高さも、硬さも、ほとんど気にならなかったですね。
次に晴れるのは月曜日になりそうですが、駅とは逆方向のホームセンターまで、空気入れを買いに行こうと思います。

第6章　統一性を作りこむ
そこで、チーフエンジニアの役割は、その車の設計が見えてきたら、最大の認知統一性を持たせられるようにトレードオフを判断できる環境を作ることなのだ。だから、チーフエンジニアは、エンジニアたちが多くのトレードオフと闘う中で、何に苦戦しているのかを理解しなくてはならない。そして、自分たちの決定がどのように製品の統一性に影響するかを、彼らが理解できるように手助けをするのだ。
伝統的には、要求は文書化され、アナリストのチームに手渡されるものである。そして、分析を行い、その結果を設計者に手渡す。設計者はソフトウエアを設計し、その結果をプログラマに渡す。どのようなコードにするかについて、日々の決定を行うのはプログラマなのだ。彼らはシステムの統一性について、顧客がどう受け取っているのかを理解した段階から、ドキュメント2,3個分離れている。そのドキュメントを引き継ぐたびに、かなりの量の情報が失われたり、誤解されたりする。最初から理解されていなかった詳細部分のキーポイントや将来の機能については言うまでもない。
あるモデルが有用かどうかを判断する方法の一つは、そのモデルが最新に保たれているかどうかを観察することだ。モデルを最新に保って、使えるようにしておくことが重要であると信じている人がいるが、私たちはその逆だと思っている。モデルが有用でなくなれば、メンテナンスされなくなるはずだ。一時的に役立つモデルを作り、それが最終的に使われなくなるのはかまわない。しかし、ただそれがいい考えのように思えるからというだけで、モデルを作ってメンテナンスをするのは、ムダである。モデルが熱心に参照され、メンテナンスされていたら、有用なモデルを編み出したということがわかる。
設計をテストとして文書化することで、開発者はそれがどう動くと想定されているかを正確かつ明快に理解しながらコーディングすることができる。これは、考えを洗練し、開発者がコンセプト統一性を持ってコーディングする助けとなる良い方法である。
自動テストスイートは、建築中の大きな建物のようなソフトウエアを仕上げる際に、システムの建築者に安全と通路を提供する足場であるといえる。この足場なしに、他のツールを効果的に使うことはできない。テストを作成すると開発が遅くなるように思えるかもしれない。実際には、テストはコストではなく、開発期間中とシステムライフサイクル全体の両方で利益をもたらす。
第7章　全体を見る
多くの人は、新製品を発表し大きな成功を収めている企業が、製品開発プロジェクトのコストやスケジュールを管理していないと聞くとびっくりする。なぜかって？コストとスケジュールがプロジェクト管理では重要なことである、と思い込んでいるからだ。コストとスケジュールは局所最適化のための計測手段であるということがなかなかわからない。そのうえ、コストとスケジュールに注目すると。究極の目的、すなわち顧客の要求に合致し、競争優位のある利益の高い新製品を開発して商売する、ということが見えなくなってしまう。
「測定したものしか得ることができない」という基本原則はこの場合でも成り立つ。重要なものすべてを測定できない場合、部分的に測定すると局所最適な計測手段となる可能性が高い。もし、ビジネス全体としての成果を最大化するのに必要な「すべて」を測定できないのであれば、局所最適化した部分的計測などない方がよい。中途半端な計測手段を持っていると、局所最適な行為を助長する大きな危険にさらされるだろう。
全てが測定されるような方法を確実に行うには、全体を測定すべきであり、分解して測定すべきではない。すなわち、測定手段を1段階下ではなく、1段階上へ移動させることだ。ニューコアは、個人ではなくグループの生産性を測定したことを思い出していただきたい。３Ｍは、製品のコストではなく、製品により生み出されるビジネスの利益性を測定する。
リスクは、それに最もうまく対処できる側が持つべきだ。定額契約では、本来顧客が対処すべきリスクが、ベンダーに移されているように見える。問題が技術的に複雑であれば、そのリスクに最もうまく対処できる立場にいるのはベンダーだ。だから、ベンダーがリスクを受けるのが適当だろう。しかし、問題がはっきりしない場合や変化している場合には、顧客がリスクを対処するのに最適の立場にいる。したがって、定額契約は避けるべきリスクである。定額契約が避けられない場合は、変更が入るのは確実なので、コストが決められた額を大きく超えるという事態を顧客自らが招くことになるだろう。
第８章　使用説明書と保証書
考えは大きく、行動は小さく、失敗するなら早く、学習は迅速に。

行動範囲を広げようと、買ったクロスバイク。
昨日の夕方、届きました。
昨日は梱包を解くだけだったのですが、今日は早速F君と、太陽のごちそうへ行くつもりです。
いつもは、太陽のごちそうのある、ショッピングモールへ、駅の近くから出るシャトルバスで行っていました。
駅まで10分かかるし、シャトルバスは30分おきだし、直前に行っても乗れないことがあります。
自転車だと15分くらい、と思うのですが、十数年、乗っていないので、ちょっと不安。
でも時間の節約と、メタボリックの予防と、エコに優しいということで、いいことづくめ。
前の日に、あらかじめ、雨除けのカバーとサドルの下のバッグと２つめのロックを買っておきました。
慣れてきたら、天気のいい日に、ちょっと遠出でもしてみるつもりです。
サドルの高いのが、少し抵抗があったのですが、意外と乗りやすそう。
F君が買った英国の車種は、サドルの高さを、工具がないと調整できなかったのですが、私の米国製は、レバーで調節可能でした。
楽しみが増えました。

第3章　決定をできるだけ遅らせる
プログラミングは、金型の切削とよく似ている。リスクが高い場合が多く、ミスが大きなコストにつながる。そのため、開発が始まる前に要求を確立しておくシークエンシャル開発が、深刻なエラーを防ぐ方法だと一般には考えられている。シーケンシャル開発の問題は、設計者が「広さを優先した設計手法」ではなく、「深さを優先した設計手法」を取らざるをえないということだ。深さ優先の手法を採ると、高レベルの決定の結果が出る前に、それが依存する低レベルな決定を下さなくてはならなくなる。もっとも費用のかかるミスは、最初の時点で、重要なことを見落とすことによって生まれる。そのような大きなミスは、詳細に速く掘り下げすぎた場合に最もよく起きる。詳細なパスを確定してしまうと、後戻りができなくなるし、後戻りすべきだということにも気付きにくくなる。大きなミスを起こす可能性があるなら、全体を見わたし、詳細な決定は遅らせるべきだ。
賢明な決定を下せる専門知識を備えた人を育てる方が、人の代わりに考えてくれると称する意思決定プロセスを育てるよりも、ずっと重要なのだ。
第4章　できるだけ速く提供する
急な事態では、情報が指揮系統のチェーンを上がり、そして指示として下す余裕はない。そのため、現場での情報伝達とコミットメントの方法を、それにふさわしいものに作り変える必要がある。そのために重要な要素の一つは、スケジュールによって作業を進める（プッシュする）のではなく、顧客のニーズが作業を引っ張る（プルする）ことだ。
第5章　チームに権限を与える
ワッツ・ハンフリーは、CMMの初期開発を先導した人物だ。彼は、訓練された、やる気のある人材がいなければ、ソフトウエア開発が成功することはない、と信じている。私たちはこの意見にまったく賛成だ。しかし、その「最も成功を収めやすい」というプラクティスには、敬意は払うが反対する。・・・私たちは、やる気に重要な要素は計測ではなく、権限委譲（empowerment）であると信じている。つまり、決定権を組織のできるだけ下位のレベルに移し、それと同時に、その人たちの聡明な決定能力を開発することだ。
私たちは、ある環境から別の環境へのプラクティスの移植は、間違いである場合が多いと、確信している。そうする代わりに、プラクティスの背後にある基本的な原則を理解し、それらの原則を、新しい環境に合わせた新しいプラクティスに置き換えなくてはならない。
モチベーションをくじかせる、最も簡単な方法の一つは、アメリカ軍で「ゼロ欠陥精神（zero defects mentality）と呼ばれているものだ。ゼロ欠陥精神は、絶対にミスを許さない雰囲気のことである。つまり、どんな些細なことにでも完全性が求められる。軍隊では、ゼロ欠陥精神をリーダーシップの深刻な問題であると考えている。なぜなら、それが戦場での成功に必要な率先力をそこなうことになるからだ。
人は、自分が置かれた組織の期待にこたえるものだ。プロセスやドキュメント、計画の厳守に価値を置く組織では、ソフトウエア開発のリーダーは、多くは生まれてこないだろう。組織が自らの価値を定義すれば、その価値にあったものが手に入る。

第2章　学習効果を高める
どういうわけか、可変性は悪であるという考えがソフトウェア開発に入り込んでしまった。ソフトウェア開発では、可変性をおさえ、毎回繰り返し可能な成果を得るために、標準化されたプロセスを作りだそうとしてきた。しかし、開発は繰り返し可能な成果を生み出そうとはしていない。開発とは、それぞれの顧客の問題に適した解決を作りだすものなのだ。
今日では、設計は、調査、実験、結果確認を短いサイクルで繰り返すことを通じて解を発見するという、問題解決のプロセスであることが広く受け入れられている。ソフトウェア開発は、あらゆる設計と同じように、そのような学習サイクルを通して行われるのが一般的である。
ソフトウェア開発の思考には二つの流派がある。一つは、開発者に、最初から確実に設計やコードを一つひとつ完璧にするように、と奨励する流派である。もう一つは、最初から設計やコードを確実に完璧にするよりも、小さく、迅速に試し、テストをし、失敗すれば正しくするというサイクルで進めた方がいい、という流派だ。前者の流派では、経験によって知識を得るのではなく、知識は熟考とレビューによって得られるものと信じている。最初から正しく進める前者の手法は、良構造問題に関してはうまく機能するだろう。しかし、試し、テストをし、直すという後者の手法が、悪構造問題には適している。
リファクタリングをともなったイテレーション、つまり、システムを発展させながらの設計改善は、知識を獲得し、早く答えを見つけだし、統一性のあるシステムを作り出すための、最も効果的な方法の一つであるとわかっている。
仕事をするのなら、それは、「直接顧客」のための仕事でなくてはならない。すなわち、だれかがどこかで、その仕事の成果を待ち望んでいる、という状況でなくてはならない。開発者は、直接顧客を知っているべきだし、その顧客が定期的なフィードバックを返せる方法を用意すべきである。問題が起きたら、最初にすべきことはフィードバックループがすべてうまくいっているかどうかを確認することだ。つまり、各自が自分の直接顧客がだれなのかを知っていることを確認する、ということだ。次にすべきことは、問題領域のフィードバックループを短くすることだ。
あらゆるアジャイルソフトウェア開発手法にも、あらゆる場面で適用するスタート地点がある。それは「イテレーション」だ。イテレーションは、ソフトウェアを設計し、プログラムし、テストし、統合し、提供するための、長さを固定した短いサイクルだ。製品開発でのプロトタイプと非常によく似ているが、イテレーションは最終的な製品の一部を、きちんと動作するように作りだすという点が違う。そのソフトウェアは、後のイテレーションで改善されることになるだろうが、最初からきちんと動作し、テストもされ、統合されてもいるのだ。イテレーションによって、シークエンシャルソフトウェア開発に比べてフィードバックの量が劇的に増加する。そして同時に、顧客やユーザーと開発者の間の、また、そのシステムに関心を持ついろいろな人たちの間のコミュニケーションが大幅に増加する。テスターは最初のイテレーションからプロジェクトの参加し、ハードウエアやソフトウエアの環境も早期に考慮される。設計の問題点は早期に見つかり。変更が入るごとに、変更に対する耐性がシステムに組み込まれていく。
ビジネス価値が最も高い機能を先に提供するため、最優先の機能から先に開発するべきだ。リスクの高いものは、後になってからではなく、早いうちから注意を向けておくべきだ。
スタンディッシュ・グループの研究によれば、典型的なシステムの機能のうち、45パーセントは一度も使われることがなく、19パーセントはほとんど使われることがないそうだ。プロジェクトが始まる時点で、顧客が自分の欲しいものを正確に知っていることはめったにない。そのため、彼らは必要かもしれない機能をすべて求める傾向にある。要求を出すチャンスが一度しかないと思えばなおさらだ。この方法をとると、私たちの経験上、プロジェクトの全体的なミッション以上にスコープを広げてしまう可能性が非常に高い。顧客にプライオリティが最も高い機能だけを要求させ、それをすばやく提供し、それから次にプライオリティの高い機能を要求させれば、重要機能のリストは短くなるはずだ。また、変化していく顧客の事情に対応することもできる。そのため、機能をプライオリティの高い順に並べ、上から順に手をつけていくのがいい。一般的に、この戦略を使えば、確保されたリソースがなくなるまでに、全体的なミッションを達成できるはずだ。
イテレーションは、実現可能な解決の一実証例としてとらえるべきであり、唯一の解決としてとらえるべきではない。早期のイテレーションでは、システムの残りの部分を、実現可能性のある多くの方法で実装できるように、幅広い余裕を残しておくべきだ。イテレーションが進み、さらに選択されていくにつれ、設計の余地は徐々にせばめられていくべきなのだ。

アジャイル開発を実践する22の方法
マリー・ポッペンディーク/トム・ポッペンディーク
平鍋健児/高嶋優子/佐野建樹訳
日経BP社
1日30分は勉強することにしているのですが、読む本がなくなったからと言って、期待せずに読み始めた、積読だった本書。「はじめに」と「イントロダクション」だけで衝撃を受けました。実に鋭い考察の数々。これから何回かにわたって、そのエッセンスをお送りします。
はじめに
CMMやPMIを非難するわけではない。ただ、産業界でのリーン改革を経験してきたものから見れば、それらはソフトウェア開発にムダな要素を与えやすいように思える。ソフトウェア開発のパラダイムを、プロセスから人へ、ばらばらの個から集団へ、推測からデータにもとづいた決定へ、計画から学習へ、トレーサビリティからテスティングへ、コストとスケジュールの管理からビジネス価値の提供へと変えることが、本書のねらいである。
高品質と低価格とスピードは、本当に共存できないのだろうか？リーン手法を知る前、製造や製品開発を行っていたころには、私たちも「できない」と思っていた。しかし、価値とフローと人に焦点を当てることによって、高品質、低コスト、迅速な出荷を実現できる。それを私たち自身、市場からから逃げ出していった競合他社から学んだのだ。
イントロダクション
メタファを使いあやまった場合にリスクがあることを承知で言えば、ソフトウェア開発は製造ではなく製品開発と似通っていると私たちは信じている。
製造の最終段階での変更による莫大な損失の回避方法として、最初から設計に関して正しい決定を下し、それ以降、変更する必要をなくす、という方法がある。これがデトロイトの手法だ。トヨタやホンダは、設計に関する不適切な決定の損失を避けるのに別の方法を発見した。それは、「取り消しのきかない決定を最初にしないこと」だ。設計に関する決定をできるかぎり先延ばしにし、決定するときには、わかっている情報を総動員して、正しく決定する。この思考は、トヨタが開拓したジャストインタイム生産の背後にある、「顧客の注文を受けるまで、何を作るべきか決めてはいけない。注文を受けてから、できるだけすばやくそれを作れ」という思考に通じるものがある。
「原則」が、ある分野についての指針となる考えや洞察であるのに対し、「プラクティス」は、原則を実行するために、何をするか、である。原則は普遍的なものだが、それらが特定の環境にどう当てはまるのかが、わかりにくい場合もある。一方プラクティスは、何をすべきかについて明確なガイダンスを示してくれるが、それぞれの分野に適応させる必要がある。私たちは、「ベスト」プラクティスなどというものはない、と信じている。プラクティスは、コンテキストを考慮しなくてはならない。
ムダを排除する。
ムダとは、顧客が認める価値を、製品に付加しないもの、すべてのことだ。リーン思考では、ムダという概念を最大の問題としている。部品がちりの積もった棚に置かれたままになっていたら、それはムダだ。要求を集めた文書が、使われないまま埃をかぶっていたら、それはムダだ。製造工場が、すぐに必要となる以上の量を生産しているのなら、それはムダだ。開発者がすぐに必要となる以上の機能をコーディングしているのなら、それはムダだ。製造の過程で、製品をあちこち移動させるのはムダだ。製品開発において、あるグループから別のグループに開発を引き継ぐのはムダだ。理想は、顧客が欲しがっているものが何かを見つけだし、製造するか開発して、顧客が要求するそのものをただちに納品することだ。顧客のニーズをすぐに満たすのにじゃまとなるものはすべて、ムダなのだ。
決定を遅らせることには価値がある。なぜなら、推測ではなく、事実にもとづいている方が、より的確な決定を下せるからだ。成長中の市場では、早期に確定するよりも、いろいろな設計オプションを選択可能にしておくことに価値がある。複雑なシステムを開発している場合に、決定を遅らせるためにキーとなる戦略は、システムに変更可能性を組み込むことだ。

尊敬するSteve McConnellの会社、「Construx Software」の提供している無料の見積りツール。
これは規模(LOC)から工数（人月）とスケジュールを計算するツールです。
今回、新しいお仕事で、ファンクションポイントとファジー理論で規模を見積もって、McConnellのツールで工数を見積もったのですが、これが極端に小さい。
規模が小さすぎるということで、信頼性は低い、と表示されるのですが・・・。
米国のエンジニアはものすごいんだろうか？
作るだけだったら、できるかもしれないですが、テストはしなければいけないし、ドキュメントは作らなければいけないし、簡単に倍になってしまいます。
ということで、今回は、私の過去のデータを使いました。
規模を見積もるツールは、Accessで自作しています。ファジーの場合は過去のデータが必要になりますが。
デマルコは「測定していないものはコントロールできない」と言いましたが、データ収集は重要です。
今度は、その質を高めていこうと思いますが、目標は収集ではなく、コントロールの方です。
また、収集が、生産性を下げないように、工夫も必要です。当たり前のことですが。