【技術書典7新刊】「エンジニアのチームを整える技術」について

どうも！
「エンジニアのチームを整える技術」
著者のkaramageです。

2019/9/22(日) 技術書典7
サークル「からまげ＠うまうまだよもん」にて
以下の書籍を3冊頒布しました。

【既刊】累計1000冊販売「エンジニアの心を整える技術」
【新刊】「エンジニアのチームを整える技術」
【新刊】「たった 1 人で SaaS をグロースさせる データ分析秘伝の書」

サークル紹介ページ
https://techbookfest.org/event/tbf07/circle/5728090902757376

このnoteでは、「エンジニアのチームを整える技術」の前半66ページを
無料公開します。

【整えるシリーズ第二弾】
「エンジニアのチームを整える技術」
 本書には、チーム開発を成功に導くためのマインドセットについて書きました。
チームの本と書くと、「なんだ、マネージャ向けの本か」と思われるかもしれませんが違います。
 リーダやマネージャだけでなく、「チーム開発」に関わる全てのメンバーに読んでほしいです。
 ――そう、あなたです。 あなたに読んでほしいんです。

また、このnoteをご購入いただくと「エンジニアのチームを整える技術」のPDF版のダウンロードが可能になり、全編を読むことができます。

Kindle でも「エンジニアのチームを整える技術」を販売しています。
https://www.amazon.co.jp/dp/B07Z9FKZ1F

BOOTH でもPDF版「エンジニアのチームを整える技術」を絶賛販売中です！
https://karamage.booth.pm/items/1571170

前作「エンジニアの心を整える技術」も合わせてお読みいただけると嬉しいです
https://karamage.booth.pm/items/1309156

Twitterの反響

購入者からのTwitterの反響を載せさせていただきます。

書籍頒布物紹介

【電子版】「エンジニアのチームを整える技術」118ページ / ￥1200

目次

まえがき
　- キャッチャー・イン・ザ・ライ
　　 - ぼくは、耳と目を閉じ、口をつぐんだ人間になろうと考えた
　- 変化し続けることができるチームが求められている
　- この本の概要

第 1 章 プロダクトをつくるためのチーム
　1.1 チーム開発における 3 つの課題
　　- 「人」と「プロダクト」を大切にしたい
　1.2 プロダクト型開発に移行せよ
　　- プロジェクトという形態からプロダクト開発へ
　　- アジャイルはジャズ

第 2 章 変化し続けるチーム開発
　2.1 チームは何のために仕事するのか
　　- You know what I’d like to be?
　　- あなたは何をする人ですか?
　　- 壁と境界と越境
　　- 納期を守るためのチームという悪夢
　　- プロダクトに意味付けできるチームが強い
　　- アジャイルとウォータフォールの違いは不確実性との向き合い方
　2.2 なぜ日本ではアジャイルが普及しないのか
　　- わからないことを、「わからない」という勇気
　　- エンジニアリングとはアジャイルである
　　- ウォーターフォールからアジャイルへ移行できていない企業
　　- SIer は近い将来淘汰される
　2.3 プロジェクト型開発からプロダクト型開発へ
　　- プロジェクト型は終わらせるのが目的
　　- プロダクト型は継続するのが目的
　2.4 ユーザ企業の内製化にはアジャイルチームが必要
　　- アジャイルだと 3 倍の成功率、1/3 の失敗率
　　- 大規模開発でもアジャイルが有効
　　- アジャイル型人材の必要性が高まっている
　2.5 認知フレームの問題
　　- 過去のウォータフォールでの成功体験が邪魔している
　2.6 リフレーミングでチームの働き方を変える
　　- 会社や組織は変えにくいが、チームのメンタルセットは変えやすい
　2.7 変化し続けるチーム vs 硬直するチーム

第 3 章 Solid State Team には近づくな
　3.1 登場人物
　3.2 曖昧性と不確実性との戦いが、いま、はじまる
　　- ハイブリッド・アジャイルという名の悪魔合体
　　- 何を作るのか決まっていないのに見積もりを強要する
　　- 破裂しそうに膨らむ要求仕様いう名の爆弾
　　- どんぶり勘定のステップ数見積もり
　3.3 マイクロマネジメントを強要する上司
　　- 頻繁な作業報告
　3.4 Solid State Society - 個体状社会
　　- 遅れる進捗と怒れる人々
　　- 客先常駐という刑務所
　　- 監視体制と臨戦態勢
　3.5 分断するチーム
　　- 作業員としてコードを書く日々
　　- デザイナーとの分業
　3.6 ドメイン知識の不在
　3.7 硬直するチームの憂鬱
　　- UI/UX を考えるのは誰?
　　- プログラマはコードだけ書いていればよい
　　- マネージしないマネージャーは、ただのャーだ
　　- 説教されるだけの 1on1
　　- いつからアジャイルだと錯覚していた?
　3.8 唐突な開発打ち切り宣言
　　- プロダクトオーナの消失、そして誰もいなくなった
　3.9 憂国への帰還 ENDLESS ∞ GIG
　　- ぼくらはみんな生きている

第 4 章 チームを整える技術
　4.1 個人よりチーム
　　- 一人から始める
　　- 最初のチームメンバーは自分
　　- チームは個人の拡張
　4.2 複数人チームで働くということ
　　- 個人の能力よりチームワークが重要な理由
　4.3 タックマンモデル
　　- チームの成⻑の「4段階」
　　- チームビルディング
　4.4 対話がすべて
　　- 対話することでチームを変える
　4.5 コミュニケーションの不確実性
　　- 私はあなたではないという単純な問題
　　- 意見の対立
　　- 個人で働くことの限界
　　- HRT
　　- コードレビュー
　　- 有害な人と付き合う方法
　4.6 学習するチーム
　　- メタ認知で学ぶチカラを鍛える
　　- コンフォートゾーンを出てラーニングゾーンへ
　　- コンフォートゾーンに戻ろうとするホメオスタシス (恒常性)
　　- 対人リスクを取って前に踏み出す勇気
　　- 斧を研ぐ時間
　　- 価値があると認識しながら学習する
　4.7 強いチームとは
　　- 「これやる意味あるんすか?」と言えるチームが強い

第 5 章 チームをリフレーミングする技術
　5.1 リフレーミングの定理
　　- リフレーミングとは?
　　- ネガティブなことの中に、ポジティブな力を見つける
　　- 仕事の意義をリフレーミングする
　5.2 再生と再認 アンラーニング
　　- 成功体験が「負債」になる
　　- 学習棄却 (アンラーニング) の方法
　　- ウォータフォールからアジャイルに移行する方法

第 6 章 自己組織化を超えた先に
　6.1 今後、どういうスタイルでエンジニアは開発するのか
　　- チームから、「個」の集合体へ
　6.2 スタンドプレーから生じるチームワークとは
　6.3 チームという概念の消失。溶けて消える
　　- 人の心が自由になる働き方とは
　6.4 STAND ALONE COMPLEX

あとがき
　- 著者紹介

----------------------------------------------------

「エンジニアのチームを整える技術」 本文
(前半66ページ(全118ページ)無料公開中)

エンジニアの チームを整える技術 

— 変化し続けるチームへと導くリフレーミング術 — 

karamage 著 

技術書典 7 新刊 2019 年 9 月 22 日 ver 1.0

■免責 
本書は情報の提供のみを目的としています。 本書の内容を実行・適用・運用したことで何が起きようとも、それは実行・適用・運用した人自身の責任であ り、著者や関係者はいかなる責任も負いません。 

■商標 
本書に登場するシステム名や製品名は、関係各社の商標または登録商標です。 また本書では、TM、®、© などのマークは省略しています。

まえがき 

我々の間には、チームプレーなどという都合のよい言い訳は存在せん。
あるとすればスタンドプレーから生じる、チームワークだけだ。
攻殻機動隊 STAND ALONE COMPLEX 第5話

キャッチャー・イン・ザ・ライ 

ぼくは、耳と目を閉じ、口をつぐんだ人間になろうと考えた 

朝、バイト先のエレベーター待ちで、先輩社員の I 氏と遭遇した。
 I 氏は、まだ、こちらに気づいていない。
どうする、 話しかけるか。 

いや、まて、思い浮かんだのは「今日はいい天気ですね」くらいしか話題がない。

結局のところ、沈黙することを選択した。

うつむいていると、こちらに気づいた I 氏が手を上げながら近づいてきて、声をかけてきた。

「おはよう、ここんとこ、ずっと暑すぎだよね。今週は30 °C超えが当たり前らしいよ」

ぼくは、背中に暑さとは別の冷や汗をかきながら、手で顔をあおいであたふたした。

「昨日のプログラム、ありがとう。完璧だったよ。見せたら、相南運送さん、スゴく喜んでたよ」

昨日に突然、客先からの要望で帳票出力プログラムの修正が必要になったと聞いて、ぼくが独力でパパッと修正したのだ。

「えっ、たった 1 時間でアレを、結構ムズカシイはずだけど」

I 氏は、何やら手をあごに当てて、ひとり納得し始めた。

I 氏の様子を見て、得体のしれない違和感に包まれた。
エレベータに乗り込みながら、I 氏が「これからもよろしくね」と、ぼくの肩を叩いた。
ビクッと背中に電撃が走り、作り笑顔でうつむいた。
「あ、おれ、一服していくから」と言い残して、I 氏はエレベータを降りていった。
ぼくは、急に寒気を感じて、冷たい汗が背筋をつたって落ちた。

 
この時のプログラムの修正が、後に問題を引き起こすことを、知る由もなかった。

――つづく

はじめに 

本書を手に取っていただき、ありがとうございます。 著者の karamage です。
フリーランスのエンジニアとして、様々なアプリ開発に取り組んでいます。
アプリは、個人開発で作っているものもあります。
企業の開発チームの一員として、作っているものもあります。
個人とチームの境界線を渡り歩いて、仕事をしています。 

「チームを整える」とは
本書には、チーム開発*1を成功に導くためのマインドセットについて、書きました。
「チームを整える」とは、チームのマインドセットを整えることを意味します。
チームのマインドセットが整った結果、「変化し続けるチーム開発」が可能となります。
チームの本と書くと、「なんだ、マネージャ向けの本か」と思われるかもしれませんが、違います。
リーダやマネージャだけでなく、「チーム開発」に関わる全てのメンバーに読んでほしいです。
――そう、あなたです。あなたに、読んでほしいんです。 

他者との共創の二重奏
わたしたちエンジニアが一人でできることって、限界があります。
わたしは「個人事業主」のエンジニアですが、エンジニアが個人でできることは限られます。
すべてのエンジニアは、他者と共創することによって、ソフトウェアを作っています。 わたしは個人でアプリを開発しているのですが、個人開発アプリでさえ、様々な OSS ライブラリやツールを使って作成しています。
開発でわからないことがあれば、GitHub の Issue を読んだり、質問したりします。さまざまな人の助けを借りて、アプリの個人開発をすすめることができています。
つまり、本当の意味では、「ひとり」でソフトウェアを開発している人はいないのです。みんな、何かしらのカタチで「チーム開発」をしています。
しかし、わたしたちは「チーム開発」について、体系的に学ぶ機会は、ほぼありません。 

*1 本書におけるチーム開発とは、「ソフトウェア」を「エンジニア」が「複数人」で開発することを意味します。

「チーム開発の正解」とは
――「チーム開発」って、難しくないですか?
個人でアプリを作るよりも、チームでアプリを作るほうが、何百倍も難しいです。
個人では優秀なアプリエンジニアだとしても、チームとなると、なかなか成果が出せないことも珍しくありません。
  
――あなたのチームは、成果を出せていますか
仮に、日本中の有名なエンジニアを集めて、スターエンジニアチームを作ったとしても、できあがるプロダクトが素晴らしいかと言えば、そんなこともないです。サッカーでいうレアル・マドリードのような銀河系軍団を作っても、チーム開発はうまくいかないはずです。 

理念で突き詰めていくと失敗する。
確かに、真面目なアリだけ集めて集団をつくれば、作業効率は高まるような気がする。 ところが実際はそうはいかない。
5%の優秀なスタッフだけを集めて作品を作りたいという欲求に駆られても、そうはいかないのだ。
押井守 

そもそも「チーム開発」のやり方について、学校でも、会社でも、誰も教えてくれません。
――何故でしょう?
なぜなら、「チーム開発」に、正しいやり方なんて存在しないからです。
残念ながら、「チーム開発」には、正解がないのです。
世の中は、目まぐるしく変化――それどころか、激変につぐ激変を繰り返しています。
一時的にもてはやされたビジネスモデルや知識は、すぐに陳腐化し、役に立たなくなります。
個人でもチームでも、努力すべき方向が見えず、不明瞭な時代になっています。 

正解のない問題に向き合う
ここで大事なのは、正解がわからないけれども、「わかっていないことはわかっている」ことを自覚することです。
この状態になって、初めて問題の本質に近づくことができます。
チーム開発で本当に大事なことは、わからないものに囲まれたときに、答えがないまま、それにどう対処するかの智慧と言えます。

チーム開発がうまくいかない原因とは
チーム開発がうまくいかない根本原因は、「想定外の事象」に対応できないことです。
「想定外の事象」に臨機応変に対処するためには、「変化を許容する」必要があります。
「変化を許容する」ことができない理由は、それを担うチームのメンタルセットと組織構造にあります。
日本の SIer 的なシステム開発では通常、営業がいて、PM がいて、SE がいて、プログラマ (コーダ) がいて、インフラ担当がいて、QA テスターがいて、という役割に応じて、チームメンバーの頭数を揃えます。 

SIer 的組織構造
縦割り的にピラミッド組織を構築するのは、日本の SIer の定石的なアプローチです。 

• 営業が、顧客と契約交渉を行い、
• PM が、プロジェクトのスケジュールや進捗を一括管理し
• SE が、設計書を作り
• プログラマが、コードを書き
• インフラ担当が、ネットワークやハードを敷設し
• QA テスターが、テストをする 

SIer では、このような分業体制でシステム開発が行われるのが一般的です。
役割ごとに高い壁を作り、壁の中で割り当てられた作業だけをこなします。
これが、チームの硬直化を招きます。硬直化したチームは、変化することができなくなります。 

チームの硬直化は命取り
最悪なことに、現代のソフトウェア開発では、チームの硬直化は命取りになるのです。
現在、世の中が、多種多様で、複雑で、ものすごいスピードで現在進行系で移り変わっているので、たとえ今日、正解を見つけたとしても、明日には不正解になっています。 

