Rのつく財団入り口

ITエンジニア関連の様々な話題を書いているはずのブログです。

【感想】『カイゼン・ジャーニー』がエモくて刺さった話

越境しちゃう?

 2018年2月に出版、ネットでかなり話題になったのでエンジニア界隈の方だともう読んだ方も多いのではないでしょうか。出版に関連してカンファレンスのようなイベントや勉強会もいろいろ開催されてきましたね。
 内容としてはアジャイル開発のひとつの手法であるスクラムを包括的に解説した本であり、内容も2010年代の現在に即してアップデートされています。全体を通して1冊の小説のようなストーリー仕立てになっており、このストーリーが実にリアルっぽくて面白い。
 序文には経験が浅い人向けともあるのですが、最後に述べるようにこのストーリーがよりエモく深く刺さるのは、経験を積んだより上の世代じゃないかなあと思ったりします。今更ですが読了したので、以下大まかに内容を追いながら感想メモなどを。

第1部 一人から始める

  • プロローグは時間軸がもっと後、本書の物語を回想するシーンから始まります。このへんからもうアツい。おしごと系アニメの絵で再現されてしまいそうでした。(アニメ脳乙)
  • 主人公の江島君は20代半ば、それなりに経験を積んだエンジニア。現在の会社の状況に鬱屈したもやもやしたものを抱えており、転職も多少考えていたりこのへんがリアルで主人公っぽいっですね。内向的な主人公、とはまたちょっと違うんですが2000年代以降のアニメや漫画の主人公を彷彿とさせます。
  • そして物語の舞台は架空のアチーブ&パートナーズ社(AnP社)。これがカフェのような嘘くさいオシャンティなオフィスで会社のサイトがやたらキラキラしているWeb系企業で、なんかTwitterアイコンを自撮りインスタ画像にしてそうな主人公の女の子が「私、春からWebエンジニアとして入社しました。Railsやってます!(キラッ★」とか自己紹介しだして始まったらまた別の印象を受けそうなんですが(注:ギャグですよ!笑)、このAnP社の設定にリアルっぽさがあってよい。
    今まではメーカー相手のシステム・インテグレーションが主業務。会社自体を自社サービス開発メインに転換しようと数年前から悪戦苦闘中、残業でカバーしてなんとかやっている…というあたりが実に泥臭くて現実的で頷けます。社員数500人クラスということで、IT系では大手じゃないけどそれなりに大きい方でしょうか。
第01話 会社を出ていく前にやっておくべきこと
  • もっとうまくやりたいけどなかなかうまくいかずに悶々とする江島君、社外の勉強会で刺激を受けて興奮します。隣の芝生は青いというけども、本当に青いのだ…というあたりに共感します。
  • その勉強会で伝説的なスクラムの偉い人に会ってすべてが変わっていく訳ですが、「それで、あなたは何をしている人なんですか?」という作中の問いかけが心に刺さった読者が多いようです。
  • そして外に出ることはいいことだ、しかし自分たちにそのまま適用しても上手くいかない…と解説でもはっきり言っているのが現実的でよいですね。

 多くの読者に刺さったこの「あなたは何をしている人なんですか」の話。私的には、自分がエンジニア界隈でリアルで知っている方々で言うと、このイベントのLT資料『凡人の生存戦略』に同様の、まさにあなたは何者なんですか…という話があってちょっとニヤリとしました。リンク張っちゃえ。てへ。

blog.vtryo.me

第02話 自分から始める
  • タスクの抜け漏れ、メンバー入れ替えによる知識の欠損などが現場あるあるで辛い……(笑)。
  • ここで出てくるのがタスクマネジメント、タスクボードでの見える化、朝会、振り返りなど、基本的なテクニック。「許可を求めるな謝罪せよ」というワードがよいですね。
  • そして見える化の媒体をアナログかデジタルか、本書では最初はアナログを勧めています。確かに年とったおぢさんがチームにいると先進的なデジタルツールが使いこなせなかったり(笑)、アナログでやると通りかかった別部署の人や偉い人に「おっなんか新しいことやってるね」と関心を寄せられるという効果があったりします。
第03話 一人で始めるふりかえり
  • 作中の会社でも半期に1回振り返りをやっているが、うまく行っていないというあたりが実にリアルです。別の個所でAnP社は社内の改善活動的なこともやっている描写がありますが、おそらく形骸化したりでだんだん効果が薄れてしまったという塩梅ではと想像します。
  • そして手法ではKeep, Problem, Tryのあれ、ネットの記事でもよく見るKPT法(ケプトもしくはケーピーティー)が紹介されています。スクラム開発では1ヶ月かそれ未満の単位を推奨、うまく回っているなら2週間おきが良いそうです。
  • コラムで、事実・意見・対策に分けて問題解決をナビゲートする手法が紹介されていてこれも有用ですね。テーマ例の「朝会が上司への報告会っぽくなっているのをなんとかしたい」というのがすごくリアルです。
  • 主人公の江島君が徐々にだが現場がよくなっている様をSNSで投稿しているシーンがあり、明言されていませんがおそらくTwitterですね(FBかもしれませんが)。ここから、舞台のAnP社は独立系らしく、コンプライアンス周りはあまり煩くない会社なのかなと思ったりします。

my-manekineko.hatenablog.com

第04話 一人で始めるタスクの見える化
  • 仕事をしているとタスクがさらにどんどん降ってきて収集がつかなくなる件、これもあるあるで経験した方は多いんじゃないでしょうか……。
  • タスクの情報として誰からの依頼で次に渡すのは誰か、期日、作業期間、終了条件を明らかにする話が載っています。
  • タスクを分割する分割統治法の話で、様々な分野でよく聞く台詞「分割して統治せよ」が登場。これは元は紀元前の地中海世界を制したかの古代ローマ帝国の言葉ですね。元の意味は、いろんな国を征服したら分割して治めると非征服民族同士で争い合うから我がローマ帝国は血を流さずに済むのだという、ローマ怖エェ〜な血なまぐさい話ですが、ソフトウェア開発の名著でもよく見る言葉です。
    要は「タスクが大きかったら分けていけば見積もれるし計画も立てられるよ」
    「実現したいことが複雑で途方もない話でも、分割することで対処できるよ」
    「プログラムする段階だったら単一責任原則に従ってクラスを分けたり(あるいはメソッドに分けたり)していけば複雑な機能も実現できるよ」
    という話ですね。
第05話 明日を味方につける
  • まだタスクに漏れがあるようで、江島君はチャットで怒られて謝ったりしています。「。。」で点が一つ多いとかメールの返事でもあるあるです……
  • 1日の最初に1日の計画を立てるので朝会はいいよ、ひとり朝会も効果があるよということでこのセクションでは朝会の話をしています。ウォーターフォールアジャイルを問わず、このへんは実施している方も多いのではないでしょうか。
  • 1on1ミーティングでしっかり相手の話を聞き、信頼関係を築くのが大事であるという話。業界問わずよく「傾聴」という言葉で表されたりします。心理学でいう「ラポール」ですね。僕もむかし新人教育の先生をやることになって指導する側の事前研修を受けた時、この話を知っていつも心に留めておかないとなあと思うようになりました。
第06話 境目を行き来する
  • ストーリーの方はSlackで会話していたり今風です。背景で登場し深夜残業していたモブの新人君が辞めてしまって辛い……(;´Д`)
  • ここではタスクボードの話が登場。TODO/DOING/DONEの3つに分けるのは割と普通ですが、ここではTODOは直近のタスクだけにして、先々のことや気付きはParking Lot(駐車場)やIcebox(冷凍庫)のエリアを新設してそこに止めておくと良いとあります。このへんのメタファーは分かりやすいですね。
  • そして稼働中のサービスやシステムだと起こり得る緊急事態は、「緊急割り込みレーン」をタスクボードに追加して、それに対応中であることを周りにも見える化するとよいとあります。高速道路の脇でパトカーや救急車のために空けてあるあれですが、このメタファーも分かりやすくて良いなと思いました。
  • 人間は基本シングルタスクなので、DOINGは数を制限しないとスイッチングコストが掛かるよという話。これをWIP(Work In Pprogress) と呼び、1−2に抑えておくとよいと本書では定義しています。このWIPという言葉も2010年代だと割とよく目にしますね。
     ちなみに略すと同じWIPですが、工場の生産システムなんかの文脈だとWIP(Work In Process)で「仕掛品」を指したりすることもあります。
  • 主人公の江島君は自分用カスタマイズとして、DOINGを自分のタスク、人に依頼中のタスクに分割して運用しています。こういう工夫の例があるのはよいですね。

designmemo.jp

第07話 二人ならもっと変えられる
  • チームリーダーは自分が状況を把握できていればよいという考えの人で、あまり会話がうまくいっていません。「僕もリーダーになったら、工数と効率化のことしか口にしなくなるのだろうか」の台詞がグサッと刺さります。あーいますいますこういう人。そうならざるを得ない立場の人もいますが、なんというかこうね、エンジニアが燃えるにはそれじゃ足りなくて、パッションにグッと訴えてくる燃料がいるんだよ!(突然の力説)
  • 江島君がもう会社辞めそうです。辞めないで…(;´Д`)
  • 社外の勉強会はいつもどおり楽しいですが帰り道、暗い明日を思って辛くなる。転職しても、芝生は前にいた場所から続いていて大して変わらない…というくだりも刺さりますね。しかし、仲間がいればまた違うのだ!
第08話 二人で越境する
  • 第一部の最後は社内の勉強会を決行、なんとスクラムのすごい人も来て実はうまくいって「それぞれの持ち場で。がんばれ、だよ」の台詞で終わります。
  • 解説で、外のキラキラした話をそのまま現場に持ち込んでもうまくいかないよとはっきり書いてあるのがよいですね。本書全体を通して、理想論に終始しない現場に寄り添った姿勢が見られます。
  • コラムで紹介されている「氷山モデル」が勉強になりました。他人から見えるのは出来事だけで、その水面下にはパターン、構造、メンタルモデルが隠れている。出来事だけで考えてはいけないよという話。メンタルモデルというと私的には『蒼き鋼のアルペジオ』という海洋コミック・アニメを思い出してしまいますが、その人の奥底に閉ざした信念や世界観で、経験によって形成されるものだそうです。
     その人の歩んできたキャリアや経験、立場、仕事によってIT用語ひとつでもスコープや微妙なニュアンスが違ったりすることがよくあるなというのは最近特に思うので、なるほどと納得します。

 総合して第1部は本格的なスクラム開発に向けた序章ということもあり、話は江島君の心に踏み込んでぐっとエモく、紹介されているプラクティスもアジャイルスクラム問わず手軽に実践できるものが多いです。
 ネットで感想をたどると、触発されて自分でもひとり朝会やタスクボードを始めてみた…なんて話をよく見ます。本格開発でなくとも週末のおためし開発やプログラミング学習、学業などにも、応用してみるのも良いのではないでしょうか。

 ちなみに自分専用タスクボード的なやつは僕も過去いろいろ試しまして、だいたい今はこれで落ち着いています。

  • 特定プロジェクトに関係しないタスク(交通費を精算する、なんかの書類出す、いつまでにWeb教育やる...とか)はWeb上のToDo管理サービスで管理。会社のネットワーク制限の変遷や新しいのを試したりで、Remember The MilkNozbeMicrosoft To-Do(MSがWunderlistを買収したやつ)と変わりつつ一元管理。
  • いろいろ試して最強はやっぱり自由に書けるテキストだということに回帰。プロジェクトごとにフォルダを作って直下にテキストメモをいつも置いているので、その最後に簡単ToDoリストで覚え書き。TODO/DONEしかない簡単なやつです。
  • 会議の中でタスクが増えたら、議事メモになんかマークをつけといて上の簡単ToDoリストに転記したり。
  • 朝のメールチェックの後でこれらを見て今日何をするか整理して適宜実行。一応これがひとり朝会といえなくもない(笑)
  • ライフハック系の記事だと仕事とプライベートを一括管理する方がいいようなことも書いてありますが、自分の場合は分けた方が気分がよいので、プライベートのタスク管理はデジタルでドイツ製のWunderlistに。主にiPhoneからアクセスしています。

 個人でなくチームとしての仕事では、スケジュールなりガントチャートなりタスク表や課題管理表を誰かが作るので、それを朝会や昼会で進捗を見つつ…という感じですね。SIer系として伝家の宝刀Excelがやっぱり多いですが、まあ使えれば何でも良いというのも真実です。

第2部 チームで強くなる

第09話 一人からチームへ
  • 第2部は主要登場人物も入れ替わっていよいよ本格的なチーム開発へ。具体的な機能などは省かれていますが、テスト管理支援ツールが開発対象です。スクラム開発手法の解説がストーリーの中でもメインになっていきます。
  • 2週間や1ヶ月の短いスプリントを開発期間として何回も回していくよ…など知っている人にはおなじみのスクラム用語が解説されていきます。案の定チームからは反発があって、「ウォーターフォール開発との違いがよくわからない」なんて質問はいかにも出てきそうですね。

www.ogis-ri.co.jp

第10話 完成の基準をチームで合わせる
  • 最初は作るもののイメージが曖昧で苦戦。
  • プロダクトに対してスプリントボードを作り、その中でプロダクトバックログ→スプリントバックログにやることを移し、開発していく解説。このスプリントバックログがいわゆる細分化されたタスクやチケットですね。
第11話 チームの向かうべき先を見据える
  • ストーリーでは満を持して謎のスクラムマスター、西方さんが登場。スクラムマスターって何のためにいるのかと、チームから反発が出るあたりが面白い。
  • そして積み上がったタスクの山を前に、西方さんから「これを全部やらんとあかんのか?」と聞かれてメンバが全員答えられなくなるあたり、あるあるですね。目先のことが忙しすぎてより長いスパンでの視点が欠けてしまうプロジェクトでよく起こります。
  • そもそも何のために作ってるのかを明らかにするために、プロジェクトの向く先を明らかにする「インセプションデッキ」が出てきます。チームでやるのがポイント。
  • そしてスクラム開発のゴールデンサークルの話。WHY - HOW- WHATの同心円で、なぜ作るのか、どう作るのか、何を作るのかの順。「まずWhyから始めよ」だという話。
    受託開発だと要件や設計指針は決まっていてWhyはあまり気にしないことも多いのですが、サービス開発の比率がより大きくなっていくかもしれないこれからの時代、やはりこのWhyがより重要になっていくのかなあと思います。リーダー論の本にもなっていますね。

第12話 僕たちの仕事の流儀
  • そしてこれもよくある開発チーム内の軋轢。ドキュメントに書き記さないとかテストコード書かない派、朝が遅いなどなど……。主人公の江島君はタイ人女性プログラマーのウラットさんに「マークダウンが読みにくいです」と文句を言われてしまいます。チケット管理ツールのRedmineとか情報共有のesaとか、マークダウン形式のテキストを自動的にHTMLに変換して表示してくれるツールは多いと思いますが、ウラットさんIDE系は何使ってるのかな? VS CodeAtomSublime Textでもなく、なんかタイ製のマニアックなエディタとかなのかな?とかエンジニア的に余計なことを考えてしまいます。(笑)
  • ここでWork Agreementとして、自分たちのチームなりの具体的なルールを決めるプラクティスが紹介。例では「ミーティングの際は腕を組まない」なんてのがあってリアルですね。僕も会社のコミュニケーションの研修で習ったのですが、人間は他人に心を開かず防御的姿勢に入るとつい腕を組んじゃうそうですね。よく心理学などでこの話題は出てきます。
  • うまくいくとチームがさらに良くなっていく成功循環モデルも説明。ここで一緒に載っているバッドサイクルの例が、炎上プロジェクトにあるあるで辛い……(笑)
第13話 お互いの期待を明らかにする
  • 今度はプロダクトオーナーとの軋轢が起こり、期待マネジメントとして「ドラッガー風エクササイズ」の話が出てきます。アジャイル関係の名著『アジャイルサムライ』にも出てきますね。
  • チームメンバが自分にどんな成果を期待しているか?までとことん言い合ってギャップを埋めていきます。確かにここまでチームで一体になれるとかなりパフォーマンスも上がるでしょうが、なんかここまでさらけ出すのは恥ずかしいような気もするし、チームメンバが社員だけじゃない場合なんかはどうするのかなあと思います。

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

  • 作者:Jonathan Rasmusson
  • 発売日: 2011/07/16
  • メディア: 単行本(ソフトカバー)

第14話 問題はありませんという問題
  • チームが順調に回り始めて朝会で問題が出なくなくなってきたけど、実はあるという展開。このキーマンがもしトラックに轢かれるとプロジェクトが崩壊してしまう人数を「トラックナンバー1」と呼ぶのは面白い用語ですね。プロジェクトマネジメントにおけるクリティカルパスみたいなものでしょう。
  • 日々のデイリースクラムで、今の調子が5段階でどうかを各自が話す「ファイブフィンガー」のプラクティスが紹介されています。ここで偉い人が硬いことを言うと言いづらくなるから、役職者やキーマンが率先してバカをやれとアドバイスがあります。これも真理だなと思います。
  • ストーリーではこうして各自を掘り下げていった結果、メンバーのウラットさんが作業を自分で抱え込みがちだったという問題が明らかになっていきます。これも1年めの新入社員なんかによくありがちです……
第15話 チームとプロダクトオーナーの境界
  • 今度はプロダクトオーナーの土林さんに危機が到来、全員で仕上がりを確認する「スプリントレビュー」が大事だよという話に。
  • ちょっと難しいクネビンフレームワークや、品質管理の世界でよく出てくる狩野モデルが登場します。
第16話 チームとリーダーの境界
  • 今度は今まで作ってきたものが無駄になる今そこにある危機が到来、「むきなおり合宿」をしようという話になっていきます。進むべき先を見据えて現在を直すのが目的であり、しっかりとプロジェクトのいろんなことを点検して洗い出していきます。
  • 合宿には集中、リードタイム短縮、高揚感の効果があるとのこと。いつも同じ場所だとテンションが上がらなくてダメだったり、食事がまずいとダメだよとアンチパターンも書いてあるあたりが面白いですね。
  • スタートアップ企業さんの公式ブログなんかでも時々、合宿で開発してきた!的な記事があって楽しそうだなと読んだりしていたのですが、やはりスクラムを実践していたのでしょうか。
  • またこういう合宿も自分の時間が100%近く自由に使える独身の身なら良いのですが、家族がいる人とかはどうしてるのかなというのもちょっと思います。
第17話 チームと新しいメンバーの境界
  • 登場人物面々も頑張って拒否したんだけど社内政治の世界で負けたらしく、チームには実力未知数の若手が送り込まれてきます。あ〜エライ人の意向でなんかが決まっちゃうこと、あるあるですね……
  • ここでメンバ全員の能力をしっかり共有しようということで「星取表」のプラクティスが登場。技術や言語で各メンバーごとにエース級/一人前/ヘルプ希望/習得希望/できないの5種類を記入していきます。
  • 本書のストーリー部分はスクラム開発の解説に集中するため、技術面は抽象化されているのかなとずっと考えていたのですが、ここで第2部の開発対象システムの技術スタック的なところが判明します。バージョン管理は流行りのGit、実物はAWS上で稼働、開発言語はRubyでテストコードにRSpec、WebアプリケーションフレームワークとしてはRuby on Railsという設定だったんですねー。並んでいるNode.jsとHTML5の細かいところが不明なのですが、おそらくJSライブラリをちょっと使ってクライアントサイド(=フロントエンド)の動きを補強したりする感じなのかなと思いました。
  • この星取表を用いると誰が誰を助けられるか、教育に掛かる工数、リスク等も分かっていきます。そして心理的安全性が損なわれるから人事評価に使ってはならないと明記されているあたり、なるほどと思います。
  • そしてペアプロを越えて「モブプログラミング」が実践されていきます。ネットでも話題になったモブプロ、これがもう書籍に載っているのが2018年の本だなと思います。メリット、運営ポイントを詳しく解説しているので試してみる方にも有用でしょう。
  • そしてストーリーでは新人の浜須賀くんを加えてチームもうまく回り始めます。コードを前にすると人が変わるというスゴイヤバイ人設定の新人くん、ウラットさんにコードのインデントにもっと気を遣えと指摘するシーンがあります。しかし作中の星取表の設定だとウラットさんはRubyがエース級ということになっていますね。
     プログラム言語を問わず、エース級の人はふつうインデント回りはしっかり気を配って綺麗なコードを書くので、めっさ重箱の隅なんですがこういうシチュエーションは現実ではあまり起こらないんじゃないかな…?と思いました。テストコードの中の話か、Rails特有のコード部分の話なのかもしれませんね。

 本セクションで解説されているモブプログラミングの話は、僕がよく聴いているポッドキャスト #しがないラジオ でその筋のすごい人を招いて話している回があります。めっさ参考になるのでオススメです。

shiganai.org qiita.com

第18話 チームのやり方を変える と 第19話 チームの解散
  • ストーリーは急展開でぬぁんとスクラムマスター撤収。時には手法を変えるのも変化を抱擁するアジャイルのやり方だ…ということで、バリューストリームマップの作成、リードタイムの計算…と進んでいきます。
  • そして主人公君がたどり着いたのが、トヨタで有名なカンバン方式をIT業界に応用したもの。タスクボードよりもっと大きな紙になりますが、企画に要件定義〜最後のリリースまでフェーズを分け、タスクを全部張って一覧で見られるようになる形式です。
  • そしていろいろあってプロジェクトは無事リリースを迎えるのですが、その後の振り返りを「ポストモーテム」としてかなり念入りに振り返り、お互いにメッセージカードを贈り合って感謝の念を伝えたりしています。
     ありがちなプロジェクト終了記念飲み会をもっとスクラム的にちゃんとやってるような感じですが、確かにここまで丁寧にやるとチームもより強固になっていくのでしょうね。

 第2部はスクラム手法を本格的にチーム開発に適用する話で、1部はエモさ全開だったストーリー部分もチーム内の描写が主になり、スクラム用語がばんばん出てきます。
 ネットの感想をあちこち巡ると、流しの名スクラムマスターとして登場する西方さんの関西弁が中途半端なのが気になるという感想があってなんか面白かったです。(笑)
 僕は標準語を入出力する人間なのでまったく気付かなかったのですが、関西のエンジニアの方々だと気になるんでしょうかね。地方が舞台のアニメ作品なんかでも、視聴者の分かりやすさを優先して方言を実際より緩めて標準語に寄せたりすることってありますね。
 またタイ国籍の女性プログラマー、ウラットさんの描写に、ずり落ちてくる大きいメガネを押し上げるという仕草が時折出てきます。おっ何これドジっ子属性の眼鏡っ娘キャラ登場?と最初は思ったのですが、もちろんそんなことはありまへんでした。(ラノベ脳乙)

第3部 みんなを巻き込む

第20話 新しいリーダーと、期待マネジメント
  • 第3部はまた登場人物も一部変わり、今度は単一チームでなく複数のグループが絡んだ、より大きな開発プロジェクトを題材に採って進んでいきます。
  • 今度のターゲットは大きなインテリアメーカーのBtoBのECサイト構築。いかにもSI系ぽい仕事ですね。PHP言語の案件なんかによくありそうです。
  • 作中のAnP社には他に炎上中プロジェクトがあるそうでパイセン蔵屋敷さんが引き抜かれてしまい、代わりに由比さんという人が登場します。転職組で前職は社員1万クラスのSIer企業で職種はアーキテクト。銀行系のフィンテック(金融テクノロジー全般、スマホ決済とか家計簿サービスとか金融関係の作業をシステム化する)の仕事で設計の腕を振るっていた…というのがリアルっぽい。
  • もちろんこの由比さんも架空の設定ですが、現実世界で特に銀行の顧客が多いSI系企業というとNTTデータ、日立、IBMあたりが上がります。データさんが本体が社員数1.1万なのでまさにそのぐらいでしょうか。
  • 僕も金融系脱出組なのであーこういうストーリーにもしも自分が登場したら、下手したらこの人の立場に近いじゃん(ガクブル)……などと思いながら読んでいくと、さすがお堅いウォーターフォール畑出身、由比氏はまず要件定義をしっかりやれと主人公君と対立します。
     でもこの人の言うことも正しくて、アプリケーションの基盤になるアーキテクチャやレイヤー構成やクラスやファイルのディレクトリ構成、認証・認可とかログとか各種部品などなど、最初にしっかり決めておかないと後で困ることも多いんですよね。
  • 解説では期待マネジメントの、インセプションデッキのアップデートが語られます。コラムでモダンアジャイルの概念の基本原則のうち、「安全を必須条件にする」の話が。よくキーワードで上がる「心理的安全性」に近い話ですね。互いが尊敬しあい信頼できる確信が、より強いチームを作っていくという話。
     派遣会社からとにかく人をかき集めてなし崩し的に進むような大規模炎上プロジェクトではこれが確約されないので、チームも何もありません。こうした上手くいかなかったプロジェクトのネガティブイメージが、最近多いSIer批判と結びつくことが多いのかなぁと改めて思ったりします。

agilemanifesto.org

第21話 外からきたメンバーと、計画づくり
  • プロジェクトという戦いを勝ち抜くにも優秀な兵士が足りない。ならば凄腕の傭兵部隊だ……! ということでストーリーではフリーランスRubyプログラマを雇うことになり、和尚さんとマイさんのコンビが颯爽と加わります。
     開発スケジュールを組み直していくのですが、2人とも、詳細が分からないタスクには必ずバッファを積んで見積もり、安請負いせずにできないことはできないと江島君にはっきり断り、台詞からも過去のPJ経験の蓄積が伺えます。このへんの描写からも、この2人はかなり開発スキル、経験値とも高い歴戦の猛者なのが見て取れます。
     派遣契約で来る方だと基本は言われた通りのことを実行することを期待され、受け手も基本はそう振る舞うものなので、なかなかこういう動きは難しいよなと思います。この話は後の方で江島君の独白にも出てきますね。
  • ラクティスでは「プラニングポーカー」が登場。全員でカードを同時に出してタスクことにかかりそうな人日をチームで見積もっていくというものです。ここでカードにはフィボナッチ数列が書いてあるというのがギークっぽくて面白いですね。違ったら見解の相違は善として話し合いながら再度見積もっていく。これでベテランからは過去の知見を、チームメンバからはそれぞれの得意分野を学ぶことができる……という話はなるほどと思いました。
     大きいSI系プロジェクトだと上流工程専門の業務SEやプロマネが見積もるケースも多いですが、技術がない人やプロジェクト運営の知見が不足していた場合がキケンです。だいたいこういう時にも苦労するのは実装フェーズの現場の若手や子会社や派遣の人とかになってしまいます。
  • コラムではCCPM法として、バッファをタスクごとでなく全体で持つやり方が紹介されています。個々のタスクを五分五分で達成できる見積もりを積み上げて合計し、その1/2のバッファを全体で持つとのこと。この手法は知りませんでした。原典を当たればこの数式にもきっと根拠があるのでしょうね。

appresso.hatenablog.com

第22話 外部チームと、やり方をむきなおる
  • ストーリーの外側で絶賛炎上中のAnP社の他プロジェクトはさらに燃え広がっているようで、今度はアーキテクトの由比さんまで引き抜かれてしまいます。記述からも主人公の江島君と10歳は離れているそうですし、アーキテクト級というとだいたい課長クラスだったりするので年齢は40ぐらいなのでしょうか。
     一般的にアーキテクトクラスの人はそう多くはないし、(内容に触れてしまいますが)最終話の浜須賀君との言い合いから、実はこの由比さんは設計だけでなく実装もバリバリできる人なのが読み取れます。(僕もこういう人材を目指しているのですが、正直現実のSI系企業だとなかなか少ないと思います。)
     このクラスの高度要員が重要なはずのプロジェクトから無理やり引き抜かれる……ということは、もしかしたらAnP社では役員クラスまでアラートが上がって「とにかく各部門から強制的に人を出して最優先であのプロジェクトの火をなんとか消せい!」とお達しが出たのかな?などと勝手に想像しています。
  • それでもめげずにチームを引っ張る江島君、今度は疎遠になっていた別チームの在庫管理チームとの認識の齟齬が問題になります。商品IDとかカテゴリ階層の仕様変更とか、当初想定のAPIの仕様が古いままだったとか、あーこういうのあるある……。
  • ここでSoE(Service of Engagement)とSoR(Service of Record)の話が出てくるのが2010年代らしいですね。
  • ラクティスでは「YWTフレームワーク」を用いた、やったこと、わかったこと、次にやることを整理する「むきなおり」や、複数のスクラムチームのマスターが集まって会議するスクラム・オブ・スクラムの話が紹介。
  • コンウェイの法則「アーキテクチャは組織に従う。組織はアーキテクチャに従う」がここで登場します。よく組織論やアーキテクチャを論じた本に出てきますね。僕は前に読んだ『マイクロサービスアーキテクチャ』で知りました。

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

  • 作者:Sam Newman
  • 発売日: 2016/02/26
  • メディア: 単行本(ソフトカバー)

第23話 デザイナーと、共通の目標に向かう
  • 今度はUIにこだわるデザイナーサイドの人との衝突が起こります。あーこれもわかりゅ……。相手に少しでもいいから開発の基礎知識があると歩み寄れるんですけどね。
  • 本書を通してのテーマですが、アジャイル的にはここでも「対立」でなく「協調」で解決しようということで、「ユーザーストーリー」を考えていくことを中心にカイゼンしていきます。ギャレットの5段階の話などは初見でした。
第24話 視座を変えて、突破するための見方を得る
  • 今度は営業向けに、営業支援のボットサービスを作るという案件の話が突如湧き上がってきます。仮設キャンパスの話などは初見でした。
  • 「視座を変える」、すなわち視点を上げ下げ移動したり相手や顧客の立場になると突破口になることがある……という話なのですが、実は営業が欲しかったのは妙なボットサービスでなく単にゴニョゴニョすることでムニャムニャできるようにすることだけだった、というストーリーの実例はとてもハラオチしやすくて良いと思いました。よく『顧客が本当に必要だったもの』としてネタにされる木の下のブランコのアレ的な話ですね。

dic.nicovideo.jp

第25話 広さと深さで、プロダクトを見立てる
  • ストーリー中で何度か伏線が示されていましたが、クライマックスのここでとある方が最大の障害として立ちはだかります。言った言わないの線引きが境界なんだという話、あ〜これもわかりゅ……わかるんだ……(;´Д`)
  • 開発案件はとんでもないちゃぶ台返しに遭うのですが、諦めない江島君、「ユーザストーリマッピング」と「MVP(Minumum Viable Product)」のプラクティスで戦います。MVPはよく自社サービスを打ち上げた新進のWeb系企業のブログなどで語られている話ですね。かなり深く解説されています。スポーツのMVP:Most Valuable Playerと似ていますが、ValuableでなくてViableなのも間違いやすいです。

boxil.jp

第26話 チームで共に越える & 第27話 越境する開発
  • 解説ではユーザーインタビューのやりかたのコツが非常に詳しく書かれています。
  • ストーリーの方はマイさんの意外な秘密が分かったり、ユーザーインタビューを決行する江島君たちの前には最後の最後で……と怒涛のクライマックス。これから読む方のために書かないことにしますが、もう映画で言ったら苦難の果てにアベンジャーズX-MENが全員集合してフォオオオッ!!!ってなるようなそういうアレ、もうエモさ全開の王道胸熱展開が待っています。

goodpatch.com

  • そして混乱期を超えて成長し、機能しだしたチームはやがて解散して分散する……ということで、最後はみなそれぞれの新たな道を歩みだす後日談的なエンディングになっています。最後が爽やかに、静かに終わるのが良いですね。
  • 成長した主人公の江島君は浜須賀くん経由で悩んでいる後輩の相談を聞くことになります。うまくいっていないプロジェクトで塹壕の中のような開発に悩み、転職も考えていると……あ~こういうのも分かる。
     ある程度たくさんプロジェクトを経験したり会社の様子が分かってきたり、本書でいう所の視座が広まったりするとそれが仕事の一つでしかないのが分かるのですが、若手のうちにドカッとデカくてスゴクヤバイ案件に潰されてしまいそうになると、それが世界の全てのように見えてしまうんですよね。
     昨今ネットで見る所謂Web系に転職してTwitterにいいねがついてるような人が語る過去に残してきたSIerというのは、得てしてこういう失敗プロジェクトであったり、またSI寄りの業界全体に関する誤解の一因にもなっているなと思います。
  • そんな悩む後輩君を救うために江島君が企画したのは、社内で人を集めて……ということで最後のプラクティスは「ハンガーフライト」。まだ飛行機がプロペラで飛んでいた時代、雨の日の格納庫での緩やかな集まりのように、ベテランもフレッシュマンも互いの経験から知恵を学び、立場が違う人から学ぶというもの。
     「ハンガーフライト」と名前を最初に聞いた時は何か難しい特別なものなのかと思ったのですが、要は大都市圏を中心によく開催されている勉強会などのイベントや社内の集まりなどと同じことですね。おっなんだこれ、社外から刺激を受けようと最近時々行ってるのと同じじゃんと分かって安心でした。

iwasiman.hatenablog.com

 ちなみに当ブログのこのあにべん!LT会の記事を見たのがきっかけで、お隣りブログのひとつ、未来のWebエンジニアを目指すさいとーえくさんがカイゼン・ジャーニーを読んだとのことで、記事にしてくださいました!😄

sathoeku.hatenablog.com

 第3部はチームと別チームや社外などの外側との関係にフォーカスし、みなを巻き込んで越境していこうという話になります。解説されているスクラム的なプラクティスもかなり高度になり、明日からすぐ実践したりするのはちょっと難しいかもしれません。自社サービスをこれから立ち上げていこうという会社さんなんかだと役に立ちそうですね。
 そして、ストーリーの方は相変わらず非常に現実味があります。仕事の経験が豊富な方、単なるプログラミングよりもっと広く打ち合わせや社内調整やいろんなことをしてる方ほど、アツくエモく読めるのではないでしょうか。
 登場人物でいうとアメリカ育ち帰国組で台詞がカタコトの日本語になっているマイさんが面白いですね。こういうキャラよく漫画やアニメに出てきますね。脳内で補完が捗る読者もおられたのではないでしょうか。おいらもうっかりすると「HEY、提督ゥ~」とかそういう口調に変換されそうでやばかったです。(ゲーム・アニメ脳乙!)

まとめ:あなただけのジャーニーを始めたくなっちゃう刺激に満ちた本

 本の最後には、アジャイルの価値と原則から始まり、作中に登場したプラクティスがすべてまとめてあります。これがかなりの数に及んでいて改めて見るとすごい。ストーリーと整合を取りながらその中で自然に紹介できるよう、かなり構成を検討したのだろうなと推察します。フィクションだけど現実味のあるストーリーや人々の描写にも、SIer/事業会社/アジャイルとかなり幅広く経験されてきた筆者の方の過去の知見がかなり活かされています。
 そして巻末の参考書籍もIT技術書やマネジメント、アジャイル関係の名著、著名な本がかなりの数並んでいます。これも圧巻。

 読み始めた時は舞台が自社サービスをやろうとしている企業だったり、コミュニケーションツールにSlackが出てきたり、若手のエンジニアにも共感できるようにしたスクラム解説本かと思っていました。
 しかし読み進めていくにつれ、そしてネットの感想を見るにつれ、ああこのストーリーが一番刺さるのはもっと上の現場経験の豊富な世代、30代~40代~のエンジニアなんじゃないかなと思い直しました。
 苦労した新人時代を超え、経験を積んで今はもうリーダークラスだったり後輩を指導する立場の方。
 あるいはもっと上の世代の方、今ほどソフトウェア開発技法が整備されていなかった時代に幾つもの苦難を乗り越え、失敗から学び生き残ってきた歴戦のエンジニア。
今は昇進したりもうマネジメントに主軸を移したりした方。2000年代にアジャイルが日本に上陸した頃にやってみたけど当時は様々な障害がありうまく実践できなかった方。
おっさんの武勇伝自慢は老害の証(笑)なので普段は若手の前では抑えてるけど、本書を読んで昔を懐かしく思い出して熱くなってしまった方。そんなシーンが思い浮かびます。

 あちこちでよく名前を聞いてきた謎の「越境」というキーワードには本書では様々な意味が込められており、人によっても異なる意味、力、パッション、求心力として働く抽象的な何かなのだと理解しました。
 プロジェクト内の人間関係や力関係の無形の壁、大きい企業ほど増えていく組織内の上下左右に伸びる壁。それらの壁を越えて活動すること、視座を広げ変える力、そこに至る勇気。
 自分から何か新しいことを始めよう、変えていこうと思い立つ意志。いつもと違う人と触れ合ったり、いつもの世界の外側に踏み出してみようという思い。
 そんな、自分なりの旅…ジャーニーを始め、ジャーニーの途中で後ろを振り返ったり、さらに前に進んでいる人を「越境者」と呼ぶのだと。

 「さあ始めよう。あなただけのジャーニーを」というフレーズに触発されて、明日から基本的なプラクティスを試しに使ってみたくなる。
 普段の仕事や自分自身で、何か変えられないところはないか見つめ直したくなる。
 「越境」とか「ジャーニー」のワードをなんだか使いたくなってくる。
 社外の勉強会に繰り出したり、ブログを書いたり、個人で何か作り始めたり、何かを始めたくなってくる。
 もう最初の一歩は踏み出しているなら、今度の勉強会のLT資料に登山や旅の画像をなんだか使いたくなってくる。
 ……そんな、普段はすり減りがちな人の魂の奥底に働きかけて発火を起こし、エモーショナルなエンジンを再起動させる、刺激に満ちた本でした。自分の中で今年読んだ/これから読む技術書の中で、2018年MOSTエモい部門のBEST1はもうこの本に確定しそうです。

kaizenjourney.jp

なお、本書の著者のお2人はPodcast「しがないラジオ」のsp.40にゲスト出演されています。裏話や様々な話が聴けるのでこちらもどうぞ。 shiganai.org