ブックオフオンラインが便利になった

ちょっと前ですが、いつもお世話になっているブックオフオンラインがリニューアルして、いろいろ便利になりました。

  • お知らせメールの登録数上限が、「100件」から「200件」へ増加
  • 注文時に、注文する商品をお知らせメールから削除する機能が追加
  • お知らせメール登録商品一覧から、「新品をカートに入れる」が選択できるようになった。
    (ちょっと買い足したいけど中古が無いときに便利)

すばらしい! あとは

  • 予約された中古商品が入荷したら自動的に発注したことにしてくれる機能

が欲しいです。

「プログラマーのジレンマ」読みました。混沌の闇に落ちる…

プログラマーのジレンマ 夢と現実の狭間

  • ソフトウェアベンチャーを創業者として大成功させ、たっぷりの資金をもったリーダー。
  • 彼が目指すのは、世界を変えるソフトウェアを作ること。
  • それは、プログラマ以外のユーザが容易に機能を拡張し、組み合わせ、あらゆる情報を管理できるようにしてくれるツール。
  • 彼のビジョンに賛同し、集まる一流の開発者達…。

これは、2001年にはじまった、あるオープンソース・プロジェクトに、3年間密着取材したドキュメンタリーです。

およそ考えうる最高の条件で始まったとしか思えないプロジェクトですが、序盤からすぐに難関が立ちはだかります。決まらない仕様、決まらないアーキテクチャ、他の事に興味がうつり去ってゆくメンバ…。重く辛い日々が延々と続きますが、本の終わり近くになって、ようやくプロジェクトは動き始めます。

これはドキュメンタリであって、フィクションではありません。物語の都合よりも、現実が優先されるのです。かなり余裕をもってこのプロジェクトに付き合えるように準備していた著者の持ち時間も、ついに尽きてしまうのですが、取材の期限終了が終わってもプロジェクトはまったく終わることなく、なんとそれから6年たった現在でも続いています。この物語のラストは、まだ決まっていないのです。

私には「ドリームチームを結成して凄いソフトウェアを開発する」という夢があります。この本の題材となった「チャンドラー・プロジェクト」は、まさに、私の夢そのものの世界だったのに、どうしてこんなことになってしまったのか…いや、まだプロジェクトが失敗に終わったわけではないのですが、明らかに大成功とは言えない状況でしょう。いろいろと学びの多い本でした。

「人を助けるとはどういうことか」読みました

人を助けるとはどういうことか 本当の「協力関係」をつくる7つの原則

これは、誰かを"支援"する人のために書かれた本です。

支援には色々なカタチがあります。

例えば奥さんに「今日のパーティ、どんな服を着ていったらいいかなぁ」と聞かれた時も"支援"ですし、お医者さんが患者に「最近、トイレが近いんですよ」と相談されるのも、この本でいう支援に含まれます。

そして、もっとも効果的な協力体制を作れるのは、どのようなやり方か、その時々で違います。そういうことを、それなりに体系だてて教えてくれる本です。

—–

去年の12月だったかな…。

コラボFという勉強会で、OSNのDr.OGAさんから「今すごくはまっているんですよ」と熱くオススメされたので読んでみました。以下、感想です。

もうちょっと若いとき、20台後半くらいで読みたかったです。

貼った付箋は20ヶ所くらいでしょうか。この本からリストを作って毎日読み直せば、色々な場面でサービスレベルが上がりそうです。

Dr.OGAが「読むのにすごく時間がかかるんですよ。一文一文、考えさせられることが多くって…」と聞いていたとおり、私も読むのに時間がかかりました…。7時間くらいかかったと思います。あんまり時間がかかって、案の定、最初のほうに書かれていたことを忘れてしまったので前半だけ読み直しました。

なんか、まとまらない感想です。まだ消化不良なのかも…。

「組織が大きく変わる『最高の報酬』」読みました。行動科学マネジメント実践編?

組織が大きく変わる「最高の報酬」 トータル・リワードを活用した行動科学マネジメント

またもや組織マネジメント系の本を読みました。

あんまり目新しい事が書いてなかったな…と読み終わってから調べたら、石田淳さんの本、4冊目でした。


読んでる途中で「あ、行動科学マネジメントの人だな…」と思いだしたのですが、「すごい実行力」もこの人だったんですね。全然違う人だと思ってました。
私は「すごい実行力」がいちばん面白かったです。

