機雷がなんだ! 全速前進!

SEというかプログラマというか、日々のエンジニア生活の中で体験したことなどを中心に書き残しています。

Team Geek を読んで思ったこと

社内の同僚が読んでいた本「Team Geek」が面白そうだったので借りて読んでみた。

自分メモとして特に印象に残った点と感じたことを書き留めておこうと思う。

f:id:orinbou:20140111220255j:plain

この本が全体を通して大切だと言い続けていること。

それは、優れたソフトウェアを作るチームではHRT(ハート♥と読む)が重要だということ。

  • H:Humility(謙虚)
  • R:Respect(尊敬)
  • T:Trust(信頼)

この三本柱は、人間関係を円滑にするだけでなく、健全な対話とコラボレーションの基板となる。そしてこうも言っている。

  • あらゆる人間関係はの衝突は、謙虚・尊敬・信頼の欠如によるものだ。

と。著者(Fitz&Ben)は、世界を変えるような功績は、インスピレーションの閃きとチームの努力であると述べ、本の中で、NBAバスケットボールのマイケル・ジョーダンとチームの関係などを例に出して、

  • ソフトウェア開発はチームスポーツである。

というメタファが出てくるのだけど、これが自分にはものすごくにハマった。自分がバスケをやっていたせいもあるのかも。ビジョンを共有し、仕事を分担し、他人から学ぶことの重要性は、まさにバスケと同じだな…と思ったことが、かつて自分にもあったなぁと。最近バスケしてないせいか、いつからか忘れてしまっていたようだ。そういえば、草バスケ選手としての自分のプレースタイルも、飛び抜けた身体能力があった訳でもなかったし、他のプレーヤーとコラボレーションすることで結果を出してきたように思う(恥ずかしいくらいに全く本当にしょぼい結果だけど)。というより、そうするしか無かったんだけどw実際、そういうスタイルになってからの方が試合で使ってもらえることが多くなったし、他のプレーヤーからも一緒にやってて楽しいとか、やりやすいとか言われることが多かったような…いわゆるつなぎ的な地味なこと(リバウンドやDFのカバーリングとかね)を淡々とやることが多かったな。自分が何点取ったとかより、チームとして機能するにはどうしたらいいか?みたいなことをいつも考えてた。思えば、いつも職場でもそんな感じだw反面、これは決定的な強みがないっていう弱さを隠すための「逃げ」なんじゃないかと感じることもあるので、もちろんコアとなる強みは作って置くべきだと思う。この辺は表裏一体なのでバランスが大事なのかな?

 

次に気になったキーワードは「ミッション・ステートメント」。この言葉を最初に知ったのはフランクリン・コヴィー氏の「7つの習慣」の研修を受講した時だった。ようは企業サイトによくある経営理念みないな「実際の行動に資する指針・方針として明文化したもの」のことなんだけど、これは別に企業に特化したものではなく、例えば個人やチーム、プロジェクト毎に作成してもいい。エンジニアリングチームのミッション・ステートメントであれば、チームの方向性を定義して、プロダクトのスコープを制限して、やること/やらないことを明確にしておくことが、場合によっては年単位で仕事の節約になる可能性もあると書かれていたのだけど、これは物凄く共感できる。これはアジャイル開発では、インセプションデッキに相当するのかな?いずれにせよ、方向性というか指針を明確にして、共有して常に意識できるようにしておくことで、迷った時に背中を押してくれると思う。言葉は違えど、大事なことっていうのは、共通するものがあるな、と感じた。

 

最後に、管理者(マネージャー)について。プロジェクトを進めるためにはリーダーが必要になるが、望まずとも気付いたらそういう役回りになっているという苦悩のことを「マネージャー炎症(manageritis)」と呼ぶとかwそれは置いといて、この本で理想としているのはサーバントリーダーで、時代遅れの管理者をトンガリ頭のマネージャー(@Deprecatedマネージャー)と呼んでいる。時代遅れのマネージャーというのは、軍隊の階級制度を参考にして、100年以上も昔の産業革命の時に導入されたモデル。決まった単純な作業を行う場合は、労働者をロバのように扱う「ニンジンとムチ」によるマネージメントは有効だっただろうが、創造的な考えや問題解決が必要なエンジニアリングでは全くナンセンス!つまり、封建的なカタチでガチガチと管理するやり方は、創造的なチームを活かすどころか、殺してしまう。上から押さえつけるように管理するのではなく、チームが有効に機能するように、執事や召使いのようにチームに奉仕するサーバントリーダーシップこそが、いま求められている新しいカタチなのだと言っている。これはスクラムでいうところのスクラムマスターとも非常に似ているなと思った。アジャイル開発において、ソフトウェアは、工場のベルトコンベアで製品を作るのと違い、人間が作るものだという「人間中心」を前提にしている。技術だけじゃなく、人間であることを前提とした感情やコミュニケーションも重視し、生涯を取り除くという仕事をすることは、物凄く理にかなっていると感じる。

 

