エンジニアが2014年の初めに技術書を読むなら“リーン開発の現場 カンバンによる大規模プロジェクトの運営”を薦める理由

リーン開発の現場を昨年の年末から読み始めて今年のお正月の内に読み終えたんです。かなりゆっくりではあったのは、他に複数の本をところどころで読んでいたというか、通勤の往路は別の本を読んでいるし、お風呂の中はあっちの本を読んでいるし、みたいにちょいちょいとあちらこちらを摘まみながら読んでいるってところもある、という読書スタイルをしていたから、なんですが。


この本の第一印象
アジャイルサムライを読んだことがあるなら、わかると思うんだけど、あの本の文体、よく言えばとってもフレンドリーだよね。エンジニア向けの技術書のお硬い文章になれているとなんだかとっても砕けすぎていて、慣れるまで違和感を感じるかもね。まぁ、アジャイルサムライを読んでいれば「あぁ、あの文体か。」って思い出すまでだけれども。


紙と電子書籍(PDF)の違い
電子書籍でいいところは、挿絵と写真がカラーなところ。あと勿論PDFなのでキーワード検索ができるところ。目次のページで標題をクリックすればそのページに飛べるしね。


この電子書籍Kindleのコンテンツでは“ない”ので、iPhoneとかiPadとかのアプリでどこでも読んだ続きから読めるという便利さはないけれど、PDFなのでコピーができる。だから手間だけど、自分が読むだろうデバイスにコピーを入れておくか、dropboxのようなローカルと同期するクラウドサービスの共有ドライブに入れておけばいい。


PDFだからと言って著作権が緩いわけではなくて、書籍のページに購入したメールアドレスとキーが埋め込まれている。


誰が読んだらいいか
ITのエンジニアが読むのは当然としても、Webサービスを作るようなアプリケーションエンジニア向けか、とは思わないで欲しい。ワタシはエンジニアなら全員これを読んで欲しいと思っている。


なぜか。2つある。多分、多くのエンジニアはきちんとした体系でシステム開発手法を学んでいない。ウォーターフォールの名前は覚えているだろうけれど、それを実践するとき、自分が主体となってプロジェクトの業務としてのワークフローをテーラリングして組み立てられるエンジニアがどれだけいるだろう。企業の研修の場で学んだとしていてもそれは受け身で時間を費やしただけではなかったのではないかな。どうだろう。学んだことを自分のノウハウとして実践できているだろうか。


学んだと言っても実践できていなければホントの学びじゃないよ。1つ目で言いたいことは、きちんと体系だって学ぶということをやり直そう、ということ。


2つ目は、プロジェクトのロールに関わらず、プロジェクトの全体の情況を共有されていなくてもどかしくても、カンバンを使えば自分で手に入る情報の範囲でだけど、プロジェクトを俯瞰することが出来るようになるからだ。そのための“カンバン”というツールが手に入る。はじめてカンバンに触れるなら、挿絵のまま試してみたらいい。テンプレートとして使ってみたらいい。その点、挿絵がカラーな電子書籍版は参考にしやすいだろう。


エンジニアとの特性なのか、−ワタシ個人は嫌いだけど−、バグが出たら、トラブルになってから対処すればいいと思っているエンジニアがわんさかいる。そうしたエンジニアに限ってトラブル対処がいい加減だしトラブル報告書なるものを書けない。いや、トラブル報告書を報告相手が理解しやすい形で整理して書けるくらいならそうならないように配慮しながら仕事をしているだろうから……。


それもでこの本を読んでカンバンの特性に気付いていれば、もしもトラブルに巻き込まれたときホワイトボードの使い方として参考になるだろうし、何よりアナタを助けるだろう。意外とトラブルになったとき、何をしようとしていたか、何をしたら何が起きたのか、それを時系列で書くことを忘れて当たり次第それこそDoS攻撃のようにアタックする。そしてそれは誰にも共有されないし、誰も助けてくれる環境を作っていないんだ。


それは、時間かかるしムダをやっているし、そのトラブルシュートをあなたがやっていたらいつの間にかにアナタがトラブルの中心となってしまうだろう……。それでもいいならいいんだけど出来れば一人でやることでもないんだから巻き込みたいじゃないですか。だから、巻き込むためのツールとしてホワイトボードを情報共有するためのツールとして使うんだよ。


以前あったんだ。本番移行でトラぶったのに、チームのエンジニアがバラバラに解析しようとしていたんだよ。ワタシはその作業を遮って言ったんだ。


「こういうときこそ、フリップチャートを使うんだよ。」
「そんな手間なことはやってられないよ。」
「何をしていたのか。何が起きたのか。これから何をするのか。それを書くんだよ。」
「時刻を入れることを忘れるないで。」
「書けたら、ポイントだけ、顧客にそのまま事実だけを伝えてきて。」


「解析でどこでエラーが起きているか、それを図に描いて。」
「なんで!」
「メンバで共有しないと。頭の中をシンクロさせるんだよ。」
「君が気づいていないことをみんなで調べるんだよ。」

こんな、ペンギンのような勢いで言っていないけどね。
こうしたトラブルは、ホワイトボードでもフリップチャートでも何でも使って目に見えるようにやるんだよね。で、全員を巻き込む。コトの原因は顧客かもしれないんだから。


ワタシの学び
scrum of scrum
ウォーターフォールの大規模プロジェクトの機能別組織に近い形態だと思った。それと個別アプリケーションのチームとの混成部隊のイメージかな。ただ、その混成部隊より個別アプリケーションのチームの中にも機能別組織のロールを明示的に独立させているところが新鮮と感じた。既視感もあるけれど、ウォーターフォールのプロジェクトだとそこまで明確じゃないことが多いので。


因果関係図
問題を中心にして“悪い結果”を上に、“原因”を下に書く。あまり、いやほとんど使っていないから、今年は意識して使ってみよう。


テストの自働化
やりたいことの一つだけど、これ、環境的にどこまでそろっていないとできないものなんだろう。Webアプリケーションなら出来ないわけないんだろうけれど、じゃあインフラは?と思ってしまうし、そこのヒントが欲しいところ。多分、一部でもいいから自働化モドキでもやってごらん、が解なのだろうけれど。実際、ミドルウェアパッケージではやったし、効果があったし。でも、インフラはどうしたモノか。


構成管理の使い方
構成管理ツールの使い方は、試行錯誤が必要だと思うのは実感していることなんだ。svnだって構成管理ツールだし、そのディレクトリを分けるわけ方だってプロジェクトごとに違うので落ち着くまでに試行錯誤があるもの。


一つ、へぇーって思ったのは、マスタからシステムテストリポジトリに分岐してそれでバグが出たらそのシステムテストリポジトリを修正して修正をマスタに反映するって言う考え方かな。無意識にローカルで試験して、フィックスしたらマスタにアップして、っていうルートを考えてしまうので。