全自動資本主義
現代の世の中が、移り変わりが激しいのは、資本主義経済による「新自由主義」が激化しているからです。
資本主義の逆の体制である「計画経済」の国家は、旧ソ連が典型です。
旧ソ連のような「計画経済体制」の国家は、簡単に言うと、
「国家の官僚に、神様のように万能な頭のよい人がいて、その人の正しい予測をもとにして、経済を回していけば、国は豊かになるでしょう」という前提にもとづいた社会です。 

しかし、計画経済には、大きな矛盾があります。
すべてを完璧に予測できる官僚なんて、いないのです。
この矛盾が原因で、旧ソ連をはじめとする旧社会主義国家は、破綻していきました。
いっぽう、資本主義経済による「新自由主義」では、「頭のいい人がすべてを決めるなんて無理ですよ。そのかわり、市場に集まった人がそれぞれ自由にお金やモノをやりとりすることによって、自然とうまくいきますよ」という考え方をとります。
アダム・スミス曰く「神の見えざる手」に任せるという考えのほうが、「計画経済」より、うまくいくということです。 

変化し続けることができるチームが求められている
資本主義の「新自由主義」において、世の中の移り変わりが激しい現代に求められるのは――「変化し続けるチーム開発」です。
チームは、変化し続けることが重要なのです。
「神の見えざる手」に対して、臨機応変に、その場で、自律的に、自分たちで考えて行動することが求められています。 

神は、サイコロを振り続けます。
1の目が出ているあいだ、上手くいったとしても、次の日、5の目に変わったとき、上手くいかなくなります。 

本書でもっとも言いたいことは、変化し続けることの重要性、これだけです。 

そこで、「変化し続けるチーム開発」の現場を、より楽しく、体系的にまとめたものを、「エンジニアのチームを整える技術」としてあなたにお届けいたします。
ソフトウェアの「チーム開発」に関わるエンジニアの皆様の少しでも助けになればという想いで、今まさに執筆しています。

本書のロードマップ
1 章にて、「チーム開発における 3 つの課題」における「プロダクト型チーム開発」が、なぜ今必要なのかということを説明しています。
2 章には、「変化し続けるチーム」の重要性について、「変化しないチーム」の問題点を挙げて比較しています。
3 章には、「変化しないチーム」について、筆者の体験談を元に、チーム開発のアンチパターンとして、ストーリ仕立てで記述しています。
4, 5 章には、チームのメンタルセットを整えるための技術を体系的にまとめています。
最後の章では、未来のチーム開発について、筆者の未来予想図を書いています。

【コラム】アニメ『攻殻機動隊』について
突然のコラムコーナー失礼いたします。 唐突ですが、私は、アニメ『攻殻機動隊 STAND ALONE COMPLEX』が好きです。ちなみに一番好きなキャラクターはボマーです。
攻殻機動隊は公安 9 課で働く人のチームワークの物語です。政府の組織に「公安 9 課」という、電脳犯罪専門のチームがあり、事件を解決へと導きます。
「公安 9 課」は、個性的なメンバーばかりですが、チームとして最強の動きをなします。攻殻機動隊のチームワークストーリーは、どの業界/会社でも、どんな職業でも同じことが言えると思うこともあって、本書では随所に攻殻機動隊の名言を引用させていただいています。
攻殻機動隊で描かれる働く人の考え方や思考や心の揺れ動きは、IT 業界と親和性が高いと思います。

この本の概要 

■本書で得られること
• プロジェクト型チーム開発 (ウォータフォール) が時代遅れになってきている理由
• プロダクト型チーム開発 (アジャイル) のマインドセット
• チームのメンタルの整え方やリフレーミングについて 

■対象読者
• リーダーやマネージャーだけではなくチーム開発に関わる全てのエンジニア
• プロジェクト型開発からプロダクト型開発に移行したいエンジニア
• チームのメンタリングについて興味があるエンジニア
• プロダクトに愛情を持っていてよりよくしたいエンジニア 

■前提知識
• ソフトウェア開発業務についての基礎知識
• アジャイル開発の基礎知識 

■問い合わせ先
• URL: https://karamage.booth.pm
• Twitter: @kara_mage

第1章 プロダクトをつくるための チーム 

未成熟な人間の特徴は理想のために高貴な死を選ぼうとする点にある、
それに反して成熟した人間の特徴は理想のために卑小な生を選ぼうとする点にある
功殻機動隊 STAND ALONE COMPLEX 第 16 話

1.1 チーム開発における 3 つの課題 

本書を手にとっていただいたということは、チーム開発になんらかの課題感をお持ちですね。
チームで開発をしていると、頭が痛くなるような様々な課題があります。
課題を大雑把に分類すると、以下の3つに分類されます。 

• 人の課題
• プロジェクトの課題
• プロダクトの課題 

人の課題
人の課題とは、人と人との関係性の問題です。
チームのメンバー間の関係だったり、社内の別部署の人との関係や、顧客との関係です。
さらには、各メンバーの心の問題を含みます。 

プロジェクトの課題
プロジェクトの課題とは、プロジェクトの計画や納期、見積もり、進捗管理、契約などのことです。 

プロダクトの課題
プロダクトの課題とは、「そもそも何をつくるのか」「どういう技術を使うのか」といったものです。 

「人」と「プロダクト」を大切にしたい 

日本の SIer 企業では、⻑らく「プロジェクトの課題」だけにフォーカスしてきました。 SIer ではおなじみの、ウォータフォールという開発手法があります。

ウォータフォールは「プロジェクトの課題」を遂行するために、人を奴隷のように扱い、プロダクトの品質は犠牲になります。
その結果として、「人」や「プロダクト」は、ないがしろにされてきました。
少なくともわたしが居た現場では、人に対しても、プロダクトに対しても、ひどい仕打ちを、さも当然かのように行っているのを、目の当たりにしてきました。
このような職場では、変化は悪です。変化しない結果、硬直したチームを作り出します。

そんな SIer と、ウォーターフォールが、嫌いです。 

「人」の課題 にフォーカス
チーム開発で起こる、問題の大半は「人の課題」です。
さらに「人の課題」と、「プロダクトの課題」は、密接に結びついています。
つまるところ「人の課題」が解決しないと、「プロダクトの課題」の解決にたどり着けず、チーム開発はうまくいきません。 

しかし、「人の課題」を解決することは、なかなか難しいです。
理由は、人の関係性がますます複雑で多文化的になってきているからです。
マネージャが、一人の個人として、チームメンバー全員を管理したり、意思決定をしたり、仕事をやりとげるといったことは、不可能です。

 
本書では、「人の課題」と、どう向き合っていくのか、まとめたいという想いで執筆しています。 

親しい者の姿を見ず、声を聞かず、
公務にまっとうすることが正義と考え、
ここまで来たが、それが正しいことだったのか。
攻殻機動隊 STAND ALONE COMPLEX 第22話

1.2 プロダクト型開発に移行せよ

「人とプロダクトの課題」と向き合うために必要なのが、「プロダクトをつくるためのチームづくり」です。プロダクトをつくるためのチームは、プロダクト型開発を行う必要があります。 

プロジェクトという形態からプロダクト開発へ 

「リーンソフトウェア開発」シリーズの著者として知られる、メアリー・ポッペンディーク氏の発言を引用します。 

ここ15 年以内に創立した企業は、ソフトウェア開発はビジネスのメインの一部になっている。これらの企業では「プロジェクト」という形態でなく、むしろプロダクト開発(サービス開発を含む)であり、ソフトウェア開発はラインのビジネスユニットの内側にある(例えば、銀行 の IT 部門と facebook を比べてみると良い)。プロダクト開発はプロダクトマネジャ(マーケティングに強い)とテクニカルリード(技術に強い)のペアによって指揮される。成功している企業は両方(マーケットと技術)のスキルを、プロダクト開発のリーダーのポジションにお く(1 人もしくは 2 人ペア)。これらの会社では、初期製品を作って、それを成⻑させるため、 開発と保守の区別もなくなりつつある(例えば Gmail や facebook は、一週間に 2 回デプロイ される)。これらの企業は、Eric Ries のThe Lean Startup(邦訳:『リーンスタートアップ』 日経 BP)のようなやり方で製品を成⻑させる。保守、というふうには考えておらず、継続拡張だと捉えている。これらの企業では、アジャイルはすでにここ数年で広く普及している。
メアリー・ポッペンディーク 

ポッペンディーク氏は、ソフトウェア開発がビジネスのメインである最近の会社では、プロジェクトという形態から、プロダクト開発という形態へと、進化していることを指摘します。
プロジェクト型開発とプロダクト型開発の違いについては、後述することにします。 

ウォータフォールとアジャイル
チーム開発のやり方として、大きく分けて2つの開発手法があります。 

• ウォータフォール型開発
• アジャイル (スクラム) 型開発 

ウォータフォールは、プロジェクト型開発の手法で、 アジャイル (スクラム) は、プロダクト型開発に有効な手法です。
こんなこと書いてると、あなたから「ウォータフォールとアジャイルを同列に比較して語るな」というお叱りの声が飛んできます。その声も承知の上で、続けます。
筆者は、⻑年ウォータフォール開発に従事してきました。
本書には、その時に感じたウォータフォール型開発の問題点について、筆者の経験を交えながら記します。 

誤解してほしくないのですが、ウォータフォール開発がアジャイル開発に比べて劣っているということを言いたいわけではないです。もちろんウォータフォールにも良い面がちょっとだけ、ほんの少し、多少はあることを過去の経験から嫌というほど知っています。

 
例えば大規模な基幹系の開発の場合、作業に従事するエンジニアのレベルもバラバラです。このときアジャイル開発でやるとなかなかうまくいきませんでした。自発的に行動できない意識の低いプログラマたちは手を抜きサボっていました。収拾がつかずに永遠に成果物ができないことも多かったです。 

この場合、プログラマは「言われたこと」しかやらないマインドセットに支配されているので、 厳しいプロジェクトマネージャの元でマイクロマネジメントが必要だと考えます。このような状況によってはウォータフォールでやったほうが良い場合があるのも事実です。 

ウォータフォールでは、変化に対応できない
アジャイルとウォータフォール、どちらの手法も比べられない世界の事象であり、その違いは筆者も重々承知しています。
日本の SIer の特質として、一つ一つのプロセスが後戻りしないよう、「ウォータフォール」で非常に綿密にチェックしてきましたが、変化の激しい現代では勝ち抜いていくことが難しいと思います。世の中には、ウォータフォールで計画を重視しつつ、アジャイルのマインドセットも持ち合わせるという「いいとこ取り」で開発しているチームも多く存在し、素晴らしいと思っています。
しかしながら、ウォータフォールで開発するよりもアジャイルで開発するほうが圧倒的に楽しいです!
そう、アジャイルは楽しいんです。

アジャイルはジャズ 

わたしは、アジャイルが好きです。
音楽で例えると、アジャイルはジャズです。自由と秩序のバランスが良いです。ジャズには「モード演奏」があります。「モード演奏」は、「一定のルールの中での自由」なのです。
短歌が「五七五七七」の中での自由だったり、俳句に「季語」が必要だったりするのと似ています。「規律を守りつつ自由になる」のが楽しいのです。

自由とは、規律から「逸脱する精神」のこと
自由になるとは、別の形容をすれば「逸脱する精神」ということになるでしょうか。
アジャイル開発において、既存の枠組みから「逸脱する」瞬間があります。たえず逸脱する瞬間がないと、ソフトウェアは変化に対応できず滅んでしまうのです。
アジャイルが楽しいのは、「逸脱する精神」が認められるがゆえにチームの取り組みに活気がみなぎっているのです。
逆に、ウォータフォールは楽しくないです。「逸脱する精神」が認められず、自由がないからです。そう、だから、わたしはウォータフォールのことは嫌いです。
しかし、これは筆者の主観であり、偏った思いです。
本書では、私の主観のもと、ウォータフォールの価値を認めながらも、アジャイルを推進するという立場で、執筆します。 

「仮説」を立て、「検証」し、「逸脱」するサイクル
アジャイル開発は、「小さなサイクルを高速で回す」という手法です。変化の激しい現代では重要です。
正解がわからない現代におけるソフトウェア開発は、「仮説を立てて、それが正しかったかどうかを検証する作業」を、何度も、何度も、繰り返すことが最重要なのです。
「仮説・検証」という小さなサイクルを高速で回すことによって、プロダクト開発が完結します。
しかし、気をつけてください。アジャイルは銀の弾丸ではありません。むしろ、チームの死期を早める猛毒になりえます。アジャイル開発を導入することによって、失敗するプロジェクトも多く存在します。
チームに、ウォータフォールを適用するのか、アジャイルでやるのかは、適材適所な面が大きいです。ウォータフォールからアジャイルに変えればすべてうまくいく、なんてことはありえません。二元論ではないのは承知しています。本書では、私が実際にウォータフォール開発からアジャイル開発へと移行した経験を元に記しました。
本書を読むことによって、変化し続けるチーム開発への移行の参考になれば、これほど嬉しいことはありません。

第2章 変化し続けるチーム開発 

願わくば、成⻑した彼らの将来、個のポテンシャルをあげて
我々が出せなかった答えを見つけだしてくれることを祈るばかりだ。
攻殻機動隊 STAND ALONE COMPLEX

2.1 チームは何のために仕事するのか 

この章では、チーム開発について、わたしの経験談を交えながらお話します。 

You know what I’d like to be? 

名も無き者へ
私の IT 業界の就業年数は、20 年弱です。思い返すと、様々なチームに参加して別れを経験してきました。
初めてチーム開発を経験したのは、学生時代アルバイトで、プログラマーとして小さなソフトウェアハウスで働いたときです。
バイトの目的は、お金が欲しかったからです。プログラマーの時給は、コンビニなどに比べると、かなり高い金額でした。大学で情報工学を専攻しており、自分で言うのもなんですが、プログラミングの腕前はそこそこデキる自信がありました。 

飽食の僕
しかし、コミュニケーション能力に問題がありました。ひとことで言えば、コミュ障でした。はじめてバイトに出社した際の自己紹介で、ガチガチに緊張して声が思うように出ず、周りは何も聞き取れなかったらしいです。
人と関わるのが苦手で、対人関係を構築することから逃げ続けていました。自分がコミュ障だと周りにバレるのもイヤで、「自分はビジネス上のコミュ力なら問題ないはずだ」という謎のプライドを持っていました。
社員の人とランチを一緒にするのが嫌で、お昼になると一人外に出て、コンビニでサンドイッチを買い、人気のない公園のベンチでモソモソと昼食を食べていました。公園に人目が多い場合は、トイレに隠れてランチ*1をとったこともあります。社内に居ても、どこか居心地が悪く、常に気の抜けない緊張した状態でいました。 

*1 いわゆる便所飯です。食べても音がしないゼリー系が便所飯におすすめです

