渋日記@shibu.jp

土曜日はXPまつり2009でした。スタッフとして参加していました。参加者への配布物がたくさんあったので、「配りやすいように、４種類のチラシとかEM ZEROを１部ずつ束ねて、配りやすいようにしよう」と、セッションが始まった後の時間に数人でワイワイやっていました。今回のXPまつりの気づきとしては、この作業中の@afukuiさんのつぶやき「こういう作業って、最終的にはセル生産になっていくんだよね」というものから１つ得ることができました。

そして昨日、実家の屋上で親と人工芝を並べて、パチパチくっつける作業をしたのですが、この作業中に@fukuiさんのつぶやきを思い出していました。パチパチくっつける作業は以下の３工程に分けておこないました。

1. パネルの向きをそろえる
2. ジョイント(1辺に8個ぐらいある)の両端だけパチパチ付ける
3. 残りのジョイント部を足で踏んづけて固定

最初はパネルの向きを合わせるのと、両端を付ける作業を父親と二人一組でやっていました。だいたい作業時間が一緒だったので。その後、母親が入ってきたら、パネルの向きを合わせる作業１人に対して、パネルの両端をパチパチする作業２人になったり、最終的にはみんなバラバラに作業をしました。@fukuiさんのつぶやきが頭に残っていたので、色々考えていたけど、このような工程の変化は「平準化」の程度によるのかなと思いました。役割分担をするというときには、各人の作業のバランスがとれていないとダメです。各作業も、慣れてくると劇的に作業効率が変わってきます。今回の場合は、向きを揃える作業がそう。段ボールに入っているパネルの向きの法則性が分かったら、ほとんど頭を使わずに向きを揃えられるようになったからです。変化の過程を観察するとこんな感じかな。

• 流れ作業でｎ人で作業をする
• １部分の作業効率が改善して、手が空く人が出る
• 手が空いた人はすぐ隣のボトルネックの作業に手を出し始める。ボトルネックが並列化する
• この流れが至るところで起き始め、次第に全員並列のセル生産になる

各工程の平準化が崩れるところがポイントみたい。

果たしてセル生産は進んでいるのか？そうじゃないのか？

続きを読む

XPまつり参加の方々、スタッフ、スピーカー、LTトーカーのみなさん、お疲れ様でした。いろんな意味でアジャイルな運営でしたが、個人的には運営のVIPはキータムラーさんかな、と思います。努力の割にすごいクオリティで、なんでこんなイベントができたのか・・・経験以外にどういう要素があったのか、良くわからないぐらいですが、すごく楽しく過ごせました。

参加者の方が結構楽しんでいたという噂の、匿名希望さんのLTの資料と、トーク原稿を本人から預かりまして、アップロードして欲しいと言われたのでアップします。プレゼンテーションZENの要素が入ると、スライドだけアップしても意味が分からなくなってしまうのですが、それを補足しようとすると結構たいへんですよね。誰かいい方法あれば教えて下さい。

• 発表資料(on slideshare)

---

SMマトリックスという、行動やコミュニケーションの癖を４つにパターン化することにより、行動や会話の予測、改善に繋げられる、強力なツールがあります。自分のために行動する＝支配型、相手のために行動する＝服従型、自分から行動する＝Ｓ、相手から行動してもらうのを待つ＝Ｍという２軸からなる４パターンで人間を分析していきます。２×２で、支配型Ｓ、支配型Ｍ，服従型Ｍ，服従型Ｓになります。おそらく、EM ZEROの野口さんは「気持ちよく、自分の望み(原稿)を得られるような雰囲気を作るということで、支配型Ｍです。服従型Ｓと支配型Ｍは、相手の望みをかなえようとするし、自分の望みを相手にかなえてもらおうと画策するので、間接的なコミュニケーションが得意です。逆に、支配型Ｓと服従型Ｍは直接的なコミュニケーションが得意です。

このSMマトリックスを使って、よくあるような恋愛術、モテ講座などを分析すると、女性は「自分の望みを他人に叶えてもらう」支配型Ｍ、男性は「相手の望みを自分が叶えてあげる」服従Ｓのポジションを取るということで、恋愛がうまくいくという前提にたっているということが分かります。今までの恋愛本・モテ男養成塾の特徴といえば、この間接コミュニケーションラインに強くフォーカスしているという点です。女性は支配M。いかに男をその気にさせて、相手にアクションを起こさせるのか、ということが中心に書かれています。また、モテ男養成塾も、相手の望みを知り、それをかなえるのか、というのを中心としています。(補足：間接コミュニケーションの話は当日は時間の都合で削られた模様)