他にもグッと来た点が、いろいろとあったけれどキリがないのでこの辺で。

内容としても学びがあるし、読み物としても面白いので、興味がある人はぜひ読んでみることをオススメします。

 

 

 

エナジャイズドな現場を追い求めている道半ばで思ったこと

あけましておめでとうございます。

この記事は 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かw)でもあります。もちろん、今できることを全力でやるしかないのですが、場合によってはある程度トップダウンで物事を進められる力が必要だなと感じることが多くなってきました。ある程度の裁量権というか決定権と言うか…そのためには、自分にできることを増やしつつ、そういう立場へ自分から名乗りをあげて進んで行かないと行けないのかもしれません。

 

そんなことを思いながら、年も開け、また今年の仕事が始まりますが「機雷がなんだ!全速前進!」の精神で、今年も頑張りたいと思います。

 

現場をあきらめない。。

We energize us!

次の人へ

次は Mitsuo Hangai (bangucs) on Twitter さんへバトンをお渡しします。

どうぞよろしくお願いします!

 

[2013/11/28 (木)]リーン開発の現場 塹壕コミュニティ「リーンとカンバンの本質と現場改善 〜平鍋さんと現場課題を考える〜」に参加してきました

年始の時間を使って、昨年中に書きかけのままになっていた記事を更新しておくことにします。

 

昨年2013/11/28 (木)に、勉強会「リーンとカンバンの本質と現場改善 〜平鍋さんと現場課題を考える〜 - リーン開発の現場 塹壕コミュニティ | Doorkeeper」に参加してきました。この勉強会は、藤原大さん、市谷さん、角谷さんが翻訳、監訳された書籍「リーン開発の現場〜カンバンによる大規模プロジェクトの運営」の出版を契機に開催されたイベントでした。

 

f:id:orinbou:20140103012158p:plain

 

響いたキーワード:

"Stop starting Start finishing"(始めるのをやめよう。終わらせることを始めよう)

 

ということで、関連資料URLなどをメモがてらまとめようと思っていたのですが、勉強会終了後に藤原大さんから参加者宛にまとめメールを送っていただいたので、ここではそのまま掲載させて頂きます。

 

当日のtogetterは下記のとおり。

リーンとカンバンの本質と現場改善 〜平鍋さんと現場課題を考える〜 - Togetterまとめ

 

今回の勉強会は、同僚から誘われて参加したのですが、社内の人間から社外勉強会に誘われたのは初めてでした。今までは、専ら誘う側でしたので、それだけで、なんだかとても嬉しかったです。

 

平鍋さんの話も非常に面白かったし、学びのための良い契機になりそうです。

 

短かったですが、最後に、各自の現場の悩み事を相談し合える時間を取ってもらったのも嬉しい配慮でした。さすが市谷さん

 

せっかくなので自分の現場で今困っている(た?)「ふりかえりの形骸化」について質問してみました。私の現場ではKPTをホワイトボードに書き出すカタチでふりかえり会をやっていたのですが、それだと声のデカイ人ばかりが話をしてしまったり、Tryは言ったもん負けになったするなどの問題が発生しやすかったのです。他の参加者の方によると、KPTの最初に時間を取って各自で黙って付箋に書き出して、それを順番に貼っていく…などの配慮をすることで、そのような問題は改善できますよ!というアドバイスをいただきました。やはり、ああいう場で、他の現場のやり方を教えてもらったりすることは、非常にありがたいなぁ…と思いました。

 

さらに質問者の特典として「I LOVE 現場」ステッカー(↓)をいただきました(^^)

これも嬉しかったですね。

f:id:orinbou:20140103015553j:plain

 

そんな訳で、機会があれば、是非また参加したいと思います。

 

