モメごとになる前に、モメごと本を読んでおこう。

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術

 　献本頂きました。なぜシステム開発は必ずモメるのか(以下、モメごと本と記す)。実は馴染みがある本です。というのも、「リーン開発の現場」を探して書店を回っていたとき、結構な頻度で隣に配置してもらっていたためです。

 　さて、こちらの書籍、書き手はIT訴訟の調停委員をされていた方ということで、法的観点からソフトウェア開発のさまざまな問題やリスクを評価、対策を解説する内容になっています。当然ながら法的な解釈については説得力があり、だいたいにおいて「まぁ、そういう判断になるんやろうなぁ」という妥当感があります。

　モメごと本の中で主人公がたびたび口にするように、法的判断といっても杓子定規なものではなく、意外と要件定義書とか設計書とか開発のためのドキュメントが判断材料になったり、「ふつう考えたらそらそうでしょ」な観点も盛り込まれることに気づきます。後者は例えば、ITベンダーは開発のプロなのだから、プロとして発注側に開発上のアドバイスを怠ったりすると、その責任を問われることがある、など。善管注意義務というやつですね。 

　構成は、7章からなり、要件定義、外部設計、内部設計、プログラミング・単体テスト、統合テスト、システムテスト、受入テストと章がふられています。下敷きにしている開発のコンテキストは、この章立ての字面の印象から受け取れるとおりです。また、システム開発の受発注を想定しています。なので、サービス開発を内製でしてきております、という方にはちょっと想像し難い設定かもしれません。

　では、ウォーターフォールや受発注型の開発でしか得るところが無いのかというと、そうでもありません。システム作りを頼む側と頼まれる側という文脈に立って、この本を読むと、様々な発見があるはずです。頼む側も頼まれる側も、双方がどのような期待を持っていて、何を考え、どんな姿勢で開発に臨む可能性があるのか推し量ることができます。それは、開発のリスク察知の上で参考になります。各章末にチェックリストがついていて、自分の経験が不足している局面についての良い補完になると思います。また、メインターゲットとなる受発注型の開発をされている方(で、まだプロジェクトの経験が浅い方)はとにかく一度目を通してみると良いかと思います。「え、この解釈ちょっと厳しくない？」と思えるものがあったら襟を正すには良い機会かもしれません(私もいくつかありました)。

　なお、文体というか書き方が人物の会話形式になっていて、こういう形式の開発関連本って最近見なくなったなーと同時に、たくさん字を追うのが苦手な方には読みやすいかもしれないと思いました。内容はみかけの文体ほど軽くはないので、自分だったらどうするという解釈を入れながら読み進められると良いのではないかと思います。

現場はどこだ？ 現場は、今、ここだ。

このエントリーはDevLOVE Advent Calendar 2013 「現場」の9日目の記事になります。

自己紹介

改めまして市谷といいます。ソフトウェアの受託開発の仕事をしています。

現場はどこだ？ 現場は、今、ここだ。

「このWBSを更新してあすの進捗会議に届けなければならない。」

　上司からのメールを読んで、氷を飲み込んだような冷たさを体に感じた。WBSの項目は気が遠くなるほどある。それを1つ1つ更新していく。大丈夫だ。状況は壁に貼ったタスクボードを見れば分かる。しかし、いかんせん数が多い。隣を見ればチームメンバーが2人3人まだ残ってタスクに挑んでいる。別のチームの島も覗いてみる。同僚のチームリーダーがじっとディスプレイを食い入るように見つめている。彼も同じ状況だ。時間は22時を回った。夜の高層ビルの窓際はたいそう冷える。ビルの玄関口が閉まってしまう前に、ホットコーヒーを買いにいこう。このEXCELとの格闘は間違いなく夜を徹することになるのだから。

　かつて自分が居たその現場のことを時々思い出す。もう5年も前になるが、割と鮮明に記憶に残っている。誰がそこに居て、何に憤り、どんな朝会で、何を皆で笑っていたか。決まって進捗会議の前の日は徹夜になった。結構無茶をしたし、怒りに身を任せて上司にかけあったことも何度かあった。プロジェクトとして順風満帆とは全く言えなかった。むしろ、あまりよくない方の記憶として記録されるべきプロジェクトだろう。

　だが、そのプロジェクトはここまでの10数年のキャリアの中で最も面白く、最も自分が学んだ時間だったとはっきりといえる。毎日が実験だった。試す、試す、試す。状況を好転するべく、知恵を絞る。自分一人だけではない。頼もしいチームメンバーと一緒に考える。顧客とも考える。顧客と開発チームという立ち位置を越えて、ミッションを共通に感じていた。当時はインセプションデッキなんてまだ無かったけども、われわれはなぜここにいるのか？きっと言えたと思う。

