Jenkinsの診断サービス：Jenkins Advisor を試してみたよ
Jenkins Worldの1日目キーノートで発表された、Cloudbeesの新しいサービス「Jenkins Advisor」、せっかくなので試してみました。
これは、Jenkinsの稼働状況を診断して、レポートしてくれるサービスです。
設定はそんなに難しくないです。まあ大体Pluginのページに書いていますが。
- （ないならば）Cloudbees のアカウントを取得
- Pluginをいつもの手順でインストール
- 設定画面で、Cloudbeesのアカウントを入力
これだけで、あとは日次もしくは起動時に勝手にスキャンして、登録されてるメールアドレスに診断結果を送信してくれます。何かあやしいところがあれば、対応方法のリンクも一緒についてくる。動いてる状況も判断するのかな？時々だけ送信される指摘項目もあります。診断項目は、以下の4分類。
- Security
- Stability
- Performance
- Best Practice
減るものでもないし、入れておいて損はなさげな。特に、Stability / Performance などは、書籍や参考サイトだけでなく、実際の稼働状況を見ないと適切な診断を下せないこともあるだろうし、そのときの一つの参考情報として。
Jenkins World 2017 の感想
↑のブログでは伝えたい内容を絞るのと速報性を大事にして、Jenkins World自体の感想を後回しにしたので、こちらから。
主な目的
受賞式に出るというのも一つの目的ではあったのですが、それ以外では主にこの辺。
- 海外のカンファレンス（特にネットワーキングとかブースの）の雰囲気を感じ取る
- 現在の英語力を実感して、気合を入れる
どちらかというと、セッション自体はまあ少し優先度落とし目で。発表内容だけなら国内でも見ようと思えば見れるので、現地に行かないと味わえないことを中心に見てきたかった感じです。あと、僕そもそも国内でも旅行あまり得意じゃないので、観光のことはそれほど・・・
カンファレンス前日（8/29）
着いたら、まずはJenkinsコミッターのアンカンファレンスに顔出し。午前中からあってたみたいですが、僕が到着したのは16時ぐらいだったので、ほぼ終わりかけでした。
終わった後は、川口さんに話しかけると、他のコミッターを紹介するよと言われて、まずは近くにいたDocker社の人？Docker Pipeline Pluginの人？と一対一で話すことに。わーお。何話したっけな。「仕事何やってるの？どんな会社？」って聞かれたので、「ソフトウェアエンジニア時々プロジェクトマネージャー。Cacoo出してる会社で、他にはITSとかチャットとか、大体アトラシアンと似たようなサービスを提供してるよｗ」って答えた気が。で、その流れで、「ITSやチャットって何使ってる？」って聞いたら、「GitHubとかSalesforce、slackとhipchatと、あとはJenkinsコミュニティではIRCだよね、ははは」みたいな感じだった、はず。
で、「バッグとかもらった？もらってないなら持っていっていいよ」って言われて、ボストンバッグと帽子をゲットしてきました！
その後は、Blue Oceanのproduct manager？とGit？SCM APIの誰か？あまり覚えてないけど、その二人が話してるところに。「自分がメンテしてるBacklog Pluginを、GitHubやBitbucketみたいに、Blue Oceanに対応させたいんだけど、どうすればいい？」って聞いたけど、「よく分からないんで、IRCで聞いてみてよ」みたいな回答だった、多分。
で、その後は、Welcome Receptionで、スポンサーブース巡り。ブースの人英語はやーいと感じたけど、こっちがゲストなので何とか説明しようとしてくれる。なので、この機会にガンバった。なぜか、どこかのブースで昔日本の大学の英語教師をやってたって人がいたのですが、その人はさすが慣れてて、僕でも聞き取りやすく言わんとしてることも分かってくれました。
戦利品はこんな感じ。ステッカーは貼らない派なので、最低限だけしかもらってきてません。Tシャツは好きなので、なるだけ回ってきました。あとは、ハンドスピナーとかちょいちょい。
その後は、Autodeskで、国外から来た人とカンファレンススタッフの数名で、International Programに参加。日本からはテクマトリックスさんから2名きてたけど、ここで日本人で固まってもしょうがないので、到着後は基本別々に動いてました。Autodeskのギャラリー内には色々おもしろいものがあったので、それきっかけで "What is this?" "How do we use this?" って話しかけて、そこから "Where are you from?" "How many people do you use Jenkins in your team?" とか、定番の質問にもっていけたので、まだ話しやすかったです。
9時過ぎにあがって、1日目はこんな感じ。
カンファレンス1日目（8/30）
Morning Yoga が早朝6時からあったので、せっかくなので参加。5分前に行ったら先生入れて2名しかいなくて、どうしようかと焦った。結局10名弱来たけど。ホテルの中庭であって、ちょっと小雨も降ってて寒かった。写真は、今回用のヨガマット。
その後は、ちょっと落ち着いた後にbreakfastの時間。さすがというか、いっぱいあった。
で、ようやくキーノート。の前に、何かいっぱい手が込んでるCG映像が出てきた。ひとまず一つだけ。
最初は川口さんのキーノート。内容は、"Jenkins 1.0 ~ Jenkins 2.0 ~ Blue Ocean" に沿ってふりかえって紹介する感じ。
- Jenkins 1.0 : 最初は川口さんのチームで、Hudsonを使い始めるところから。まだこの時代は、特定のエンジニアの情熱ベースでCIを整備するところ。
- Jenkins 2.0 : プラグインを適切な組み合わせを自分で探してインストールする形から、ある程度プリセットされたのを提供する方式へ。複数あったFreeStyle Jobを1つのPipeline にしたり、Jenkinsを再起動しても適切な形でPipelineを再実行できたり。
- Blue Ocean : Blue Oceanのproduct managerから、非エンジニアも分かりやすいようなUI/UXを提供するものとして、Blue Oceanを提供しようとしてるよっていう説明。
その後は、CloudBees CEOのSachaのキーノート。Cloudbeesの提供してる有償のJenkinsサービスや、Accenture やらDockerやらAWSの人が出てきて話した後、CloudBees Jenkins Advisorというフリーの診断ツールがリリースされたよという報告。
あと、途中で多分VSMのこの画像が出てきて、VSMとJenkinsでのPipelineのマッピングみたいなのが紹介されてました。自分の中で二つが結びついてなかったけど、ちょっと考えると関連して考えるべきだよなーと思って、なるほどーと思った感じ。
キーノート終わったあとは、スポンサーブースをまた回ったり、セッション聞いたり。スポンサーブース回ってる途中で、ちょっとしたステージが用意されてるところで各スポンサーによる15分程度のデモが代わる代わる行われてて、それはいい設計だなあと思ってました。デモは多少離れたところからでも見えるように大画面ディスプレイが備えられていて、そのデモで気になればブースに聞きに行こうとなるので。
で、セッションの方ですが、致命的なことにほとんど聞けてません。。。時差ぼけ＆アルコール＆英語などでかなり眠くて、ちょっとセッション出てもすぐ意識が飛ぶ、疲れたのでソファに横になったら1時間以上寝てしまうとかとか。。。2泊しかしないという割りとタイトなスケジュールしか組めなかったのもあったのですが、今度からはもうちょい余裕持たないと、結局参加しても集中できずにもったいないなあという反省です。
ただ、セッションは、全体的にはそこまで国内と大差ないんじゃないかなーと、何となくな印象。サマリーとか、インフラテスト周りのセッションをちょっとだけ聞いて判断してるだけですが、日本でのユーザーカンファレンスの内容でも十分遜色ないんじゃないかなと、勝手な判断。次はぜひ日本からもスピーカー出るといいですね。
後は、2日目の終わりにまたスポンサーブースのところでReceptionという名のネットワーキング。前日とそう大差ない内容だったのと、ライブがあってうるさくて話もしづらかったので、ここではもう早めに切り上げました。こういうのがいいって人もいるだろうけど、話できないほど大音量での音楽はあまり好きじゃないんですよねー。
カンファレンス2日目（8/31）
Jez Humbleによるキーノート。どこかで聞いたことある名前だなと思ったら、"The DevOps ハンドブック"とか"リーンエンタープライズ"とか"継続的デリバリー"の著者ですね。継続的デリバリーしかまだ読んだことないけど、他の二つも読みたいと思ってたところでした。
Jez Humbleからは、Business / Engineering / Operationsという流れがあるフローの中で、Engineeringだけスクラムとかやってアジャイルになっても意味がないよ、周りも含めてアジャイルになっていかないとね、みたいなものを丁寧に説明してくれてました。この辺は、まあDevOpsとかの界隈ではよく言われてることだろうけど、それを改めて説明してくれて、知識のいい整理になった感じ。
よくまとまってたので、キーノート資料が公開されるとすごく助かるんだけど、まだ出てないみたいですね。
その後はお待ちかね、Jenkins World Awardsの授賞式です。streaming でうちの会社の人も何人か見ててくれたみたいですが、自分が初っ端でかなり緊張しました。
壇上降りてパシャリ。
その後は、またセッションとスポンサーブース巡り。セッションは、"Scaling Jenkins with Kubernetes"と"DevOps at Enterprise Scale"というやつを見に行きました。前者は、自分がついたあとはほぼデモで、何やってるか分かりやすかったけど、ちょい手際が悪く感じた。後者は、Hewlett Packard Enterpriseで作ってるALM Octaneというツールの紹介。Jenkinsと連携して動かすことができるのかな。自社ツールの紹介という時点で、ちょっと興味度が落ちました。
ブース巡りでは、Jenkinsのバスと撮るの忘れてたので、このタイミングで取りに行きました。写真待ちしてると、何人かが "Congraturations!"って言ってくれたのは、素直に嬉しかったですね。せっかくなので、"Thank you!"以外にもうちょい話膨らませられるとよかったのですが、力不足で叶わず。。
最後は、再度のInternational Programで、幾つかのテーブルに分かれてLunch食べながらフリートークをするというやつ。テーブルごとに、"Continuous deployment with Docker"とか"The Twelve-Factor Pipeline"とかお題があって、Cloudbeesの人がホスト役として各テーブルに座ってる中、興味があるお題のテーブルに座って話すというやつ。ここでは、"Plugin/upgrade stability"というテーブルに座りました。
で、これが最後の鬼門。数人でのフリートークなんて、英会話初心者にはかなりつらかった。1対1だと相手がまあだいぶ気遣ってくれてゆっくり話してくれたり何度も聞き直してくれたりするんだけど、数人で話されてると全然ついていけん。かつ、お題もちょっと難しかったので、自分が考えたこともうまく伝えられず、かなり凹みました。。。
帰り際には、グッズとして何故かサンダルをもらった。
カンファレンスは夕方まで続いてたのですが、飛行機の時間があったためにここで撤収。そういや、カンファレンス期間中、壁にペイントしていくエリアがあったのですが、帰るときにはだいぶできあがってました。
サンフランシスコの町並み
以前ハワイは行ったことあるのですが、これが初のアメリカ本土上陸でした。
JALを使ったのですが、機内でも有料のWifiサービスがあったので、その場で契約。雲の上から機内食とか撮ってつぶやいてました。一段落したら、チャット見たり先週のアクションのふりかえりしたり。まあいつも通りな感じです。
着いたら、BARTと呼ばれてる電車で、空港からホテルへ。土地勘まったくないけど、日本出国前にレンタルしていたモバイルWifi & Google Mapsの力を借りながら歩いていきます。着いた日は温度も低かったらしく、ちょっと寒いなあと感じた。写真は、BARTから撮った風景。もろボケです。
基本カンファレンスがあるホテルにこもりきり＆カンファレンスに参加してたので、ほとんど出歩く暇もなかったのですが、さすがにそれもあれかなと思って、2日目の夜にちょっとだけ出ました。サンフランシスコ、一歩路地間違うとかなり危険だよみたいな前情報があったので、かなりビクビクしながら。
授賞式のための身だしなみとしてのひげ剃りと、海外出たらその土地のソウルフードを食べたくなるのでラーメンを買い出しにコンビニへ。ラーメンが何か薄い気がしたのは、水入れすぎたかな？箸 or スプーンもらうの忘れてたので、インスタントコーヒーについてたストローらしきもので食べる羽目に。。
帰る日は、結構晴れて少し暖かった。路面電車なるものも走ってましたが、もちろん乗ってません。
空港に戻って、急遽海外に行くと決めて迷惑をかけた家族に対して、お土産購入。子どもには飛行機や電車のおもちゃを買ってきて、妻には一番単価が高いGODIVAの限定チョコレートを。こういうところで、ポイント稼ぎです。
あとは我が家恒例の、家族おそろいのTシャツ。一番下の子どもはイヤだといってきてくれませんでした＞＜
お金的なところは、ほとんどお土産になりました。ご飯はカンファレンスで朝昼晩ともにほとんど出るので、使ったお金は交通費とコンビニで、それでも多分30ドルぐらい。100ドルくらい？をなんやかんやのお土産になったので、お土産をもう少しコンパクトにできれば30ドルで暮らせた感じですね。
目的達成できた？どうだった？
すごくよかった、最高！と手放しで言えるほどではないですが、来てみていろいろ感じるものはあったなと思いました。例えて言えば、ディズニーランド的な非日常な世界を味わった感じ。
ネットワーキングパーティーやキーノートなど、カンファレンスの細部に対するコストのかけ方が違う。自分が携わったJenkinsユーザカンファレンスは基本ボランティアだったのでまあだいぶ違うし、いくつか出た日本の企業主催の大きなカンファレンスともちょっと違う気がする。もう一つ非日常感というか、スケールが違う感じ。一度こういうイベントのスタッフに携わってみたい。大変そうだけど。あと、いいなあと思ったのは、聴覚障害者のために手話で解説する人が準備されてた。
英語については、まあそうだよねというか案の定というか。カンファレンスに参加すると決めたのがお盆前ぐらいで、そっから焼け石に水程度かもとは思ったけどDMM英会話を始めたんですよね。で渡米前に10回以上レッスンやって、英語を話すことの抵抗感はだいぶ薄れてはいました。が、まあ実際カンファレンスで人と話すと、全然ついていけないですね。英会話の先生は拙い英語を聞くのもこっちに合わせてゆっくり話すことも慣れてるけど、まあ普通の人はね。
どこまでを目標とするかにもよりますが、英語はやっぱもうちょいやらんとよねと。せめて、こういう場でちゃんとコミュニケーションできるぐらいは。今後英語圏の人や文化と関わること多いだろう＆多くしていかないとだろうし。
カンファレンス自体については、Blue Ocean推しだなというのと、DevOps系のセッションがすごく多かったなという印象。自作プラグインをBlue Ocean対応させるのもやっておかんと、本体のトレンドについて行けなくなりそうだなーけどちょい大変そうだなー、という感じ。
こちらからは以上です。この勢いのまま、また勉強会とかユーザーカンファレンスもやりたいですね。他にも声があがるとより一層やるぞという決意が固まるので、やりたいーという人がいたらぜひぜひ声をあげてもらえると。
Jenkins World 2017 で日本のJenkinsコミュニティの代表として Most Valuable Advocate 賞をいただきました！
初めての海外カンファレンスとしてJenkins World 2017に参加し、何とそこで日本のJenkinsコミュニティの代表としてMost Valuable Advocateなる賞をいただきました！
Most Valuable Advocate
https://www.cloudbees.com/jenkinsworld/awards
This award is presented to an individual who has helped advocate for Jenkins through organization of their local Jenkins Area Meetup.
Your Contribution:
ikikko-san leads the Jenkins User Group in Tokyo, which is one of the largest and the most active with a long history. The group has been organizing meet-ups for more than 10 times now, and every meet-up fills up to 100% very qucikly with regular turn-out of 100-200 people. At one point the group under his leadership organized a fully volunter-run "Jenkins User Conference" in Tokyo that commanded 1000+ attendees.
Jenkins World自体については、また別途紹介させてもらうとして、ここでは取り急ぎ報告とお礼を。
( 2017/09/04 Jenkins Worldの感想を別エントリに書きました )
ikikko.hatenablog.com
今回の賞では、二度のJenkinsユーザカンファレンスを始めとして、日本のJenkinsユーザ会を取りまとめていた功績を評価してもらいました。もちろん、これは僕の力だけではなく、他のスタッフやユーザの方など、日本のJenkinsに関わる全ての方々の功績だと考えています。
思い返せば今から7年前の2010年10月。CIという概念やJenkins（当時はHudson）が徐々に知られるようになってきた状況での「日本でHudsonの勉強会をやりたいなと思うのですが」というメーリングリストへのポスト、ここから始まったのでした。
「1ダースもくれば大成功なんじゃないでしょうか」という川口さんの言葉とは裏腹に、蓋をあければ200人以上の参加！この会をきっかけに、僕も含めた日本のJenkins界隈がさらに加速したのではと、今思い返してみると感慨深いものがあります。
これからも、みんなの力でJenkinsやCI界隈を盛り上げていきましょう！みなさん、ありがとうございました！！
「ファシリテーション・グラフィック」を読みました
ミーティングの内容が同じところを堂々巡りしてたり、結局何を話してたんだっけってなったりで、なんとなーく空中戦が多いなと感じてたので。空中戦を避けて、議論を見える化するための引き出しの一つとして読んでみました。
ファシリテーション・グラフィック―議論を「見える化」する技法 (ファシリテーション・スキルズ)
- 作者: 堀公俊,加藤彰
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2006/09/01
- メディア: 単行本
- 購入: 22人 クリック: 124回
- この商品を含むブログ (117件) を見る
うちは拠点が分散してるのもあって、ホワイトボードを使うことは少なく、代わりにデジタルなツールを使うことが多いです。その辺は、下記のスライドでも紹介してました。距離が分散してる場所でも使えることや、ある程度定形のフォーマットがあるミーティング（例えば、ふりかえりのKPTなど）、きれいに整形して記録として残しておきたい・コピペ的な流用が多い場合は、デジタルツールはやはり便利ですね。
ただ、やっぱデジタルだと使うのに一手間かかることも多く、柔軟性がない。具体的には、フリーハンドでグリグリ書いたり何かと関連づけたりが、どうしても1テンポ遅れて、なんか思考に直結しないというのを感じてました*1。で、結局ツールを使うのにもたもたしてる間に、口頭で話進んでいって、しばらくすると空中戦になったりーの。
その辺を打開すべく、お世話になってる関西弁のコーチがよくホワイトボード使ってるのを見て、自分もやってみようと思ったのがきっかけ。まだまだ試行錯誤してる段階ですが、最近ではビデオ会議システムでホワイトボードを映して、僕がホワイトボードに話しながら書くのを別拠点の人に配信するというやり方もちょいちょいやってます。結局参加してるみんながホワイトボードに書くわけではないことが多いので、このやり方でも結構うまくいきますね。
第1章 基礎編 議論を書けば話し合いが変わる
発言の中の言葉を活かす
よくある失敗は、体言止めを使って一般的な用語に置き換えてしまうケースです。たとえば「そもそも、この商品が持っている機能が、狙っていた顧客層になっていないのではないでしょうか？」という発言を「商品コンセプトの問題」と要約してしまうのです。
...
なるべくメンバーが使った言葉をそのまま使い、キーワードをうまくつなげて要約文をつくりましょう（例：機能がユーザーに合っていない？）
あ、これ前までよくやりがちでした。きれいにまとめようとして、いい感じの言葉に置き換えようとしてしまうんですよね。けど、この箇所を読んでから、ちゃんと発言そのまま活かして、疑問形ならば「？」をつけることで表すようになりました。
Column-3 準備してきたものを手放す勇気を持とう
ファシリテーターともなれば、前もって議論の展開を考え、使えそうなツールを思い描いて場に臨むのは当たり前の話です。だからといって、それを会議が始まるなり押し付けるのは、あまり関心しません。
...
事前の準備は大切ですが、用意してきたものを使うかどうかは、場の状況を見て決めるものです。人はどうしても準備してきたものを使いたくなりますが、それを潔く手放す勇気を持ってください。
これも、最初のほうは自信のなさからよくやってた気がします。が、今はある程度経験を積んだのをふまえて、頭の中に思い描いた道筋はあるものの、まずは相手の疑問や話したいことを話してもらうというのをやれるようになってきました。相手が特に話したいことがなかったり、自分が思い描いたものと同じ方向性ならば、準備どおりに進められるし、別の方向にいったのであればそれはそれで有意義な方向なのでそれを尊重しつつ議論を進めるように（頭の中はかなりフル回転してますが）。
第2章 技術編 ファシリテーション・グラフィック上達の6つのポイント
この章はテクニック的な話。いくつかあるのですが、知っておくだけで簡単に活かせるのは、この辺かな。
見やすい字を確認は、ゴシック体を意識して書くのがコツです。四角のマスに字を埋めていくつもりで書いていくのです。大半の人は四角ばった文字を書くと安定した感じになります。
...
ペンの太いほう（太字角芯）を使って字を書くようにしてください。
...
基本は「横線を細く、縦線を太く」です。そうすると、安定した文字に見えます。そのためにはペンを図2ｰ17のように持ち、ペン先の角をうまく使って横線／縦線を描くようにしてください。字の上手下手ではなく、書き方のちょっとした気配りで、とても読みやすくなるのです。
図がないので、ここだけ読んでもいまいちぴんと来ないでしょうが、ともかく「両方とも細い部分で書かないように」「横線描くときは細く、縦線描くときに太く」なるようにペンを握ります。実際にやってみたイメージは↓な感じ（左が意識した方で、右が今までの書き方）。学生の頃から、自分で書いたノートが汚くて読めない自分が、これ意識するだけで「字が見やすい」と言われるようになっちゃいましたｗ
あとは、色の使い分けの指針とかも。感覚では何となく分かっていたものの、こうやって明記されると判断しやすいです。
- <黒> 大半の文章や図解を描く
- <赤> 重要なタイトルを枠で囲む、重要なキーワードに下線を引く、特に注意を引きたい文を描く
- <青> 少し目立たせたい文を書く、囲み図形を描く
- <緑> 補足事項を書く、囲み図形を描く
他には、箇条書きや囲み・矢印・つなぎ方など、単調になりがちなところをいくつか例示してるところが参考になりました。一度素振りしてたけど、もうちょっと定着させてぱぱっと出せるようになるために、また素振りしとこうかな。
第4章 研究編 ファシリテーターの頭の中を解剖する!?
説明しづらいけど、この章はかなり参考になる。最終的にできあがったホワイトボードや模造紙だけでなく、議論の流れと一緒に描いてる途中経過も説明しながらどういう流れでできあがったかを、幾つかのサンプル事例を見せてくれる章。
パーキングロット
色々参考にはなったのですが、やっぱりというか「パーキングロット」の技は使えるなという印象。
あまり今の議論に関係なさそうなやつを隅の方に一応書き留めておくやつですが、こうやっておくと本来議論したいところに戻ってきやすいってのは、結構経験しています。それでいて、発言者もまったく流されたわけじゃないという受け止めができるので、結構オススメ。
ゴールの明示
ゴールがどこまでか設定してなくて、結局終了時間になっても何も決まってない、ってのをよくやりがち。予めゴールは考えておいて、それを明示しておきつつ共通認識を合わせるっての大事。
逆に、ゴールをちゃんと決めておけば、時間がこなくてももうさくっと終われる。これ、精神衛生上にもいいんですよね。もちろん、時間をムダにしないっていう点でも。
ファシリテーターって誰でもできる？
で、この章見ながら感じたのですが、ファシリテーションはある程度スキルがいりそう。聴きながら、描いていく。分かりやすくするためには多少なりとも描き方にコツがいるし、シミュレーションなど事前準備も結構大事。これを、メンバーでやるのっていけるんだろうか？まあ最初はやっておいて、やり方見せていけばだんだんできるものなのかな？
まあ、0か1か、いつもファシリテーターがいる or いらないというものではないですね。ある程度込み入ったミーティングになりそうな場合は、別途慣れた人がファシリテーターとして入って（今の状況だと多分自分）、そうじゃない定例的なものは他の人でもできるようにしていくのが健全そう。
ある程度想定の上で読んだのですが、今の自分にとってはテクニック寄りな内容が多かったです。テクニック系は、状況にはまれば即効性は高いので、使い所を間違わないように活用していきたいですね。
実際に、この本の内容を実践した後、「ホワイトボードの字がきれいですね」って言われたことがありました。自分が取ったノートすら、字が汚くて後から読めないこの僕がですよ。それだけでも、効果のほどは分かるんじゃないかと。
「アジャイルコーチング」を読みました
原著を読もうと思ってたら、ちょうど翻訳版が出るという噂を聞いて、心待ちにしてたのでした。ちょうど一年ぐらい前からこういうチーム・組織を支援するロールもいいなと思ってて、けど何と言えばいいか分からなかった*1ところを、「アジャイルコーチ」という呼び方があるというのを知ったところだったので。
- 作者: Rachel Davies,Liz Sedley,永瀬美穂,角征典
- 出版社/メーカー: オーム社
- 発売日: 2017/01/21
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
第1章 旅を始める
「エクササイズ：コーチングを始める前の質問」は、いい問いかけ。こういうの、頭から抜けがちですが、大事なところですしね。というわけで、いくつか問いをピックアップして、問に対する答えを言語化してみました。
- 動機：自分はどのような変化をもたらしたいのか？
- 十分にスキルを持った個々のメンバーに対して、1+1=2 以上になるようなチームにしたい
- スキル：自分は何を提供すべきか
- （他チーム・他社のベストプラクティスを含め）メンバーだけでは気づきづらいことに対して、外部からの第3者視点を提供する
- 責任：仕事の進捗をどうやってレビューすればいいか
- 以前よりチームとして成果を出せていること
- （のためには、成果って何？とか以前/今の状態をちゃんとトラッキングしておく必要があるんだよね・・・）
- 支援：周りからどのような支援が受けられるか
- 金銭面・権限含め、ある程度自由に物事を導入でき、任せてもらえる
第2章 みんなと一緒に働く
「2.4 合意を形成する」で紹介されてた、「合意の段階」。「賛成」or「反対」の2値ではなく、「全面的に賛成」〜「どちらとも言えない」〜「絶対に反対」という段階で表す。↓の資料で紹介されてた「5 fingers」みたいなものかな。
ちょうど見積もり時のプランニングポーカーみたいなもので、意思決定が必要な場面で、最初の方でこれやっておくと話が早くなりそうと感じました。お互い大体同じ結論に達してるのに、枝葉の差異にこだわりすぎて議論して時間をムダにしちゃうとかを、これで防げそう。あと、中庸の意見はひとまず置いておいて、極値の意見同士で話し合うとか。
権限を委譲したい/してほしいときに便利なデリゲーションポーカー - Qiitaもそうですが、all or nothing で考えるのではなく、段階があることを踏まえて適切に対応していく必要がありそうだなと感じてます。
第3章 学習を促す
質問してはいけないとき
助言をしたいときには、質問をしないように気をつけましょう。質問をすれば、同意できない答えでも受け入れなければなりません。（略）たとえば「このバグをもっと早く見つけるにはどうしたらいい？」と質問して、「もっと手動テストをやる」が答えだった場合、自動テストの方向に進めることは難しくなります。
あー、これ時々やりがち。上記の例で「いや、自動テストやろうよ」みたいにあからさまにもっていくことはさすがにないですが、自分が望む方向の答えだった場合、待ってましたとばかりに色々話しちゃうことがたまーに。。。
とは言え、望まない答えは避けたいからといって、全部一から教えてるとそれはそれでよくない。なので、最初は質問して答えを自分なりに考えてもらう、その後その答えはちゃんと受け止めつつ、こういう選択肢・方法もあるよと提供する感じかな。
ここまでが、コーチングの話。アジャイルコーチに限らず全般的な話でした。この辺は、以前読んだコーチングの本に通じるところがあって、いい復習になりました。
第5章 デイリースタンドアップ
「5.4 時間を設定する」について。この話で、結構いい感じにチームをコーチングできたなあと思うのを思い出しました。
ユーザからの問い合わせを主に担当するチームがあるのですが、このチームに対しては朝に行うのではなく午後一に行うようにしました。問い合わせ対応は、短い時間で多くの件数を処理するため、朝のタイミングではその日一日のことを計画しきれないという声があがったためです。
朝ではなく昼にやることによって、下記のような効果を期待してました。実際に、いい感じに回ってるように見えてます。
第6章 何を作るかを理解する
ユーザストーリーの作り方や、ストーリーテスト（受け入れ基準）の話。ストーリーテストのテンプレートとして、 Given-When-Then（前提 - もし - ならば ） という形が紹介されていました。ってこれ、BDDで見たパターンだ。
以前まで、BDDとTDDの区別があまり分かってなかったのですが、ストーリーテストという文脈で見て、少し分かってきました。ストーリーテストだと、Given（前提）とWhen（もし）の区別が重要になってきそうですね。Whenというほんとにテストしたい条件と、テストする前段階のGivenを明確にすることによって、何をテストするのかをはっきりさせることができそう。
いいテンプレートだなーと思って、さっそくチームに紹介・導入しました。
第7章 前もって計画する
午前中にユーザーストーリーを提示して、午後に見積もりをしているチームもあります。このやり方であれば、開発者で何をすべきか話し合う前に、コードを見ることができます。
このやり方、よさげ。機会あれば提案してみようかしら。
あと、直前のコラム、これどういう意味だろう。ちょっとよく分からなかった。誰かと話してみるか。もしくは分かりそうな人、コメントもらえるとありがたいなー。
書記はやらないように
ミーティングの記録係を引き受けないようにしましょう。チームを支えるためにできることだからと、ついついやっちゃうのよね。でもこれをやってしまうと、他のみんながミーティングに参加するのを妨げてしまうことになるの。そればかりか、ミーティングはチームのためのものではなくて、あなたの利益のためにやっているのだと思われかねないわ。チーム全体を巻き込むようにしてね。
(2017/05/08 追記 翻訳者の @kdmsnr さんから、書記についてのコメントもらいました)
@ikikko 書記のところは、コーチやスクラムマスターみたいな人がホワイトボードのペンを持ってしまう、みたいなことです。その人が場をしきる感じになってしまい、チームのための会議という感覚が薄まってしまうので、できれば避けたいところです。
— 角征典／新刊『アジャイルコーチング』 (@kdmsnr) 2017年5月8日
第8章 見える化する
この章、目下の課題。
うちは拠点が離れてることもあって、物理的な形での見える化はしづらく、その結果効果的な見える化がしきれてないんですよね。もちろん、距離を補うために色々やってて、そのための自社サービスを開発して自分たちの業務に組み込んでいたり、リモートワークを支えるツールなりを導入してはいますが、やっぱりリアル対面にはまだまだ及ばない。
まずはタスクボードから取り掛かるとして、そっからは以前読んだ「アジャイルコーチの道具箱」をもう一回見直してみようかな。何かインスピレーション湧いてくるかもしれない。
第13章 ふりかえりで変化を推進する
ふりかえりやカイゼンなど、自分の中でうまく説明できない状況だったので、この章読みながら、雑にメモ書きした。
スーパー雑に、ふりかえり・カイゼンとやる必要があること（タスク）や、大きな目標について、自分の今の理解を書いてた pic.twitter.com/4cPETpKns7
— ikikko (@ikikko) 2017年5月4日
第14章 あなたの成長
この章、いいよねー。今まではチームのためにアジャイルコーチができることについて書かれてたのですが、ここはコーチとして成長していくためにどういうのが必要かについて書かれてる。あまりこういう視点で書かれた本ない気がするので、すごくいい。
例えば、最初の書き出しからこれですよ。結構慎重派なのであまりドラスティックな変化は好まない傾向があったのですが、こういうところは意識しようと思いました。
コーチは絶えず変化をリードします。つまり、自分自身を変えることに抵抗感を持たないことが重要です。
あと、最後の方のこのコラム。長いけど全文引用します。うまくできないことも多々あるし、やればやるほど自分のできなさや先人たちの偉大さが分かって心が落ち込むときもありましたが、このコラム読んで心が少し楽になりました。
自分に優しく
あるカンファレンスで、私は尊敬している人に愚痴っていたの。仕事であんなミスをしただの、こんなミスをしただの、チームのコーチをするのはどんなに難しいかだの。すると彼女は、ただ私を見て、こう言ったの。
「あなたは他の人はミスをしないと思ってるの？」
「いえ、違うわ。誰だってミスをすると思う」
「それじゃあ、どうしてそんなに自分に厳しくするの？」
「それは・・・」
それに続く理由は山のように浮かんだわ。
（うまくやらなくてはいけないから。）
（明らかなミスをするのは恥ずかしいことだから。）
（もっとうまくやりたいから。）
そしたら、彼女はこう言ったわ。
「自分に優しくなりなさい」
その言葉は心に刺さったの。私は自分に厳しかったのよ。みんなと同じね。自分はミスをしてはいけない、もっとうまくやらなくてはいけない、常に有能でなくてはいけない、そう思っていたの。自分に優しくしたっていいじゃない。息子がミスをしたら、抱きしめてこう言っているのに。
「大丈夫よ。次はもっとうまくやれるわ」
どうしてその言葉を自分に言えないのかしら？
途中でもいくつか引き合いに出したけど、この1年で読んできた本がだんだん結びついてきました。感想ブログまでじっくり書く方針なので、一つ一つ読むのは遅くなるけど、こうやって後から引き合いに出したりふりかえったりもできるので、自分にはこのやり方結構合ってます。
ちなみに、この本とは直接は関係ないけど、ちょうどどっかから流れてきた資料がすごくよかったです。アジャイルコーチを頼む方に視点を当てた内容ですが、コーチ自身のあり方とか価値の出し方とか、すごく参考になりました。"An Anonymous Agile Coach"ってあるけど、誰なんだろう・・・
「リーン開発の本質」を読みました
何か発想の転換になりそうなので、「リーンソフトウェア開発」はちゃんと突き詰めていきたいところ。というわけで、次はこれを読んでみました。
- 作者: メアリー・ポッペンディーク,トム・ポッペンディーク,高嶋優子,天野勝,平鍋健児
- 出版社/メーカー: 日経BP社
- 発売日: 2008/02/07
- メディア: 単行本
- 購入: 6人 クリック: 141回
- この商品を含むブログ (67件) を見る
そもそもなのですが、リーンソフトウェア開発が全体の中でどういう位置づけかが曖昧だったので、そこから。「リーン」と「アジャイル」の関係とは？：書籍でたどる「リーン」の本質 (3/4) - ＠ITの以下の画像が、分かりやすかったです。
第2章 原則
検証時の欠陥発見は、当然ではなく、例外であるべきだ。検証がいつも「テストをしては修正する」というサイクルを生むようなら、それは、開発プロセス自体に欠陥があるということである。
欠陥は早め早めに（理想的には作るそばから自動的に）発見・対処できるように、プロセスを作り込んでいくべきだってことですね。思い当たるふしがあったので、今後の参考に。
第3章 価値
トヨタでは、チーフエンジニアがその車種のビジネス上の成功責任を持つ。
（中略）
チーフエンジニアを立てるという手法には、多くの情報を、責任ある一個人の頭の中で統合できるというメリットがある。
「チーフエンジニア」について。以前は、どちらかというとこういうリーダー的なのは不要ではと考えてました。チームメンバーがチームが達成すべきことなどを適切に把握してたら、リーダーはいなくとも進むだろうと。ただ、この本で説明されてた下記の理由を読んで、やっぱりリーダー的な役割はあったほうがいいかなとも思ってきました。
- 結果責任・説明責任を明確にできる
- 一個人の頭の中で、多くの情報を統合できる
あと、知らずに何となく感じてたことですが。チーフエンジニアって、スクラムで言うところのプロダクトオーナーみたいな役割に似てるなーと思ってたら、やっぱり関連があったとのことです（参考：株式会社戦略スタッフサービス）。なるほどー。
第4章 ムダ
複雑さを自動化するな
複雑なプロセスや、乱雑なプロセスをただ単に自動化したところで、顧客の役には立たない。ソフトウェアのもつ複雑さというがちがちのよろいで、ムダだらけのプロセスをつつむようなものである。
う、頭が・・・＞＜ CIやビルド周りに興味があるくらいなので、自動化は好きなのですが、これはそうだよねー。
続いては、ムダの話。これは有名な話ですよね、多分。リーン生産とリーンソフトウェア開発の対応表はこちら。
| 製造 | ソフトウェア開発 |
|---|---|
| 在庫のムダ | 未完成の作業のムダ |
| 作りすぎのムダ | 余分な機能のムダ |
| 加工そのもののムダ | 再学習のムダ |
| 運搬のムダ | 引き継ぎのムダ |
| 動作のムダ | タスク切り替えのムダ |
| 手待ちのムダ | 遅れのムダ |
| 不良を作るムダ | 欠陥の無駄 |
いくつか、対応付けがいまいち分かってないところもあります。「加工そのもののムダ」に相当するものが「再学習のムダ」だったり。ただ、「作りすぎのムダ」＝「余分な機能のムダ」が一番タチが悪く他のムダを引き起こすことがあるというのと、（対応付けは分かってなくとも）ソフトウェア開発のムダに紹介されてるもの自体はその通りなので、ひとまずはそれらのムダを意識して見つけることができるようにというところからかな。あとは、カンバンにも表れてるけど、「在庫のムダ」＝「未完成の作業のムダ」らへん。
あと、バリューストリームマップ。これは、カイゼンの基本 | Ryuzee.com (on Azure)で紹介されてたこの本を読んで、別途やってみようと思ってます。
トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!
- 作者: マイクローザー,ジョンシュック,Mike Rother,John Shook,成沢俊子
- 出版社/メーカー: 日刊工業新聞社
- 発売日: 2001/08
- メディア: 単行本
- 購入: 1人 クリック: 8回
- この商品を含むブログ (5件) を見る
第5章 スピード
要望やタスクを管理する「待ち行列」について。
- 待ち行列は短くなくてはならない。おそらく、作業の2サイクル分あたりが適当だろう。その程度の長さであれば、開発プロセスの間中、要求の平均サイクルタイムを管理できる。
- マネジャーは、待ち行列にある項目をいつでも改定したり、変更したりできる。しかし、いったんチームがある項目に着手したら、マネジャーが日々の開発作業に干渉してはならない。
- チームは、待ち行列から作業をプルし、その作業が完了するまで、一定のリズムで作業を行う。プルシステムによって、作業を許容範囲に収めながら、常にチームに仕事を与えていられるのだ。
- 待ち行列がありさえすればチームに対応する時間がなくても、そのうち要求に対応してもらえる、という誤解を与えてはならない。
特に、1, 2が気になりました。1 は、無限待ち行列になってるのをよく見かけますよね。。。意識して制限しないとそうなりがちなのですが、無制限だと全体が見えづらく改善ポイントが分かりづらいとか、待ち行列を見るだけでいやになるとか、あとはリズムが出ないとかも結構大きいことかも。2 は、仕掛り始めたものをやっぱりやめたってなると、これまたリズム出ないしなかなか終わらない=価値の提供が遅れますしね。
とここまで書いてきて、これ見たことある、カンバンの原則だー！って気づきました。カンバンはリーンの考えから影響受けてるっていってましたしね。自分の読書感想ブログも含めて、本も改めて見直しておこう。
第7章 知識
この章では、「顧客要求にもっと応えたい」というチームにおける例をふまえて、科学的方法の進め方が説明されています。科学的方法とは、こんな感じ。
- 問題を定義する
- 状況を分析する
- 仮説を立てる
- 実験を行う
- 結果を検証する
- フォローアップする / 標準化する
この中で、3 の「仮説を立てる」が「科学的方法の要でありながら、問題解決を急ぐチームが見落としてしまいがち」とされています。これ、すごい分かる。ちゃんと意識しておかないとだめですね。
ここの例、すごく参考になるので、多分今後何度も見直すんだろうなあ。
第9章 パートナー
オープンソースでのセキュリティフィックスをグローバルにまたがった複数のチームで対応した話と、トヨタ傘下のサプライヤの工場が火事になったときに別のサプライヤが協力して大本の発注を無事に納品した話。その中で、何がキーポイントだったのかというのが、↓な感じで説明されています。
よく、どうすれば世界規模のチームでのコミュニケーションを改善できるか、という質問を受ける。しかし、たいていの場合、根本的な問題はコミュニケーションではなく、約束を取り交わしたチームの不在なのだ。
なるほどね。約束を取り交わすことが第一で、その約束を果たすために必要ならばコミュニケーションの話になる、とのこと。多分その約束も、お互いがちゃんとやるべきことを把握できるレベルでの約束が大事な気がする。何となくとか、いい感じでお願いね♪みたいな曖昧なものだと、多分正しく機能しないんだろうな。
あと、コラムにあった「グローバルな作業グループから、グローバルなチームへ」っていうTIPSも、すごく参考になる。目次と簡単に一言で説明。
- 頻繁な統合：コードベースでの統合とか
- 人の交換：一方のチームメンバーを、もう一方のチームに送って一緒の時間を過ごす
- テストを交換する：要求を引き渡す際、実行可能なテストでやり取りする
- 窓口（Proxy）：窓口となって、毎日コミュニケーション
- 動き回るチームリーダー：各地のチームを、チームリーダーが動き回る
- 差別の撤廃：言語や立場などの違いは、真のチームワークに欠かせない尊敬や信頼や約束を簡単に破壊する
第10章 旅立ち
どこからリーンソフトウェア開発を始めるかについて。「訓練」「思考」「計測」とありますが、計測が特に気になりました。
「開発作業が終了してからしばらくたたないと、効果的な計測は難しい -> たくさんの部分最適から着手してしまう」という流れが紹介されてましたが、これだと全体最適を阻害する可能性もあるのでだめだとのこと。代わりに、計測対象を減らして、（サブシステムではなく）システムレベルでの計測点を見つけるのがいいよと。具体的には、この辺。
- サイクルタイム
- 財務上の成果
- 顧客満足度
サイクルタイムは、コンセプトがキャッシュになるまで。これを見るだけで、あらゆるムダが露呈するので、リーン手法の一番基本的な計測対象となる。
財務上の成果は、まあそのまま。開発（やもろもろの作業）がどう財務・ビジネスに紐づくか、当然意識して計測できるようにしておくべきだとは思ってるのですが、現実なかなか難しいなあと。ビジネスレベルまでいくと、開発者の作業以外の要素も絡んできそうなので。もちろん、最終的にはここに行き着くべきだけど、一歩目はもうちょいやりやすいところからかなーと。
顧客満足度は、こういう簡単な指標で出せるみたい。
「あなたの製品を、どれだけ薦められますか？」そして、顧客に0（薦めない）から10（絶対に薦める）までの点数をつけてもらう。その回答を、9~10点は「推奨者」、0~6点は「批判者」7~8点は「中立者」としてグループ分けする。
...
推奨者の正味比率を算出するには、推奨者の割合（パーセント）から批判者の割合を引く。すると、マイナス100パーセントから、プラス100パーセントまでの数字が出る。平均的な企業なら、点数は10パーセント」前後である。本当に優秀な企業であれば、50パーセントからそれ以上の点数が出る。マイナスになったら、深刻な問題につながると思った方がよい。
簡単なのはいいけど、実際にこのデータが手元にあった場合、どう活かせばいいのかはちょっとイメージできていない。傾向を継続的に見ていって、傾向が変わったタイミングで何かを検知するとか。もしくは、何かアクション起こす前に傾向がどう変わりそうかを仮説立てておいて、アクション後にその仮説を検証するとかかなあ。
一度通して読んだ後、この読書感想ブログを書くために再度読み直したのですが、この辺がいいなと感じたのかなと改めて。忘れがちなので、適宜また戻ってこようと思います。
- スクラムなどの開発チーム・プロジェクトにフォーカスするだけでなく、（バリューストリーム（マップ）をはじめとして）より上位の全体システムを見据えた最適化をはかれそう
- うっかりするとバッチサイズを大きくして一度に効率よく作業しようとなるところを、逆にバッチサイズを小さくしてサイクルタイムをよくすることを心がける
それにしても、いつにもまして長い・・・
「アジャイルサムライ」を読みました
これも定番中の定番ですが、特にプロジェクトキックオフ時の取り組みに関してインセプションデッキを追求したくて、読もうと思いました。
- 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未
- 出版社/メーカー: オーム社
- 発売日: 2011/07/16
- メディア: 単行本（ソフトカバー）
- 購入: 42人 クリック: 1,991回
- この商品を含むブログ (255件) を見る
第3章 みんなをバスに乗せる
はい、インセプションデッキの章です。
今までも、プロジェクトの概要や目的を明文化するような取り組みとして、"インターナルプレスリリース"という取り組みを社内でやってきていました。これは、Amazon流の開発術では、まずプレスリリースを作る | fladdictに習って、先にプレスリリースを書いてみるというものです。ただ、インセプションデッキを試した後に気づいたことは、「インターナルプレスリリース作成前に、プロジェクトメンバーみんなで認識を合わせる場があったら、もっとよりよくできたのかもしれない」ということです。
インターナルプレスリリース
インターナルプレスリリースは、以下の流れで作成していました。
- ある一人が、プロジェクトの概要をプレスリリースとして明文化する作業を行う
- 明文化したものを、プロジェクト内外に共有する
- フィードバックを受けて、ブラッシュアップする
インターナルプレスリリースの目的の一つに、「プロジェクト外の人に、プロジェクトの概要を周知するため」がありました。これは、会社が大きくなっていくにつれて、他のプロジェクトが何をやっているのかが分かりづらくなってきたという課題を解決するものです。インターナルプレスリリースによって、実際にプロジェクト外の人が該当のプロジェクトの概要を分かるようになりました。
ただ、インターナルプレスリリースを続けていくに従って、以下の点が問題点・改善できそうな点としてあがってきました。
- プロジェクトの概要を明文化するのは思いのほか難しく、一人で考えていると煮詰まってしまう
- プロジェクトメンバーでさえも、プレスリリースを眺めても深く入ってこない
上記の課題に、インセプションデッキ作成はぴったりはまりました*1。プレスリリースとして明文化する作業の前にインセプションデッキ作成を行っておくと、「プロジェクトメンバーが、プロジェクトの概要や目的をより深く認識・共有する」ことができるようになります。その前提だと、デッキを作成するときに話した内容を元にインターナルプレスリリースを作成することができます。これによって、プレスリリース作成者が煮詰まることが少なく、多少煮詰まっても他メンバーと相談していくことができます*2。
テンプレート化 on Cacoo
インセプションデッキを実際に作ってみると想像以上によかったのですが、ちょっとだけ手間がかかるところがありました。当初、本書のサポートサイトで配布されているテンプレートを使ってたのですが、更新が入るたびに毎度更新して、ファイルサーバ上に置きつつチャットにキャプチャ貼って・・・みたいなことをやってたんですよね。
で、こういう手間を無くすために、うちらはCacooというサービスを作っていたのでした。というわけで、インセプションデッキもCacoo化して、合わせて社内の他のプロジェクトでも手軽に利用できるようにテンプレート化。
多分このままだと、見ることはできても社外の人はコピーして流用するのはできなさげですが、欲しい人がいたらコメントか何かもらえると。コピーできるように、もうちょい設定します*3。
第4章 全体像を捉える / 第5章 具現化させる
インセプションデッキの中でも、うちらの中では以下の2つが重要だなと実感しています。
- 我々はなぜここにいるのか？
- エレベーターピッチ
「なぜ」これを作るのかという問いだと思いますが、エンジニア目線だとどうしてもこの辺が疎かになってしまうことがあります。結果として、何の役に立つのか・誰に向けた機能なのかがゆるふわになったり、当初のスコープより想定以上に膨らんだりしちゃいます。「なぜ」をプロジェクト初期にちゃんと考え抜いて、何かあったときにまたこの場所に戻って来れるようにしておくことは、当たり前といえば当たり前ですが大事なことですよね。
あとは、「パッケージデザイン」が上記のインターナルプレスリリースのたたき台に使えるんじゃないかとか、「やらないことリスト」「トレードオフスライダー」でプロジェクトで重要視するものを考えるきっかけになるよねとか、感じています。
そうそう、「期間を見極める」のところで出てきた、「プロジェクトの期間は6ヶ月以内が望ましい」ってのはまさにその通り。長いと、どうしても曖昧になってしまって、あれもこれもと夢を詰め込みがちになりますしね。
第6章 ユーザーストーリーを集める
ユーザーストーリーの洗い出しについていつも悩むんだけど、よさげなやり方が紹介されてました。フローチャートを書いてそこからストーリーを抽出していく方法と、画面モックからストーリーを抽出する方法。両方よさげ。
あと、あまり詳細に立ち入りすぎないようにってアドバイスもよかった。これもそのまま引用。
ストーリー収集ワークショップでは、1日かけて開催した場合で、ざっくりとしたストーリーを10~40ぐらい書き出せれば十分だろう。これぐらいあれば、向こう3ヶ月から6ヶ月ぐらいの計画を立てられる。書き出したストーリーが数百もあるのだとしたら、それは半年以上先の遠くまで計画を立てようとしているか、詳細に立ち入りすぎているかのどちらかだ。今の時点で優先すべきは幅だ（孵化さじゃない）。深みにはまって身動きが取れなくなっちゃいけない。
第8章 アジャイルな計画づくり：現実と向きあう
バーンダウンチャートではなくバーンアップチャートにして、かつスコープの広がりを表すもの。「アジャイルな見積もりと計画づくり」を読みました - @ikikko のはてなブログにも、バーンダウン棒グラフだったっけな？スコープも表現するようなものはあったけど、こっちのほうがシンプルでよさそう。今のプロジェクトに提案してみようかな。
最初の一歩の人に進めるときにいい一冊。アジャイル全般ならこの本で、もうちょいスクラムに絞った本ならばSCRUM BOOT CAMP THE BOOK、カンバンならばカンバン仕事術かな。本のWIPは1冊＆読書感想ブログを書くのを自分ルールに決めてるのであまり色々な本を読めておらず、もっと適切な本もあるかもですが。
- 作者: 西村直人,永瀬美穂,吉羽龍太郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/02/13
- メディア: 単行本（ソフトカバー）
- 購入: 5人 クリック: 13回
- この商品を含むブログ (33件) を見る
