リーン顧客開発を試している

シンディ・アルバレスの「リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES) 」を読んで、実践しはじめた。リーン・スタートアップから派生したシリーズの本で、原題は「Lean Customer Development: Building Products Your Customers Will Buy」という。副題は「顧客が購入する製品を作る」というところか。



売れる製品とは、誰かが金を払うだけの価値を見出しているからだ。つまり、その誰かの課題を解決している。

この本は、課題の設定がそもそも妥当なのか？ 解決策は妥当なのか？ を検証する方法を紹介している。具体的には、想定顧客へのインタビューを通して、仮説を検証するガイドである。

リーン・スタートアップ関連の本を読んで、いつも「製品を作る前に、潜在顧客に話すの？」と懐疑的だった。けれど、軽い気持ちとは言え、いくばくかの時間をかけて作ったちょっとしたオンラインツールに、ぜんぜんアクセスがないという経験をした。2つ連続で。

需要があるのか？ そもそも課題設定も妥当なのか？ 妥当だとして、どうやって人を引っ張ってくるんだ？ という問に、まったく答えられないことを認めざるをえない。この本にも「製品/サービスの機能よりも、流通、価格、協業あたりにリスクがあることが多い」と指摘されている。おぅふ。

そんなわけで、課題の想定が妥当かのインタビューの準備をしている。インタビューの練習くらいの気持ちで、身近な知人と話しただけで、いきなり学びがあって驚いた。来週も、知人にインタビューのお願いをしてある。

原泰久 / キングダム 1〜37巻

ニート生活もだんだん充実してきつつも、ちょこちょこ仕事を請け負っている。その取引先の人に勧められ、読まないがために取引を止められると辛いので、キングダムを読んだ。低い身分の少年の、戦士としての出世物語だ。

春秋戦国時代の末期がベースになっている。何百年もの平衡状態が崩れて、秦が中華を治めるタイミングなので、大きな変化があった時期なんだろう。ストーリーとして、そもそも面白くなる時期なのだと思う。

七国が入り乱れているので、登場人物が多い。主要人物だけでも描き書き分けが難しくなりそうだが、大きな脚色を加えてある。秦の武将だけでも結構な人数なので、王騎はオカマっぽいキャラになっているし、羌瘣や楊端和は女性という設定になってる。そして記録があんまり残っていない李信を、分かりやすい主人公的なキャラクターに仕上げている。キン肉マンや桜木花道のように、考えたことがそのまま発言と行動になるような。

信を主人公として見たキングダムは、大塚英志の「物語の体操」に書いてある（と思うんだけど）、英雄物語の王道ストーリーになっている。英雄が何らかのハンデを背負ってスタートし、ハンデを克服したり、新たなアイテムや仲間を得て、大きな目的を達成していく話だ。

もともと始皇帝が英雄伝説テンプレートに則ってるけど、キングダムは周辺の人物を軸として、英雄物語になっている。他の登場人物もフラクタルのように英雄伝説を生きていて、たとえば王賁はエリートだけど、父にあんまり直接可愛がられてない、とかだ。

史記（の一部）とキングダムの関係は、三国志と三国志演義の関係みたいな感じだろうか。読んだこと無いけど。史実に創作をかぶせている。宇野常寛の「リトル・ピープルの時代」でいうところの、いまどきの創作っぽい。現実に創作をかぶせているとか、主要人物が読者に近いところにいるように見えるところとか。

諸葛亮孔明や劉備玄徳だと、大ボス感がありすぎてビッグブラザー的になってしまう。始皇帝だって大ボスなんだけど、下僕の立場である信と漂から物語がスタート → 漂と瓜ふたつの政（始皇帝）という設定にすることで、一気に近づけてしまっている。信がタメ口をきくから余計に近くなる。リトル・ピープル的というのは、そういう意味で。

羌瘣も政も、過去が少しずつ無理なく明らかになっていく。たとえば羌瘣は、最初はまったく謎の戦士である。そうしないと、信の戦闘物語とごちゃごちゃになってしまうのだと思う。映画「バンテージ・ポイント」みたいに、同じシーンをスピーディーに何度も複数の視点で見せられればいいんだろうけど、漫画では、とくに週刊誌の連載では、くどいくなりし、だいたい進展が遅くなるんだと思う。たとえば、事前に羌瘣が戦から離脱 → 信の戦が一段落 → 羌瘣が復讐を果たす過程で、過去が明らかに、という順序になっている。

国同士の戦闘なので殺人シーンが多いのと、殺せとかいうセリフが多いので、うわぁ... って思ってしまうんだけど、まあ時代的にはしょうがない。アニメ化するときはきっと大変だったんだろう。

というわけで、先週の金、土、日は、抜歯の痛みに耐えながら、キングダム 1〜37巻を読むだけで終わった。ニート生活万歳。交際費として経費にできるかなぁ。

   

カズオ・イシグロ「日の名残り」

圧倒的らしい本

quipped の人の「２０１４年に読んだ本」をながめていたら、カズオ・イシグロの「日の名残り」という本が紹介されていた。

Bezosはこの本を、「たったの10時間、主人公の人生を覗くことで、人生と後悔について教えてくれる本だ」と評していたが（Bezosは後悔最小化フレームワークの提唱者である）、自分の感想は、社畜ライフの最大の悲哀は、社畜であるという自意識の欠乏だということ。今年読んだ小説では、圧倒的に印象に残った。

それほど圧倒的なら、ということで、読んでみた。だが和訳。「わたしを離さないで」（Never Let Me Go） と同じく土屋政雄の翻訳だ。

みんな

家が火事になったらどうする？　家族全員を今に集めて、どの逃げ道が最適か一時間も討論するか？　昔ならそれでよかった、昔ならな。だが、世界はすっかり複雑な場所に変わってしまった。その辺を歩いている人が、誰でも政治学と経済学と世界貿易のことを知っているとは期待できない。

みんなで意見を言い合おうとか、誰の意見にも一理あるとかで、広く意見を集めるというのは、問題解決の手段としては必ずしも適切ではない。とは常々考えている。

基本的な物理現象を理解できない人が、発電所の稼働に反対/賛成だと思うのは勝手だけれど、わたしと意見が同じかどうかに関係なく、直接的な意志決定に関わらないで欲しい。

※ 異なる視点を取り入れること自体に、文句があるのではない。念のため。

後悔

