『変わらない開発現場』を変えていくために。

前回のエントリですが、はてブや Twitter でびっくりするほどたくさんのコメントをいただきました。当該ページの PV も 2 万超え、そして 1,000 件を超えるはてブは初めてで、勉強になるコメントも多く、なるほどと頷かされるご指摘が多かったです。この場を借りてお礼申し上げます。ありがとうございました。（はてブでエールを送っていただいた皆様もありがとうございました。励みになります。m(_ _)m）

コメントを読んでいると、やはりものすごく現場で苦しまれている方が多いと改めて感じると共に、年次や役職で抱える悩みはずいぶん違う、という印象も受けました。ただ、いずれの悩みにも共通するのは、

「意思決定者の方々になかなか理解してもらえない・動かせない」
（意思決定者＝自分のマネージャ、お客様など）

という点だと思いました。実際問題として、意思決定権者にしか変えられないこと・決められないことについて、正論をタテに現場担当者に解決を詰め寄るのはただの無理ゲーで、これだと、あんまり建設的な議論にはならないのですよね；。この件に関しては様々な宗教論争、もとい議論を見てきましたが、全体的にビジネスの仕組み的な観点からの考察が不足していることや適切な問題分解・整理がなされていないこと、さらに多彩な開発現場を十把一絡げに議論しようとしていることが、建設的な議論を妨げている、と感じました。

この辺の解決方法は、結局、現場や人ごとに大きく変わるので、万能な処方箋は存在しない（個々人で自分の問題としてじっくり考えるしかない）のですが、コンサル的な視点から、考え方に関して多少のヒントは書けるかも？ と思って、補足エントリとして書いてみることにしました。蛇足ではありますが、何かのヒントになれば幸いです。

今日のエントリで書きたいポイントは 3 つです。タイトルだけでだいたい内容の想像はつくと思いますので、ピンと来た方は特に読まなくてもよいと思います、はい^^。

• 問題分解の必要性：責任境界線を明らかにする
• 変わらない意思決定者への「伝え方」のヒント
• 鶏と卵、先に変わるべきはどちらか？：プロフェッショナルとして

■ 問題分解の必要性：責任境界線を明らかにする

前述したように、SI 開発現場に関わる様々な問題には、自分でも変えられることと、意思決定者にしか変えられないことが存在します。（下記の例はとりあえずのケーススタディとして書きましたが、それぞれの開発現場、そしてご自身の役職やロール次第で、話は大きく変わります。なので、ちょっと時間を取って書き出してみるとよいかと思います）

• 例 1. 「請負契約」を前提条件として、大きな粒度のアジャイルを可能にするために必要なことは？
  • お客様（意思決定者）に求められること
    • 要件定義への積極的な参画
    • 素早い契約締結
    • 柔軟な予算確保と執行　（※ アジャイルの大きな阻害要因のひとつは、日本でよくある予算確保と予算執行の硬直性です。）
  • SIer （現場担当者）に求められること
    • 適切なベースライン定義と変更管理
    • 精度の高い見積もりを素早く出せること
    • 高速な開発（設計・実装・ビルド・テスト）
  • 両者に求められること
    • 誠実な信頼関係とプロフェッショナリズム