ですが、ほとんどのIT技術者は支配型Ｓです。そのうちの半分はツンデレ。そして、周り（XPまつりの参加者）を見てもらえば分かる通り、ＩＴ業界のイベントはまさにメガネ男子牧場。こんなにエサだらけなのに、今までの恋愛本はこのフィールドを完全に無視していたなんて、もったいないですよね。IT技術者は、支配S。直接的コミュニケーションが得意なタイプ。そのため、IT技術者に対して、恋愛本に書かれているようなテクで迫っても効果がないのです。ということで、今回発表するタイトルはこれです。

続きを読む

アジャイルな見積りと計画づくりを読んでいます。元々アジャイルとかを追っかけていると、知っている内容もそれなりにあったりはしますが、見積もりという、発注側と開発側の境界線上の業務に沿った話ですので、ぜひともビジネス側の人にもアジャイルを知ってもらいたい！というときに一押しできる本だと思います。

この本にはバーンダウンチャートの書き方が２種類でてきます。僕がかつて翻訳したことのあるScrum本で紹介されていたこともあって、バーンダウンチャートにはちょっと懐かしい気持ちもあったりはしますが、２種類目のやつが僕が考えていた改良策とちょっと違う内容だったので、ここのブログで僕のアイディアを公開します。本当はこれだけでライトニングトークスできるネタではありますが、さらっと公開します。僕の場合はLTネタはもっと濃いモノが期待されていそうなので。

作成するのはこれ。株式のろうそくの足チャートを利用して、タスクの増加分、タスクの消化分も一緒に表示したグラフになります。Excelの準備はよろしいでしょうか？Google Spreadsheetは・・・ムリそうかなぁ。本当はこういう見える化ツールこそ、オンラインでできるといいんですけどね。あ、ろうそくの足なので「キャンドル・バーンダウンチャート」と適当な名前にしていますが、もっといい名前があったら教えて下さい。

続きを読む

オブラブレポート第二弾です。懇親会です。今回はLT資料を作っていたら、どうしてももう一つネタがしゃべりたくなって、勢いで資料を作って参加しました。リジェクトトークスは3分。でもスライドの枚数はあんまり変わりませんでした。ささ、こちらの資料もどうぞ。

続きを読む

by TBradleyDean

VS

by Army.mil

アジャイルソフトウェア開発についての本が出てから、もう9年ぐらいになります。この間、いろいろな本が出されていてアジャイルソフトウェア開発だとか、アジャイルテスティングだとかアジャイルデータベースとか、言葉は色々出てきています。じゃあ、アジャイルの本質って何なんだろうか？というのを僕なりにまとめてみました。「コミュニケーション中心だ」とか、「人間中心だ」とかいろいろありますが分析するだけではなくて、ソフトウェア以外の他の業界にも役に立つような知識を提供するのがこのエントリーの目的です。アジャイルは他の業界に輸出されるべき、価値のあるモノだと思っています。

僕の考えるアジャイルの本質は「人間の弱点に合わせた仕事をする」言い換えると「無理な管理はしない」ということにつきます。逆に、旧来の(ウォーターフォール)と呼ばれる開発手法の問題の本質は「人間の弱点を管理しようとする」と言えるかな、と思います。後者についてはきちんと考え抜いてませんが。

続きを読む

XP祭り2008で発表してきました。LT五輪でみごと銅メダル。このブログでは、５分に込めたかったけど、言葉では表現しきれなかったことなどを補足してみたいと思います。ぐぐリストというページを作って、「後で自分で調べてね」という資料にはなっていますが、それ以外の自分の考えの部分です。

小悪魔agehaというのは女性向けのファッション誌です。見た目はこんな感じ。大きめの本屋もしくはコンビニで買えます。 続きを読む

Buildbotを使って、仮想環境も利用すると一台で多数OSのテストを行える、というのがPyDevCampで清水川さんに教えて頂いたことです。マルチOSなテストは今はしてないけど、いつかはこういう環境を用意したいと思います。PySpecもwxPytnonがない状態でのテストも一緒にできたらいいな、と思うし。あ、そんなときのvirtualenvか。でもBuildbotと共存できるかどうかは調査が必要かな。

builder by ZDNetの記事によると、Intel CPUのMacOS XマシンにはSolarisもインストールできるとか。この記事はBootcampだけど。もし仮想PCとして起動できるなら、MacOS X, Windows, Linux, Solaris, FreeBSDなど、多くのテストを一台でまかなえるようになるのかな？これならXeonのMac Proを買ってもエコな気がする。買わないけど。

---

この記事と関係ないけど、Firefoxのスペルチェック機能って便利だね。僕みたいにちょくちょくプアな英語力で英語を書こうという人には。FireFoxアドオンでPySpecのGUIを作るってのはどうかな？できるか分からないけど。FireFoxアドオンもちょっと調べてみよう。