天敵
バイト先では、先輩社員の I 氏とチームを組んで、作業を進めていました。I 氏は、営業や顧客 との打ち合わせで、外に出ずっぱりでした。I 氏含め社員は、スーツ着用が義務付けられていました。このクソ暑い真夏日に、ネクタイを締めて出社しているのを見ると、こっちまで汗をかきそう になります。私は、T シャツ、ジーパンでした。
私は、営業や顧客との打ち合わせなど、対人的なコミュニケーションが苦手でした。ですので、 対外的な作業はすべて I 氏に任せていました。
正直言えば、I 氏とのコミュニケーションも苦手で、彼との接触も最小限に留めていました。コミュ障特有の症状として、人とコミュニケーションをとって仕事をすすめることが大の苦手です。
なんとかして一人で作業が完結するように、わからないことがあっても周りに聞かない、質問しない、といったような縛りプレイをしていました。「わからない」と口に出してしまうと、周りに無能だと思われるのが怖かったからです。 

素食の晩餐
ほぼ一人で作業していたので、自分の中に「チーム感」といったものは、ありません。 時折、I 氏と周りの大人に誘われて、飲み会に参加したり、顧客との商談に連れて行ってもらったりしました。夜の繁華街の、きれいなお姉さんのいるお店に連れていってもらったこともあります。正直、なにが楽しいのか、さっぱり理解できませんでした。飲みの席にスゴイ美人が近くにいると、なんだか気疲れして、苦手なのです。コミュ障としては、ありがた迷惑だったわけですが、今思えば、いい経験をさせていただきました。
I 氏は、飲み会の席で、私にこう尋ねました。 「K 君って、プログラム書いてるときって楽しそうだよね、 好きなの」
――はい、と答えました。
「いいねぇ。でも、俺はプログラミング嫌いなんだよね。コーディングしたくない、苦痛でさ、だから K 君きて助かるよ」と、I 氏は、ごめんねのポーズをしながら言いました。
I 氏の言っていることの、意味が、わかりませんでした。
――プログラミングが嫌いなのに、この業界にいるなんて、正気か? と、バカにしたような想いでいました。
一方で、I 氏は、顧客から好かれており、契約や納期調整の場面で、抜群の能力を発揮していました。しかし、正直、I 氏の技術に対する意識の低さと、話が合わないこともあり、相談事は避けていました。
あるとき、会社の飲み会の席で、熱く盛り上がった I 氏がこう言いました。
「このチームの目的は、チームメンバーの幸せを通じて、運送業界を改革することだ。運送業界だけじゃない、おれらが幸せじゃなきゃ、意味ないだろ」
――急に熱くなっちゃって、どうしちゃんだ。ふーん、と思いながら、聞いていました。 

心の隙間
しらけたので、冷めた目で遠くを見つめながら、テーブルのすみっこで、ちびちびと烏龍茶を飲んでいました。
会社やチームのことは、どうでもよかったのです。自分のことしか考えていませんでした。
当時は、プログラミングに対して万能感を感じており、「自分一人でなんでもできる」と思っていました。
I 氏が、「プログラムでわからないことがあるから、教えて」と聞いてきた時がありました。私は、上から目線で、「こんなことも知らないんですか」口に出しそうなのをぐっと抑えて、しぶしぶ、やり方を教えていました。
I 氏は、「さすが K 君は、なんでも知ってるね、スゴイ」と、ワァーオといった表情で、目を丸くしていました。気を良くして、得意顔で、周辺知識やうんちくを、語っていました。若気の至りというか、うぬぼれですね。
しかし、実際、バイトで任されるコーディングの仕事は、自分一人の「独力」で、片付けていました。 

橋が落ちる日
しかし、このバイト先で大きな失敗をします。
私が自分勝手に作ったプログラムにバグがあり、大幅な作り直しを必要としたことでした。周りとのコミュニケーションを怠ったことで、仕様とは違う独りよがりなプログラムを作り出し、顧客や周りに迷惑をかけていたのです。
落ち込みました。今まで感じていた万能感は、吹き飛びました。 このときの尻拭いを、I 氏がコードの修正や顧客への謝罪まで含めて、すべてやってくれました。
自分のダメさ加減に嫌気が差して、出社するのがイヤになりました。 それでも、まずは、I 氏にあやまろうと思い、気力を振り絞って出社しました。 I 氏は、会社の入り口横の路地にある灰皿の前にいました。ここは、社内御用達の喫煙ルームです。
I 氏は私に気づいて、タバコをもみ消して、「よぉ」と手を上げながら、わたしを招き寄せました。 落ち込んで絶望の淵にいた私に向かって、I 氏はこう言いました。
「まぁ、あれだな。ミスは、K 君の責任じゃない。チームの責任だから。というか、俺の責任だ から。気にしないで」と、I 氏は、ごめんねのポーズをしながら言いました。
――ハンマーで、ガツーンと殴られた衝撃を受けました。

 
再起動
あとから聞いた話ですが、これまで私が"独力"で片付けていると思っていたプログラムは、不具合を連発しており、お客さんからもクレームがきたことも何度もあったそうです。
しかし、I 氏はそのことを周りに知らせることもなく、一人で現地に赴き、顧客に謝罪して、プログラムもその場で修正してくれていたそうです。さらにその対応がバツグンに素晴らしく、顧客からは高評価をもらっているとのことでした。
ずっと「一人」で開発してたものだと錯覚していたけど、実はそうじゃなかったのです。
初めて、「チーム」を実感することができました。 「いっぽん、吸う?」と、I 氏は私にタバコを勧めました。
もらった一本を口にくわえると、I 氏が持っていたライターをかざしてもらって、火をつけてくれました。私は、初めて吸うタバコに、げほげほ、むせながら、泣きそうになりました。
――あぁ、ここにいてもいいんだ、と、この場所に、帰属感が芽生えました。

私にとって「チーム」とは、ダメな自分でも受け入れてくれる、安心感がある場所になりました。
逆説的ですが、個人が勝手に単独行動をとってるつもりでも、チームとして上手く機能することもあるって、経験的に深く記憶に刻まれました。
私と I 氏は、何もかも違います。年齢、価値観、考え方、持っているスキル、見えている世界、 背負っている責任、すべて違います。社員とバイト、社会人と学生、スーツと T シャツ、違いのあいだには、大きな壁があるように感じていました。
しかし、チームとして働くためには、「「壁」は、実は、些末な問題なんじゃないのか」という思いが生まれました。 

そこにいること
その後、自分の中に壁を作っていることが馬鹿らしくなり、I 氏と一緒にランチに行くようになりました。
客先に出かける時は、一緒に連れて行ってもらうようにしました。
タバコも吸うようになりました。喫煙ルームの常連になりました。 コミュ障の自分が、最初の一歩を踏み出すのは、かなり勇気が必要でしたが、I 氏の支援があれば大丈夫だ、という安心感がありました。
一歩一歩、歩みを、前に進みながら、自分が変わっていくことが楽しくなっていたのです。変化 することの楽しみ方を教えてくれた I 氏には、今でも感謝しています。 

―――― 

この一ヶ月後、I 氏は突然会社に来なくなります。なんでも副業でやっていた先物取引で失敗したらしく、行方をくらましたんだと聞きました。
私は、I 氏の破天荒さが可笑しくて、怖かったことを覚えています。 仕事の「相棒」を失った私は、I 氏の代わりに営業や顧客との打ち合わせに出ざるをえませんで した。しかし、I 氏がいなくなったことは、逆にチャンスだと考えました。
「ちょっとレールを外れてみよう」と自然と思えました。 

――これが、私に「逸脱する精神が生まれた」はじまりでした。 

【コラム】『STAND ALONE COMPLEX』について
「攻殻機動隊 SAC」の「笑い男事件」における一連の社会現象に対して、草薙素子が名付けた造語。作中における電脳技術という新たな情報ネットワークにより、独立した個人が、結果的に集団的総意に基づく行動を見せる社会現象を言う。孤立した個人(スタンドアローン)でありながらも全体として集団的な行動(コンプレックス)をとることからこう呼ばれる。

♣ あなたは何をする人ですか? 

それで、あなたは何をしている人なんですか?
カイゼン・ジャーニーより

あなただったら、この問いになんと答えますか。
この問いに答えることは、なかなか難しいことです。 

•「コードを書く人」
•「デザインをする人」
•「スケジュール管理をする人」
•「顧客との調整をする人」 

チームで開発するということは、この問いに答えるということです。
この問いに答えて、はじめてチームの一員として認められるのです。
チームの中で、自分は何をして価値を出すのか。
バイト時代ずっと、自分は「コードを書く人」なんだと思っていました。
バイトの目的は、遊ぶお金ほしさでしたので、コードを書いてお金をもらうことができれば何でもよかったのです。 

おまえたちには給料分しっかり働いてもらう
攻殻機動隊 STAND ALONE COMPLEX 第5話

♣ 壁と境界と越境

逆に言えば、コードを書きさえすれば、他は何もしたくないとも思っていました。
デザインも、スケジュール管理も、顧客との調整や交渉事も、御免でした。
このような考え方が、人と人との間に「壁」や「境界」を作り出します。「壁」はどこでもあるし、「壁」があるからこそ安心して働けたりする側面もあります。
私自身を振り返ってみると、「壁」を壊していくことは不可能だと考えていました。ずっと壁の内側に籠もって、安全に暮らしていこうと考えていました。しかし、その考えは、今ではまったく逆の方向に変わりました。 

自分の役割を固定化することを、止めたのです。

【コラム】理想のチームは「公安 9 課」
攻殻機動隊の「公安 9 課」のチームメンバーは、
• 近距離対人戦であればバトー
• 現場捜査や交渉が得意なトグサ
• 遠距離射撃であればサイトー
• 電脳戦であればイシカワ&ボマー
• なんでもできる少佐
といった感じで、得意分野によって、ある程度の役割分担が存在します。
しかし、これらはあくまで定番的な配置というだけであって、各メンバーの役割が固定化しているわけではありません。
近距離対人戦は、バトーが最も得意とするところですが、必要であれば電脳戦もこなします。 公安 9 課には、
• 上流工程と下流工程
• フロントとバックエンド
• マネージャと現場作業員
といった切り分けは、存在しないのです。
その時の現場の状況や情報を元に、自らフロントに立ったり、バックアップに回ったりと臨機応変の連携を見せます。
個々のメンバーが、得意分野のスキルありきで業務にあたるのではなく
「現場の状況に応じて、最適なやるべきことをやる」
という話が描かれているのです。 

♣ 納期を守るためのチームという悪夢 

ちゃんとしたチーム開発をしたのは、社会人になってからです。
最初に就職した会社は、受託開発をしている、いわゆる中小 SIer でした。この会社で、2、3 人 のチームから、10 人超えのチームまで、さまざまなチームに所属しました。
チームには、優秀な人もいれば、あまり役に立たないサボってばかりの人もいます。各人の仕事に対する姿勢や、価値観も様々です。
私が所属したチームには、生産性が高くソフトウェアの品質も高い優秀なチームもあれば、常に炎上していて疲労困ぱいなダメチームもありました。
受託開発をしているチームで共通しているのは、「納期」の存在です。
チームの共通の目的は、納期を死守することでした。もちろん、成果物のプログラムの品質にも気を配ってはいました。

しかし、納期を守るために品質を犠牲にしたことは、しばしばあります。「バグ」を「仕様です」と言い切り、納品にねじ込んだことも、ままあります。
納期を守れないと、顧客と結んだ契約を、反故にすることになります。ですので、納期の遵守は絶対であり、最優先事項です。成果物が、どんなに使いにくくて、遅くて、ゴミクズでも、納品を納期通りに済ませれば、チームとしての目的は達するのです。 

すべてが同じ色に染まっていく。
攻殻機動隊 STAND ALONE COMPLEX 第 6 話 

チームとグループの違い
チームと、ただの寄せ集めのグループを、分かつものは何でしょうか? それは、共通の目的があるかどうかです。共通の目的がない集団は、チームではなくグループです。はたして「納期を守る」ことは、共通の目的でしょうか? これは目的ではありません。 

意義や目標がなければ作業の奴隷になる
「納期を守る」ことは、契約上の決めごとで、外部から強制されるものです。このような強制された目的は、チームに「やらされ感」をもたらします。やらされ感は、チームのモチベーションを下げ、チームメンバーは、作業の奴隷と化します。チームメンバーが、作業の奴隷になっている状態は、もうチームとは呼べません。目的を見失ったチームは、烏合の衆であり、グループです。
チームがチームとして成立する目的には、「自発的な目的」が必要です。このとき、チームのメンバーが、「自発的な目的」に合意している必要があります。 

自分たちで最適な目的目標を設定する
自発的な目的とは、例えば、「使い勝手を良いソフトウェアを作る」です。チームメンバーが、自発的な目的に合意している状態が、本当のチームです。このとき、もちろん納期を守る必要もあります。いくら使い勝手が良いものを作っても、納期を一ヶ月もオーバーするようでは、顧客の信頼を失ってしまいます。限られたリソースの中で、より良いものを作るために、各人が共通の目標の達成に向けて協調する集団が、チームです。 

♣ プロダクトに意味付けできるチームが強い

チームの共通の目的には、「意味付け」ができると良いです。「使い勝手の良いソフトウェアを作る」では、意味付けが不十分です。意味付けをするには、ストーリーを語ることが必要です。例えば、「使い勝手の良い社員給与管理システムを作って、経理の仕事に関わる人の生産性をアップする」といったものです。ストーリーには、登場人物が必要です。ユーザがソフトウェアをどのように使い、使った結果どうなるのか、ということをストーリーとして語ると、チームの目的が具体的にイメージしやすくなります。共通イメージを共有したチームは、より強固なチームワークを得ることができます。

プロダクトに意味付けできない開発スタイル
しかし、多くの SIer の現場では、プロダクトに意味づけできない開発スタイルで仕事をしてい ます。これがウォータフォール開発です。SIer では、エンジニアを、ただの作業労働者としてみなす働き方を強要されます。チームの自発的な目的など、必要ないのです。プロダクトの使い勝手など、どうでも良いのです。そんなものをチームで勝手に設定されては困ったことになります。言われたとおりに期日を守って作業する、SIer で求められるのは単純労働作業であり、人間の創造性の余地は少ないです。
チームが自発的に目的を設定し、自発的に動き、学習していくことを自己組織化といいます。私は多くの SIer のウォータフォール型チームで働いてきましたが、自己組織化できているチームを見たことがありません。日本中探せばどこかにはあるのかもしれませんが、私の観測範囲では存在しませんでした。 

アジャイルとウォータフォールの違いは不確実性との向き合い方 