承認スキル、磨きたいです。そういうワークショップ無いかな。
OSNさんとか、やってくれないだろうか…。

「アイデアの力」記憶に残るメッセージの作り方

「アイデアの力」という本を読みました:

「記憶に残るメッセージの作り方」が書かれている本。タイトルから連想される内容と違いましたが面白かったです。メッセージとは、企画、提案、経営
理念、スローガン、思想、売り込み、都市伝説など。これらのメッセージを聴き手の記憶に残すには、単純明快、具体的、感情に訴える、意外性、信頼性、物語
の特性を備えていると(多ければ多いほど)良いとされています。

これらの指針は定性的ではあるものの、メッセージを磨くための手がかりに出来るので覚えておきたいと思いました。

—-

…と、こんなのが私の普通の感想文です。特にお勧めなので読んで欲しいな、と思って書いた文章ですが、すでに要点すら忘れている方も多いのではないかと思います。

以下は、この本を参考に、もっと記憶に焼きつくような文に書き直してみました。

—-

問題です。

優れた政策スローガンと都市伝説の共通点は何でしょうか?

答えは「記憶に残ること」です。あなたのどんなに素晴らしい企画や提案も、聴き手の記憶に残らなければ存在しなかったのと同じです。この本を読め
ば、企画・提案はもちろん、経営理念、スローガン、思想、売り込み文句から都市伝説まで、あなたの様々なアイディアを強烈なメッセージに仕立てる技術が手
に入ります。

—-

いかがでしょう。焼きつきますか?

「360度評価制度事例集」パラパラ読みました

あなたの仕事には、フィードバック足りてますか?

360度評価というのは、上司だけではなく、同僚と部下、上司の同僚(親戚でいうと叔父・叔母)、部下の同僚(親戚でいうと甥・姪)などにも評価してもらおうという制度です。単に公正な人事評価をしようという目的だけではなく、本人へのフィードバックを多くしようという教育目的もあります。評価者が多くなればなるほど増える手間暇に見合うだけの目的をちゃんと設定できているかどうか、というのが成功のポイントなのかな、と思いました。

※朝の電車で3回くらいチャレンジしたのですが、毎回数ページもいかないうちに寝てしまうので、パラパラ読んで終わることにしました。いつかもっと興味を持って読める日が来るでしょう。たぶん。

プロダクティブ・プログラマ読んだ

読みました。
プログラマ向けのユーティリティ紹介とか、tipsとか、各種自動化テクニックとか。
以下は、読むまで私が知らなかったもので、試そうと思ってるもののリスト。

  • CLCL
    Windows向けクリップボード拡張。
  • !キー
    bashのコマンド履歴を検索するhistoryコマンド。!の後に検索したいコマンドの最初の文字を入力する。
  • pushd, popd
    カレントディレクトリの履歴スタックを操作する。
  • OpenCommandWindowHere
    MicrosoftPowerToysのひとつ。名前の通りの機能。
  • KeyPromoter
    shortcut keyを使うようにしつこく勧めてくれるプラグイン。IntelliJとEclipseにある。
  • ローカル変数の抽出:Alt+Shift+L
    右辺になるところを選択状態、または、右辺だけを書いた状態で起動すると、変数の宣言と初期化をやってくれる。
  • 型の検索:Ctrl+Shift+T
    キャメルケースの大文字のところだけタイプしても検索できる。
  • AutoHotKey
    Windows向けのキーマクロ。
  • wgetのmirrorオプション
    サイト全体をミラーリングできる。
  • Pluse(Eclipseプラグイン)
    プラグインのインストール先を外部化して、SVNなどに保存可能にする。
  • リファクタリングではコメントの排除を目指す。(コメントがある=わかりにくさの補完。コメントが無い=補足が不要なほど分かりやすいコード)
  • Panopticode
    Emma, CheckStyle, JDepend, JavaNCSS, Simian, Panopticode Aggregatorを含むコード解析ツール。
  • SLAP
    同じメソッドに属するコードの抽象化のレベルをすべて統一する。
    それによってコードの抽象化レベルがそろうのであれば、1行のメソッドを作っても特に問題はない。
  • JEdit
    Java製エディタ。
  • eEditor
    MACのTextMateのWindows版。
  • Groovyのマークアップビルダ
    コードからXMLを生成するためのツール。既存XMLからコードを生成することもできる(アンビルド)