• 例 2. 請負契約の境界を超えない範囲で、小さな粒度のアジャイルを回していくために必要なことは？
  • SIer のプロパー（意思決定者）に求められること
    • Scrum などのアジャイル方法論の導入
    • 見積もり手法と実績管理手法の変更（プラニングポーカーとかタスクボードとか）
    • チーム運営方法の変更
    • 係数ベースのプロジェクト管理手法の導入
    • フラットで風通しのよい現場環境の醸成
    • 品質管理指標やプロセスの変更（または二重管理）　（※ 全社的な品質管理基準が今どきの開発スタイルに合っておらず、そこがネックになって新しい手法などが導入しにくくなっているケースがあります。特に大きな SIer にありがちなパターンです。）
    • 現場への超優秀なエンジニアの投入 （※ Scrum のような開発プロセスでは、一時的であっても構わないので超優秀なエンジニアを投入し、その人のノウハウを周囲に伝搬させると、開発現場のレベルを一気に引き上げやすいです。）
  • 協力会社の担当エンジニア（現場担当者）に求められること
    • ALM ソリューションの導入（できれば TFS/VSTS 使ってね！（ぉ））
    • 日々の作業におけるチケット駆動開発の利用
    • 高速開発に必要な高い技術スキルの習得
    • CI/CD 環境の構築
    • 社外とのコミュニケーションによるノウハウ吸収（例：コミュニティ勉強会への参加など）
  • 両者に求められること
    • 誠実な信頼関係とプロフェッショナリズム

自分たちに関わることは自分たちの努力で解決できる問題です。しかし多くの人が悩んでいるのはそこではなく、相対する意思決定者にしか変えられないことでしょう。ここに対する具体的なソリューションがないのに何とかしろと言われると、「どないせいっちゅうねん；」と思ってしまいますし、仮に具体的なソリューションが書かれていたとしても、自分のシチュエーションに当てはめられないと、「そんな無茶いうな！」となります；。

先に書いたように、開発現場、さらにそこに関わる皆様の役職やロールも十人十色です。なので、残念ながら、皆様それぞれが抱える個々の問題に対する最適解はご自身で考えていただくしかないです； 。確かにコンサルタントとかに頼めば、問題分解してくれて、最適解を教えてくれるかもしれませんが、その場合であっても、結果的にそれを実行するのは皆様ご自身です。変わらない意思決定者の方々を変えていくことすらも、自分自身の問題の一部として解決を目指すことが大切だと思います。

■ 変わらない意思決定者への「伝え方」のヒント

一般に、「他人を変えることはできない」と言われます。確かに、他人を自分の思うように変える、ということは不可能です。けれども、その人が変わりたい・変えたいと思っているときに、その人のサポートをすることはできます。

なぜそんな当たり前のことを書くのかというと、実際に意思決定者となる人と会話してみると、問題意識は持っているが上手い変え方がわからないとか、また単に知らないから変える必要性を感じていない、といったことも少なくないからです。例えばアジャイルを使った現場改善について考えてみると、その理解度は意思決定者ごとにまちまちです。

• そもそも知らない。（知らないのでやらない or 知ってもやることに対して懐疑的になる。）
• 中途半端に知っている。（懐疑的な人だと「やらない理由」で理論武装していることもある。）
• かつてやってみて失敗した。（あつものに懲りてなますを吹くパターン。割と頭が固くなる。）
• 自分は絶対的に正しいと思い込んでいる。（かなり困った頑固タイプ。）

こんなふうに分類した場合、意外と「そもそも知らないだけ」あるいは「中途半端に知っている」というパターンも多いです。実際、SIer のマネージャクラスの方々を招いて前回のエントリのような話をしつつ、VSTS のデモをすると、「知らなかった」「ぜひ使ってみたい」という F/B になることが結構あります。まず、食わず嫌いなのかどうなのか、またなぜそう思っているのかを確認することが大切です。

それがわかったら、相手の知識レベルに併せて説明を打ち込んでいくのですが、このとき、いくつか重要なポイントがあります。私が思う特に重要なポイントは以下の 3 つなのですが、IT エンジニアは（私も含めて）これらがかなり苦手だと思います……orz。

• 相手のロジックに併せて説明する（相手の土俵で語る）
• 端的かつロジカルに、メリットをズバリ説明する
• 第三者からの援護射撃をうまく使う

［相手のロジックに併せて説明する（相手の土俵で語る）］

