現場を改善するというのは難しい。そして徒労である。
こちらの記事を読んで、当時のことを幾ばくか思い出すきっかけになった。
私も実際に現場の改善に取り組んだことがある。ただ、その中には失敗だけでなく成功もある。というか、多くの失敗から成功させるために何が必要なのかを得たという感じで、成功したものは後半に行ったものになる。成功といえるものの中で大きめなものは、以下の二つになる。
- Gitによるバージョン管理と、タスク管理ツールの導入(当時書いたもの)
- 開発にJavaScriptフレームワークを導入(当時の検証結果をまとめた記事)
私が身につけた手法が、改善を目指す誰かがくじけないために有用なこともあるかもしれないので、ここで得られた知見を紹介しておこうかと思います。つまりこれは、ポエムです。
前提: 改善できないのは特別なことではない
何かを改善したいと行動してみる。上手くいかない。すると「周りの意識が・・・」と思ってしまいがちです。その考えが、世間的に補強されていれば(=みんなGitを使っている、とか)なおさらです。
ただ、これはあなたの職場がとびきり悪いわけではなく、またあなた自身にも起こっているごく普通のことです。
たとえば、「英語の勉強を今すぐ始めましょう！技術文書は英語で書かれているし、やっぱり英語は重要ですよ！」と言われてTOEICのテキストを差し出された時に、あなたは「GOOD」と言って受け取りその日から勉強に励むでしょうか。「まあ、わかるけどまた今度な・・・」ということが多いのではないかと思います。
このセリフは、ちょうどあなたが改善を提案したときに一番良く聞く言葉です。
メリットが明らかで、今すぐやらない理由はないのに、なぜ始めないのでしょうか。理由として良くあるのは、「めんどくさいから」「忙しいから」「別段、今英語力で問題を感じてないから」といった、特に理由ともいえない理由です。そして、これらの理由はあなたが提案を拒否されたときの理由として、一番憤慨するものです。
人はいいとは思っても、必然性がなければなかなか行動できないものです。たとえ既にGitの導入をしている企業でも、ブランチ運用やコミット単位を変えましょうと言ったら色々紛糾するでしょうし、これは技術レベルの差異によって発生する現象ではなく、純粋に人間の性質としてそうなのです。
これは何を意味しているかというと、人間の意識に訴えて行動を変えさせるのは難しいと言うことです。
あなたも一度くらい「勉強しろ」「あなたのためを思って」「勉強しないといい学校には入れない」と言われてイライラしたことがあると思いますが、こうした相手の意識を変えようという試みは概ね上手くいきません。ここまできたら、これをちょうど置き換えて「Gitを使え」「チームのためを思って」「Gitを使わないと技術力が上がらない」と言っても通じない、そして相手をイライラさせてしまうのは自明だと思います。まして、あなたが相手にしているのは一人ではなくチームメンバーという大きな集団です。上手くいくはずがありません。
ではどうすればいいのか、という話ですが、そこで重要な点が以下の2つです。
- 必然的状況の共有
- 効果を体感してもらう
これらは、いわば改善の火種を作るためのテクニックになります。これを煽ってチームや組織に波及させるには、どこに火種をつけるか、どう広げるかが重要になります。
- 最初のひとりを得る
- 外から扇いでもらう
上記の4点について、順に解説をしていきたいと思います。
必然的状況の共有
バージョン管理ツールを導入する契機になった(した)のは、アプリケーションの複数会社展開でした。ベースとなるアプリケーションは同じなのですが、各社個別の機能があり、それぞれ独自に機能を持っている、という案件でした。聞いてぱっと思いつくとは思いますが、これはGitのmasterとbranchが威力を発揮する状況です。
そもそも、Gitが威力を発揮するシーンは環境によってはそんなになかったりします。悲しいかな、コピペの多い環境ではいわゆる共通モジュールがなくそれぞれが一本のプログラムとして独立していることが多いので(共通にまとめるべきところをコピペしている)、マージの恩恵がそもそも少なかったりするのです。そうした状況では、Gitを導入しようといっても「何のメリットがあるわけ？」となるわけです。
しかし、この案件に限ってはそうではありませんでした。
- 今は数社であるが、今後ほかの会社にも展開が進む可能性がある
- ベースとなる機能を展開する際に、各会社に速やかに、そして過誤なく機能を展開する必要がある。これを手作業で行うのは現実的ではない
これは、プロジェクト全体にとって、バージョン管理ツールの導入が必要な必然的状況でした(そう演出したところもありますが)。
これは、「バージョン管理ツールを導入しなければいつか重大な障害がおこる」というのとは異なります。なぜなら、まだその障害は起こっていないからです。仮に実際に障害が起こっていても、数件しかなければ実感には個人差があるため、状況の共有には少し遠いです。
必然的状況を共有できるかは、素朴な感覚を共有できているかによります。上記で言えば、関係会社の展開は幾度となく繰り返されてきたことで、またピンセットでつまむようなマージ作業には全員が辟易していました。そんなのないほうがいいよね？というのは、大上段の理想論ではなく、誰もがうなずく素朴な願いだったわけです。
こうした「誰もが頷く状況」が来るかは若干運もからみますが、演出である程度作ることもできます。すべての開発環境・ツールは「開発を効率化」してくれるためにあるので、「短納期」「低コスト」といったキーワードがつく案件は、「誰もが頷く状況」のトリガになる可能性があります。
しかし、状況は整っていても「あなたの効率が良くなるだけ」では導入はされません。皆慣れた手法があり、それに熟練しています(しかも無駄にそのやり方で仕事が速い人がいたりする)。それより良い！と主張するにはそれだけの説得力が必要です。そして、人は人に言われた甘い話をえてして信じないので、相手に「体感」してもらうことが重要になります。
効果を体感してもらう
Gitが導入されていない環境で、あなたがデモのためにコマンドプロンプト(ターミナル)を開いたとしたら、もう失敗したと思っていいでしょう。その瞬間、Gitは「使うのがとても難しい手に負えないもの。あいつにとってはいいものなんだろうけどな」になります。その後はそんなことをやるぐらいなら、効率が悪くても今まで通り慣れたほうが安全・安心、となりそこで試合は終了します。
コマンドくらいで、と思うかもしれませんが、これは若かりし頃、Z会やチャレンジを積んでしまい「これができるならそりゃ成績は上がるだろうよ」と心の中で毒づいてしまった人は相手を責めることはできません。誰だって遠くのメリットより近くの苦悩のほうが重要なのです。ここで「技術者なら～」と意識に訴えても失敗するのは前述の通りです。
効果を体感する前にシャッターが閉じられたらおしまいなので、ここで重要なポイントをいくつか挙げていきます。
メリットファースト
何はともあれ、享受できるメリットを最初に提示しましょう。
Git(というよりGitHubになりますが)ならGUIを使って差分がみられる画面、コメントがつけられる点、JavaScriptフレームワークなら、今までこれだけ書かないといけなかったコードがこれだけで、という点・・・など、どんないいことがあるのかを先に伝えましょう。
重要な点として、これは「あなた」にとってメリットではないことに注意してください。例えば、きれいにコードが書ける、というのは「あなた」にとってのメリットですが、チームにとっては(悲しいかもしれませんが)まあ、どうでもいいことです。
チームメンバが苦しめられている何が解消するのか、今手間になっている何が簡単になるのか、相手の実感に根差した「メリット」を提示することが重要です。あなたのメリットのために付き合わされてる、と感じられたら改善は絶対にうまくいきません。
敷居を徹底的に下げる
メリットがわかっても、難しければ使ってくれないのは先のとおりです。なので、ツールを利用する敷居を徹底的に下げます。経験的には、以下は必須です。
- 日本語化されている
- GUIがある
- そのツールについて、日本語で豊富な情報がある
「日本語での豊富な情報」については、なければ自分で増やすというテクニックがあります(この記事はそのために書いたものです)。当時は、実際にハンズオンをしてもらい、詰まったところを記事にしたりWikiに書いたりとしました。
「メリット」が「簡単に」得られるようにし、効果を体感してもらう、というのが重要ということです。
最初のひとりを得る
さて、ツールの導入はまだいいほうで、それより「コードをきれいに書く」「モジュール化する」といったところはさらに難易度が高いです。なぜなら、これらはツールを導入したからきれいなコードが書けるようになった、という単純な話にはならないためです。
しかし、こうしたパターンも基本は上記の点と変わりません。共通化しなければテストケース数が増えてしまう、またこう書くとテストが一回で済む、といった状況やメリットを伝えていくわけです。決して、「きれいじゃない」とか、相手のメリットにならないことを指摘しないよう注意してください。それはあなたの価値観(メリット)で、相手にとってのメリットにはならないからです。「xxさんがうるさいから言われたとおりに書いた」となったらうまくいきません(いきませんでした)。
こうした個々人の改善(スキルアップ)に依存するケースの場合は特に、火口となる「最初のひとり」を得ることがとても重要になります。そして、その「最初のひとり」は「あなたと同じ属性」の人ではいけません。「あなたと同じ属性の人」、つまり改善を思い立つような人ははっきり言って少数派なので、そこで徒党を組んでも「あいつらがまた何かやってるぞ」と思われるのが落ちだからです(落ちでした)。多数派の「ごく普通の人」に最初のひとりになってもらうことが重要なわけです。
だんだん生々しい話になってきますが、大抵の場合仕事をお願いするパートナーの方のほうが技術に敏感でよく吸収してくれたりするので、私の場合はそこからコードをこういう風に書くと処理が簡単に書ける、次の案件にも使える、修正した後の再テストが楽になる、という形で伝えていきました。そうするとパートナーの方のほうから開発の時に「ここはこういう風にはしないんですか？」という感じで突っ込みが入ってくるようになるので、そうするとだんだんといい感じに広がってきます。
外から扇いでもらう
モチベーションを、外から誘発するという方式もあります。これには二つパターンがあります。
- 競合他社: うちはxx開発方式を導入しているぞ
- 顧客: きみらの開発環境は、先進的な企業と比べてどうなのかね
こうした外圧があると、雰囲気が変えられる可能性があります。特に現場は「顧客に言われていないことは極力やらない」というスタンスなので、顧客に言ってもらえれば弾みがつく、というのは大きいです。ただ、自分達側から顧客に提案するのはかなりハードルが高かったりします。それは、以下のような事態を招く可能性があるためです。
- 自社の落ち度をさらすことになるので、これまで何をしていたんだ、という話になる
- 今までより開発が効率化できる、というと「じゃあ、今までより安くてええんやな」という風になり単価を下げられる可能性がある
- 改善効果の(定量的な)報告を求められる。多くの場合非常に面倒なので、「忙しいのに仕事が増えた」としてチームメンバーから不満が出る
ただ、最終的に開発現場全体で導入するならこの提案は避けて通れないシーンでもあり、上記のような事態を招かないためには、今まで述べてきたような草の根活動以外に、顧客との信頼関係も必要になります。
そういう意味では、顧客にあなたの仕事、そして取り組んでいる内容を見てもらえる機会があるか、というのは重要な要素になります。そうした仕事や活動の積み重ねが、信頼関係のベースになるためです。もし顧客から遠いようであれば、改善は草の根活動以上の天井を超えられないかもしれません。
進捗会議などに同席できればそこできちんと発信するというのが定石ですが、そこからさらに遠い、そして進捗会議に出席する人を巻き込むのも難しい、という場合もあります。そうした場合には望みは低いですが裏技があって、外部に記事を発信したり、カンファレンスに登壇することでその記事から顧客に知ってもらうという技です。ウルトラCみたいな技ですが、顧客側にアンテナを張っている人がいれば見つけてもらえる可能性があります。
以上が、私が文字通り体得したメソッドになります。これが、誰かの参考になれば幸いです。