　私にとっての現場とは、誰かにとって必要なモノやコトを一緒に創る場だ。「誰かが分からない、役に立つかも分からないモノ」は作らない。システム作りなのだからと「開発側だけで作る」こともしない。自分たちには無いドメインの知識や経験を持っている相手と共に創る。目的が近くなるよう知恵を出し合いながら創る。相手はある問題を解決したいと考えている。こちらも相手に問題を解いてもらいたいと思っている。そのために必要な知識とスキルと経験を持ち寄って、創る。思えば現場とは、互いのWhyを実現するために、互いの持ち味を持ち寄る場なのだ。どちらかというとこれはまだ、理想だ。私はそうあるために、現場で仕事に向き合い続けている。

　最後に、ある私信も兼ねて。もし、仕事でミスしたり、クヨクヨすることがあったら、自分は誰の何のために仕事をしているのか思い出して欲しいんだ。それは、いつものクライアントの課題を解決して喜びを分かち合いためかもしれない。それは、憧れの上司を支えて組織を前進させるためかもしれない。あるいは、自分自身の学びや独り立ちのためかもしれない。その理由は実は何でも良い。その理由を他人の誰かがとやかくなんて言えやしないからだ。本当にそれが誰かのためになっているのなら、他人の言うことなんて聞かなくていい(立ち止まって考える機会は大事だよ)。自分が仕事をしているWhyを持ち、向かいたい先を見据えていれば、日常の悩みが些細なことに思えてくるはずだ。いや、むしろ囚われすぎてはいけないんだ。私はこう考えるようにしている。夜の間、世界は暗い。けれども。視線を上げれば、月が見える。私がこれからの生涯を含めて月に辿りつくことはないだろう。だが、それでいい。月が見えていればいい。そうすれば、向かいたい先を見失うことは決してないのだから。

次の現場は

上野さんです。

リーン開発の現場に、いたる道。

 「各自頑張ってください。」

　やや照れくさそうに、トークの最後はその言葉で締められた。10月28日にサイバーエージェントさんをお借りして開催した「リーン開発の現場」の出版イベントでのことだ。最後の言葉がしばらく耳に残った。その言葉を頼りに自分の記憶を辿ってみると、ある出来事が思い出された。

　それは2008年10月31日のことだった。出版イベントの実に5年前だ。当時私は友人の同僚と2人で「アジャイルプラクティス」の読書会を社内で開催していた。その締めくくりとして監訳者の2人を会社にお招きしたのだった。最後の読書会も終えて、その懇親会で私は恐る恐る監訳者の1人に話しかけた。その時、監訳者の方とは"持ち場"の話をした。自分たち一人一人が"持ち場"を持っている。それぞれが大切にするものは違うかもしれない。それを大切にすることは、決して楽ではないはずだ。様々な問題が待ち構えている。しかし、自分の抱える問題の解答は他人の中にはなく、自分が向きあっていくしかない。だから、自分が大切にするもののために、頑張る。監訳者の方は、私との会話をこう締めくくったのだ。

「各自頑張れ、やで。」

それは5年かけて再び耳に帰ってきた言葉だった。

ラスト3マイルからの戦い

　前回のエントリから出版に辿りつくまで「3マイル」と見立てたが想像以上に険しい道のりになった。書き終え、一旦はレビューも終わった日本語の文章を徹底的に磨いていく。残っていた誤訳をしらみ潰しにする。読んでみて感じるひっかかりを削ぎ落としていく。監訳者角谷さんとのそのやりとりはすべてgithubのissueでおこなった。角谷さんがissueをあげる。こちらでissueを倒す。角谷さんがissueをあげる。こちらでissueを倒す。50のissueを倒したら、50のissueが増えている。まさに全文に手を入れ、書きなおしていく。原文の読み直しを1周したら、2周目。2周したら、3周目。issueでのやりとりを締め切り直前まで繰り返す。

　アジャイルサムライの時も直前まで手を入れていたという。「下手くそは、努力するしかない。」上手にやれる人はもちろん居る。だが、そうでないなら。やるしかないのだ。

日本語版のまえがきと解説

　今回、日本語版まえがきは角谷さん、解説は平鍋さんにお願いをした。このお二人に文章を頼んだのには思いがある。私はお二人が出した本や話したこと、その背中を見てきた。アジャイル開発に向き合ってきた、少し年齢を重ねている人ならきっと分かってくれると思う。日本のアジャイル、その最初の10年はこの二人が誰よりも先を突き進んでいた。いつも前にその背中があった感覚だ。