最小化/最大化するという考え方が好きだ。ネガティブなことを完全に無くすのは大変だけれど、最小化するのが現実的なことがある。たとえば、サーバダウンタイムをゼロにするとの、最小化するのは大きな違いがある。

Python 温泉アドベントカレンダーで「プログラマになって、後悔がある」と書いたことに対して、Twitter なんかで反響があった気がする。後悔しないほうがいいけど、わたしはどっちに転んでも後悔はするところまで来ている。子どものころ勉強しなかったとか、高校で合コンにもっと行っとけばよかったとか、取り返しのつかない後悔はいっぱいある。遺憾ではある。なので、今後の人生で、後悔を最小化する方向に倒している。

プログラマになったことにより、いろいろと後悔はある。けれど、プログラマにならなかったら、もっと比べ物にならないくらい、大きな後悔をしただろうと考えている。

A と B を選択があるとき、どちらがより小さな後悔で済むだろう？って考える。ベゾスの後悔とはわたしの後悔は違うかもしれないけれど。

バイアス

この作品の登場人物のひとりが、自己弁護というか、自己肯定というか、とにかく自分がよく思われるように話す。嘘ではないけれど、歪んで伝わってくる。意図しているなら、信頼できない人物である。

問題は、その人物はものすごく大きな感情バイアスが働いてるかも知れない、ということだ。自分が正しいと信じたいがために、歪んで認知しているかも知れない。

後悔を最小化しようとするときには、注意が必要だ。心理的不協和を解決するために、後悔をせずに、これでよかったんだ、肯定してしまうかも知れない。

というわけで

慌てて読んだこともあって、圧倒的な印象は残っていない。読み込めていない感があるので、注意深く再読したい。

森博嗣「サイタ×サイタ」

ネタバレです。そのつもりで。ミステリーについては言及しません。いつもの小川や真鍋が、素行調査を請け負うのだけれど、その過程で...という話。

「できなくもないっていうのは、できるけれど、それなりに高くつくという意味だ」
「お金ですか？」
「まあ、そう、一般的には……」
「知りたいですけれど、今の仕事とは関係がありませんから、ちょっと無理ですね」

ソフトウェア開発を彷彿とするやりとり。調べる/実装することはできるけれど、時間＝お金かかりまっせ。

「つまり、それほど親しくもないけれど、知合いの人物から、恐いから助けてくれ、もう死んだほうがましだ、なんて言われて、放っておいたら自殺しかねない、という状況だったら、ということです」
「うーん、ちょっと待ちなさいって言いますね」
「でも、相手は電話を切ってしまう。どうします？　放っておきますか？　自殺したいなら自殺すれば良いって、そう割り切れますか？」
「うーん」小川は唸った。自分は何を考えているのか、と思った。
「僕は放っておきますよ。」真鍋が横で言った。「死ぬのはその人の自由だと思います。すぐ助けに来て欲しいと言われれば、行くかもしれませんけれど、自殺します、と言われても、たぶん、警察へ電話をするだけですね」

話題が話題だけにセンセーショナルな感じだけれど、究極的には「頼まれもしないことを、するのか？」という話だ。頼まれていないことは、やらないように努めようとしている。頼み方が下手とか、頼みにくい状況というのは考慮するけれど。

先回りして「こういうことを、したほうがいいかも」と思うことがあって、ついやりたくなってしまう。やらないように努めているけれど、ついやってしまう。

気をつけないと「俺がやってやったのに」みたいに思ってしまって、DVとかストーカーとか、そういう方向に行きそうで、恐ろしい。

プレゼントを渡されるのが嫌だ、とよく言っているのは、自分にDVやストーカーのメンタリティがありそうだからだ。頼まれた場合をのぞいて、プレゼントは「喜んでもらいたい」という渡す側の動機でなされる。したがって、喜ぶかどうかの責任は、渡す側に 100% ある。けれど、受け取ったプレゼントを気に入らなかった場合にぞんざいに扱うと、受け取った側に責任が押し付けられる印象がある（せっかくもらったんだから喜べ、的な）。渡す側に動機と責任があっただろう、と。

頼まれもしないことをすると、いろいろややこしいなぁという話でした。

田村耕太郎「頭に来てもアホとは戦うな」 〜 最優先事項を最優先する

イラッとしていることが顔や文章に出やすい。もちろん問題だとは思っている。

というわけで、田村耕太郎「頭に来てもアホとは戦うな」を読んだ。他人を見下す「アホ」という言葉が使われ、この本の中でもそういうニュアンスで使われている。けれど、後半に読み進めるにしたがって、アホへの対応というのが本質的な問題ではないことが説かれていく。

最優先事項を最優先しろよ、ということである。自分の正しさを証明したり、自分の優秀さを認めさせたりすることを優先させると、目標の達成から遠ざかるということだ。最優先事項である目標の達成のためなら、相手の矛盾を見逃す、非がなくても頭を下げる、権力にすり寄る、一時的に手柄を誰かに渡すということも、手段のひとつになり得る、と考えればよいのだ。

当たり前だろって人には、この本は既出すぎる。ピンとこない人には、もしかしたら新しい視点を提供してくれるかも知れない。

平等なマネジメント、公平なマネジメント

1分間ナントカシリーズ、タイトルが胡散臭いと思ってたのだけれど、どっかのブログで高評価だったので、ブランチャードらの「1分間リーダーシップ」を買った。結論から言うと、学びがあった。

ばらつきが課題

前提として、私は4人のソフトウェア開発者がいるチームの、開発プロジェクト管理をしている。要件を定義したり、工数から考えてどの順序で作るかを決めたり、そういうことをしている。開発者は私の部下ではないけれど、この本では部下と書いてあるので、部下という言葉を使う。

開発者によって得意分野、習熟度、問題解決、コミュニケーションにばらつきがある。

部下のステージに合わせたマネジメント

この本で提案する方法では「部下がとりくむ分野におけるステージを分ける。ステージごとに異なる指示と援助のしかたをする。そのためには、業務ごとの目標を明確にする必要がある。」というものだ。

異なる特性を持つ部下に対して、異なるアプローチをとることは、決して不当ではないという。ちょっとまえに、equality と equity の違いが SNS に流れてきたけれど、そういう感じだ。さっきまで、異なるアプローチをとるのは不公平だと思っていた。だが自分が部下だったら、それを気にするかっていうと、何が起こっているかわかっていれば、気にしない。そのためにも業務ごとの目標を明確にし、アプローチを取り決める必要がある。