特にその必要性を感じていない相手に、「1 日 10 回 deploy するのが重要です！」とか説明しても全くスルーされるのがオチですが、その最大の理由は、自分の土俵から、自分の目線と自分の価値観で物事を語ってしまうことです。これをやってしまうと嫌われるのはもちろんのこと、うっかりすると二度と話を聞いてもらえなくなります；。一般的に、優秀なエンジニアは技術に対して深い愛を持っていることが多く、それゆえに愛が暴走してついテクノロジ目線でモノを語ってしまうことが多いのですが、意思決定者は物事をビジネス目線で見ていることがほとんどです。なので、まず主語を意思決定者にして、相手の目線でメリットを訴求するのが基本中の基本です。（← というか、昔、これに関してさんざん怒られました、私；。今でもなかなか難しいのですが。）

例えば大きな粒度のアジャイルに関してであれば、

• × アジャイルでやると、仕様変更を頻繁に取り込むことができるようになります。
• ○ フルオーダーメイド方式でありながら、「どんなものが欲しいのか」が曖昧にしかわからない状態で最初から契約を切って請負発注すれば、そりゃバッファ積みまくりで高くつくでしょうし、逆に先に請負契約で金額が確定しちゃってたら、できる限りやらずにラクしてお金稼ごうとするに決まってますよね？　これってお互いにとってかなり不健全ですよね？

あるいは小さな粒度のアジャイルであれば、

• × Scrum では、スプリントという固定の長さの期間を区切り、スプリント初日にタスクの作業時間を見積もります。一日一回、残作業時間を足し合わせてグラフ化し、バーンダウンチャートを作ります。
• ○ Scrum のスプリントプラクティスは、見積もりとその振り返りを一定期間ごとに繰り返させるというもので、これを使うと現場担当者のボトムアップの作業見積もりスキルを向上させることができます。

といった感じ。小難しい専門用語を一切使わず、一般人でもわかる言葉で、お客様目線でのメリットを訴求するのが最初のポイントです。

［端的かつロジカルに、メリットをズバリ説明する］

次に重要なのが、メリットをロジカルかつ端的にズバリ説明する、という点。説明がやたら長いお前が言うなというツッコミは甘んじて受けますが（なので私も苦手；）、上の Scrum の説明なんかが恒例で、端的に何がよいのかをスパーンと説明できないと、意思決定者には伝わりません。

IT エンジニアの悪いクセは、原理主義・経典主義に陥りやすいことです。多くの場合、意思決定者にとっては、例えばアジャイルとかオブジェクト指向の定義なんて激しくどうでもよいのです。にもかかわらず、学者肌の人ほど、自分と同じレベルの知識と理解を他者に求めようとする傾向があります。Facebook で先日のエントリの話をした際に、会社の同僚の一人がこう言いました。

「現場に近いところにいる人間からいうと、どれだけの機能が何時、いくらでできるの？という顧客の問いかけに回答できれば手法は問いません」

いやホントこれ。名前なんてホントどうでもいいですから。……といいつつ、私も経典主義の傾向はあるので；、ちょっと意識的に注意してます。ここは自戒を込めて；。

［第三者からの援護射撃をうまく使う］

そして最後に、第三者からの援護射撃をうまく使うこと。これは、当の本人が何を言ってもポジショントークか愚痴だとみなされる危険性が高いという話で、第三者の調査や事例などをうまく使ったり、あるいは第三者を連れて来て同じ話をしてもらう、というのが非常に有効です。

ただしこの際、引っ張ってくる事例の開発規模や特性などが自分のシステム開発に似ているということが非常に重要です。カスタム SI の開発現場に対して、マイクロソフトの製品開発の事例を引っ張ってきても、「参考になる部分がないとは言わないけど、うちとは前提条件が違うから合わないよね」と言われるのがオチです。

違う世界の話と思わせないためにも、例えば以下のようなポイントはぜひ考えてみてください。（また、Web 上の様々な議論を見るときにも、どの世界の話をしているのかを意識することは重要です。話がどうにも腑に落ちない・かみ合わない、という場合は、話しているシステム開発の世界が違う可能性が高いです。）