　平鍋さん、角谷さんと初めて会ったのは2006年のことだったと思う。角谷さんとその後まともに話をしたのは先に書いた2008年の読書会の懇親会になる。そして、2010年に初めてデブサミ発表のオファーをもらい、発表内容の相談に乗ってもらった。2011年には、私は上野の会社に移る。

　やがて、2006年から7年の時が経ち、1冊の本が出来た。その監訳者まえがきで、藤原と私をこう紹介して頂いた。

「学びとは、ただ知ることではない。知識は頭の中のものだが、学びとは手の中にあって、熱意によって行動に移されるんだ」というフレーズを体現するアジャイル開発実践者です。

(監訳者まえがき より)

角谷さんに"アジャイル開発実践者"と呼ばれることは自分にとって格別だ。自分にも歩みがあって、ふりかえれるくらいの道のりがあることに気付く。たくさんの人や書籍との出会い、出来事や仕事があって今の自分に辿りついている。すべて自分にとって必要なことだったのだと、受け入れられる。生きていれば愕然とすることや憤ることもたくさんある。出来れば避けたいと思う。しかし、ひとたび自分の時間として経験したならば、それは必ず自分の一部になる。

相棒

　人との出会いを思い起こしてみると似たような経路を辿ることに気づいた。ある人と出会えたのは、別の人が居て紹介してくれたから。その別の人と出会えたのは、コミュニティをやっていたから。そして、コミュニティをはじめたのは今やあるメガネ屋さんでRubyプログラマーとして腕を振るう仲間が、その昔同僚に居てくれたからだった。

　さて、藤原大と出会えたのはよしおかさんが居て紹介してくれたからだった。ただし同じ会社に居ながら、その後ほぼ関わりは無かった。やがて私が会社を辞めるときを迎える。藤原とは終わりを迎えてからが始まりだった。2012年にダラスのアジャイルカンファレンスに行った。その後、イベントを開催した。そして、本を作った。

　本作りは10ヶ月を要した。その間、だいたい彼が夜0時まで作業を行い、私が0時から作業を開始するという体制になっていた。「一夜明けたら、issueが半分くらいになっていて、彼がどんな驚き方をするか」を期待するのが密やかな楽しみだった。オンラインでのやりとりがだいたいで、リアルに会うことは数えるくらいしかなかった。生息する時間帯も、所属する会社も、考え方も性格も異なっていて、それでも背中を任せるのにこんな安心する相手は居なかった。おそらくは「現場が好き」という共通するたった一つのことがあったからだと思う。

 　かくして、「リーン開発の現場」は出来上がりました。ただただ、読んで頂けるだけでこんな嬉しいことはありません。そして、読み終えたら。各自頑張っていこうではありませんか。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

ダラスからの帰り道、Lean from the Trenchesを日本に届けようと思った。

　目の前にいる彼の口調は若干、いや、相当早かった。時おり顔全体を笑顔でゆるませて、早口に語りかけるのであった。私は、彼の語る「自分たちの現場の物語」に、引きこまれた。彼の名前は、ヘンリックといった。

　2012年の夏に開催されたAgile2012のヘンリックのセッションに参加して、私はレポートを書いている。

　へんりっくのかんがえたさいきょうのかんばん – Agile2012 現地レポート

彼の書籍「Lean from the Trenches」は、PragmaticBookShelfから出版されている。Agile2012でも書籍販売ブースに並んでいた。彼のセッションを聞いて、私は彼の物語を日本に持って帰ることを決めた。

　Agile2012に行って、その帰り道に、日本に戻ったらやろうと思ったことが3つあった。最初の1つは、カンファレンスの開催だった。

　日本にも10年かけて育ってきた、"Agile"がある。

　もう1つは、日本の現場をフィールドワークすること。

　ソフトウェア開発の現場パターン -アジャイル型開発におけるプラクティス活用事例調査-

　最後の1つが、この物語を日本に居る友人たちに紹介するということだった。Lean from the Trenchesは、理論をまとめたものではなく、ヘンリックが実際に現場で工夫してきたことを生々しく描いた、実践の本である。より良い仕事をしたいと、前進し続けようとする開発現場にとって、この本は、向かうべき先を示すコンパスになりうると思った。

　さて、この本の訳をどのように進めるべきか。何しろ商業本として翻訳に携わるのは初めてのことだ。一人で進めるには何かと心もとない。ふと、アジャイルサムライを手にとってみると、そこには2人の監訳者の名前があった。アジャイルプラクティスも、アジャイルな見積りと計画づくりも、2人だ。そうか、翻訳は2人だ。相方を探さなければならない。この本を訳すからには、当然この本を気に入ってくれる人を探すべきだ。ほどなく、一人の男を思い浮かべた。藤原大だ。