アジャイルな見積りと計画づくり

読書メモ。(ちょっと愚痴っぽくなったけど)

第一章 計画の目的

p034.
「変更されてもかまわない」というだけでなく、むしろ「積極的に変更したい」と思うのがアジャイルな計画である。変更そのものに価値があるわけではない。私たちが変更に積極的なるのはなぜかというと、変更が起きると言うことはすなわち、なにか学習したり過ちに気づいたりしたことを意味するからだ。

メモ:変更が多いということは、たくさん間違っていたということ。過ちに気づいたのは歓迎するべきだけど、それを計画段階で拾う方法が本当に無かったのかは、ちゃんと考えてみたい。

第二章 なぜ計画づくりに失敗するのか

p044
ユーザーが最終的に何を求めるのかには不確実性があり、はっきりとはわからない。この事実を無視すると、プロジェクトとしては期日を守れたとしても、ユーザーにとって本当に重要なフィーチャを取りこぼしてしまいかねない。というのも、計画を立てた後で明らかになった重要なフィーチャを反映させられないからだ。

メモ:最終的に求めているものと、今求めている(と思っている)ものが違う、ということをユーザーに自覚してもらう戦略について考えてみたい。

第五章 理想日による見積

p069
理想日で見積もるときには、以下のような前提を置く。

  • ストーリーに必要な作業だけを見積もる
  • 作業に必要なものはすべて、作業の開始前に用意されている
  • 途中で割り込みは発生しない

メモ:後でベロシティを計測できるように、見積の前提条件を統一しておくためのテクニック。

第六章 見積の技法

p074
まず、アジャイルプロジェクトでは誰がどの作業をするのか事前にはわからないことが多い。たしかに、複雑なストアドプロシージャのタスクはデータベースに詳しいメンバーがやってくれると期待していい。だが実際には、必ずその通りになるとは限らない。その人がたまたま他の作業で忙しく、他の誰かが担当せざるをえなくなるかもしれない。ある作業を担当する可能性は全員にあるのだから、見積にも全員が関与すべきだ。

メモ:ある作業を担当する可能性は全員にある…それはそうなんだけど、見積時にはチームメンバすら決まってなかったりする(だって納期がおおよそ決まっているのに規模は分からない状況で要員計画できないし)。 協力会社のメンバに作業してもらう可能性も排除できないから、かなり無理して全社員で見積できたとして実際に作業するメンバーの事前の合意を得る事なんて無理かも。
なので、「見積をコミットメントと捉える」従来型の計画づくりには適合できない。導入するならそこからやらないと、ギャンブルになるか、どこかにしわ寄せが行くか。

p081
2分計の砂時計を購入して、プラニングポーカーのセッション中にはテーブルの中央に置くのだ。セッション中はいつでも誰でも砂時計を使ってよい。砂がつきたら(つまり2分が経ったら)、次のラウンドに進む。議論が合意に達しなかった場合は、議論を続けてもよいが、そのときは再び砂時計を使う。こうすれば、次の議論も2分間に制限できる。一度の議論で砂時計が2回以上使われることは稀である。砂時計を使うことを通して、チームはこれまでよりも迅速な見積のやり方を学ぶからだ。

メモ:どんな会議にも応用できそう。

第七章 再見積り

p085
「自分でもよくわかっていないことを、厳密にしても意味がない」
– ジョン・フォン・ノイマン

第二十章

p244
個人のベロシティに反対する議論を続けるが、そもそも個人のベロシティは計算可能になっているべきではない。個人のベロシティが測定できる状態になっていること自体がおかしいのだ。基本的にユーザーストーリーは1人だけでは実現できないように書くべきだ。ユーザーストーリーは、ユーザーインターフェイスデザイナ、プログラマ、データベースエンジニア、テスト担当者のそれぞれが協力することなしには実現できないように書くのである。プロジェクトのユーザーストーリーが、1人で完了させられるような内容ばかりなのであれば、ストーリーの書き方を見直した方が良い。

メモ:そんなに専門家がそろっている会社って、あるんですね…。

私の強み

先日、ストレングスファインダーをやってみました。
30分くらいかけて、性格診断アンケートみたいなのに答えていくと、34種類の資質のうち、特に強いもの5つが分かるそうです。受験には書籍(古本不可)の購入が必要。