• 開発規模：数千万円 vs 数億円 vs 数十億円 vs 数百億円
• 業務特性：随時更新業務 vs 塩漬け業務
• アプリ特性：低難易度×多数画面 vs 高難易度×少数画面
• 重視ポイント：安定性 vs 先進性
• 開発形態：内製 vs 外注
• 契約形態：請負 vs 準委任
• 開発チームの技術的熟練度：高 vs 低
• 開発チームの成熟度：自律型 vs 指揮命令型

ちなみに、実際にアジャイルや DevOps などを導入しようとした場合、参考になる類似事例がないことも多いです。そういう場合には、一気にやらずに、ちょっとずつ試験的に導入してみるとか、真似できるところから少しずつやってみるとか、リスクのないシステム（研究開発プロジェクトとか）で試験的にやってみた方がよいです。慣れない開発方法論を振り回すと、開発のリスクも当然上がりますし、痛い思いをすると二度とやりたくなくなるリスクもあります。この辺はうまくバランスすることが大切です。

■ 鶏と卵、先に変わるべきはどちらか？：プロフェッショナルとして

このエントリの最初に、自分でも変えられることと、意思決定者にしか変えられないことに問題を切り分けましょう、という話を書きましたが、これに関するもうひとつ大きな問題として、先に変わるべきはどちらなのか？ という点があります。

例えば、請負契約の境界を超えない範囲で、小さな粒度のアジャイルを回していくために必要なことは何か？ という話題を例にとってみると、「Scrum を採用する」と意思決定者が決めることが先なのか、それとも現場側の人間が「Scrum を回していくために必要な高度なスキルセットを備える」ことが先なのか、という問題です。この二つは鶏と卵の関係を持っていることが多く、意思決定者が判断を下せば現場が変わる、けれども変わっていない現場を前提に意思決定者が判断を下すのは難しい、という側面があり、どちらが先に一歩を踏み出すべきか？　という問題があります。（意思決定者がサーバントリーダシップの場合にはここは問題にならないのですが、多くの日本の現場はそうではないでしょうから、先に変わるべきはどちらなのか？　という点が問題になります。）

この点に関しては、それぞれが同時に変わることを目指すべき……ではあるのですが、少なくとも現場担当者の目線で見た場合（＝自分たちの問題として考えた場合）には、自分たちが先に変わっていないのに他人に変わることや理解を求めることは間違っている、と思います。

• 他人に何かを求める前に、そもそも自分は他者の模範となり得ているのか？
• 意思決定者に話を聞いてもらえるだけの「価値」を自分は提供できているか？

といった点を、厳しく自省することも必要なのではないかと思います。そしてそのためには、

• プロフェッショナルとして、自分たちの価値をちゃんと図る
• そしてその価値を伸ばしていく

ことが必要です。会社という看板が外れたときに、自分は人月何万円の価値のある仕事ができるのか？ を自問し、それを高めるためには何を伸ばしていけばよいのか？ を常に自問することはとても重要だと思います。

本来、意思決定者と担当者の間は、理想を言えば、互いにプロフェッショナルとしての緊張感のある関係であることが望ましいです。けれども実際にはそうなっておらず、意思決定者側にパワーバランスが偏っていることが多い。でもこのパワーバランスを生じさせているのは、単に上下関係や発注関係があるからというだけではなく、担当者側の力量不足という側面も一部にはある、と思うのです。そう話は簡単ではないことは私もわかっているのですが；、でもそういったところを目指して、意思決定者の方ばかりではなく、たまには市場の方も見て 、自分／自分たちの価値を考えてそれを磨いていくことは、ものすごく大切なことだと思います。

■ 最後に：変わらない開発現場を嘆く皆様へ。

最後にポエムを少しばかり。ここまであれこれ書いてきたのですが、こう思われた方も多いと思います。

「開発現場を変えるのって、ちょーめんどくね？」