業務ごと、というのは、部下がやっている仕事が複数あるときに、業務ごとに部下のステージが異なるからだ。

明日から

すでにチームの慣性があるので、コロコロやりかたを変えてしまうと却って、開発者の迷惑になるかも知れない。だいたい部下じゃないしなぁ。

Robin Williams / ノンデザイナーズ・デザインブック

文書デザインの考え方を紹介する本

今年、付きまとっている @ymotongpoo が読んでると聞いて、ノンデザイナーズ・デザインブックを再読しました。プログラミングでいうところの、デザインパターンとも言うべきプラクティスが解説されています。

この本自体は以前から持っていましたが、流し読みしただけで、実践したことはありません。使う機会がなかったのと、この本がパターンのカタログであると捉えていなかったからです。

再読したので、忘れないうちの実践として、このブログのデザインを変更しました。Blogger.com に最初から入っている「シンプル」というテーマをベースに、CSS だけを変えました。HTML は触っていません。

整列、近接、反復

あなたは文字揃えの扱いに慣れてきました。しかしいっそうの訓練を積むまでは、 1ページに1種類の文字揃えだけを使うようにしてください。つまりすべての文字列を、左揃えか、右揃えか、中央揃えかのどれか一つにするのです。

もとのデザインではタイトル、エントリのタイトル、本文が揃っていませんでした。そこで、これらの左端を揃えました。

右のカラムは元々揃っていたので、そのままです。

もし関連する項目がいくつかあるなら、それを近接させてグループにしましょう。直接的な関連をもたない項目は離しましょう。

ブログの論理的な構成は、以下のようになっています。

• ヘッダ
• 記事群
• 記事
• 日付
• 題名
• 本文
• セクション
• [セクションタイトル]
• 文章

これまではセクションタイトルのフォントが小さくて、セクションを認識しづらい見栄えでした。大きくすると、まとまりが見えるようになりました。

反復は、一貫性をさらに強化したものです。約物、書体、線、色など、あなたがす でに繰り返し使っている要素を見つけて、そのうちの一つを強調して反復の要素と して使えないか考えてみましょう 

ブログの場合、似た構成要素が反復するつくりになっています。絵や文章を配置するのではなく、文書構造にスタイルを適用しているので、自動的に反復が適用できます。

コントラストが課題

コントラストは、染みを隠すために壁を塗るのに似たところかあります。染みの上に塗る色が周りの色とだいたい同じではだめで、正確に同じ色にするか、それが不可能なら壁全体を塗り直すしかないのです。

今回の作業ではコントラストを活用できていません。タイトルを目立たせていないため、全体的にメリハリがないのです。

広告なんかだと、読む気がなかった人に強制的に提示するので、タイトルが目立つことは重要かも知れません。このブログへの流入は、リンクか検索エンジンからのほとんどです。ブログのタイトルが目立ったから読む、という因果関係はまず成立しないでしょう。かといって本文との差がないと構造が分かりにくいものです。そんなわけで、ヘッダ部分はフォントを大きく、色を薄くしました。

そもそもブログ名が悪いのかも知れません。見栄えではなくて、コンテンツの問題なので、今回は保留。

また、色のセンスがないのでモノトーンにしていますが、本当は色を使わないほうが難しいはずです。marippe の「色彩センスのいらない配色講座」や、フルカラー新装増補版が助けになるのだと思います。

問題解決のフレームワーク

実践してみたところ、かなりマシになりました。特に整列の効果は絶大です。インデントが好きで Python を使っているのに、もっと早く気づかなかったのが不思議なくらいです。

これまで、漠然と気に入らないなあ、と感じていたことに対して、体系的に問題と解決を捉えられるようになったのが最大の収穫です。

Max Kanat-Alexander / コード・シンプリシティ

Max Kanat-Alexander の「コード・シンプリシティ」を読みました。「Bugzillaプロジェクトの主任設計者の実体験に基づいた、ソフトウェアの簡潔性を保つさまざまな知見をまとめた書籍。」と紹介されています。

ブログを元にしているのか、Joel on Software やハッカーと画家の、もうちょいゆるい版と思うのがいいと思う。また経営者的な目線ではなくて、現場のマネージャやーリーダーの目線で書かれているという印象です。

悪いプログラマーと良いプログラマーの違いは理解力だ

プログラマの良し悪しに関する定義は、人の数だけありそうですが、ここでは理解力で。

ビジネスバリュー

ルールや指南が有効であるための前提というのが存在して、それを読み取れるか、というのは重要だと思う。この本では理解力を求めるけれど、あんまり前提に関して明確に書かれていない。だから読み取らないといけない。

ソフトウェアは人を助けるためにある

「金儲けをすること」は、個人的な目的、または組織の目的には当然なり得る。金儲けをすること自体に何ら問題はないからだ。ただ、ソフトウェアの目的にはならないだけだ。売り上げとして入る金額は、作ったソフトウェアがどれだけ人の助けとなっているか、ということと直接つながっているはずだ。

究極的には誰かが恩恵を受けていて、そのためにソフトウェアは存在する、という考え方。そうなっていなければ、そのソフトウェアには価値がない、というポジションです。特に著者はオープンソースソフトウェア開発の経験から語っているので、金銭的な利益だけに還元せずに、価値を計る方法が必要だったのだろうと勝手に邪推しています。

ソフトウェアの価値と、その大きさという指標はすごく大事だと思います。「この機能を追加すると、あるいは、この作業をすると、どんな価値が生まれるのだろう」と考えること多々あり。まだビジネス的な価値評価や、バリューチェーンが分かっていないので、常に分かるわけではないけれど、そういう視点で見るようにしています。

「こういう実装にするのが良いから」「こういう技術を使うといいから」みたいな動機だけでやらないように注意しています。ある実装方法がださださであっても、費用対効果が著しく高いのであれば、そうすべきだと考えているからです。

変更に備える

未来についてまったく予言せずに、いますぐにわかる現在の情報を元に、すべてのデザイン上の決定を行うのが最も安全だ。

これは、本論で論じてきた内容とは真逆に聞こえるかもしれないが、そうではない。デザイン上の決断を行う際、最も重要なポイントは未来だ。しかし、将来、変更ができるようにデザインを行うことと、未来を予言しようとすることは、違うことだ。