現在、私は Web 系のアジャイルチームで仕事をしています。アジャイルチームでは、自己組織化が進んでいます。アジャイルチームは、外部からの圧力でやらされ仕事をこなすのではなく、仕事に意義を見出して、日々楽しくプロダクトを作っています。SIer にいた頃とは、大違いです。
この違いの源泉は、いったい何なんでしょう。それは不確実性に対する向き合い方です。

不確実性とは「わからないこと」
不確実性とは、「わからないこと」です。アジャイルは「わからないこと」に対して、「今はわからないけどやってみればそのうちわかるでしょ」という姿勢で、問題と向き合います。
一方、ウォータフォールでは、「わからないこと」に対して、「わかってるふり」をします。要するに、知ったかぶりをして誤魔化すのです。
チーム開発における「わからないこと」とは、いったいなんでしょう。それは、「人」と、「未来」です。 

「人」はわからない
ウォータフォールでは、人月 (にんげつ)という考え方で、「人」に対して「わかってるふり」を します。人月では、「人」は 1 ヶ月にこれぐらいのコードを書ける、というのを「わかってるふり」をして、見積もりを行います。システムの開発を受注する際、この人月に応じて、顧客に費用を求めます。
例えば、3 人が 5 ヶ月かけてシステムを開発する場合、「3*5=15 人月」の工数がかかるという表現をします。1 人月が 100 万円だとすると、1500 万円でこのシステムを受注することになります。人月で表現された「人」とは、ただの頭数を揃えるための作業労働者であって、個人としての人柄や性格、能力やスキルは関係ありません。ウォータフォールの現場では、日々「他人」が増えていきます。

人月というくくりの中では、「人」は、機械と同じで取替可能だからです。「人」を「わかっている」状態は、言い換えると、人をコントロールして「支配」している状態です。会社としては、人月を売ってしまえば、誰がやっても月 100 万円稼げるのです。もちろん、自分自身も例外ではありません。
ですので、会社はあなたを徹底的に支配下に置き、「わかっている」状態を維持するためにコントロールしようとします。会社としては、人月の頭数を揃えるためだけにあなたを重宝しますが、体を壊したり使えなくなった途端に、ポイッと捨てられます。
一方で、アジャイルでは、「人」は、わからない「他人」だけど、対話を深めてわかり合っていけばいいよね、いつか「仲間」になれれば良いよね、という姿勢でチーム開発を進めます。 

「未来」はわからない
ウォータフォールでは、「未来」に対しても「わかってるふり」をします。先程の、3 人が 5 ヶ月 かけてシステムを開発する場合の見積もりの場合、なぜ「5 ヶ月」で開発が完了するのかという根拠は、見積もりの段階では本当のところは誰にもわからないからです。そもそもシステムの発注時点では、「何をつくるのか」わかってないことも多く、要件は未確定です。「未来」がわからないのに、「5ヶ月後にはシステムが完成している」「何をつくるのかもよくわかってないけど」という矛盾を抱えて、エンジニアは疲弊していくのです。
SIer では、ものづくりに対しても、より良いプロダクトを作ろうとか、ユーザに価値を提供しようなんて考えないのです。「5 ヶ月後」に「言われたものが言われたとおり」にできている必要があるだけなのです。
一方で、アジャイルでは、「未来」はわからないけど、実際にやってみて、やりながら経験を経て、進むべき方向を見定めて、一緒にやっていけばいいよねという「共創」の姿勢でチーム開発を進めます。 

人類に「予測」するのは早すぎる
人類には、まだ、未来を見通す能力はありません。つまり、予測することは「人類の弱さ」と言えます。ですので、アジャイルでは、予測に頼る割合を減らしています。予測を 0 にして、全パターンを試すわけにはいかないので、「こうなんじゃないかな」という仮説に基づいてシステムを実装し、実際に世に出してみてフィードバックを見ながら検証し、その経験をもとに開発をすすめます。

2.2 なぜ日本ではアジャイルが普及しないのか 

世界でアジャイル開発は、9 割の IT 企業で採用されています。一方、日本ではわずか 3 割程度だと言われています。SIer では、業務システムの受託開発が主流のため、アジャイルな開発スタイルは導入しづらい部分が多いです。そのことを考慮しても、この数値は低いです。低すぎます。
日本でアジャイルが普及しない理由、それは「わからないこと」から逃げているからです。これは、「日本人の弱さ」と言えます。前述したように、これまでウォータフォール開発では、「わからないこと」に対して、「わかってるふり」をし続けてきました。つまり、「わからないこと」に対して、向き合わずに、ずっと回避してきたのです。
ソフトウェアは、開発してみて、初めて失敗に気付くことが多いです。プログラムを書いてみて、ユーザーからの反応をふまえて、設計から見直すことがよくあります。これは、アジャイル型の開発の本質です。一度先に行ったものでも、おかしいと思えば、前に戻ってやり直すのが当たり前です。
昔、筆者は、まともに付き合った経験もないくせに、「彼女なんて、めんどくさいだけだから、ほしくない。今は、自分の時間を大事にしたい」と言っていました。わからないことに対して、わかってるふりをして逃げていました。なぜ逃げていたかというと、わからないことに対して一歩踏み出すのは、リスクを伴うことだからです。例えば、女性に対して「付き合ってください><」というのは、断られて自分が傷つくリスクがあります。
そういったリスクを回避をするために、逃げ回ってる状態が、これまでの SIer であり、ウォータフォール型の開発です。 

わからないことを、「わからない」という勇気 

一方で、アジャイルでは、「正直、おれ、一回も女性と付き合ったことないから、どうしていいかよくわからん。とりあえず、一回付き合ってみない。うまくいくかはわからんけど」みたいな感じで、まず行動してみて、その結果と経験を得て、次のアクションを決めていきます。
「わからないことは、わからない」と認めるのは、勇気のいることです。わからないまま一歩踏み出すというのは、何らかのリスクを伴います。しかし、そのリスクから逃げないで、一歩踏み出すのがアジャイルなのです。
日本では、国⺠性なのか、リスク回避する傾向が強いです。アジャイル開発で、リスクをとって踏み出す方式が、日本の風土に合わないのではないでしょうか。
しかし、ここで考えてほしいのは、「リスクを回避する」ことのリスクです。リスクから逃げ回ってる事自体が、大きなリスクを生んでいるのです。
実は、リスクを負って、一歩踏み出したほうが、リスクが低いのです。 

エンジニアリングとはアジャイルである 

エンジニアリングとは、技術を用いて、何かを作り出すことをいいます。エンジニアリングするということは、「わからない状態」から「具体的ではっきりとした状態」に変えていく行為です。
「わからないこと」を実際に行動し、その結果や経験から「わからないこと」を減らしていく、ということです。つまり、エンジニアリングすることと、アジャイルになることは、似通っています。
「変化を許容しない」ウォータフォール開発では、エンジニアリングすることは不可能なのです。

ウォーターフォールからアジャイルへ移行できていない企業 

近年、企業は、「ウォータフォール開発をしていてはダメだ」ということに気づき始めています。
日本でも、ウォータフォールからアジャイルへと移行しようとする企業が、増えています。しかし、アジャイルへの移行は難しく、移行が失敗するケースが多いです。そもそも、「なぜ、アジャイルに移行しなければならないのか」という問いに対して、理解がない企業が多いためです。ウォータフォールという慣れ親しんだ方法があるのに、そんなあやふやで行き当たりばったりの開発手法を用いなければならないか、企業の上層部まで理解させるのは、至難の業です。
SIer のソフトウェア開発の世界では、しばしば「工場」が比喩として使われます。「工場」で、「プログラマー」が「作業員」として、製品を作っているイメージです。 しかし、この考え方は、間違っています。
「工場」というのは、チームで切磋琢磨しながら、勤勉に品質を向上させていきます。この比喩は、エンジニアを「工員」や「肉体労働者」としてとらえているのだと思いますが、ソフトウェア開発は、本来、研究や頭脳労働なのです。
「工場」で「作業員」にソフトウェアを開発させようとすると、結果的に、
「アジャイルなんて適当で曖昧なやりかたはダメだね」
「ほら言ったじゃないか、やっぱりウォータフォールでしっかり厳密に管理しないと開発はうまく回らない」
ということになって、もとに戻ってしまうのです。 

いつまでウォーターフォール開発やってるんだ問題
SIer は、ウォータフォール開発をいつまで続けるのでしょうか? ウォータフォール開発を続けることは、「人」と「未来」という「わからないこと」から逃げ続けることを意味します。一方で、アジャイル開発を採用している企業は、「わからないこと」に対して、何度もトライを繰り返して、その失敗の度に学びを蓄積していっています。この蓄積の差が、数年後、絶望的な差を生み出します。

濁流に飲み込まれて滝つぼに落ちる
ウォータフォール開発を続ける SIer が、行き着く先は、奈落の底です。
南アメリカ大陸の北部に、ギアナ高地という場所があります。そこには、山頂が平らなテーブルマウンテンが続いています。ギアナ高地には、多様な動植物が暮らす豊かなジャングルが広がっています。
そして、ジャングルを抜けた所に、世界最大の落差を誇る滝、「エンジェル・フォール」があります。SIer は近い将来、このエンジェルフォールから滝つぼに、真っ逆さまに落ちていくのです。 現在大手 SIer に所属している人は、ギアナ高地の平らなテーブルマウンテンで、下界を見下ろしながら、優雅に暮らしているのかもしれません。しかし、その平穏な生活も終りが近づいてきています。

SIer は近い将来淘汰される。 

滝つぼに落ちる前に、SIer で働いているエンジニアは、今すぐ逃げた方がいいですよ。 「人月」と「工数」を売ってきた従来型の SIer ビジネスは、ウォータフォールを前提としています。これまで日本の SIer 業界は、「人月」と「工数」を、「人」と「未来」という「わからないもの」を、わかってるふりをして、ビジネスをやってきました。
しかし、その収益構造はすでに限界に達して、大手 SIer の粗利率を見ても、下がる一方です。つまり、儲かっていないのです。
儲かっていない原因は、人月の単価が下がっていることと、そもそも人手不足で、人月を売ることができないことです。

NEC と富士通が実施した事業売却と人員削減
国内で約 2 万 4000 人を削減. 売上は 20 年で半減 2 社は IT バブルに沸いた 2000 年以降、 国内の人員削減を繰り返してきた。18 年には NEC が 45 歳以上を対象に早期退職を募り、同 年末には 2170 人が会社を去った。富士通は 18 年秋から間接部門の社員の直接部門への配置転 換を進めた結果、2850 人が 19 年 3 月末までに早期退職した。00 年以降の国内の人員削減数は NEC が約 1 万人、富士通が約 1 万 4000 人に及ぶ。

NEC と富士通の 2 社は 20 年間で売上高が半分近くに
2000 年 3 月 期 を 基 準 に し た 10 年 3 月 期 と 19 年 3 月 期 の 業 績 https://business.nikkei.com/atcl/NBD/19/00117/00048/

SIer からユーザ企業へ⺠族大移動
収益が下がった結果、富士通や NEC など大手 SIer では、大規模なリストラが行われています。 近年、エンジニアが、大手 SIer からユーザ企業に移るという、ある種のブームが起こっていま す。「完全 SIer 脱出マニュアル」という書籍も、ブームを後押ししています。
日本では、IT 人材の 75 %が、SIer などの IT ベンダーに所属しています。しかし、アメリカで は、IT 人材の 74 %がユーザー企業に所属し、自社システムの構築・運用を行っています。つまり、日本とアメリカでは、構造が真逆といってよい状況です。
しかし、この SIer 脱出ブームが契機になり、SIer からユーザ企業へ、⺠族大移動が起きようとしています。というか、今まさに起きています。 

ウォーターフォール型チームでの働き方は死滅する
今後、SIer が消滅の方向に向かっていくと、ウォータフォール型の働き方もまた、消滅してい くでしょう。これは、良い悪いの話ではなく、世の中の流れが、SIer 消滅に向けて動き出しています。事実なので、どうしようもありません。ユーザ企業で求められるのは、自社プロダクトの開発・改良、そして価値を提供することであって、「人月を売ること」ではありません。仕事の関係性として「発注・受託」という関係から、「共創・共育」という関係に、シフトしていく必要があります。上から与えられた仕事を、言われた通りにこなすだけで安泰の時代は、終わります。 

2.3 プロジェクト型開発からプロダクト型開発へ 

ユーザ企業がソフトウェア開発に本腰を入れるために必須なのが、内製化です。開発を外部に発注していては、良いソフトウェアを生み出すのは難しいです。
外注先の企業で、より良いプロダクトを作ろう、ユーザに価値を提供しよう、なんて考えないのです。そんなことをしても、外注先にとってはインセンティブが働かないからです。外注先の企業 が気にしているのは、プロジェクトを期日 (納期) までに終わらせるということ「だけ」です。
よって、内製化を進めるユーザ企業では、ソフトウェア開発は「プロジェクト」という形態ではなく、「プロダクト」開発形態に進化しています。
プロジェクト型開発は、プロジェクトマネージャ (PM) の絶対君主制によって、プロジェクトの進捗を管理し、計画に従うように指揮されます。
プロダクト型開発は、プロダクトマネージャ(マーケティングに強い)と、開発チームのテクニカルリードのペアによって、指揮されます。 

プロジェクト型は終わらせるのが目的

プロジェクト型開発は、始まりがあって、必ず終わりがあります。
その限られた期間の中で開発を終了させるのが目的となってしまい、顧客が求める本来の目的、つまり、プロジェクトで作られたシステムを有効利用することで顧客のビジネスを成功させるという観点が抜け落ちてしまいます。
実際、プロジェクトが始まったら、開発で手一杯で、まともに動くシステムに持っていくだけでも死にものぐるいでやっていく必要があります。ウォーターフォール型開発で一発リリース直後の システムは、バグだらけで開発チームも顧客もアップアップな状況の方が多いのです。SIer のプロジェクト型の受託ビジネスが、現代のビジネスにマッチしなくなっています。ビジネス価値に直結しないクソシステムがどんどん作られているのではないでしょうか。官公庁のシステムとかヒドイ ものです。顧客に何も価値を生み出さないプロダクトを開発しても、SIer は何も問題ありません。
プロジェクトを契約通り終えさえすれば、莫大なお金が入ってくるからです。プロダクトの良し悪しなんて知ったこっちゃないのです。
プロジェクトを成功させることと、ビジネスで成功するのが完全に一致していないのが問題なのです。

プロダクト型は継続するのが目的

プロダクト型開発でも、始まりと終わりは必ずあります。しかし、プロダクト開発では、開発が終わってもらっては困るのです。それは、プロダクトの死を意味するのですから。
プロダクト型と、プロジェクト型とのあいだには、大きな違いがあります。

2.4 ユーザ企業の内製化にはアジャイルチームが必要

