あけましておめでとうございます。
この記事は DevLove Advent Calendar 2013 「現場」 の60日目の記事として書いています。
滾る進撃のスクラムマスター 伊藤宏幸（The Hiro）さんからのバトンを繋がせてもらいます。
自己紹介
昨年の「DevLOVE現場甲子園2013」をキッカケに始めたBlogですが、今年も可能な限りで継続していきたいと思っています。Twitterアカウントと同じくorinbouというHNでBlog書いてます。派遣や受託でソフトウェア開発を行う小さな所謂SI屋で働いています。現場甲子園では団長の中村洋さん率いる「団」チームで、二回裏に「世界を変える前に現場を変えよう」というタイトルで発表させてもらいました。自己紹介は省略しますので、気が向いたらBlogのプロフページでも見てやってください。
自分にとっての現場
私の普段の現場というのは、お客様先です。何名かの自社メンバーと共に客先に常駐し、そこで開発チーム（お客さん＆自社メンバー）を構成するというカタチで日々の開発を進めています。チームの構成人数は時期にもよりますが、大体5〜10名くらいの規模です。
私は、もともと存在していたプロジェクトに追加メンバーとして投入されて、今の現場に来ました。最初は3ヶ月の短期支援という話だったのですが、紆余曲折を経て1年半程経過した今現在もその現場で開発を行っています。もちろん投入当初のプロジェクトの次のプロジェクトへと移っていますが…
投入後しばらくして現場の空気に慣れてきた頃、チーム内の作業がひどくタテ割りでメンバー間がサイロ化していることに驚かされました。もうアジャイルとかWFとか関係なく、基本的な情報共有がないことで日々様々な問題が発生していました。投入当初まず短期支援ということもあって、とにかく任された業務を仕上げることに注力して、ひたすら耐えていました。が、支援期間が半年延長されるとなった時から、これは何とかしないと（特に最初はチームの開発効率云々よりも自分のストレス的に）マズいと思いました。開発チームのメンバーは、自社メンバーだけでなく、お客さんも居ます。しかも、私はPMでもPLでもなく、イチ支援メンバーという立場だったので、何から手を付けようか、どうやって進めたらいいか…という点でスタートが非常に難しかったです。本当に、どうしたもんかと困っていたのですが、たまたま若手の開発メンバー（お客さん）と共同作業することになったのをキッカケにして、ある期間だけ2人で次の事を段階的にやってみました。なるべく自然に、それとなく始める感じで…
- 朝会（毎朝私から勝手に押しかけて開催してみる）
- ふりかえり（なんちゃってKPT）
- Redmineの導入（廃棄予定サーバーを間借りしてタスク＆バグ管理）
元々そういうことが無かったこともあって、比較的早く効果を感じることができました。そんな感じで、しばらく継続していると、私より後に開発チームに合流した開発メンバー（お客さん）にも、同じように現状に問題を感じている人がいて、私達の活動に関心を持ってくれていることが分かりました。例えそれが正しいと分かっていても、現場で今までやったことがない事を試して続けるのって、一人だとそれだけでなかなか大変なので、それがわかった瞬間というのは物凄く嬉しかったです。それだけで物凄く勇気ももらえます。これがデレク・シヴァーズ氏のいうところの「最初のフォロワー（追随者）の重要性」なのかな？とか思いました。
その後は、その仲間と協力しながら、アイデアやタイミングを相談し合いながら地道にチーム内へと展開していくことができ、開発チームとして先ほどの3つのことを定着させることができました。朝会で、個人タスクの抱え込みも減りましたし、問題があった時すぐにフォローし合うこともできました。期日と各個人が抱えてるタスクのクリティカル・パスを見える化するなどして、危機感や目的を共有をすることでモチベーションも上がりましたし、数値化してませんが、生産性も良くなっていったと思います。Redmineの運用はタスク管理よりバグ管理専用で使う方向にになっていきましたがリリース管理やバグ管理の情報が蓄積＆見える化されるようになりました。ふりかえりは、後半かなり形骸化してきましたが、問題が問題のまま残り続けることが減り、以前よりは少しはマシになりました。そしてこれは「一兵卒でも現場を変えることができる」という貴重な体験にもなりました。以前自分がPLやって半トップダウン的にやったのとは対照的な体験にもなりました。
当初は、まずなんとか自社開発メンバーを巻き込んで、それを突破口にしてなんとか展開していこう…とか考えていましたが、まさか最初のフォロワーがお客さんで、その後も最も協力的というか、一緒に悩んでアイデア出して、実践に導いてくれたのもその人でした。これは私にとって、とても幸運なことだったと思います。それと同時に、例えそういう人が近くに居たとしても、最初の一歩を自分から踏み出していなければ、その幸運にも巡り合えなかったんじゃないかと思います。こうすれば必ずうまくいく…なんていういわゆる「銀の弾丸」なんて都合のいいものはありませんが、それぞれの立場や状況で、思い考えているだけでなく、行動するということが必要なんだと改めて感じました。
で、その後（今現在）の話です。前述のプロジェクトは終了し、同じ現場で、次のプロジェクトが始まっています。チームメンバーや体制も少し変わりました。ここからは少しネガティブな話になりますが、今モンモンと感じている暗黒面（Dark Side）のことを最後に書いておこうと思います。
前述のとおり、現場をボトムアップで良くしていくということは、できると思います。状況によってはそれすら難しいこともあるかと思いますが、特にスタートが「無」の状態であれば、ちょっとしたこと（例えば朝会だけでも）ですぐに効果が出ると思います。小さな成功／失敗を積み重ねていくことで、経験が蓄積していき、チームとしても個人としても成熟していくのだと思います。が、プロジェクトは有期限の活動であり、メンバーも都度変わります。毎回のプロジェクトがほぼ完全リセットされて、またゼロからやり直す…ということになるとなかなかしんどいですね。まるで賽の河原の石積みのように…全然先へ行けない。また最初の仕込みからやらんとイカンのか…みたいな。その辺は、各々の現場（業種や業界）によってかなり大きく違うと思いますが、所謂SI屋としての共通の悩みなのかもしれません。とはいえチームや個人を成長させるためにプロジェクトが存在している訳ではなく、プロジェクトによって開発されたアウトプットが価値を生む訳なので、その価値を生み出す際の利点として（契約時に？）合理的に説明できる根拠がないと難しいですね。ソフトウェア開発というものに関しての理解や経験を、契約に関わる主要な人全てが持っている訳もないですし、基本的に今までの契約の延長線上で考えるでしょうから。それを求めるのは開発者が「完璧なユーザー」を求めるのと同じくらいナンセンスなのかもしれません。
また、社外の現場で作業している限りは、文化や伝統というものは、常駐している場所の影響を大きく受けることになります。特に現場がある程度歴史ある会社だったりすると、現場をカイゼンするための取り組みも、結局は「今まではこうだった」みたいな流れに押されてしまうことが多いです。これは自社内での開発時には、そこまで気にならなかったことでもあります。何十年もかけて醸造されてきた文化や伝統というものは良くも悪くも、私達の日々の活動に影響を及ぼしてきますし、加えて、政治的なパワーゲームなどもあり、なかなか一筋縄ではいきません。現場のPMがちゃんと管理しない（プロジェクト開始直後から「気合い」を前提として、さらに割り込みを増やす…etc.）というようなことが日常茶飯事だと、モチベーションも品質も↓になります。それが俺流、あるいは、文化／伝統だと言われてしまうと正直なかなか辛いものがあります。
ふりかえれば昨年は自分が関わったプロジェクトを少しでも良くしたい…という思いで夢中で駆け抜けてきた時期だったように思います。もちろん今も変わらずその思いはあります。が、プロジェクトを重ねて行く中で、今日より明日、明日より明後日が良くなっている…という改善サイクルの理想とのギャップをどうやって埋めていこうかと悩んでいる時期（これはanytimeかｗ）でもあります。もちろん、今できることを全力でやるしかないのですが、場合によってはある程度トップダウンで物事を進められる力が必要だなと感じることが多くなってきました。ある程度の裁量権というか決定権と言うか…そのためには、自分にできることを増やしつつ、そういう立場へ自分から名乗りをあげて進んで行かないと行けないのかもしれません。
そんなことを思いながら、年も開け、また今年の仕事が始まりますが「機雷がなんだ！全速前進！」の精神で、今年も頑張りたいと思います。
現場をあきらめない。。
We energize us!
次の人へ
次は Mitsuo Hangai (bangucs) on Twitter さんへバトンをお渡しします。
どうぞよろしくお願いします！