変更についていろいろ。変更しやすいけれど、特定の予想シナリオに依存しない、というのがどういうことか、また、一般的なやりかたがあるのか分かりません。分かりませんが、なかなか勇気づけられます。

最近、私が気にしているのは変更に対応しやすいコードです。要件はこの日までに、とか言ってもどうせ決まらないという諦めがあります。諦めの姿勢の是非は、今は問わないで。決められない人や、経済的な力関係で無茶してくることがあります。また、パフォーマンスのチューニングをしている過程で、やべぇこれじゃだめだ、って発見することも残念ながらあります。

そんなときに変更しやすくしておかないと泣きます。そして、最初に作っている時点では、どんな変更になるかは分かりません。

将来、要件が別に出てくる可能性を排除せずに、直近で既知の要件に基づいたデザインが必要だ。システムがしなければならないことが「X」のみであれば、いますぐその「X」ができるようにデザインしよう。未来には「X」でないことがあるかもしれないから、それを念頭に置いておけばよい。現時点でシステムは「X」だけができればよい。

古い考え方かも知れませんが、私が注意をするのは、低い結合度と高い凝集度を目指す、というものです。いきなり抽象クラスを作ったり、フレームワーク化をしません。ただ、作っているものや技術によると思います。

加減乗除ができる電卓プログラムにこの手法を使った場合、次のようになる。

1. 足し算だけを行うシステムを計画する。
2. 上記のシステムを実装する。
3. 引き算機能を追加しやすいように作ったシステムのデザインを修正する。
4. 引き算機能をシステムに実装する。足し算と引き算しかできないシステムが出来た。
5. かけ算機能を追加しやすいようにシステムのデザインをさらに修正する。
6. かけ算機能をシステムに実装する。足し算、引き算、かけ算だけできるシステムができた。
7. 割り算機能を追加しやすくするためにシステムのデザインをさらに修正する（この時点では作業は少し、またはまったくないだろう。引き算とかけ算を実装する時点でデザインが改善されているからだ）。
8. 割り算機能をシステムに実装する。これで、望んでいたシステムがそれに見合う優れたデザインで実装できた。

電卓ごときでこれをする人はいないと思いますが、私は、このやり方を好んでいます。外部から見た振る舞いやインタフェースが決定した段階では、内部の詳細な設計はできてないことが多いです。おおざっぱなデータの持ち方やロジックがある程度です。実際に作ってみたら、思ったより複雑だったり、簡単だったりします。なので、上記のようなやりかたをすることが多いです。

ただ、これは扱っている範囲が大きくなったときには、通用しにくくなることも、またありがちな話です。

いずれにしても、ショボイ機能であっても、ひとつずつ実装していきたいのには理由があって、

プロジェクトによっては、要件が複雑すぎて最初のバージョンを永遠にだすことができない、ということもある。この状況に陥ったら、機能を絞り込むことだ。

これです。ユーザに公開するかどうかは別にして、足し算までできたら、とにかくメインのブランチにマージしてしまって、本番に近い環境で動作させたいのです。そのためには、メインのブランチから離れている時間を短くしないといけなくて、さらにそのためには、断片的ではあっても動く機能をひとつずつ実装していきたいのです。

要件定義

「この仔馬が月面まで飛べるようにするにはどうしたらいい？」と誰かに訊かれたら、「解決したい問題は何か？」と質問しなければならない。この人は、実際には灰色の石を集めたいだけかもしれない。

これ聞くと嫌がられがちなので、気をつけないといけないんですけどね。それでもなんとか聞き出したいです。本当に必要な機能や作業はなんなのか、っていうのは重要です。

一方で、「ユーザを増やしたいってのが目的らしいけど、こんな機能を入れても増えませんよ」みたいな気分になっても、私は、我慢するようにしています。が、その話はまた、いつか。

まとめ

エントロピーが増大したコードを、きれいにしつつ、機能追加をしていった経験をもつ人の話は面白かったです。最初からきれいなコードを書けるのが理想ですが、実際には、そうなっていないことが多々あります。そういう実践的な立場からの教訓から学ぶことはありますね。

http://www.oreilly.co.jp/books/9784873115757/

プロジェクトマネージャが知るべき97のこと

「プロジェクト・マネジャーが知るべき97のこと」を読みました。この本は他の97のことシリーズと同じく、複数の寄稿（っていうのか？）を集めたものです。したがって、全体としてひとつの一貫した考え方にはなっていない箇所もあります。複数の視点があるというのは、そういうことです。

プロジェクト・マネジャーの仕事の範囲というのは、本来はどこかで決まってそうですが、実際には組織ごと、プロジェクトごとに、その守備範囲はことなっている印象があります。今の職場でのプロジェクト・マネジャーと、前の職場でのプロジェクト・マネジャーの具体的な仕事の内容は、けっこう違います。なので、そんなことも範疇に含まれるのか、と思うこともありつつ。

最近の個人的な課題は、変更をいかにコントロールするか、です。その視点から見た感想として気になった箇所をふたつ紹介します。

完全な知識という誤った考えは、ソフトウェアプロジェクトのための完全で矛盾のない要求が獲得できるという妄想のことです。現実には、ソフトウェアプロジェクトのライフサイクルのいかなる時点においても、要求が完全にわかることはありません。分析フェーズ、開発フェーズ、保守フェーズ、システムがレガシーであるときですらそうなのです。
（デイビッド・ウッド 完全な知識という誤った考え）

これはなかなかに凹む意見ですが、実際問題としてそういうことなのでしょう。矛盾だらけの要件リストで開発を始めたりしませんが、形式的な手法を用いたりしない限り、無矛盾な要件は得るのは至難の業だと思います。

とくに性能要件があるときです。性能は、多くの場合、インフラやアーキテクチャに大きく依存し、その実現可能性は使えるコストにも依存します。場合によっては、使えるコストというが性能に依存することもあります（100万ユーザを捌けるなら金を出す、など）。ってなわけで、依存関係がループします。

とういわけで、全ての条件が明確ではなくても、どこかから始めなければいけません。