　2012年の暮れも押し迫ったある日、彼の家にカニ鍋を食べに乗り込んだ。楽天市場で彼が購入したカニは実に美味しかった。鍋を挟んで、彼はいつものように何でもないように応えた、と思う。

「やるか。ぱんだ。」

こうして、2人の本作りの旅は始まったのでした。それは、短くも、長い旅の始まりでした。今、書籍刊行の予告を打てるまでに至ったのは、相棒の大はもちろん、多くの人の協力があってのことです。本当に感謝をしています。

　Lean from the Trenches 日本語翻訳版 2013年秋頃予定

出版までは、あとラスト3マイルくらい。僕らは向かい続けることにします。

時を超えた共に開発する者への思い。

　2009年ごろ、所属していた海外沿いのSIerにて、社内の組織を超えた繋がりを作る目的で、社内イベントを開催していた。この開催の後に、自分が残してたエントリを覗いてみて驚いた。

　このイベントに込めた思いが、この会社が続く限り、 生きていて欲しいと願う。 

　これを読むと、すでに自分がこの回で社内イベントの開催を最後にするつもりだったのが伺い知れる。この社内イベントは、100名くらいが参加する、手作りのカンファレンスで、もともとデブサミに触発されて始めたものだ。社内にデブサミのような、自分たちの技術や知識や経験、そして熱さを存分に語る機会を設けようという思いから始めて、この2009年で第3回目を迎えていた。

　2008年にはenterprisezineに取り上げてもらった。

　身近な仲間と繋がり、刺激を与えあう「社内デブサミ」はいかにして生まれたか 

　実際のところ、2009年以降社内版デブサミが開かれることはなかった。私も、当時一緒に企てを推し進めていた友人たちも、一人、また一人と件のSIerを後にしたのだった。

　それから時は流れ、共に社内版デブサミを企画をしていた、川島義隆さんとはコミュニティの方で繋がりを持ち、コミュニティのカンファレンスや関西イベントでの発表など、力をお借りしていた。お世話になりっぱなしなので、少しでもお借りしているものを返したいという思いから、件のSIerでコミュニティとしてイベントを開き、川島さんに話をしてもらう企画を思い立った。

　川島さんの話は、「ふつうの受託開発」と呼ばれる全くふつうではないお話で、いつもはコミュニティで話をしてもらっていたが、本当に届けたい先は、社内の他のメンバーなんだと分かっていた。だから、会場を海外沿いのSIer(もう海外沿いから移転している)にして、社内の人たちが気軽に川島さんの話を聞きに来れるという建付けとした。

　開催日は、あえてデブサミ2013と同じ日の夜にした。デブサミに参加する人たちの多くは、参加のための社内の調整がついていたり、何かアクションを起こそうとしている人たちだと考えられる。

　しかし、デブサミに行きたくても日常の仕事からどうしても参加できない人がもっとたくさん居るのは想像できることだ。デブサミには行けないけども、自分がいる会社で、自分が居る会社の人が、自分の会社の開発の話をする、そこに参加してみようと思う人たちに向けて、開催を企てた。

　HangarFlight - BlizzardSailing -

 　開催からしばらくして、企画を手伝ってくれた海岸沿いのSIerの友人たちと、ふりかえりを行った。ふりかえりの中で、ある若いエンジニアがこんなことを言った。

「DevLOVE(DevLOVE2012というカンファレンス)に参加して、僕はどよめきを得たんですよ。」

　お前がいうどよめきとは何か?と聞いても、とにかくどよめいたとしか言わない。何なんだよ、どよめきって。彼のどよめきが実に面白くて、どちらがけしかけたか定かではないが、じゃあ、海岸沿いのSIerの中でもどよめきを得ることやれよ、という話になった。むかし、海外沿いのSIerにもどよめきを得る場があったんだよ、社内版デブサミと言ってな。お前ら明日ではダメだ、今すぐ事を起こせと、ふりかえりの帰り道に、彼らのオフィスに押し戻して、今すぐ企画メンバーを集める檄文を社内SNSに書け、と半ば強引に事を進めた。

　それから、しばらく静観を続けた。もとより、海岸沿いのSIerの社内カンファレンスなのだ、私が出る幕など無い。ある日、彼らの中心に立ったリーダー(彼と出会ったときは彼も若かったが、今では立派な中堅社員になっていた)がその場に私も呼んでくれるというメッセージをもらった(実のところ何とか押しかけようとさえ考えていた)。