……はい、ぶっちゃけ私もそう思います。実際、この話は全くもって他人事ではなく、私自身もまさに今現在、似たような課題で激しく悩んで困っていたりするのが実情です；（なので私が解決策みたいな話をすること自体、極めて説得力に欠けることは自覚してますし、書いててグサグサと自分自身に刺さるという；。っつーかマジ変わらないし変えられなくてつらい……orz；）。

でも、こういうのもなんですが、それが現実でありリアルなんですよね； 。正直、無理ゲーだと思うことは多いですし、すべて投げ出して別の素敵な職場に移った方が圧倒的にラクなケースも多いと思います。けれども多分、この話で悩んでいる方の多くは、それができないから悩んでいる。自分のことだけ考えれば転職した方が圧倒的にラク、けれどもメンバーや同僚を放り出せるかといえばそんなこともできないし、共に歩んできた家族やお世話になってきた会社、そして日本に対して背負うものや帰属意識もある。やっぱり今、自分が属しているこの現場をなんとかしたい、と思って悩んでいる人の方が、私は圧倒的多数なんじゃないかと思うのです。

となると、もうどんなに大変でも覚悟を決めて頑張るしかないのですよね；。言葉にすると陳腐でしかないのですが、

• プロフェッショナリズム
  • お互いがやるべき役割、果たすべきミッションをきちんと線引きした上で頑張る
• 相互理解
  • お互いの置かれている立場や気持ちを理解してコミュニケーションを取り、互いに歩み寄る

の 2 つがやっぱり大切で、これを現場担当者と意思決定者の目線に分けて考えてみると、

• 現場担当者としての目線
  • 本来、意思決定者と自分の関係は上下関係ではなく、仕事という場におけるロール（立場）の違いであるはずです。
  • もし今現在、それが上下関係であるのなら、それを対等な（あるいは健全な）関係にするために、自分に何ができるのかを考えて行動に移していくこと、そしてそれを以て意思決定者に適切に働きかけていくことが大切なのだと私は思います。
• 意思決定者としての目線
  • 今のやり方（発注方法とか仕事の進め方とか）が完璧だと思っている人など、多分どこにもいないと思います。問題意識を持ちながらも、なかなか解が見つけられずに困っているのが実態ではないでしょうか？
  • もしそうなら、その問題を一緒に考えながら解決していける、プロフェッショナルなスキルを持った会社や担当者を探して相談するのがよいと思います。実際、そういった人たちは上手いやり方を知っていることがよくあるもので、その力を上手く引き出すこともまた、意思決定者としての役割です。自分たちにとっての最適解は、相対する会社や担当者とともに作り上げていくしかないものだと思います。

といった具合に、それぞれの立場毎に問題を分解して『自分のコト』として捉えることが大切、だと思うのです。

正直、道は長いですし、どんなに頑張っても完全に解決できるものではないかもしれませんが、とはいえあきらめたらそこで試合終了です。現場担当者と意思決定者とが、互いにプロフェッショナルとして仕事に関与し、一方で飲み会ではつらさを語り合えるような関係になれるところを目指して、きちんと問題分解し、まずは自分にできることから一歩ずつ改善を進めてゴールに近付くことが大切……というよりそれ以外他にないんじゃないかな、と思います。このエントリが、改善を目指す皆様にとって、多少でも何かのヒントになれば幸いです。

＃ ……つらくなったら、みんなで語り合いたいです、ええ；。
＃ そしてもっと上手い方法やテクニックがあったら教えて欲しいです。いやマジで；；。

というわけでここ数回、「ゆるっとした」話をつらつらと書きましたが、こういうゆるふわ系エントリはホントに書くのが難しいです；。最後まで読まれて気分を害された方もきっといらっしゃると思いますが、その場合はすみません ＆ ごめんなさい；。個人的には、かちっと白黒つきやすい話の方が気持ち的にもラクなので、次回は今まさに旬の、ASP.NET Core 1.0 な話をしたいと思います、はい^^。