プロダクト型開発では
「開発を終わらせないために、顧客に価値を提供し続ける」
という目的が存在します。
つまり、開発が継続するためには、開発したプロダクトが顧客に価値を生み出し続ける必要があります。誰も必要としないプロダクトを生み出してしまうと、即死です。
この場合、プロダクト開発を成功させることと、ビジネスで成功するのが完全に一致しています。 

渦を作るしか生き残る術はない
滝つぼに落ちたくないのであれば、その手前でうずまきを作るしかありません。一方的な流れ に、スパイラルを生むのです。流れに逆らって渦を作り出した者だけに、SIer 脱出の出口が見えてきます。

2.4 ユーザ企業の内製化にはアジャイルチームが必要

組織にスパイラル構造をもたらすために、アジャイルチームが求められています。ユーザー企業でのソフトウェア開発業務は、すでにメイン業務の一部となりつつあります。これまでのように、本業の「おまけ」でソフトウェア開発をしていては、市場での競争力を失いかねません。そこで、 多くのユーザ企業で内製化に向けたエンジニアの囲い込みが加速しています。SIer からユーザ企業へと⺠族大移動が起こっているのです。

アジャイルだと 3 倍の成功率、1/3 の失敗率

ウォータフォールとアジャイルの成功率を比べてみると、アジャイルの方が 3 倍成功率が高い、という統計結果があります。
http://blog.mountaingoatsoftware.com/agile-succeeds-three-times-more-often-than-waterfall
ウォータフォールからアジャイルに切り替えた成功例として、アメリカの FBI のシステム「センチネル」があります。「センチネル」は、3 万人以上の FBI 捜査官が利用する超巨大システムです。「センチネル」の開発見積もりは、約 540 億円という莫大な値段でした。完成予定は、3 年後 の 2009 年 12 月でした。
しかし、システムの完成予定を大幅に超えた 2010 年 7 月。このプロジェクトは、中止に追い込まれました。理由は、完成予定日を大きく過ぎても、当初予定していた機能の半分しか完成していなかったのです。
この時に採用された開発手法は、ウォーターフォールでした。
しかし、一度は中止されたこのプロジェクトを、アジャイルに切り替えたことによって見事に完成に至りました。悲劇のプロジェクトは奇跡のプロジェクトとして語り継がれるようになりました。驚くべきことに、システム完成に費やした時間はたったの 1 年です。費用は、当初の 10 分の 1 以下の約 30 億円でした。

大規模開発でもアジャイルが有効 

上記の例の FBI のシステムは、かなり大規模です。大事なことは、「大規模な開発」であってもアジャイル開発は有効ということです。
アジャイルは「大規模な開発」には向かないという誤解がありますが、そんなことはないのです。むしろ、大規模だからこそアジャイルでやるべきだという意見もあるくらいです。大規模になると、ウォータフォールの後工程における失敗が致命傷になりやすいのです。アジャイルで小さく失敗しながら前に進むほうが、実は確実なのです。

アジャイル型人材の必要性が高まっている

アジャイルチームを作るためには、アジャイル型の人材が求められます。 2019 年、ユーザ企業だけでなく、SIer 各社もアジャイル人材獲得に乗り出しています。逆に言えば、「アジャイルじゃない人材」は、これからの時代、どこからも必要とされないことを意味しています。

2.5 認知フレームの問題

とりあえずアジャイル開発を導入してみたものの、思ったような成果が出ないと不満を感じているチームは多いです。では、アジャイル開発から、本当の意味で成果を生みだすには、どのようにしていけばいいのでしょうか。このとき、問題になるのが、認知フレームの問題です。
人は物事を認識するために、ある種の色眼鏡をかけて物事を見ています。この色眼鏡のことを「認知フレーム」と言います。この認知フレームは強力で、簡単に現実を歪ませます。
SIer のウォータフォール開発は、歪んだ認知フレームに支配されています。計画や契約を完遂するために、「人」と「プロダクト」を犠牲にしても構わないという色眼鏡を強制的にかけさせられているのです。これは、ある種の洗脳です。 

過去のウォータフォールでの成功体験が邪魔している

ウォータフォールからアジャイルに移行するためには、この認知フレームを書き換えなければなりません。これを、「リフレーミング」といいます。 

リフレーミングする必要がある
アジャイルというのは、エンジニアになんらかの「変化」を求めます。最大の変化は、「心の変化」です。アジャイルには、基本となるマインドセットや姿勢はありますが、やり方そのものの教科書があるわけではありません。つまり、現場や市場の状況に応じて、何かを自発的に探求していく姿勢が求められるのです。

ウォータフォールのフレームを外す必要
アジャイルのマインドセットにリフレーミングする際、過去に経験したウォータフォールの認知フレームが邪魔をします。
ウォータフォールそのものが、「変化」や「失敗」を嫌うからです。アジャイルでは、「変化」や「失敗」を許容します。
このマインドセットの両端を、急にくるっと正反対にすることは、なかなか難しいことです。
まずは、ウォータフォールの認知フレームを外してください。ウォータフォール開発では当たり前だと思っていたことに、疑問を持ってみてください。客観的な視点を持つことによって、はじめて洗脳が解けます。

2.6 リフレーミングでチームの働き方を変える

認知フレームを書き換えると、働き方が変わります。アジャイルな状態になると、「人」と「プ ロダクト」が大事な価値観に、脳の認識が書き換えられます。SIer における、いわゆる IT 土方的なブラックな働き方は、できなくなるということです。

会社や組織は変えにくいが、チームのメンタルセットは変えやすい。

会社の「組織改革」はチームのメンタルセットを変えてから
会社をアジャイルに「組織改革」をするには、手順を間違えないことが重要です。
チームのメンバーが受け身ではなく、チームの目的のために自主的に動く状態を作ること。これが最重要ポイントです。
つまり、チームの「メンタルセット」が変わらない限り、アジャイル開発しようとしても、うまくいきません。
アジャイルに組織改革をするうえで、以下のようにする会社は多いです。

• 単に上司を変えたり、チームメンバー変更をしたりするだけの会社。
• 会社から補助金を出すから、定期的にランチ会をやりなさい、1on1 やりなさい、勉強会やりなさい、飲み会を開きなさい、と促す会社。
• 社内情報共有を促進するためにコミュニケーションツールの導入や、タスク管理システムの変更をする会社。

しかしながら、どれもチームのメンバーが受け身であったら、機能しない仕組みばかりです。
手間暇かかることに忍耐強く向き合うことを、人は尊いと受け止めるものです。てっとり早く問題を解決しようとする姿勢は、軽視されます。
あなたがチームのメンバーと対話する姿勢を持つことさえできれば、チームのメンタルセットを変えることはたやすいのです。

2.7 変化し続けるチーム vs 硬直するチーム

ここまで、「変化し続ける」ことがチームにとって重要だということを述べました。
チームがアジャイルになり「変化し続ける」ことの重要性をご理解いただけたかと思います。
繰り返しになりますが、 世の中の移り変わりが激しい現代において求められるのは「変化し続けること」です。
アジャイル開発を導入することはチームに変化を促す最善の方法だということは世界のスタンダードであり周知の事実です。
さて、逆に駄目なチームとは、いったいなんでしょうか。

答えは、変化できないチームです。

 日本の SIer にはびこる「硬直するチーム (Solid State Team)」のことです。(本書では、変化 できずに「硬直した状態」を「Solid State」と呼びます)
前述したように、チーム開発には正解がありません。しかし、「明らかな不正解」は存在します。
それが「硬直するチーム」です。「硬直するチーム」になりたくないですよね。
そこで次章では、「硬直するチーム」の例を、わたしの経験談を元に説明しております。

第3章 Solid State Teamには近づくな

この国はいい加減、誰かが何とかしなければいけない状態に来ている。
六百万を超える貴腐老人、
失業率の増加と反比例するように減少を続ける労働人口、
そして少子化。
挙げ始めたらきりが無い。
知っているか?
これだけ少子化が叫ばれる中、 年間五万人もの 6 歳未満の子供が無意味に命を落としている事を。
攻殻機動隊 STAND ALONE COMPLEX Solid State Society 

本章では、SIer でのウォータフォール開発からアジャイル開発への移行の難しさをストーリー仕立てで説明します。
前章では、「変化し続けるチーム」が、これからの時代に求められていることを十分にご理解していただけたと思います。
この章では、逆に「変化できないチーム (Solid State Team)」の具体例として、過去に著者の所属したチームを書いています。
チーム開発のアンチパターン集として読んでもらえれば嬉しいです。

この物語は、筆者の体験に基づくフィクションです。
登場する人物・団体・ 名称等は架空であり、実在のものとは関係ありません。

3.1 登場人物 

登場人物は、わたし (=K) 以外は、すべて架空の人物です。 

K
中小 SIer コスモサードエンジニアリングに勤める 6 年目 主任 PL(プロジェクトリーダー)。 Java が得意。Rails はチュートリアルを一通りやった程度。アジャイル開発を勉強中。趣味はアニメ・ゲーム。

溝口くん
同じくコスモに勤める 2 年目の若手エンジニア。スポーツマンでガタイが良い。趣味はバスケと釣り。

二見さん
同じくコスモの副課⻑。マネージャで冷酷クールおじさん。二児の父でもある。趣味はゴルフ。

梶浦さん
協力会社 - 皮肉屋。かなり大雑把な性格のおじさん。

アーニャ
協力会社 - ロシア人エンジニア。独特の変な日本語を使う。日本酒と日本のアニメが好き。

⻑田さん
大手メガベンチャー「スタシス」のクリエイティブマネージャ。高級腕時計のコレクションとテニスが趣味。

渋谷さん
スタシスの UI/UX デザイナー。新卒一年目。期待の若手。

池上先生
スタシスお抱えの技術顧問。世間的には有名な人。よくブログがバズっている。

3.2 曖昧性と不確実性との戦いが、いま、はじまる 

渋谷駅ハチ公前の喫煙所*1にて、ヤニ臭さが立ち込める中、フゥーと煙と一緒にため息をはいた。
ギラギラとした雑踏を眺めながら、缶コーヒーをぐいっと飲み干した。
これから「監禁部屋」に戻ると思うと、クラクラして吐きそうになった。
ツンっと、ドブ川がくさったような臭いがした。 K は、プロジェクトのことで悩んでいた。 

――悩みのタネは、「スカーレット」のリプレイス案件のことだった。
ぼくは、コスモサードエンジニアリング (以降、コスモと略す) という中小 SIer に勤めている。 一ヶ月以上前、大手ベンチャー企業「スタシス」にコスモの社員 3 人で訪れた。 真夏日で最高気温が 32 度を超えていた。TV ニュースでは熱中症対策を万全にするよう呼びかけていた。
コスモでは客先に向かう際は、スーツ着用を義務付けられていた。さすがに夏はノータイ&ノージャケットで良いのが救いだ。
打ち合わせの目的は、「スカーレット」のリプレイスについて、RFP*2の内容についてである。 「スカーレット」は釣り用品の EC サイトである。
RFP とは提案依頼書のことで、システムの開発や業務委託を行うにあたり、発注先"候補"の事業者に具体的な提案を依頼する文書である。システムの目的や概要、要件や制約条件などが記述されている。「発注先候補」というのは建前で、事前に「内々定」をスタシス側からいただいている。
溝口くんはスタシスのビルに来るのは初めてで、入り口のところで、周囲をキョロキョロしていた。溝口くんに声をかけ、ギンギラしたビルのエントランスのなかに入った。 

溝口くんは「すごいっすね」を連発していた。

*1 渋谷駅前で愛煙家が集う有名な場所。現在は閉鎖されています
*2 Request for Proposal(提案依頼書)の略

ぼくは以前のプロジェクトでスタシスに常駐した経験があったので、このビルの風景には慣れっこだった。
吹き抜け構造になった外窓から日差しが大理石の床に反射して、小川の流れのようにさらさらと涼しげだった。
溝口くんは受付嬢のふんわりしたお姉さんを見て、顔がにやけていた。 

溝口「K さん、あの子、よくないですか?」 

ぼくは、受付に置いてある Windows 端末がメモリダンプを吐き、真っ⻘になって死んでるのが気になっていた。
そんな注意散漫なぼくら二人に対して、スーツをビシッと着こなしたマネージャの二見さんが腕時計を指差しながら近づいてきた。二見さんは、おそらく先に着いて、ぼくらを待っていたのだ。
二見さんは、開口一番にぼくらに向かってグワッと吠えた。 

二見「おいっ、30分前には集合と伝えたはずだ。これじゃビルで待ちわ『びる』だぞ」 

顔を合わせるなり、二見さんは、ぼくと溝口くんに説教をはじめた。
二見さんは、時間に厳しいことと、つまらないオヤジギャグで有名で、社内では「ナビタイムおじさん」という異名を持っている。

K「すいません、電車の遅延で遅れました」

溝口「同じく、電車がおくれちゃいまして...」

二見「時間厳守。今回は、集合時間を 30 分前に設定したからよかったが、おぅっ、と、先に入館許可手続きしないと......お前らも一緒に来い」

二見さんが受付にチャカチャカ小走りに駆けていった。ぼくと溝口くんもバタバタ後に続いた。

溝口「(......でも、見てくださいよ。まだ、15 分前ですよ)」

受付を済ませて、二見さんがぼくらを睨んで、手を前に突き出して言った。

二見「今日の打ち合わせでは、わたしがメインでしゃべるからな。K と溝口は余計なことをいうなよ」

スタシスは、「スカーレット」を自社開発している大手ベンチャー企業だ。業界では有名大手ベン チャーとして、IT 業界ピラミッドの上層部に位置している。「スカーレット」の他にもソーシャルゲームなどを手掛けている。

視覚素子は笑う
ぼくらは 770 会議室に通された。
そこで、スタシス側の担当者である、⻑田さん、渋谷さん、と挨拶を交わした。 ⻑田さんは、これまでも自社 Web サービスをいくつも担当しており、この手のプロジェクトはお手のものという感じだった。名刺の肩書には、

インテリジェントソフトウェアエンジニアリング
イノベーショングループ9課
クリエイティブシニアマネージャ

という肩書が書いてあった――さすがに、⻑すぎだろ......日焼けした肌と腕に輝く高級腕時計がギラギラして眩しかった。

⻑田「へんな話、コスモさんのとことは⻑い付き合いですからね、今回も頼りにしてますよ〜」

ガハハと笑う声とピカピカの白すぎる⻭が高貴な感じがした。人に媚びるようでもない。粗にして野だが卑ではない、という感じだった。

渋谷「メインで UI デザインを担当します。ユーザー目線で使いやすい UI を目指したいと思っています」