[2013/11/26 (火)]アジャイルサムライ横浜道場の忘年会でLTしてきました

もはや去年のことになってしまい恐縮ですが、自らの活動記録的な意味も含めてブロクを更新しておくことにします。

昨年末「アジャイルサムライ横浜道場 特別編 忘年会&LT大会」に参加してきました。で、せっかくの機会なんで忘年会LTへ登壇してみることに…

昨年は「DevLOVE現場甲子園2013」に続き、登壇の機会に恵まれた年になったのでした。

ありがたやありがたや(^^)

f:id:orinbou:20140101224815p:plain

タイトル:「アジャイル開発してますか?」

 

私の現場は、やんごとなき諸事情のため「アジャイル」という言葉をあまり使えないという状況に置かれているのですが、それを「隠れキリシタン」になぞらえて「隠れアジャイラー」という風に表現してみましたw

f:id:orinbou:20140101230100p:plain

 「アジャイル」と声高に言うと…(↓)…みたいなw

f:id:orinbou:20140101231927p:plain

とは言え「アジャイル」という言葉で遊んでいる暇はないのです。 アジャイルに関わらず、日々の戦場(現場)を生き抜くための武器をひとつでも増やすことに意義はあると思うのです。

f:id:orinbou:20140101232452p:plain

目的重要!!ですよね。でも常に確認しないとすぐ見失いそうになります。

f:id:orinbou:20140101232700p:plain

活気ある職場と、生み出す価値に目を向けることが重要かと…

もちろんコンテキスト次第なので、あくまで私のコンテキストでは…ですが

f:id:orinbou:20140101232624p:plain

(再)目的重要!!ですよね。時々、手段と目的が逆になってしまうときもあります。

意識高い(つもりの)自分に酔いしれて、今までのやり方や、別の手段のダメ出しばかりしていると、結局ひとりよがりでしかありませんよね。自らの経験から、特にミーハー期は注意が必要だと思います。名著を読んで気持ちが高ぶってる時なんかは特に。

f:id:orinbou:20140101233556p:plain

昨年はTwitterなどで「アジャイル開発」という言葉でいろいろと議論が盛り上がって(ex.アジャイルの正しい実践方法 や 「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ - Publickey など)いましたが、私としては、今の自分の現場で役立つのか否かというのが一番の感心事であったので、一歩引いて見ていました。もちろん、開発手法の特徴や利点や欠点について理解するための議論が不要と言っている訳ではありません。ただ、初志や目的を忘れて、開発手法の優劣ばかりを議論するのはそれぞれのコンテキストに依るところが大きいので今の自分にはあまり重要ではないと感じました。

f:id:orinbou:20140101233614p:plain

WFであれアジャイルであれ、イイ!コイツは役に立ちそうだ!と思ったことは何でも取り入れるという貪欲さが必要だと思うのです。特に今の自分(達)には。

f:id:orinbou:20140101233634p:plain

アジャイル本とか読んで最初に気にする事って、そのやり方が「正しい(ちゃんとした)アジャイル」になっているのか?とかだったりします。少なくとも私は、初期の頃はそんなことを気にしていました。でも、今の開発手法が正しいアジャイルかどうか?を議論するくらいなら、どうやったら問題を解決できるか?あるいは、もっと上手くやれるのか?っていう方に力を使うべきだと思うように変化していきました。物凄く当たり前のことではありますが…ちょっと恥ずかしい反省点です。

f:id:orinbou:20140101233700p:plain

それぞれの立場や状況において今やれることをやる!!

結局はこれに尽きるのかなぁ・・と。

できることをもっともっと増やしていかんとなぁ…っていうのはアリますけどね。

f:id:orinbou:20140101235118p:plain

昨年は、現場でいろいろと試してみて、そんなことを考えされられた一年でした。

 

最後に、私が好きな言葉で〆てみました。それは、アジャイルは「やる(Do)」のではなく「なる(Be)」という心構えが必要なんだということ。ちょっと精神論というかphilosophyな世界の話になってしまいますが、アジャイルの前提がプロセスよりも人にフォーカスしていることから考えても、絶え間なく継続的にカイゼンし続け、顧客やユーザに価値を提供し続けるということは、結局そういうことになるのではないかなぁ…と。それを実現するために、様々な手段(CIやiterationや自動テストなどなど)があるのだと

f:id:orinbou:20140101235521p:plain

 