トヨタ生産方式のかんばんと、ソフトウェアかんばんは別ものですよね。トヨタ生産方式の方は、各工程間の情報のやりとりの手段。全体をみなくても、この「かんばん」という、全体からすると一部分の情報片だけを見ていれば仕事が回るというもの。まぁ、本来のトヨタ生産方式では、本当に「かんばん」のみの情報伝達をしていたように書かれていますが、さすがに21世紀はもっとコンピュータ化されているんじゃないかと思いますけど。ポイントは、ラインの作業者には、一部分しか見ることができないということ。

それに対して、ソフトウェアかんばんというもの(定義があるかは分からないけど、トライコードとかで実装されているもの)は、作業全体が書かれたモノです。朝会などで、チーム全体でかんばんを見て、仕事の割り振りをしたり進捗を見たり。確かに一枚のかんばんは、一つの仕事を表しているので、かんばん方式と類似性があるように見えますが、チーム全体で作業の全体を常に見て把握できる、かんばんの選択にチームメンバーの主体性がある、というところは、まったく異なると思います。

続きを読む

PySpecの新バージョンお披露目は現在取り組み中の0.53(なかなか安定しないので1.0にならない)で3回目です。そして、毎回リリースの作業では時間がかかります。アジャイルソフトウェア開発っぽいツール(テスティングフレームワーク)である以上、そこの部分は改善していかなきゃと思っています。

アジャイルソフトウェア開発で必要とされるものに「リズム」があります。なので、今まで4分音符で刻んできたのに、いきなり４小節ぐらいまたがる長い音なんかが出てくると、リズムが乱れます。特に、個人で趣味でやっている場合には、２〜３日かかってしまうと、リリースするのがおっくうになってきます。「やる！」と宣言して自分をむち打たないとね。

続きを読む

バズワードを考えてみました。ちょっと前の日記に書いた、「管理のためのテスト」ではなくて「開発を促進するためのテスト」という意味を表現したいなぁ、と思っていたら思いつきました。

ユニットテストだと、Ｖ字開発モデルの底の方でやるショボいテストみたいなイメージを持たれかねない。デベロッパーテストというと、開発者だけのものになってしまう。でも、ユニットテストやテスト駆動開発の持つパワーは開発者だけのものじゃない、と思っています。

で、指導する、などの意味でいくつか調べてみて、候補に挙がったものがいくつかあるけど、適当に選別。

ディレクティブ：なんか偉そう。ちょっと意味が伝わるのに時間がかかりそうでいい。
リーディング：Leadingだけど、Readingも被る。何か速読か読書術みたいだ。
トラクショナル：なんかダウンフォースで上から押さえないと抜けそうな感じがマイナス。

ちょっと検索してみると、ディレクティブテストだと、管理職の昇進テストみたいな意味もありそうな気もするけど、まぁこれでよしとする。

ＸＰの受け入れテストはユーザテストをディレクティブにしたもの、と言える。数週間先の目標を、テストという形式で提示しているからだ。この前のＮＬＰセミナーの、「否定形ではなく、主体的に達成できる目標を立てて下さい」という問いもディレクティブだ。合気道など相手の地力をうまくコントロールするというやりとりのきっかけになるものはディレクティブテストである。もはやユーザもデベロッパーも関係ない。クレドやフィロソフィーというものに基づいて行われる質問もディレクティブだ。

と、勢いで書いたけど、とりあえず、ライトニングトークスのネタかなぁ、という感じです

「デザインとはバランスを取ることだ」というフレーズが急に頭に浮かんできました。

いわゆるソフトウェアの設計フェーズ。なんのバランスを取っているかというと、実装の手間と機能。なるべく手間が少なく、多くの機能を詰め込む。アジャイルは常にバランスをとり続ける。アジャイルの場合はただ機能のバランスを取るだけじゃなくて、時間や費用対効果のバランスも取り続けます。

ウォーターフォールだと、「この機能を入れる」というレベルまでは面倒を見れても、「この機能は重要だから、もっと時間をとって作り込もう」とか、「ここはあんまり使わないから、ダイアログもそんなに使いやすくなくてもいいよ」みたいなバランスは取らなくて、だいたい出来上がってからユーザに文句を言われるというオチ。そういう意味ではアジャイルの方がいっぱい設計しているということですよね。

咳さんがよく日記で「設計って何？」とか「分析って？」みたいなことを書かれていますが、咳さんみたいな人はきっと「コードの美しさ」と「機能」と「拡張性」でバランスを取っているような気がします。違うかなぁ。今度聞いてみよう。