経験豊富なプロジェクト・マネジャーであれば、「高、中、低」というフィーチャーの分類をしません。顧客は何もかも「高」にしてしまうおそれがあるためです。彼らはビジネス価値に基づいたフィーチャーの優先順位リストを好んで使います。すぐれたプロジェクト・マネジャーはビジネスオーナーに対して「遅れが発生した場合に、優先順位リストの下の方にあにあるフィーチャーは、このリリースでは実現できないかもしれません」とくぎを刺します。こうしたやり方は、ビジネスオーナー、特にフィーチャー同士の衝突について学んでこなかった人にとって、苛立ちの原因となるでしょう。ですが時間がたてば彼らもこうしたプロセスに慣れて、プロジェクトの現実として受け入れるようになります。
（ジョー・ゼネビッチ 約束以上にすべきか、約束以下にすべきか）

まあ間違いなく「高」ってつけられます。ABC を使っていると、いつのまにか A+ とか S とかついてます。何かを優先する、ということは、別の何かを優先しないということです。発注側が「全部大事」といって押し込んだとき、受注側は見えないところで手を抜かざるを得なくなります。それは多くの場合、品質やパフォーマンスだったりすることでしょう。

いまだにプロジェクトの中での優先順位付けを、ステークホルダ間で共有する方法というのは持っていません。ゼネビッチが書いているように、理解できない人にとっては苛立ちの原因になりますし、状況によっては単純に受け入れらません。がっかりな話ですが、まあ、そんなもんです。

絶対うまくいく法則というのはないのですが、できるだけ相手に分かる指標に変換するように心がけています。「これもやってほしい」「はい、できます。+1週間です。」というような会話です。+100万円でも、同時アクセスできるユーザ数20%減、でもなんでもいいんですけど。

この本を読んで、正解を見つけるのは大変・不可能かも知れませんが、飲み屋で先輩や同僚の話を聞く、の効率良い版だとコストパフォーマンスはよいと思います。

プレゼンとマジック - 森博嗣「タカイ×タカイ」

森博嗣の X シリーズ 3 作目「タカイ×タカイ」の文庫が出ていたので、読んだ。

マジックって、たしかに、観客に何かが起こっていると見せかけるけれど、それって、実際に起こっていることを隠すためのものですよね。

真鍋瞬市が、高いポールの上に死体があったことに対して、死体を見せたいからではなくて、別のことから目を逸らしたいからでは、と、疑問を投げるセリフだ。実際がどうたったかは、読んでのお楽しみ。



ここから我田引水。プレゼンをするときにも、この手法は使えるだろう仮説。少なくとも私は今まで使ってきたし、これからも使うと思う。

場合によるけれ聴衆に何かアクションを起こして欲しいとき、何か変化を起こさせたいとき、伝える側がフォーカスして欲しいことに、聞き手にフォーカスさせたいことがある。そんなとき、嘘じゃないけど、注意の引き方を工夫する。

たとえば新製品や新サービスを発表をするとき。当然だけど、競合できて、自社製品にできないことや劣っていることがある。おそらくそれは戦略上、優先順位が低いから落とした機能だろう。けど、状況によっては（メディアや顧客は大事だと思い込んでいるかも知れないけど、こちらは重要ではないと思っているとか）、めんどくさい形で突っ込まれるかも知れない。そんなときには、100項目もある新機能ぜんぶではなくて、ポイントになる数機能にフォーカスさせるようなストーリィの組み立て方をする。うまくいっているのか、うまくいってないのか分からない。

ところで、そうやって推理小説にうまく騙されたときは気持ちいい。

Python を使った開発の技術とプラクティス - ビープラウド / Python プロフェッショナルプログラミング

ビープラウドによる「Python Professional Programming」が出版されたので、早速、購入。「Python を使ったウェブサービス開発のプロセス、ツール、プラクティス」がまとまっている。

ビープラウドでは、定期的に社内での情報共有を目的にした「BPStyle」という集まりがあります。誰かがこの本は BPStyle なんだよ、と言ってたような、言ってなかったような気がする。

たとえば「Chapter 10 環境構築とデプロイの自動化」を見てみよう。技術的には、Debian 系パッケージのインストール、dpkg -l 、 pip freeze 、Fabric の簡単なチュートリアルと、簡単なレシピになっている。ググればすぐに出てくるし、ヘルプやドキュメントを見れば分かるような内容だ。

が。

ユーザの作成、MySQL、nginx などのインストール・設定、この章までに使った pip によるパッケージインストールをして、構築とデプロイの手順をまとめて、手順書から環境ごとの fabfile.py を作る、という一連の流れを説明したような文書は、なかなかない。少なくとも、私はググっても見つけられなかった。

そういうプラクティスが詰まっている本なのだ。私がビープラウドにいた時にやっていたこと、やっていなかったこと、アップデートしていることなどいろいろある。

この本は、ふつうに自腹で購入しているのだけれど、以前の勤め先なので贔屓目じゃないか、と言われたら、否定はできない。ちなみに、今の同僚が、この本を読んだ感想は「古川はビープラウドにいたんだなぁ」とのこと。全部とは言わないまでも、あそこで学んだことは生かせているらしい。



ってか、この本を先に読んでたら、Jenkins であんなに苦労しなかったのに！ ひどいよ、さぼてんまん！

バグの影響を伝播させないアプローチ - Michael T. Nygard / Release It!

なんとか It! シリーズのひとつ「Release It! 」を読みました。


航空券予約システムをダウンさせたバグの経験から始まります。

極論を言うと、この種のバグがひとつ残らず消滅するなんて夢物語にすぎない。 バグは発生する。消えてくれないなら共存するしかない。 [...] この例で最悪だったのは、ひとつのシステムのバグが全システムに伝播して影響したことだ。答えるべき問いは、「ひとつのシステムのバグが他に影響するのをどうやって防ぐか?」である。 (p.21)

バグの影響を伝播させないシステムの作り方、というのが、この本の「本番用システム」のあるべき姿です。その中からいくつかピックアップ。

本番と同じサイズのデータセットでないと、クエリで数百万行が返っ てきて、それをオブジェクトに変換するときに何か起きるか確かめることかできない。本番と同じサイズのテストデータを使えば、パフォーマンステストでより良い情報が得られるという副次的な効果もある。 (p.93)

ダミーでいいから量をある程度用意するのはよいことだと思う。いまやっているプロジェクトでは、想定ユーザ数と平均的なユーザの典型的な行動パターン（つまり各URLのアクセス頻度）のシナリオを用意してもらえた。まだ調整中なのだけれど、どこがボトルネックになっているのか分かるし、優先順位も明らかになっている。