渋谷さんは、鈴の鳴るような声で表情を変えずに軽く挨拶した。背が高くスラッとしていて、⻑い髪のあいだからみせる表情は冷たく感じた。⻑田さんとは対照的に、全体的に白っぽくてそこだけ雪が降っているようだった。ピンクゴールドのおしゃれなネイルの指先がビームライフルのようだった。

⻑田「渋谷はメインでデザインを担当するのはこれが初めてですので、みなさんにご迷惑をおかけすることもあるかと思いますが、ぜひともご指導ご鞭撻のほどを」 

⻑田さんと渋谷さん、二人を前にすると、夏と冬が同時に同居している感じがした。

⻑田「ごほんっ、えー、早速ですが、RFP にも記載しました通り、今回スカーレットのリプレイスについてコスモさんにお願いしたく」

プロジェクターに映し出された RFP の最初のページを指しながら、⻑田さんが説明をはじめた。

⻑田「ここまでで、コスモさんから、なにか質問ありますかね」

二見「Web ベースで Ruby on Rails を用いるということですが、なかなか思い切った選択ですね」

当時、この手の Web システムは PHP を使うのが主流だった。Rails を使った開発は珍しかった。

K「Rails を選定した理由はありますか? PHP の方が一般的だと思うのですが」

一瞬、二見さんが僕の方をキッと睨んだ気がしたが、意にとめなかった。

⻑田「イイ質問ですねー、かいつまんで、早い話、現行のスカーレットは PHP の独自フレームワークで作られたレガシーなやっかいシステムです。つまるところー、これがですね、使い勝手が悪すぎてユーザからは大不評なんです。困ったことに。いやぁ、ほんとに困っとるんですよ。悪いことにコードもスパゲッティ状態で変更や保守も難しい状態で」

⻑田さんは、苦悶の表情を浮かべて、現行のスカーレットにたいする不満を苦々しく語った。

⻑田「......ですね、ですねと、ルビーにリプレイスすれば、迅速に開発ができ、保守性の高いシステムが構築できると考えています。最近流行ってるらしいですからね、弊社の別部門でもルビー、ルビーと言ってますし」

――Rails にリプレイスしたからと言って使いやすいシステムになるかは別問題だぞ......
とぼくは口に出しかけたが、二見さんが遮った。

二見「Rails は、たしかに生産性が高いですからね。そうそう、溝口と K はたしか Rails の経験あったよな」 

溝口「えっ、あ、あれは Rails でちょっと社内用の掲示板を作っただけですけど」

⻑田「おぉっ、レイルズ経験者がいるのは心強い」

溝口くんは Rails 経験者として、Rails の素晴らしさをせつせつと語り始めた。得意げになっている。
――あの使いにくい社内掲示板? あんなのおもちゃみたいなもんだろ......
とぼくは溝口くんの適当さにあきれていた。 あんなのは Rails チュートリアルを一通りやれば誰でも作れる代物だ。

二見「弊社では、Rails の技術にもちょうどチカラを入れているところでして」

⻑田「それは、それは、弊社でも、外部のルビー技術顧問に助言をお願いしようとしてるんですよ。池上先生という界隈で有名な方でしてね、いま話しを進めているところです」 

溝口「えー、池上先生ですか、知ってます。ブログとか SNS で有名な人ですよね。あの人の記事 で Rails 学びました。池上先生に助言いただけるなんて」

⻑田「池上先生には、弊社の別の案件で何度もお世話になっていましてね」

池上先生は、ネットではちょっとした有名人で、ブログ記事が頻繁にバズっている。最近では Rails の書籍を商業出版したらしい。しかし、池上氏が SNS で言っていることが過激でぼくはあまり好きになれなかった。池上氏は Rails 至上原理主義者で、PHP を使っているエンジニアを「ペチパー」と揶揄して貶める発言だったり、Java を使っているエンジニアを見下す発言が多かった。
ぼくは会議の終わりの時間を気にして、Rails の話を打ち切るために話を変えた。

ハイブリッド・アジャイルという名の悪魔合体 

K「ここに、"アジャイル開発を部分的に適用する"とあるのですが」

⻑田「今回のリプレイスでは、絶対に失敗が許されないです。特にリプレイスしたのに使いにくいといった状況になった場合、大問題になります」 

K「失敗しないことを約束することは、なかなか難しいことだと思います。実際にリリースしてみて、ユーザにとって使いにくいことが初めて分かることも多いですから」

⻑田「そこで、部分的にアジャイル型の開発を採用したいと思います。アジャイルならリリースしたあとでもカイゼンを積み重ねて、使いやすいシステムに変えていくことが、後からでもできるからです」

二見「しかし、アジャイル開発で手戻りを続けていると、納期に間に合わない可能性がありますが・・・」

⻑田「いえいえ、そんなことないですね。二見さんはアジャイルを誤解されてる。わがスタシスが提唱するハイブリッドアジャイル 2.0*3では、ウォータフォールとアジャイルを組み合わせることで、スケジュールをキチっと管理しながら、試行錯誤を試していくことができます」

――きな臭いな...... 

⻑田「今回のプロジェクトでは、スカーレットの単なるリプレイスではなく、画面リニューアルをしたいと考えています。リニューアルデザインに関して、うちの渋谷が UI/UX デザイナーとして、ユーザーに使いやすいものに変える予定です」

渋谷「...新画面デザインについては、検討中ですので、もうしばらくおまちください」

ぼくは、直感的に⻑田さんの物言いに嫌な臭いを嗅ぎ取った。
しかし、「アジャイル開発ができる」という言葉に浮足立っていた。

*3 別名エンタプライズアジャイルとも呼ばれる

ずっとウォータフォール開発ばかりやってきたので、ようやく自分たちもアジャイル開発ができるのだと思うと嬉しくてしかたなかった。
それは溝口くんも同じだったようで、目を輝かせて今後の開発に想いをはせていた。
一通りの説明を終えて、⻑田さんは、言った 

⻑田「――月はじめに新スカーレット導入開始が決まりました。これは決定事項です。ですので早急に見積もりをお願いしたい」 

つまり、残された期間は 6 ヶ月ということだ。見積もるのは「人月」のことだ。つまり 6 ヶ月でスカーレットをリプレイスするために、何人月必要か見積もるということだ。
しかし、見積もりをするには、「要件定義」が必要であるが、そんなものはなかった。

⻑田「要件定義の確定は現段階では行わず、現行のスカーレットの仕様から見積もってほしいのですよ」

二見「せめて、画面数だけでも確定していただけませんか」 

⻑田「現行のスカーレットは、30 画面ですが。同じくらいの数字になると思います。しかし画面数の確定はできません」 

二見「そうですか。わかりました。30 くらいを想定ですね」

渋谷「画面デザインについては、こちらで早急に決めさせていただきます」

⻑田「あ、要件定義についてですが、今回、要件定義書を作らずに実装していただくことは可能で しょうか?」

えっ?  ぼくは思わず声が出そうになったが、踏みとどまった。

二見「どういうことでしょうか」

⻑田「現行のスカーレットには、ドキュメントのたぐいが全く無くてですね。要件定義書はもちろん、設計書も何もありません。基本設計書はかろうじてあるようですが、画面設計書もありません」 

K「ということは、要件を知るには、現行のスカーレットの動作を見るか、PHP のソースコードを 読むしかないということですか?」 

⻑田「そういうことになります。ですので最初にやっていただくのは、現行のスカーレットの PHPコードを保守しやすいルビーのコードに置き換えていただきたい」 

二見「もちろん可能ですよ。われわれの方で現行のソースコードを解析し、Rails に置き換える。 できたところから動作チェックは⻑田さんのほうで行うということですよね」

⻑田「そうですね。お願いしたく。本来ならば弊社が要件定義書を用意すべきところなのですが、私の方がほかに作業がありまして」 

二見さんはスタシスとの付き合いが⻑く、こういうやり取りはなれっこらしい。

二見「いえいえ、元から要件定義までコスモ側で引き取る予定でしたので問題ありませんよ」

――要件定義まで丸投げすると、いったい、⻑田さんは「何をする人」なんだろう...... 

⻑田「現行のスカーレットを Rails に置き換えたあとで、UI や UX のカイゼンフェーズに入ろうと考えています」

溝口「そこからはアジャイル的にやるんですよね」 ⻑田「弊社のデザイナーの渋谷が UI/UX をデザインしますので、コスモさんにはそのマークアップだったり実装の変更をお願いしたく。あ、もちろんこの時は、弊社側で画面設計書を用意いたします」

渋谷「......よろしくお願いします。画面仕様やデザインについて、もう少々お待ち下さい」

二見「承知いたしました」 

K「あのぉー、一点、質問させてください」 

⻑田「はい、何でしょう?」 

K「"DB は現行のまま"とあるのですが、DB サーバはリプレイスしないのでしょうか?」 ⻑田「Web サーバのみのリプレイスと想定しています。しかし、これも確定ではなく、もし DB側も変更が必要な場合はアジャイル的に手を加えたいと考えています」

二見「わかりました。いったん持ち帰って検討させていただきます」 

⻑田「できれば、今週中には回答を頂きたいと思います」

二見「わかりました」 

K「あ、最後に一点だけいいですか」 

二見さんが無言でぼくを睨んで(余計なこと言うなよ)とプレッシャーをかけてきた。 

K「⻑田さんは、釣りはお好きですか?」 

⻑田「えっ、釣り、ですか? いやぁ、釣りはさっぱりでして。かくいう私は、休日はもっぱらテニスでね。こう、スコーンと、で、なんでしたっけ?」 

⻑田さんは、その場でテニスの素振りフォームの披露を始めた。 

K「え、いや、釣具の EC サイトですから、釣りに詳しいのかなと。わたしも釣りには全然興味ないんですが、渋谷さんは、釣り、しませんよね」

渋谷「わたしもちょっと、釣りは...ごめんなさい」 

K「二見さんはどうですか?」

二見「おいおいー、おれは、ゴルフで忙しいんだから、釣りはやらんな」

そのとき、溝口くんが大きく手をあげてアピールした。

溝口「はいはいー、おれ、釣りやります! やってます! なんでも聞いてください」 

溝口くんは、せきを切ったように釣りの面白さをせつせつと語り始めようとした。しかし、⻑田さんが溝口くんの⻑くなりそうな話をバッサリ切った。

⻑田「プロダクトオーナーとして、ドメイン知識のほうは、わたしのほうで、詳しく調査しておきますので、どうぞご安心ください。みなさんは開発に専念してください」

そして、ぼくらは帰路についた。
二見さんは別件の用事があるらしく、「見積もり任せたぞ」と言い渡して、駅で別れた。
帰りの電車のなかで、溝口くんが目を輝かせながら小声で話しかけてきた。

溝口「渋谷さん、キレイでしたね。K 先輩、テンションあがってきません?」

K「そうかな、年齢よりも落ち着いて見えた」

――だが、優秀なデザイナーかどうかは......

曇り空のどよんとした空気の中で、電車の窓を通り過ぎる風景を見ながら、溝口くんは、今後の渋谷さんとの共同作業に思いを馳せていた。

何を作るのか決まっていないのに見積もりを強要する

二見さんは、コスモ社に戻るなり緊急会議を開いた。
会議室に入るなり、スタシスからの情報を整理したメモ書きをモニタに表示した。

要求リスト:
• 釣具 EC サイト「スカーレット」をリプレイスする
• 現行スカーレットの画面数は約 30 画面
• 現行のスカーレットが絶望的に使いにくい。何を実行するにも遅い。コードもスパゲッティ。
• 新スカーレットは「使いやすさ」が第一。
• UI/UX 改善のため使いやすさを模索するため部分的に「アジャイル」を導入する。
• PHP で組まれた Web アプリケーションを Ruby on Rails に置き換える
• DB は現行のまま
• 期限は 6 ヶ月。最初の 3 ヶ月で Rails 置き換えを済ませて社内だけの 0 号リリースを行う。ここまではウォータフォールでやりきる。
• その後、開発は試行錯誤フェーズに移行する。このフェーズはアジャイルで行う。

模倣者は踊る

二見「わたしは何としても、このスカーレットリプレイス案件を受注したい」 

二見さんは、ぼくと溝口くんを交互に見て激を飛ばした。

K「見積もりを出すんですよね」

二見「そうだ」

溝口「でも、ぶっちゃけ、何をどうやって見積もるんすかね」

二見「契約内定上の見積もりの数字は、もう決まっている」 

溝口「えっ、それってどういうことなんですか?」 

K「溝口くんは、スタシスの案件は初めてだから知らないかもしれないけど、受注するための見積もりってもうすでに決まっているんだよ」

溝口「ははー、出来レースなんすね。決まってるんなら話ははやいっすね」 

二見「そう、K が言ったように、スタシス本社でスカーレットリプレイスに割り当てた予算はすでに決まっている。そこから逆算すると『3 人月』× 6 ヶ月というのが、受注するための数字だ」 

K「ここで二見さんが話し合いたいのは、実際の"本当の見積もり"ってことですよね?」

二見「そうだ」

溝口「でも、それってむずくないですか? 何作るかもよくわかってないのに」

二見「何を作るかは決まっている。現行のスカーレットのリプレイスだ」 

K「まあ、まずは先程送られてきた現行スカーレットの基本仕様書見てみましょうよ」

先程、⻑田さんから我々 3 人宛に、ZIP が添付されていた。ファイル名が「P-2501_スカーレッ ト基本仕様書 v2_20xx0611_003 最新.zip」となっていた。
スカーレットには、ドキュメントがほとんど存在せず、この「基本仕様書」だけが唯一のドキュメントらしい。

溝口「あれっ、この zip、、、開かない。パスワードがかかっている」 二見「zip パスワードのメールは、別途、届いてないな。⻑田さん忘れたのかもしれん」

K「ぼくは zip 開けたので、こっちのを見ましょう」 

溝口「え、K 先輩、どうやって、やったんですかそれ!?」 

K「こんなの zip パスワード解析ツール使えば一発だよ。設定されてたパスワードは、"starsys5"なんて短いものだったから一瞬だったね」 

と得意げに溝口に語っていると、二見さんが急に怒り出した。

二見「その解凍したファイルはいますぐ削除しろ。お前のやってる行為はハッキングだ」 

K「ハッキングだなんて、そんな、大げさな」 

二見「いいから、すぐに削除しろ。溝口は⻑田さんに zip パスワードの送信をお願いしろ」

溝口「はい、了解です」 

溝口くんは、手元のノート PC で、すぐに⻑田さんに zip パスワードを送ってもらえるにメールした。

K「パスワードをメールの平文で送るほうが、問題だと思うんですけど」

二見「黙れ。お前のやった行為はセキュリティ的に問題がある。他人がかけたパスワードをクラックするなんて行為は許されないんだ」

そうこうしてると、⻑田さんからメールが届いた。