わたしの診断結果は以下のとおり:

  • 学習欲
  • 収集心
  • 目標志向
  • 着想
  • 最上志向

アンケートの質問文が、よく意味がわからないことがあって、ちゃんと答えられた気がしなかったものがありましたが、だいたい正しいとおもいます。これ、強い順に出てるのかな。誰か知ってたら教えてください。

あなたのStrengthsFinderの結果に基づき、上位5つの資質を強い順に並べたものです。

って書いてありました。ほー。学習欲と収集心か…本棚が膨張し続ける原因ですね 😉

OSN公開ワークショップ:コミュニケーション・ゲーム前編

先週末、OSNさんの公開ワークショップに参加させていただきました。

テーマは「コミュニケーション・ゲーム」。
ワークショップの内容については、akifunaさんの日記 が詳しいです。ここでは私が体験したこと、気づいた事についてのみ書いておきます。

ゲーム1:秘密の指令ゲーム(勝手に命名)
私は、「まとまりにくい指令」テーブル(table#2)に参加していました。

このテーブルの司令書(封筒に入ってた)には、秘密にするべきことと、実現したい要求について書かれています。厄介なことに、

  1. こちらの要求を実現する(相手側に聞き入れてもらう)ためには、秘密にするべきことを公開(背景情報を共有)しなければならないようになっている。
  2. ゲーム中に知ることが出来ないのですが、互いに情報共有しなければ、両者とも問題の全体像を把握できないようになっている。(しかし情報公開するな、という指示がある)
  3. 互いに衝突するようにしか見えない利害が存在する。(情報公開すれば、実はwin-winにもっていけるようになっているが、情報公開できない)
  4. 機密事項、要求事項の優先順位が分からない/分かりにくいようになっている。

という「ややこしい」状況が見事に演出されている内容です。

このような状況で、どのようにこちらの要求を聞き入れてもらう交渉ができるか、というのが難しいだろうことは、容易に想像がつくとおもいます。

ものごとの優先順位が分からない(上記ポイント3)ので、戦略も立てられません。win-winな解決策をさぐるには、互いに要求の背景を説明することが必要なのに、それも禁じられています。

とりあえず、私達は「情報公開せずに、自己の利益だけを追求する」というwin-winからは最も遠そうなやり方で、トレードオフポイントを見つけようとしたのですが、なかなか進みません。互いに、公開できる限られた情報と、それぞれの要求を伝えるのに2分もかかりませんでした。背景情報の説明なんて無しですから…。

とにかく情報を出さないでトレードオフしそうなポイントを見つけるには、質問しつづけるのが楽そうだったので(多分、相手側もそう考えてのことだと思いますが)、私達は互いに質問しつづけました。提案は無しです(要求はもう伝えてあるし)。情報は小出しにしますし、知ってることも「知らない」とか「言えない」と言ったりりします。そして、相手側がウッカリ(たぶん)言ってしまったことについて、どんどんツッコミます。そりゃぁ、険悪にもなりますよね…。

とにかく、そうやってジワジワと(互いのウッカリとかの積み重ねで)話が進むのですが、交渉は平行線のまま、あっけなく時間切れになってしまいました。

さて。

このゲームには3人の登場人物が居ました。「指示する人(司令書)」「指示される人」「相手」です。「指示者(指示する人)」「実務者(指示される人)」の立場で、上手に問題を解決するにはどうするべきだったか? について私は、幾つか気づいた事があります。

  1. 指示者
    1. 優先順位を明確にする。
    2. 相手が納得できる(論理的な)道筋を、実務者に示す。
    3. 相手が納得できそうな落としどころを付けられるだけの権限(情報公開なども含む)を、実務者に与える。
  2. 実務者
    1. 上記が明確になるまで、指示者と交渉する。

指示内容に優先順位があれば、戦略的に交渉できるでしょう(指示者のポイント1)。それが無理なら、あらかじめ落としどころを考えて指示する必要があるでしょう(指示者のポイント2)。それを考えることができないのなら、実務者の判断で優先順位をつけて、実務者の判断で条件提示(または情報公開)できるだけの権限をあたえる必要があるでしょう(指示者のポイント3)。

実務者は、指示受け取り時に、上記ポイントを押さえられるように、指示者と交渉するべきです。

そして、どれも不可能なら、普通は話がまとまらないよな…ということを考えました。

長くなったので、ゲーム2については、また後日かきます。