待たせた結果がエラーメッセージであってはならないし、相手のタイムアウトまで待たせてもいけない。それでは、こちらの問題を呼び出し側に転嫁するだけだ。 (p.116)

フェイルファストっていうのは、なんか努力せずに諦めたみたいな感じがするんだけど、応答が遅い状態が長く続くくらいなら、さっさとフェイルして、アラートメールを出したほうがいい。どうせアラートメール出すハメになるのだから。

開発プロジェクトか大忙しのときに、こうした設計についてのトピックを意識するのは難しいかもしれない。[...] そんなあなたにいいニュースかある。これらの問題を開発中に取り上げるのは断念してもいい。ただし、これは悪いニュースでもある。開発中に収り上げないなら、 本番で取り組むことになるだろう。 (p.235)

開発開始段階ですべての機能/非機能要件が決定されていない（つまりほとんどの）場合、最適な設計も最初に決定できないということになる。少し設計して、作って、また設計して、の繰り返しになるので、設計コストは増加する。そのかわり不適切な設計のままつっぱしって、システムがダウンするリスクを避けられる。

今やっている案件でできていることは続けたいし、できていないことは今後やっていきたいものです。

データではなくメソッドを学ぶ - 森博嗣「科学的とはどういう意味か」

「信仰は科学です( ｰ`дｰ´)ｷﾘｯ」みたいなことを普段言っている割には、かなりな勢いで直感でものを考えているふるかわです、こんばんは。

駅の本屋さんでふと目に止まって、森博嗣の「科学的とはどういう意味か」を買いました。

人間にとって「気持ち」の影響力は大きい。けれど、いくら感動しても、いくら泣いても、飢えている人を救うことはできない。いくら一時の笑顔があっても、それは「解決」ではない。 (p.12)

当たり前のことですが、つい忘れてしまいますね。

こんなに大げさな話ではなくても、問題の解決にまったく寄与しないことが、自明であるにも関わらずやってしまうことってあります。目下の課題とまったく関係のない質問、誰にも聞かれていないし、役にもたたない発言など。そういうことに自覚的でありたいと思います。

学科で教わることには、以上のように2種類ある。きっちりと分かれてるものではないけれど、大別すると、「データ（情報）」と「メソッド（方法）」だ。[...] これに対して、後者は、それらの材料を用いて加工する「方法」を憶えることになる。算数や数学というのは、一言でいえば「方法」なのである。 (p.35)

 「大学の研究室でやった研究で仕事してる奴なんか、ほとんどおらんで。ここは方法論を教えるところやから」と言ったのは、私が所属した研究室の先生の言葉でした。私は物覚えが悪いので、テストは常にひどかったですし、いまでもひどいです。


仕方なく方法論を身につけようと思いました。なので、何か新しいことを知ったら、とくにそれが方法論であったり、解釈の仕方であったりすると、「この方法を違う問題に当てはめられないか」と考えます。いつも、ではないですが、そういうふうに考える傾向があります。


それがどのくらい有効なのかよく分かりませんが、少なくとも私には役に立つ考え方であり、アプローチです。


と、まあ、当たり前なことを、ドヤ顔で書いてみました。「こんなこと役に立つのかよ」って思い悩む、高校時代のときから余裕でプログラミングとかできている学生の役に立てば、と思いました。

節度をもって変化を抱擁する - アラン・デービス「成功する要求仕様 失敗する要求仕様」

今の職場に入ったとき、初めてアサインされた仕事が要件仕様の定義でした。そのときに何冊か買った本のうちの、ひとつが、アラン・デービスの「成功する要求仕様 失敗する要求仕様」です。原題が「Just Enough Requirements Management - Where Software Development Meets Marketing」であるということに、今、気づきました。

ケビン・フォースバーグとハロルド・ムーズによるNASAプロジェクト の研究によれば、NASA(米航空宇宙局)が要求活動を含む計画活動に開発予算の5パーセント以下しか充てなかったプロジェクトでは、総コストは40~170パーセント超過した(図1-11)。一方、NASAが全開発予算の10~20パーセントを計画活動に充てたプロジェクトでは、コスト超過は30パーセント未満だった。 (p.21)

計画活動に時間をかけると、コスト超過が起こりにくい。デービスは他のところでも、この例を挙げて、計画に時間をかけるように勧めています。その最初の段階での成果物が、要件仕様、というわけです。

私は、スケジュールが要求を決めるべきだと強く感じている。 (p.23)

最大の不足するリソースは時間だということを考えれば、必然的にこういう方針になりますね。時間は貯めたり、借りたり、増やしたりといったことができない、とドラッカーが指摘していたと思います。もちろん、時間を節約するために、ヒト、モノ、カネを調達することはできるでしょうけれど、時間自体を増やすことはできません。

どれだけ徹底的に導き出しを行っても、要求は変わっていくものだ。問題は変化していく。そして、問題に対する ステークホルダーの認識も変わっていく。要求を洗練させ、議論するうち、ステークホルダーは新しい要求をさらに思いつくはずだ。それでいいのである。ただ、変化に対する備えはしておこう。決してステークホルダーに「それで、これが最終的な要求なんですね?」などと言ってはならない。  (p.55)

耳が痛いです。最後の要求なのか、とつい聞いてしまいます。

一方で、要求を決めないと、設計や実装ができません。だから、多くのアジャイルなプロセスでは、タイムボックスを区切って、その間は仕様変更をしないというプラクティスがあるわけです。

しかし、約束してもいい。スピードと品質は両立できないものなのだ。  (p.67)

これは心しておかないと。そして、それを痛感するような経験もあります。

• 要求への変更は、善であり、悪ではない。 
• 要求変更の流れを阻止しようとしてはならない。 
• 要求変更の流れを管理できるようにならなくてはいけない。 
• どの要求を次のリリースに含め、どの要求を含めないかを決定するために、定期的にミーティングを開く。 
• 10パーセント以上の要求変更を受け入れれば、プロジェクトは失敗するだろう。 

(p.209)

「変化を抱擁せよ。ただし、抱擁できる範囲で。」ということです。その手段として、さまざまなやり方があり、アジャイルな手法はこの前提をもっているように見えます。ですが、デービスはアジャイルがいい悪い、という見方ではなくて、要求のトリアージができるプロセスに、という立場をとっているようです。

危機が起こったときに備える - エドワード・ヨードン 「デスマーチ第2版」

デスマーチが起こってから、どう対処するか、を、主にマネージャの視点から書かれています。デスマーチが起こることが前提になっているのが、他のマネジメント本と違うところです。プロジェクトマネジメントは計画段階でかくあるべし、と正論を言われても、「いや、もう、プロジェクトはじまっちゃってるし！」ってなりますからね。

しかし、我々が憤れ親しんでき たプロセスに新たにプロセスを追加したり、プロセスを改訂したりする必 要がある新技術を導人するのはずっと難しい。 (p.244)

そうなんだよなぁ。慣れたところから、慣れないところに行くときは、いつもそういうことが起こる。最初から、新しい方法だったらまったく問題は起こらないのに。

納期に遅れたり、予算を大幅に超過したり、プログラマを燃え尽きさせてしまうプロジェクト・マネ ジャーに、プロジェクトを次々と「破滅」させる機会を与えてはどうか？要するに、なぜ、プロジェクト・マネジャーもメンバーも、実際の経験に 備えてデスマーチ・プロジェクトの経験をシミュレートしようとしないの か？ (p.252)

デスマーチの練習、っていいなぁ。デスマーチを避けることは大事なんだけど、現実にそれに近い状態が起きるのであれば、それに備えることは意味のあることであるなぁと思いました。爆弾処理班とか、テロ対策特殊部隊とかって、そういう人たちだもんなぁ、などとも。

# 別に火消しになりたいわけでも、管理に意味が無いと主張しているわけでもありません、念のため。

ジェイソン・フリードら「小さなチーム、大きな仕事 37シグナルズ成功の法則」

ずいぶん前に同僚が読んでいた、ジェイソン・フリードら「小さなチーム、大きな仕事 37シグナルズ成功の法則」を読んで、残業や生産性について考えました。


基本的に、長時間にわたって仕事をするのを避けたいな、と思っています。一方で、それが必要なことが多々あって、それは私の見積りや、プロジェクトの進め方に問題があるんだろうなぁ、でもどうすればいいんだろうなぁと考えるのですが、目の前の作業に忙殺されて答えが出ません。典型的なきこりのジレンマです。

仕事依存症患者は、ほどよい時間しか働いていないという理由で、遅くまで居残らない人たちを能力に欠けているとみなす。これは罪悪感と士気の低下をはびこらせる。

罪悪感と士気の低下、というのがよろしくないですね。「みんな帰らないから、私も帰らない」というのは意味が無い。だいたいにおいて、努力というのはコストなんですよね。成果物のほうに目を向けねば。

もしあなたがいつも残業し、週末も働いているとしたら、それはやるべき仕事が多すぎるからではない。それは仕事を「完了」させていないからだ。そしてそうなるのは、仕事に邪魔が入るからだ。

長いかたまりの時間が必要なんですね。私はコンテキストスイッチによる、パフォーマンスのロスが非常に大きいので、これが顕著に表れます。それを避けるために早く会社に行ってたんですが、いつのまにか普通になってしまいます。というネガティブスパイラル。

[...] 僕らはメンバーの誰か一人が二週問以上時間を費やしているものがあるならば、他のメンバーに見てもらうようにしている。他のメンバーはそのタスクに関して何も手を貸せないかもしれないが、それを手早く再検討して、意見を述べることはできる。明白な解決策があなたをまっすぐ見つめ返していても、あなたはそれに気づくことさえできないこともある。

時間がかかっているときには、助けてもらう、というプラクティス。私は恥ずかしいことに、人間の小ささと、プライドの高さだけは世界トップクラスなので、人に聞くのを躊躇します。ですが、プロジェクトを進める、という一番重要な目的にフォーカスしていない、という点においては、勤務時間中にぼーっとするのと同じ程度の背任だとも言えます。

コンテキストスイッチの話に戻るのですが、話しかけられるのが苦手なので、話しかけるのを躊躇するのですね。そこらへんの折り合いも大事であるな、と。

何か家でやらなければならないことがあればあるほど、人は会社で仕事をする。

なんとかして、早く上がれるような環境をつくりたいな。残業を求めなければならないこと、は、必ずあるのだから、安定しているときくらいは、定時帰りできるプロジェクトにしたいものです。

ちなみに、勤務時間外に、仕事と関係あるなしに関わらず、何らかの技能や知識を習得することは、個人として必要だと思っています。仕事は固定ではなく、変化するので、その変化への準備、という意味で。

「Webアプリケーションテスト手法」

「Web アプリケーションテスト手法」なる本を読みました。内容は広く浅く、あんまりテストの経験がない人がテストを始めるとっかかりになりそうです。RoR とか、フレームワークを限定しているので、即物的/具体的なことが書かれています。


Selenium をちょこっと使うことがあったので、読みました。

使いわけとして、たとえば、正しいページに遷移したことを assert で確認し、ページの内容は verifyで確認する、といったことができます。こうすると、ページ遷移が間違っていたら、続けても無駄なのでその場でテスト中断し、ページのの内容は部分的に間違っていても最後まで確認することができます。(p.238)

XP のユニットテストでは100%か0%だけど、どうなんだろ。と思いましたが、acceptance test では、そういうわけではないからいいか。

・要素のロケータは、idが一番テストしやすいので、ページを作るときに適宜id要素を指定しましょう。動作上必要ないところでも、idが入っているとテストが便利になります。

 ・開発とテストを一人てでやっているなら、テストを書きながら必要に応じてidをページのほうに追加していってもいいでしょう。 (p.241)

class での指定は、たしかにやりにくいですね。テストしやすい HTML にする、というのも重要かと思いました。HTML をいじれないときは困るんですけどね。

トム・デマルコほか /「アドレナリンジャンキー」その1

デマルコの「アドレナリンジャンキー」、読んだあとに付箋はりまくりなので、ちょっとずつ記録に残していきます。自戒ばっかり。

この種の [アドレナリンジャンキーな] 企業文化では、死に物狂いに急ぐことと効率良く成果をあげることが同一視される。このような組織にいたら、中毒にならずにいるのは難しい。切迫感があることがよしとされる。 (p.2)

これ気を付けないとなぁ。短納期なときには、適切にプロジェクトを進めていかないと、これに陥りがち。イベント系の単発システムとか。本来はそれを防止するためのタイムボックス化したイテレーションなのだと思います。

進捗だけでは不十分である。「５月末までに仕様書を50%セント仕上げよう」といった目標では、満足のいく結果は得られない。小さな声がささやく。「50%パーセント、つまり5月末までには終わらないということだ。それまでにほんとうに終えなくてはいけない仕事はどれだったかな。」 (p.7)

つい目先のタスクに「だけ」目がいってしまうんですよねぇ。

プロジェクトに信者がいると、身動きがとれなくなることがある。コンテンツに集中せず、手法戦争を始めるのだ。 (p.33)

これも気をつけなければ。議論がずれていくのは気持ち悪いんだけど、それはコンテンツに集中する、という方向に持っていけてないからなのですね。状況によって修正の方法は違うのだろうけれど、何がコンテンツなのというのを常に覚えておかねば。in-person でやっているときには、ホワイトボードや付箋で、議題を可視化するんだけど、チャットのときが自分にとっての課題です。

小室淑恵 / ６時に帰るチーム術

ワークライフバランスって言葉が目に付く本ですが、究極的には生産性向上のしくみの提案です。仕事すんな、とか、そういう話ではないです。

たとえば、その日の予定を立てて共有する朝メールと、実績を報告する夜メール。まだ他者と共有してはいませんが、私はカレンダーに大きなタスクをざっくり書きこんで、それを予定にしています。で、それを実績のとおりに修正すると、それが日記というか活動記録になります。ほんとは、予定と実績を別のカレンダーにしたほうがいいのかもしれません。

まあ自分の予定通りには進まないです。残念ながら。

ただし、就業時間と残業時間の区分はしっかりしておきましょう。残業ではどんな業務が多いのか、なぜ残業にずれ込んでしまうのかを意識させると、次のステップにつなげやすくなります。(p.90)

別に勤務時間外で仕事をしちゃいけないとかいう意味ではなく、予定とどのくらいずれているか、ってことのフィードバックが重要なんですよね。そもそも見積が甘いのか、割り込みがあったのか、云々。

共有と言えば、

一つの業務を一人で担当すると、自分にしかわからないことばかりですから、「休みたくても休めない」という状況に陥ります。(p.117)  

こんな話も。仕事自体の共有です。XP のペアプロを彷彿とさせます。レビューやコードの共有は重要だから、ペアプロしようぜという極端なやりかた。いつも仕事を一緒にやっていれば、日々、少しずつ共有が進んでいくってわけです。じゃあいきなり、ってわけにもいきませんが、なにがしか近いことはできるんじゃないかなと思います。

ワークライフバランスっぽい話でいくと、取引先の時間が夜型のときには、全体的にこちらもそれに引きずられやすいので、そうしない工夫とか、あるいは、始業時間をシフトさせることを言えるようにしたい。いまは、なんとなく自分がバリューだせていないっていう引け目があって言いにくい。

業務上のタスクには締め切りがあるはずですが、締め切りまでの間にさらにいくつか「チェックを入れるタイミング＝締め切り」を設定するのです。

マネジャーからメンバーに仕事を依頼するときにも、「何を、いつまで、何時間ぐらいかけて」と指示するとともに、「こことここの段階で見せて」と言っておきます。 (p.177 )

ほんとにダサい話なのですが、私は締め切りの設定が下手で、非常に大きな誤差が発生します。ほとんどの場合、見積もりのほうが楽観的すぎますが、「なぜそんなにかかるのか？」という修辞的質問の圧力に屈してしまいます。そしてまったく根拠のない締め切り設定をしてしまう。だからこそ、チェックポイントを用意して、締め切りごとのごさを小さく、そして修正を早めにできるようにならないとなぁ、と、思いましたとさ。自分にも他人にも。

村上龍「歌うクジラ」の感想

村上龍の「歌うクジラ」を読みました。

群像に連載されていた、未来SFディストピア的ロード小説「歌うクジラ」を読みました。iPad の電子書籍版で1,500円です。「五分後の世界」「コインロッカーベイビーズ」「イビサ」みたいな描写が好きな人は、好きなんじゃないかな、と思います。

これまでの作品で描かれていた、あるいは主張されていたことと、今回新たに書かれたこと、の両方があります。村上龍節++ っぽい感じでしょう。ディテール描写でぐんぐん惹きつけられる感じでした。

プラットフォームとしては未来SFですが、書かれているテーマであろう、格差や断絶はタイムリーだと思います。「日本に移民が増えすぎる」みたいなのは、10年前と今ではリアリティが違うと思います。

epub などとの互換性のない電子書籍版を先行販売したことや、小説のウェブサイトがあることなど、メタな話題については、基本的にポジティブに受け取っています。

注意：以下、物語の核心に関する核心部分が明かされます。

大勢の人が笑顔をつくっている乳製品の宣伝映像を父親のデータベースではじめて見たとき、目まいと吐き気を覚えた。害悪だと子供にもわかった。 (p.207)

村上龍は、この種の笑顔を否定する記述を、小説内でよくやっている。本当に本人が嫌っているのか、そういう立場の人を描きたいだけなのかわからないけど。ただ、あまりに無表情な会話を続けると私は不安になります。この人、いやなのかなぁ、あるいは何か威圧しようとしているのかなぁ、と。

歩いて老人施設まで行くのかとアンジョウに聞いても意味がない。アンジョウに付いていく以外に老人施設を目指す方法はないからだ。 (p.332)

やっても意味のないことはすべきではない、っというのも、村上龍がよく明示的に書いています。個人的にそれはよいプラクティスだと思っていて、それは心がけたいなぁと思う。思考停止と間違わないように、と。

あの小型のドーム内にはガラスのグラスで飲みものを飲んでいる特別な人たちがいる。だが外を眺めるためのものではない。あれは自分たちが特別だと示すための施設なのだ。(p.149) 

「VIP 用なんとか」が目に見える状態になっているのは、今でも見せるために見せていると思います。それが商品としての価値だったりする。そのことに自覚的にならないと、まんまとマーケティングの餌食になってしまうなぁと思いました。

人口の減少および労働力の移民への依存度は幾何級数的に高まり生産性は劇的に下がり幾度となく円は暴落してやがて燃料と職労が欠乏するようになるが一般大衆の政治意識はゼロに等しかった。(p.238)

それ今でもそうだよなぁ。最近、政治がらみで盛り上がってるふうだけど、具体的な活動に移す人は殆どいないし、私もまったく行動をしていません。あまりに何もしていないとか、無関心が続くと、いざとなったときに、どうしていいのか分からないと思います。こわこわ。