▼ from ⻑田 nagata.xxx@starxxxsysxxx.co.jp
毎々お世話になります。⻑田です。
すいません、いやー、忘れてました。
パスワードは、"starsis555" でよろしくです

ぼくの解析結果と微妙に違っていた。

溝口「・・・このやりとりって、なんか笑っちゃいますね」

K「くくくっ、たしかに」 

二見「いいか、これは決まりなんだ。おまえらは、黙ってそれに従え」 

僕ら 3 人は、スカーレット基本設計書に目を通した。 

溝口「めちゃくちゃ読みにくいっすね〜。この「SCLT3L005CV2」みたいなクラス名とか、メソッ ド名の「ARR002」とか」 

K「これはスタシス流の命名規則だよ。慣れればスラスラ読めるようになるさ。問題ない」 

溝口「うげぇ、なれたくねぇっすわ。この仕様書、全部 Excel のシートで作られてるんですね。う わさに聞く Excel 方眼紙ですか」 

K「Excel 方眼紙を初めて見たとか......嘘だろ」 

溝口「いやぁ、Excel の仕様書は何度も見てきましたけど、こんな目の細かい方眼紙になってるのは初めてですよ」

二見「それ以上、おしゃべりはやめろ。急いでざっと目を通せ」

♣ 破裂しそうに膨らむ要求仕様いう名の爆弾

その後の数週間は、要求仕様の策定でもめた。
もめた原因は、⻑田さんからメールで言い渡される「要求」にあった。 

▼ from ⻑田 nagata.xxx@starxxxsysxxx.co.jp
毎々お世話になります。⻑田です。
スカーレットのシェアリングエコノミー対応の件、対応をお願いしたく。
...(略)
−以上− 

⻑田さんから言い渡される要求は、単純な EC サイトのリプレイス案件ではなくなってきていた。もっとも大きな要求は、スカーレットを「EC サイトからフリマサイトへ変えたい」というものだった。
「シェアリングエコノミー」という言葉が、巷で流行りだしていた。
シェアリングエコノミーとは、車、家、家具、服など、個人間で物品を他人に貸し出したり売ったりするサービスを言う。
近年、欲しいものを購入するのではなく、必要なときに借りればよい、他人と共有すればよいという考えを持つ人やニーズが増えている。そのような人々と、所有物を提供したい人々を引き合わせるインターネット上のサービスが注目を集めている。
フリマサイトも、広い意味ではシェアリングエコノミーサービスと呼ばれている。
二見さんは、社内で緊急会議を開いた。
会議室で、ぼく、溝口、二見さんは、スカーレットのフリマサイト変更の是非について話し合った。

二見「どうだー?  K 隊⻑、溝口隊⻑、わが軍はいけそうか?」

ニコニコしながらぼくら二人に話しかけてきた。その笑顔が逆に怖くて、背筋に冷たい汗が流れた。二見さんは無理難題を言う時、道化師を装って、おどけて語りかけてくる。 

二見「『隊⻑2人組の体調』はどうでっしゃ?」

溝口「これは厳しくないっすかー、かなり大幅な変更すよね。リプレイスってレベルじゃねぇっすよ」 

K「んー、ぼくも、これは、ちょっと無理そうな感じがしています。正直、6 ヶ月でやりきれる自信はありません」 

二見「できない理由はなんだ? どこらへんが無理そうなんだ?」 

K「ぼくは、EC サイトは何件かいままでやったことあるので、EC サイト構築の大体のことは事前にわかるのですが、フリマサイトは今まで構築したことがないので、正直わからないというのが本音です。要求仕様も不明確なところが多く、なんとも」

二見「なんだそれは。わからないからできないとか、そんな子供みたいな物言いで、プロとして恥ずかしくないのか」 

K「そうは言ってもですね、現時点では直感的に間に合いそうもないとしか、言えないです」 

二見「K はまだ見積もりもしていないんだろ? だったらまずは⻑田さんの要求に対する見積もりを出せ、今日、明日でなんとかしろ」 

K「⻑田さんからの要求もあやふやですよ、現時点で見積もることもむずかしいんですけど」

二見「いいから、やれ。むずかしいことはわかっている。それでもやるんだ。ざっくりでいいから。溝口、お前もいっしょにやるんだ」 

溝口「えっ、、あ、はい...(まじか)」

二見「できるかできないかは、俺が判断する」 

K「わかりました。ざっくりと見積もりをします」

二見「できない理由より、できる理由を考えろ」 

よし、やれ、という二見さんの掛け声とともに会議は解散となった。やれやれ......。
席に戻る途中で、溝口くんが給湯室の陰から話しかけてきた。

溝口「ひどくないっすか? 工数見積もれないのに、無理やり見積もれなんて」

K「よくあることだよ。カットオーバーは6ヶ月後に決まっているから、見積もりなんてのはそこに辻褄合わせさえできればそれでいいんだよ。」

溝口「えっ、でも、それだと間に合わないんじゃないんですか、どうすんですか」

K「おめでたいやつだな。間に合わせるんだよ。何がなんでも」 

溝口くんは、うげぇという表情で去っていった。

どんぶり勘定のステップ数見積もり

ぼくは、さっそくざっくり見積もりを開始した。例えば、以下のような感じだ。 

▼工数見積り
* トップ画面 - 4人日
* 商品一覧画面 - 5人日
* 商品詳細画面 - 3人日
* 商品購入画面 - 3人日
* ユーザー詳細画面 - 3人日
* 共通課金ロジック - 2week
* ... (略) 

カットオーバーの日付から逆算して、ざっくりと見積もりをでっち上げた。この見積もりには、何の根拠もない。それっぽい値を終了日から逆算して入力したものだ。正直、この通りに作業が終わるとは思っていない。
溝口くんに、この見積もりを見せてみると、

溝口「これ、工数少なすぎじゃないですか、できる気がしねぇっす」 

と返されたが、ぼくはそのまま二見さんにこの見積もりを見せた。
二見さんの返答は 

二見「人日は小数点1桁まで出せ。人日だけでなく、ステップ数見積もりも一緒に出せ」 

だけだった。 

ステップ数とは、プログラムのコードの「行数」がどれくらいになるかを示すものである。本来であれば、コードの行数と、作業が何日かかりそうかは、まったく関連がない数値であるが、コスモとスタシス間のやりとりでは、このステップ数見積もりが作業日の根拠として必要不可欠だった。
ぼくは、渋々ステップ数を作業日から逆算して、むりやり割り出した。このステップ数も何の根拠もない。ただ単に「それっぽい値」を入れただけだ。

▼工数見積り (ステップ数)
* トップ画面 - 4.1人日(1.2KL)
* 商品一覧画面 - 5.0人日(1.5KL)
* 商品詳細画面 - 3.2人日(1.2KL)
* 商品購入画面 - 3.1人日(1.1KL)
* ユーザー詳細画面 - 3.1人日(1.1KL)
* 共通課金ロジック - 2week(3.1KL)
* ... (略) 

二見さんはこの数値を見て、ちょっと大雑把すぎるんじゃないか、と不満そうだったが、後のことは二見さんと⻑田さんとの交渉に任せることにした。
ぼくは、「こんな見積もりで本当に大丈夫か?」という疑念があったが、スタシス側から、見積もりの了承をいただき、いよいよ開発がスタートする運びとなった。 

3.3 マイクロマネジメントを強要する上司 

頻繁な作業報告

この日から、二見さんから毎日2回の作業報告をするように言い渡された。1回目はその日の昼食後に、二見さんと 1on1 形式で行われる。2回目は帰宅する前にメールで今日一日の作業とかかった時間を書き出して、明日の作業予定も記す。この 2 回の作業報告が義務付けられた。
一緒に昼食にきていた溝口くんは、さっそくブーたれていた。

溝口「毎日、こんな作業報告する意味あるんすかね?」 

K「ちゃんと進捗管理したいんだろ。マネージャとして。仕方ないんじゃない」 

作業見積もりを時間単位で見積もれ 
昼食後、二見さんとの進捗報告のため会議室に向かった。
会議室の中には、すでに二見さんが座って待っていた。 (まだ、5 分前なのに...) 

二見「とびら閉めて、座って」 

中に入って会議室の扉を閉めると、重苦しい雰囲気が場を支配した。

K「はい」

ぼくは、おずおずと席に座った。

二見「では、報告を始めてちょうだい。『内緒はないっしょ』で頼むぞ」

K「今日は商品一覧画面をやってます。進捗的にはまだまだで 20% といったところです」 

二見「昨日の報告から 10% しか進んでないが、なぜだ?」 

K「仕様書がなく、旧スカーレットのコードを解析しながらの作業ですので、なかなか苦戦していまして」 

二見「今週中には商品一覧画面は、完了する予定になっているが間に合うのか?」 

K「まぁ、なんとか、間に合わなければ休日出ます」

二見「よし。それとメールの作業報告の件だが、もう少し詳細に書け。これだと何にどれだけ時間をかかっているのかがわからん」 

K「詳細にと言いますと」

二見「もっと細かいタスクを箇条書きにして、分単位でどれくらい時間をかけているのか明記しろ」 

K「そこまで書く必要ありますかねー」

二見「必要だ。やれ。」 

K「...」

ぼくは、黙って会議室を退室した。
廊下で溝口くんとすれちがった、彼はこれから二見さんとの進捗報告をするようだ。
自分と同じように厳しい追求されるんだと思うと、かわいそうにみえて同情した。
ぼくはその後、終電間際まで作業した。
溝口くんも 23 時頃まで一緒に残っていたが、先に帰るように促した。
ぼくは、帰る前に作業報告メールを出し忘れていたのを思い出し、二見さんお望みの「分単位」の作業報告をでっちあげて、メールを送信した。
思いのほか時間がかかってしまって、時間は終電を過ぎてしまっていた。
しかたがないので、この日はタクシーで帰った。

3.4 Solid State Society - 個体状社会

ある日から、スタシスからメールが届いた。

▼ from ⻑田 nagata.xxx@starxxxsysxxx.co.jp
毎々お世話になります。⻑田です。
この度、「スカーレット」プロジェクトに、池上先生が就任されました。
今後は、池上先生の設計のもと、実装を進めていただきたく。
... 略
−以上−

⻑田さんからメールの文面には、これからのスカーレットの"要件定義"や"設計"に関して、全部、池上先生にやってもらうので、それに従ってほしいとのことだった。

▼ from 池上 ikegami.xxx@starxxxsysxxx.co.jp
毎々お世話になります。 本日よりプロジェクトに加わりました池上です。 よろしくお願いいたします。
これから設計書を書いていくので、現状でいいのでソースコードの送付をいただきたく。
... 略
−以上− 

ぼくは現状のソースコードを zip で固めて、パスワードをかけて池上先生へとメールで送付した。
池上先生からすぐに返事がきた。

▼ from 池上 ikegami.xxx@starxxxsysxxx.co.jp
多謝
... 略
−以上−

「多謝」と一言メッセージが書かれてあった。
これはスタシス流のメールの返信にありがちなことで、メールの返信には「多謝」と書いとけばいいと思っているらしい。このメールから感謝されている感じは微塵も感じなかった。スタシスからのメールは、文末が「......していただきたく」で結ぶことが多い。当然のことだがこちらに拒否する権利はない。

遅れる進捗と怒れる人々

それからは進捗は遅れる一方だった。
そもそも、最初の見積もりの時点で、適当にでっちあげた計画に従っているのだから、遅れるのは当然だ。
定例会議で、二見さんは現状の進捗を報告した。
⻑田さんは苦々しい表情で告げた。

⻑田「先週、お聞きした時は、『遅れを取り戻すためになりふりかまわない』と言ってましたが」

二見「も、もうしわけございません、私どもとしても、休日問わず作業してまして、精一杯やらしていただいているんですよ」

⻑田「コスモさん、これは、いかんですな。休日出ているかなんてこちらは知ったこっちゃないんですよ。まずは社内向けの0号リリースには絶対に間に合わせないと......」

二見「もちろん、0号リリースは絶対に間に合わせます。絶対に」

⻑田「......二見さん、もうそれ、聞き飽きましたよ。先週もそれ言ってましたよね、まったく」

⻑田さんの隣にいた池上先生が、なにやら小声で耳打ちを始めた。

池上「だから、いったでしょう、...に、これ以上は...ですから、・・・するしか」 

「――――」 

⻑田「急ですが、来週からの作業は、ウチにきてやっていただけないでしょうか」 

突然の常駐宣言にぼくらはびっくりしたが、⻑田さんの無言の圧力に押し切られた。
(常駐が飲めないなら......今後はないぞってことか) 

二見「......わかりました」 

ぼくらは渋々、スタシスに常駐することを認めた。

⻑田「二見さんには、ちょっと、このあと個人的な話がありますので、外でお話いただいてもよろしいですか」 

二見「えっ、えっ? なんでしょう」

なにか言おうとした⻑田さんを制して、池上先生が前に進み出た。

池上「私の方から簡単に申し上げますと、このままでは進捗が芳しくないので、わたしのほうで新たに協力会社さんを手配することにしました。セブンウェアさんから2名、一緒に常駐される予定です」

二見「え、あ、そうなんですか。増員要望をおっしゃっていただければ弊社でしましたのに」 

⻑田「・・・セブンさんは Rails に強い会社で非常に頼りになります。池上先生のお墨付きです」

――これは、コスモ側が見限られ始めているってことなんだろうか、ぼくと溝口くんは不安な顔で見つめ合った

客先常駐という刑務所

翌週より、ぼくと溝口くんはスタシスに客先常駐となった。二見さんはマネージャなので、週 1 の定例会議にだけ参加すればよいらしい。
ぼくらはスタシスにつくと、渋谷さんが作業部屋まで案内してくれた。
廊下を歩きながら、渋谷さんと溝口くんが話していた。

溝口「阿蘇 F ランド行って――実家、熊本なんすよ。俺、地元 S 町ですよ」

渋谷「えっ、えっ、わたしも熊本です。S の近くです。Y です」 

溝口「うへ、まじか、あの辺、一気にキレイになりましたよね、H 商店とボーリング場が潰れて、スタバできてたし――」 

渋谷「あー、H 商店なつい。わたし、ボーリングうまいんですよ。あそこで鍛えました」

ぼくは二人の後ろを黙ってついていった。
廊下の奥の突き当りの扉の前に着いた。 

扉のプレートには「プロジェクト 2501「スカーレット」開発室」と書かれていた。

監獄部屋 

渋谷さんはカードで扉をあけて、ぼくらを部屋に通した。そこは 14 畳位の物置のような部屋だった。

渋谷「せまくて申し訳ないんですけど......」