　かくして、社内版デブサミは再開し、私は彼らと再会したのだった。どよめきの彼とも、リーダの彼とも、もちろん川島さんとも。それから、2009年の開催にあたって激しくやりあった当時の企画メンバーで、今回も企画を支えたごみさんとも。5分LTでも必ず100枚近くスライドを用意する塩じいとも。今回のリーダーを支えてくれたあまぬまや、現場仕事に追われて外に行く余裕もない若きインフラエンジニアも。満面の笑顔を見せてくれた。そして、藤原士朗とも。 　

　

　面の厚いことだが、LTの時間をもらえたのでこの話をした。

　 Can we change the world?

 　この話は、最初の社内版デブサミを開いて、開きました!という事例発表をXP祭り2007というカンファレンスで話すために用意したものだった。かなり若い内容だが、あえて手を入れることをせず、あの時と全く同じ話をした。

　みんな、開催にあたっては、本当に参加者が会場に現れるのか、始める瞬間まで不安だったはずだ。だからこそ、この話をはなむけにしたかった。みんなが図らずとも生み出した熱量は、きっと届いているはずだ。大丈夫だ。なぜなら、すでに私が、6年前にそれを証明しているからだ。

　リーダが祭りの最後に言った。やめていった人たちが悔しがるような場を作るんだ。すばらしい。きみは既にそれを達成している。

　私が2009年に残した最後のエントリ、その願いとも言うべき予言は、彼らの手によって成就したのだった。

アジャイル開発の優しい教科書

　わかりやすいアジャイル開発の教科書を読みました。この本の著者の皆さんは関西の方で、いずれの方ともコミュニティにて繋がった方々でした。前川さんには、私が企画した東京の方のイベントでお話を頂いたり、細谷さんとも同じくイベントや本作りでお世話になっています。西河さんには、昔私が関西で開いたイベントに来て頂いたことがありました。お三方ともソフトウェア開発に真摯に向き合っている方々で、私が開発コミュニティに顔を出し始める前から活動をされていて、尊敬する先輩諸氏です。身近に感じる方々がアジャイル開発の、教科書と銘打った書籍を出されると知って、これはどうしても読みたいと思いました。先輩諸氏がアジャイル開発についてどんな言葉を残すのか。どんな言葉を日本の開発現場に届けるのか。楽しみでした。

　本には、様々な工夫が凝らされていました。まずは、構成から。冒頭のテーマは「なぜアジャイル開発なのか」です。Start with Why。いきなり開発プラクティスの紹介ではなく、そもそも、なぜアジャイル開発であろうとするのか、そして、ソフトウェア開発が関与する「価値」とは何なのかに踏み込んでいきます。抽象度の高いテーマなので、すらっと読めてしまうところですが、書籍を一旦閉じて、Whyや価値について思いを馳せると良さそうです。なぜアジャイル開発なのかというWhyに始まり、では現場でどのように導入し定着させていくのか、具体的には何をしたらいいのかというHowへ展開する構成。教科書と銘打っているとおり、テーマに対するカバー範囲は広く、要求を捉えるところから、それを実現するためのエンジニアリングまで。TDDに関してはコードで説明しています。

　本書では、具体的な始め方や学び方のために、いくつかのワークショップを紹介しています。目的や手順を詳しく説明しており、読み手のアクションを助ける内容になっています。他に類書を見ないくらい、ファシリテーションの紹介に力を入れており、この本の特徴にしています。他にも、Smiling Adventureと呼ばれる小さなワークを随所に織り込んでおり、書籍の内容理解を助ける工夫、フーバーストアやマエカワ電器という仮想プロジェクトを題材にストーリーで分かりやすく伝える工夫、実践で遭遇しそうな課題への対処をコラム(「こんなときどうする?」)で補足したりと、書き手の工夫が随所にあふれています。さらに巻末は、書籍の外側で学ぶための場、コミュニティの紹介で締めくくります。

　また、表現の仕方に、この書籍のらしさがあります。要求をこうありたい、こうしたいという「思い」という言葉に、価値をその思いが手に取れるようにすること、すなわち「カタチ」と表現しています。思いからカタチを描き、エンジニアリングによってカタチを実際に作り上げる。カタチはタイムボックスで確認し続ける。思いとカタチを合わせて行くようにする。こういう表現の仕方は私は好きです。

　本書をどういう言葉で表すかと考えたときに、「易しさ」以上に「優しさ」を感じました。数多くの独自の工夫から書き手の、分かりやすく伝えたい、伝わってほしいという思いを私は感じた気がします。この本が日本の開発現場で、アジャイルサムライ以来の全部入り入門書として活用されると願って、紹介を終えたいと思います。

わかりやすいアジャイル開発の教科書