そんな訳で、来年(もう今年ですがw)も心を新たに、昨年の活動も踏まえていろいろと挑戦していきたいと思います。

 

ご指導ご鞭撻の程、よろしくお願いします。

 

[2013/11/09 (土)]DevLOVE現場甲子園2013に参加&登壇してきました

少し前の話になりますが「DevLOVE現場甲子園2013」に参加してきました。

そして、この日は私にとって人生初の登壇という特別な日になりました。

 

f:id:orinbou:20140812091632p:plain

 タイトル:「世界を変える前に現場を変えよう」

 

当日の朝4時までスライドが完成せずに焦り、寝不足でフラフラしながら参加したタフな一日となりましたが、それをつい忘れてしまうくらい刺激的な時間でした。

 

私は団長の中村洋さん率いる「団」チームで、二回裏の打順でした。驚くべきことに、というか嬉しい事に、私なんかのプレゼンを聞いてくれた人が沢山いて、さらに、知り合い以外の人も何名か再演投票を投じてくれたことに感動しました。もともと人前で話すことにあまり慣れていないこともあり内心ドキドキしていましたが、当日は楽しんで話すことができました。夢中で話し過ぎて、最後のオチまで到達できなかったのは反省点ですがw

 

発表スライドの準備は少々難航しました。長い間スライドを作った記憶が全くないので、恐らく社会人一年生の時に、新人研修発表でやったっきりだったかもしれません。だとすると既に10年以上の年月が。。。Keynoteを初めて使うってものあり、なかなかしんどかったです。発表資料の共有については、他の登壇者の方々が次々とSlideShareへUPしていく中、今回は諸事情によりUPできないのが悔やまれます。次回はちゃんとUPできるやつを作りたいと思います。

 

さて、発表スライドにも盛り込んだとおり、

ここ一年、現場の改善活動や社内勉強会など、拙いながらも、いろいろな取り組みを企画し活動してきた訳なのですが、今回の発表スライドを作るという作業過程の中で、自分(達)が、やってきたことの棚卸しができたのも、ひとつの収穫になりました。今後の進むべき道を考える時に、役に立ちそうです。

 

下記のように、頭の中のモヤモヤをひたすらMYホワイトボードに書きなぐっただけですが、なかなかスッキリするもんです。

 

 f:id:orinbou:20131021071055j:plain

(仕事の)現場と社内外の勉強会やイベントでやったこと、問題、気付きなどを書き出して相関関係などを見える化してみました。一人で頑張った結果、度々心が折れそうになったので、共感してくれる人を探して、なるべく一人で頑張りすぎないようになりました。

 

f:id:orinbou:20131021071143j:plain

活動クロニクル。とにかく夢中でやってきたことのひとつひとつが、不思議と次の活動へと次々と繋がっていっていたことも分かりました。

 

f:id:orinbou:20131021071205j:plain

なんでわざわざ頑張ってこんなことやってるのか?という自分自身のモチベーションへの素朴な疑問に対して、背景/動機と自分の業務経歴を並べて見える化してみました。そういえば、活動の原点は書籍「アジャイルサムライ」だったことを思い出しました。

 

 

思い返せば、DevLOVEへの初参加は、忘れもしない去年の今頃の2012年12月5日(水)のことで、確かアジャイルビュッフェへの誘いというのが最初の参加だったと記憶しています。

電車を乗り間違えて遅刻してしまい、急いで入口から一番近くのテーブルへ飛び込んだのですが、そこにいた@papandaさん(たぶん人数足りないから助っ人で入っていた)に、「で、普段どんな仕事してるの?」とか「今日の昼は何してきたの?」とか馴れ馴れしく聞きまくってましたね。知らなかったとはいえ、今考えると顔から火が出るほど恥ずかしい思い出です。

 

ですが、その馴れ馴れしさの甲斐あってか、この時に同じグループになった方にアジャイルサムライ横浜道場へ誘ってもらい、さらなる繋がりへと広がっていくことになりました。その繋がりで出会った多くの人に助けられ、励まされて、今回発表したような、現場や社内での活動を続けることができました。

 

時々、

「いい年こいて何やってんの?」とか

「そんなことやって意味あるの?」とか

「どうせうまくいかないって!!!」とか…

という病に、心が折れそうになることもありますが、

 

機雷がなんだ!全速前進!」の精神で、明日からも頑張ります。

 

現場をあきらめない。。