部屋には⻑机とパイプ椅子が並べられていた。ホワイトボードもある。
机の上には、DELL 製の PC とモニタ、キーボードが 2 台用意されていた。
入ってきた扉の上方に防犯カメラが設置されていた。

渋谷「あぁっ、忘れてた。わたし、受付に、もういっかい迎えに行かないと、すいません」

渋谷さんは、小走りに廊下をかけていった。
ばたんと扉がしまり、ガチリとロックする音がした。

溝口「・・・刑務所みたいっすね、やべー、プリズンですよ。プリズン・ブレイクってみました?  あれ、俺、好きなんですよ」 

K「この椅子、やぶけているな」

ぼくはパイプ椅子の座り心地を確認した。
まあ、こんなもんだな。

溝口「ちょっと、俺、トイレいってきますわ」 

K「おっけ」

しかし、溝口くんが何度もガチャガチャと、ドアノブを回す音が聞こえた。

溝口「あれ、あれ、開かないかも。もしかして、このカードリーダー」 

K「カードがないと開かないのか。このゲストカードで」

カードリーダーは、ビーという BEEP 音と赤いランプでエラーを伝えていた。

協力会社の投入
完全に閉じ込められた。
しかたないので、ぼくらはプリズン部屋で PC のセットアップを開始した。机の上に紙が置いて あり、そこには「インストール可能アプリケーションリスト」と「開発サーバの IP アドレスと ID とパスワード」などが記述されていた。こんな部屋なのに有線 LAN は敷設されていた。
さっそく「TeraTerm」、「WinSCP」「さくらエディタ」などをインストールした。「TeraTerm」を起動し、開発サーバに接続した。

K「......Red Hat Enterprise か」 

開発はこの開発サーバ上で行われる。シェルを Zsh に書き換えて、Vim のカスタマイズを始めた。

溝口「K さん、相変わらず Vim 使いなんすね......」

溝口くんはゲンナリした様子で、代わりに Emacs を起動していた。
作業をすすめていると、急に扉が開いた。
渋谷さんが、新たに二人を引き連れてもどってきた。
入ってきたのは、さえない中年のおっさんと外国人の女性だった。池上先生が言っていた新たに投入された協力会社の人らしい。

梶浦「今日からチームに加わります梶浦っちゅう者やけど。よろしゅうお願いいたします」

アーニャ「よろしく、オネガイシマスです」

梶浦さんは、大阪出身の気のいいおっちゃんって感じで、Rails を独学でマスターしたらしい。
アーニャはロシア出身のエンジニアで、日本が好きでこっちで仕事をしている。ブロンドのセミロングの髪と⻘い目が輝いていた。 まるで人形みたいな子だ......。彼女はウィザード級のハッカーで、セキュリティの世界大会のファイナリストに残ったと聞いた。
二人が所属しているセブンウェアは Rails 専門の会社で、外国人も積極的に採用する会社だそうだ。

溝口「すいません、トイレどこですか?」

渋谷「出て、左の突き当りです、あ、そうなんですよ、ゲストカードではこの扉の開閉はできないらしくて」

渋谷さんは、ピッと自分のカードをリーダに当ててロックを解除した。

渋谷「戻ってきたらノックしてください。開けるので」

溝口くんは、無言でダッシュで駆けていった。

梶浦「自由に出入りできひんなんて。わたしらの人権はどうなっとるんやろな」

アーニャ「ジユウ、ニンゲン、だいじデス」

渋谷「申し訳ないんですけど、扉をあけたいときは、あそこの内線から、わたしを呼んでいただければ......内線番号は――です」

梶浦さんの横にいたアーニャは日本語をよく聞き取れなかったらしく、キョロキョロしていた。

K「ちなみに、喫煙所ってありますか?」

渋谷「はい、3F にありますよ。自販機や軽食も買えますので、あとでご案内しますね」

アーニャ「キーボードのモチコミ、ダイジョウブです?」

渋谷「すいません、機器の持ち込みは NG なんですよ、あと PC にインストールできるソフトは一覧に書いてある許可が出ているものだけにしてください。その他をインストールしたい場合は稟議が必要ですので」

ガチャッと音がして、扉が開くと、知らない男性が入ってきた。その人は、池上先生だった。
続いて、溝口くんもトイレから戻ってきた。
これで全メンバーがそろったらしい。

池上先生はホワイトボードにそれぞれの役割を書いた。

我々の「A チーム」:*4
• 池上 - PM 兼 SE
• 渋谷 - デザイナー
• 梶浦 - 新規機能担当
• アーニャ - 新規機能担当
• K - EC リプレイス担当
• 溝口 - EC リプレイス担当

どうやらリプレイスと新規機能で担当を分けるらしい。
その後は、池上先生がチームに激を飛ばしていた。

監視体制と臨戦態勢

監獄部屋に移ってから、1 週間が過ぎた。

池上「いまのままのペースでは、カットオーバに間に合いません。今日から臨戦態勢を敷きます。わたしもこの部屋で作業しますので、よろしくお願いします」

監視役ってわけか。

K「――自由に扉の出入りができないのは困るのですが」

ゲストカードでは、この部屋への出入りができないことを池上先生に伝えた。
渋谷さんが補足として、この部屋の入退室権限は特殊で変えられないことを説明した。 

池上「わかりました、外に出る際はわたしのカードキーを貸しますので、取りに来てください」

模倣者は踊る
ある朝、いつものように監禁部屋に出社すると、チーム全員がそろったのを見計らって、池上先生が手を叩いて前に進み出た。

池上「今日からアジャイルのプラクティスを導入していきます。まず、今日から毎朝、朝回を導入 します。それに伴い週に 1 回のふりかえり会を行います」

*4 プロジェクトをやり遂げるためにチームに必要な役割。海外アクションドラマ「特攻野郎 A チーム」が由来

池上「では、さっそく、今から朝会を始めましょう。それでは K さんから現状を報告していってください」 

K「あ、はい、昨日は、xx の実装を進めていました、今日は引き続き xx をやります」 

池上「xx の実装が遅れているようですが、進捗はいかほどですか?」 

K「現時点ではまだ 20% というところです」 

池上「20% ぉ、それはいけませんね、そのあとも詰まっています。どれくらいで終わりそうで すか?」 

K「あと、3日はかかるかと」

池上「3日ぁ、いけません。今日中になんとかしてください」 

K「......今日中はちょっと厳しいかもです」

池上「やってもいないのに何をいっているんですか。やるんですよ。やってください」 

K「......わかりました。やってみます」

池上「よろしい、次、溝口さん」

――その後も、池上先生による朝会という名の「進捗糾弾会」が続いた。進捗を見える化するために、タスクボードの運用も始まった。池上先生は模造紙に、付箋を貼ってみせた。
これを毎日やるのか。地獄だ。週 1 で行われる「ふりかえり会」も、きっと憂鬱な会になることだろう。

暴走の証明
ある日、池上先生が「コードレビュー会」をやると言い出した。
いままで、いっさい「コードレビュー」は行われなかったはずなのにどういう風の吹き回しだ。

池上「コードがね、DRY じゃないんですよね、これ。同じような処理何度も書いて、あれれ、" 共通化"って知ってます?」 

溝口「......DRY って、どういう意味っすか」 

池上「話になりませんね、K さん、ここコードレビューしてるはずでしょ」

K「たしかに、仰る通りなのですが、ここは共通化するべきではないと私は思います。現時点で は、"たまたま"似たような画面構成で似たような処理を行っています。しかし、この 2 つは別の画面処理を行っていて、共通化するべきではないですね」 

池上「どうしてですか? 共通化することでコード量も減って、DRY になっていいことずくめだと いうのに? 似たようなコードをなんども書いて、それってあなたのレベルが低いってことじゃ?」

K「コードを共通化するとですね、こういうふうに共通化部分に IF 文がいりくんじゃうわけですよ」

池上「それはクラスの継承を使えば簡単に解決ですね。ベースクラスに共通メソッドを処理させて...」

溝口「......ちょっと、おれ、言ってることがわからないです...」

ぼくは溝口くんを制して続けた。

K「いや、――いえ、それだと依存関係を見えなくするだけで、コードがますます追いにくくなりますね」

池上「これ以上の議論は無駄です。ピリオド。いいから共通化しなさい。できないのなら私がやります」 

K「...承知いたしました。修正します」

池上「――次に、――これを書いたのは誰ですか」

溝口「......俺っす」

池上「あー、ダメ、ダメ。ひどいですよ。これは、――ですよ。コスモさんではこんなレベルの低いコードを書くのですか、ゴミですよ。こんなものは」 

K「たしかに、見落としていました。修正します」

作業員としてコードを書く日々

それからは、基本設計は池上さん、画面設計は渋谷さんで行う。
実装は、ぼくと、溝口くん、梶浦さん、アーニャの四人体制だ。 EC リプレイス側画面はコスモ側の担当で、新機能はセブン側の担当という分業体制がしかれた。
分業と同時に、全体の情報が入ってこなくなった。
気がつくとこの部屋に移って1ヶ月が過ぎていた。早いものだ。
ぼくらは池上先生の指示に従って、ただの作業員に徹した。
作業員は、この作業がどんな意味を持つかなんて考えてはだめなのだ。
ぼくと溝口くんは、割り振られたタスクに集中した。
梶浦さんやアーニャがどんな作業をしているのか、まったく把握していなかった。
システム全体を把握しているのは、池上先生だけだった。
渋谷さんは、画面のデザインに関してしか知らない様子だった。

なかなか送られてこない仕様書
しかし、池上先生からの仕様書は、待てども待てども上がってこなかった。 池上先生の言い分としては、新規側の設計を優先させているので、EC リプレイス側の仕様は後まわしにするとのことだった。

池上「アジャイル的にやっているので、これが普通ですね。いたし方ないのですよ」

しかたがないので、ぼくらは旧スカーレットのコードを解析しながら実装をすすめた。

機械たちの午後 PAT.
喫煙室で一服を終えて、近くの自販機コーナを見ていた。

K「ドクペ*5はないな......」

しかたないので、缶コーヒーを買って、フリースペースで飲んでいた。
すると給湯室から、アーニャが顔を出した。
こちらに気づいた彼女は、笑顔で隣の席に座った。

アーニャ「K さん、オヤツのじかんデス」

手には、かわいい紅茶ポットとカップをもっていた。

K「あぁ、もう15時か......」

時間が経つのが早く感じる。それになんだか身体が重く感じる。
アーニャがカップに紅茶を注ぐと、いい匂いがして身体がリラックスして、気持ちがやすらいだ。

*5 ドクターペッパーの略。当時「シュタインズゲート」にハマっていて。その影響で常飲するようになった

アーニャ「クッキーほしいデスか?」

 
ポケットをごそごそすると、はいっと、小袋に小分けされたクッキーをくれた。 

K「ありがとう、もらうよ、うん、うまい」

――クッキーをかじると、不意に涙が出た。

ゴミでもはいったのかな。目をシパシパさせて、涙を拭った。
最近、このように、よくお菓子をもらうようになった。
アーニャは日本のアニメが好きで、アニメの話をして二人でもりあがった。
この監禁生活の中で、唯一、気持ちが楽になる時間だった。

監禁部屋に戻ると、溝口くんに「なんかいいことでもあったんすか?」と尋ねられた。
自席に戻っても笑顔の残滓が残っていたらしい。
ぼくは、ニヤケ顔に手をあて「そう?」と、とぼけた。

デザインが決まらない
渋谷さんが行っている画面設計だが、各画面のざっくりとしたワイヤーフレームだけが、僕らのもとに届いていた。詳細なデザインについては社内でもんでいる最中なのでもう少しまってほしいとのことだった。
しかし、待てども待てども画面のデザインは上がってこなかった。
デザインを待っていてはこちらの仕事が進まないので、仮の画面として旧スカーレットの画面をもらっているワイヤーに重ねてそのまま移植するカタチで、ぼくらは作業をすすめた。
デザイナーの渋谷さんは「もう少しだけお待ち下さい」と言い続けるばかりだった。

溝口「ぜんぜんっ、だいじょうぶです!」

と大見得を切っていた。

デザイナーとの分業

二週間後、ようやく渋谷さんからトップ画面のデザインがあがってきた。 画面仕様書は、Excel にイラレで作った画像を貼り付けるカタチで僕らに渡された。 しかし、これでは、枠の幅や高さが何ポイントなのか? レスポンシブルに対応すべきなのか?
一切わからなかった。

溝口「おれ、詳しいところ、直接聞いてきますよ」

と言って、何かに付けて渋谷さんとの接触をはかろうとしていた。
溝口くんが渋谷さんのもとに通い詰めたおかげで、密接なコミュニケーションが取れた。 とりあえず、ぼくは渋谷さんの画面設計書と溝口くんの情報をもとに、それっぽく HTML/CSS をマークアップし、渋谷さんに見せた。

渋谷「良いですね。ウン、ばっちりです」 

と快諾をいただけてぼくはほっとした。 

溝口「彼女によろこんでもらえてよかったー、よかった」 

と満足気な様子だ。 

デザインするのは誰? HTML/CSS マークアップするのは誰?
ぼくらは、次々と、Excel 画面仕様書を見ながら、HTML/CSS のマークアップを行った。渋谷さんも画面仕様書を仕上げるのペースを上げていた。
と同時に、渋谷さんから上がってくる画面仕様が雑になっているのが気になった。 

K「ここのお知らせの文字を、もっと目立たせたほうがよくないですか?」 

と提案すると、 

渋谷「たしかにそうですね」 

と修正された結果が、「単純に文字サイズを大きくするだけ」で終わっていた。大事な情報を 「周りの情報に埋もれないようにする」のがデザイナーの仕事ではないのか? 

渋谷さんは、Web の技術にまったく興味がなかった。当然 HTML/CSS は書けない。彼女にで きるのは、イラレで描いたお絵かきを Excel 仕様書に貼るという仕事だ。 渋谷さんは新人ということもあって、デザイナーとしてのレベルはかなり低かった。 ほかにも、ページのコピペミスで、画面パーツがおかしな配置になっている箇所もあった。

最も気になったのは、
「このデザイン、つかいにくいのでは?」
という点だった。 

渋谷「新スカーレットでは、『シンプルかつクール』な UI を目指してデザインしています」

という言葉のとおり、シンプルさを追求するあまり、インターフェースを隠すデザインを採用していた。
メニューや設定画面は、基本「閉じている」状態になっていて、画面を遷移したいときに分かりづらかった。
しかし、指摘するのも面倒だったので放っておいた。
この頃、梶浦さんとアーニャは、完全に新規機能画面に作業が移ってしまい、彼らがなにをやっているのか、ぼくらは知らなかった。

―――つづく

いかがでしたでしょうか。

以上で無料公開部分は終わりです。

続きは本編で。