大河ドラマ「花燃ゆ」がおもしろい

これまで大河ドラマは見たことありませんでしたが、 3週間カンボジアに出張にいっている間、 CSかなにかで唯一日本語のチャンネルがNHKだけだったので見ていたら 「花燃ゆ」がやけに面白い！というので日本に戻ってからもずっと見ています。

会社の行動指針が5つあるんですが、そのなかに
クレイジーであれ！
というのが一番上にあります。

「花燃ゆ」の主人公である吉田松陰のセリフに
「諸君、狂ひたまえ」
というのがあり、この狂という字がクレイジーと同じ意味のように感じたのが、興味を持つきっかけになりました。

少し調べてみると狂という意味は
「自分でも持て余してしまうような情熱」
という意味だそうです。 松田松陰もそうとうクレイジーな人であったようです。 常識にとらわれず、自分でも持て余してしまうような情熱で事をなす！ これがクレイジーであれということなんでしょうね。 自分自身、もっともっとクレイジーになっていきたいと思います。

それにしても最近は吉田松陰の狂と志という2つの言葉がずっと頭から離れません。 しばらく「花燃ゆ」にハマりそうです。

PFP関西「部下が動かない！そんな状況を変える魔法の言葉」の勉強会に参加しました

５月２３日にPFP関西主催の勉強会に参加してきました。 http://kokucheese.com/event/index/167325/
改めて実感することができた有意義な時間となりました。

参加した動機

部下やチームメンバーが自主的に動かない！そんなことって部下を持つ人や、チームリーダーをしている人なら誰しも経験したことがあるんじゃないでしょうか？

私もこれまでそういった経験を多くしてきていました。 部下やリーダーをやるようになったばかりの頃は、「なぜ動かないんだ！」と腹を立てていましたが、最近は「もっと楽しく仕事をしてほしいな〜」と思うようになり、少しずつ自分の中でも変化が出てきました。

そんな時、アジャイルに出会い、昨年から勉強会に参加したり、実際に真似事をやってみたりして、少しは手応えを感じつつも、もっとうまくコミュニケーションをとってチーム一丸となって仕事をする楽しさを共有できるようなマネジメントをしたいと思っていたときに、この勉強会の通知が来ました。

内容は「質問」にフォーカスを当てたものだという事で、何かしら新しい気付きがあるかも！という期待を込めて参加しました。

イベントの内容

今回のイベントでの内容はこんな感じでした。

• 座学
• ロールプレイング①　コントロールする上司
• ロールプレイング②　褒める上司
• ロールプレイング③　質問する上司
• チームディスカッション
• チーム発表

最初の座学はマネジメントの研修や、本を読んで勉強している人などは、なにかしら聞いた事があるような内容だとは思います。その後、「質問」にフォーカスをあてて３段階のロールプレイング（寸劇）を続けて実施。それぞれ設定は同じで、上司が部下に新しいプロジェクトリーダーをやってくれ！と伝えるシーンです。部下はまだリーダー経験も浅く自信がありません。さて、自分ならこういった場合にどう部下にリーダーを任せると話すだろうか？

①コントロールする上司

とにかく有無を言わさず部下に新しいプロジェクトをやらせる上司。部下が不安に思っていることなどもおかまいなし！とにかく「やれ」という内容ですね。

②褒める上司

とりあえず部下を褒める「君しかいないよ！君ならできるよ！じゃあ、頼んだ！」てな感じですね。

③質問する上司

①②とは違って「任せたいんだけどどう思う？」と質問から入り、部下の不安な気持ちや、なぜ不安なのか？を聞いた上で、「こう考えてみたらどうかな？」「君が普段から頑張っているところをここで発揮してほしいんだけどどうかな？」など、提案したり、期待を伝えながら最終的には部下から「できそうなので、やります！」という感じになっていきました。また、

シチュエーションなどによって一概には言えないとは思いますが、自分が部下の立場であれば、やはり③でプロジェクトリーダーになれたほうが、自主的に動けるだろうというのはすぐに感じました。じゃあ、なぜ？そう思ったのか？どうすれば自主的に動けるようになってくれるのか？をその後のディスカッションをしましたが、私の中ではいくつかのキーワードが出てきました。

なぜ③だと部下が自主的に動くと感じたか？

• 決定したのが「他人」ではなく「自分」だった
• この上司は自分を見てくれている（認めてくれている）と感じた
• 自分に何が求められているか？の「ビジョン」と「ゴール」が共有できていた
• 何かあっても相談にのってくれそうという安心感があった

他の方の意見も見て回りましたが、表現の違いはあるのせよ本質的なところで大きな違いは無かった気がします。

最後のチーム発表で他のチームが、うまくフレームワークにまとめられていて、とても参考になりました。

双方の思いがインプットとなり「質問▶︎探索▶︎共感」を繰り返しながら、共感の値をしきい値を超えると、「合意」がなされ、自発的に動いていく。

そして、共感がしきい値より下がると、再度「質問▶︎探索▶︎共感」を繰り返し「合意」を繰り返していくというものでした。分かりやすい。

これからやっていくこと

で、どうやったらこんな上司になれるのか？を考えていたんですが、一番大事だと感じたのは「部下のための時間を確保する」ことでした。

自分の仕事でいっぱいいっぱいになっていて、余裕が無い上司やリーダーは部下のことを普段から見る余裕も無く、①②のようなコミュニケーションしかできないだろうし、自分も過去を振り返ると忙しいときほど①や②だったな〜と思いました。 これからは、自分のスケジュールの最低３割は部下やチームをうまく回すための時間として確保していこうと思います。

これも、本とかではよく書いてある事だとは思うんですが、ただ文章でさらっと書いてあるだけか、こういった場で実感したことかではまったく違うと思うので、忘れず実践していきたいと思います

コミュニティで得た価値観を「現場」に持ち込んでみた

はじめに

本エントリは「DevLOVE Advent Calendar 2013 「現場」」の34日目の記事です。

昨日の「新井 剛」さんからバトンを受けとりました。あらゆる場所を現場に、そこで最高の好奇心を

自分の現場は、自分がいる場所なんだ

というところが印象に残っています。とても素晴らしい記事でした。

自己紹介

大阪でBtoBの自社プロダクト開発をしていますkazinoupといいます。今年の２月から京アジャ、DevLOVE関西を中心にコミュニティの勉強会などに参加するようになって色々なことを学びました。それを「現場」で実践しようと取り組んだことについて今回は書いてみようと思います。

私は「笑顔のある職場」を目指して現場改善をする為に、いくつかのプロジェクトの支援やスキルアップの取り組みを行うようになっていました。これまでは技術的な支援が中心でしたが、コミュニティでアジャイルやスクラムというものがあると知り、徐々にプロセス改善にも取り組もうと動き出したそんなとき、あるチームが炎上したため、火消し役としてそのチームに入っていくことになりました。今回は約２ヶ月間その「現場」での取り組みを振り返ってみたいと思います。 かなり長くなってしまいましたが、よろしければ最後までご覧ください。

今回の現場の様子

• プロジェクト全体が完全なウォーターフォール開発

• 社員１名（A子）、協力会社４名の５名のチーム　※プロジェクト全体は数十人規模

• A子は開発経験も少なく、協力会社の方と仕事をするのも初めてで混乱している
• 仕様を決める設計者は別にいて、随時新しい仕様が伝えられて機能拡張をしている
• 期限が近づいても完了の目処がたたない
• 残タスク、課題などが把握できず何をすれば終わりかA子自身が見えない

---

ということで、この状況をなんとかするためにチームに合流することになりました。 ウォーターフォールの現場にいきなりアジャイルやスクラムを導入するのは組織的にも技術的にも課題は多くありますが、コミュニティで得た「価値観」は持ち込めるはず！と思って、今やれることをやってみました。

まず、私が感じたこのチームの主な問題が以下の３つでした。

チームの問題点

1. チームになっていない
   • 自分の担当分の事しか知らない
   • 自分の作業が終われば帰っていき、特定のメンバーだけが残業をしている
2. 全体像が把握できておらず完了の基準があいまいでゴールが見えない
   • どんな要求があって何ができればいいの？に対する明確な答えを持っていない
   • 自分の担当が他のどこに影響するか分かっていない
   • 仕様の確認は会話のみでズレが多く発生
   • テストは？何すれば終わるの？などの基準もない
   • 動作確認しないままタスクが「終わった」という人も・・・
3. テストができずソースマージの間隔も長すぎる
   • それぞれで開発を進めていて整合性がとれていない
   • １週間から長い場合は２週間もマージがされずに開発をしていた

チームに入って取り組んだこと

これらの問題に対して以下のことを取り組みました。

チームのベクトルを揃える

まず最初にやったのは、チームとして５名のメンバーのベクトルを合わせることでした。 入って初日に、作業をすべてStopして以下のことについて話し合いをしました。

• プロジェクト全体の話や経緯、チームが担当するところが全体にどう影響しているかを再認識
• 理想的なチームとはどういったチームか？
• 理想的なチームになるために守るべきルールを決めよう！
• チームが目指すべき、達成すべきことは何か？
• チームが日々行っていることはなにか？
• チームのリズムを作ろう！

これらを話し合いは全員の意見を引き出しながらまとめて納得がいくように！というのを意識してやりました。PMやPLといった影響力のある人は参加せず、チームメンバーだけでやったことがよかった気がします。

結果として理想のチームを考えてまとまった、このチームの方針を以下に決めました。

• 全員野球
• 残業なし
• 品質重視

まず、全員野球は「仕様は全員が把握しておくべき」「変更点は全員が把握するべき」「特定の誰かしか知らないという状況をなくすべき」という理想の状況の意見を集約して決めた言葉です。 そして、残業をしないわけではないですが、極力しないためにどうするか？を考えて、残業なし＝悪　という雰囲気を、残業なし＝良　ということを考えたいという意見から決めました。 最後は共通部品を作るということで、品質重視でいきたい！というメンバーの意見が多く出てきたことから決まりました。

ここから、3でチームのルールを決めたのが以下となります。

• 元気に挨拶する！
• １人で残業しない！
• テストなしでチェックイン禁止！

挨拶は大事ですね。これを決めてから朝のMTGで全員が大きな声で挨拶するようになりましたが、チームがコミュニケーションを密にとるための最初の１歩だと思います。 テストモジュールはあとで詳しく書きます。

あと、１日、１週間でやることを出し合って、それをいつやるのがいいか？をチームで考えてきめました。やるべきことはなに？その目的は？じゃあ、いつやるのがいいか？といったことをチームで再認識できたことはよかったです。ここでチームにリズムができたことでスムーズに動き出したのは確かですね。 これらの話し合いで決めたことは、印刷しておいて常にチームのMTGの際には皆で確認しながら進めてもらうようにしました。

この取り組みで大変だったのは、PM層から「とりあえず２１時まで残業して進めてほしい」や、「なぜこのチームだけ止まっているのか？」、「やり方がぬるい」といった話を受け流すことでした。チームは問題を認識してるので協力的でしたが、PM層には理解できないところでなんどか衝突が起きました。どう進めようとしているか！求めている要求レベルは上げている！とりあえずは任せてほしい！というのを伝えてなんとか進めていました。PM層も話が分からない人たちではないので、最終的にはすべて任せてもらえたのでありがたかったです。

現状の見える化と完了の定義を決める

チームで一番の問題だったのが、何をもってこのチームの作業が完了するかが誰もわかっていないことでした。仕様が別で設計するメンバーがいるので、日々増えていく要求を対応していたり、設計者との認識のズレなども多く後で修正が発生することが多くありました。また、残タスク、追加対応、課題、仕様検討などがごちゃ混ぜになった表があるだけで、全体像を見れている人もいません。進捗管理もタスクが日々変わっていくためガントチャートのメンテナンスばかりで、チームメンバーが現状をきちんと把握することが困難な状況でした。そこで、取り組んだのが以下となります。

1. 機能を32項目に分類し、この32項目が実装できれば完了という枠を作成

2. 項目が「完了」となる基準とステップを定めて塗りつぶしの表を作成　※ガントチャートは廃止

3. 月曜日に項目の仕様洗い出しを設計者に確認させてもらう時間を確保

4. 金曜日に月曜日で確認した仕様を動くものとしてレビューしてズレを修正していく
5. 5回のサイクル（5週間）で32項目を終わらせる目標を立てて、１週間の完了の線をチームで引く
6. 項目に担当者は作らず、朝会で塗りつぶしの表を見て、チームで目標の線を終わらせるタスクを決める

これによって既に実装済みのものも含めて、すべての項目について設計者への仕様確認と動くものでのレビューを毎週繰り返すというサイクルができたのでズレが減りました。何をもって完了にするか！をチームで話し合って基準を作ったのでズレも少ないですし、やることが明確になったことでメンバーもモチベーションを上げているようでした。そしてなにより、進捗の遅れ・進み、課題を全員が常に共有し、チームとして達成すべきラインがあることで、自分だけのタスクではなくチームとしてどう動くべきか？をメンバーが考えるようになっていく様子は私には衝撃を感じるほどでした。

とはいえ、最初は個人のタスクしか見れず、誰かだけが残業したり、チームとしての達成のラインを超えられないということが続きました。ここで「全員野球」というキーワードを何度も使って話しましたし、「周りからは自己組織化されたチームになるのは無理だと思われているが、そんなことはないはずですよね？私は皆さんを信じます。」ということも伝えました。そして、ようやく４、５週ほど進んだあたりで、自ら積極的にチームのために他の人のタスクをとっていったり、色々な提案が生まれてきた気がします。ここでラスト２週間でしたが、やはりチームになるまでは時間かかりますね。 このあたりのオーバーヘッドも考えて組織作りはするべきだと改めて実感しました。

テスト用のモジュール作成して毎日チェックインと動作レビューを実施

技術的な面でも大きな問題がありました。それが、同じチームで開発しているにも関わらず、１週間〜２週間マージがされずに各自のローカルで開発を進めていて、マージした段階で問題が起きるということでした。

ソース管理はTFSで行っているのですが、チェックインすることは特定の人以外ルールとして禁止されていました。このチームの場合、プロジェクト全体のリーダーのところに依頼を投げていましたが、多忙であるためどうしても遅れがでてしまいます。

また、作成しているものがUI部品ということもあり、その部品を使う画面がないと動作確認ができないということで、タスクが終わったとしても実際にそれを動かしての確認ができるのがもっと後という状況になっていました。Unitテストなどの自動化の経験もないですし、私も教えられるほどの力はありません。

そこで、チーム専用のテストモジュールを作り、そこに全機能のテストができるようにしました。私が入ってから最初のMTGしたあと１週間ずっとこのテストモジュールを作っていたので、「なぜこのチームだけ立ち止まっているんだ」という事も言われましたし、「早く課題をつぶしていってくれ」という依頼もありましたがこれだけはやらせてくださいとお願いして作りました。

これによって、チーム全員が実装▶︎テスト▶︎チェックインを毎日できるようになったので作業効率と、品質が劇的に上がりましたし、使い方の説明資料もなくして全てソースと動くモジュールを用意したことで、部品を使う開発者とのやり取りも簡素化されました。 動作確認もほとんどできていなかったA子も、後半は先にテスト画面を作ってから実装するなど、テストファーストの開発が出来るようになっていたのは嬉しかったです。

ただ、ここにも反省点はかなりあります。まず、サンプルという意識が強かったのか、ファイル名がめちゃくちゃだったり、テスト画面の作りが実際の開発にはまったく準拠していなくて、逆に混乱をまねいてしまったり・・・テストモジュールであっても動くものである以上、もう少し意識を高くして作成できていたらかなり違っていたのにな〜と思いますし、チームからもそういう声が上がってきていました。

日々のプチ振り返と、週１の振り返り

あとは、私からチームへのお願いとして、毎日のプチ振り返り（夕方にその日の作業の確認とともに５〜１０分程度で実施）と、１週間に１度のKPT（だいたい３０分くらい）をしてもらい、常に改善の意識を持つようにしてもらいました。ここにはあまり力を入れれなかったので、もっとうまいやり方があったんだろうな〜と思いつつ、それでもいくつか素晴らしい意見があがってきて効率が上がったのと、メンバーからの提案が少し増えた感じがしました。

結果

これらの取り組みの結果、他のチームよりも残業も少なく、かなりボリュームのある開発もスケジュールを調整しつつ、最終日に定時帰りができた事はよかったと思います。 その後も色々と問題もでてきて、もっと改善できた事は山ほどあるのですが、それでもコミュニティで得た「価値観」は少しは現場に持ち込めたのではないかと思います。

まとめ

いかがでしたでしょうか。アジャイル、スクラムなどのコミュニティで得た価値観は多いに今回の「現場」に役立ったことは間違いありません。 今後もコミュニティへの参加やブログなどの発信もやっていきたいと思っています。

次はchris4403さんにバトンタッチです。楽しみですね。 よろしくお願いします～。

PO Meetup 5th ユーザー・ストーリー・マップでプロダクトを語る に参加しました

山本雄一郎(@u1r_red)さん企画でやっている、POMeetup 「ユーザー・ストーリー・マップでプロダクトを語る」に参加しました。 http://pomeetup.doorkeeper.jp/events/7166

POMeetupとは

スクラムの中でもPO（プロダクト・オーナー）って難しくないですか？ ということでPOがより優れた開発と高いビジネス価値を達成するための実践知を交換できる場所を作って行きたい！というので始められました。 今回が5回目ですが、3回ほど参加せていただいていて楽しみな勉強会の一つになっています。

今回のテーマである、ユーザー・ストーリー・マッピングという言葉は聞いたことあるのですが、実際には体験したことがなくてどんなことをするんだろうとワクワクしながら参加しました。 コンテンツとしては

• ユーザー・ストーリー・マッピングの手法を体験する
• 効果的な使い道を議論する

ということで、この2つは山本さんの仕込などのおかげで楽しく遂行できました。

やったこと

今回はほとんどワークショップ中心でした。

ユーザーの活動を時系列で書き出す

まず、山本さんが用意してくれた仮想プロダクトを元に、それを使うユーザーの立場になってどういった活動をするか？というのを考えて左から右へ時系列に並べました。この「時系列」がミソですね。目的の行動の前後に何を考えているか？何をしているか？という活動を想像すると、普段考えるよりも広範囲に考えられる感じがしました。シーンを考えることはありましたが、はっきりと時系列で考えるという事が新鮮でした。

アクティビティを列挙す

次にユーザーの行動をグループ化しながらアクティビティを下に書きだしました。 ここでのポイントは「動詞」を使うことだということですが、なかなか日本語で動詞だけで書き出すのは難しかったです。 とりあえずは簡単な主語だけは使いました。 例えば「店を探す」とか、「友達を誘う」とかです。もしかしたら、単純に「探す」「広める」とかの動詞に落とし込んだ方が本質をつかむためにはいいのかもしれませんが、やっている最中ではやはり主語がないと難しかったです。

ユーザータスクを洗い出す

先ほどのアクティビティに対して、ユーザーがアプリ上で行うタスクを書きだしました。 本来なら事前にどういったビジョンに対して、どういった機能があるか？が決まっている場合に使うこともあるそうでしたが、今回はここで初めてプロダクトの「機能」も考えました。時間が限られていたのですが、それまでの流れがあったおかげでユーザー視点で考えることができ、色々なアイデアが出てきたのは楽しかったです。

振り返り&休憩

ここでいったん振り返り。最後でなくここで振り返りを入れるのも山本さんの巧みな進行ですね。 皆さん新しい気付きがあったようで活発に意見が出ていました。 私がこの時点で思ったのは、やはり「時系列に活動をイメージする」というのがとても新鮮だったのと、それが想像以上に考えやすかったことが驚きでした。めちゃめちゃ使えるやんこれ！みたいに興奮してましたね。 休憩時間にも関わらず、皆さんさらに真剣に議論されていたのが印象的です。このあたりが会社で指示されて出ている会議と、自ら勉強会に参加しに来ている場との違いですね。

プラグマティック・ペルソナ

そして、ペルソナです。数人のペルソナを作りそれぞれで特徴（抱えている課題や要求）を決めて行きました。そして、ペルソナをプロダクトにとって重要な順番に並べて、そのペルソナが必要とするタスク（機能）に分けて行きました。

私が今まで思っていたペルソナを使った手法は、先にペルソナを決めてから、そのペルソナの課題を解決する価値は何か？を考える、いわば先にターゲットやマーケットを決めてから価値を考えるという流れがほとんどでした。今回は後でペルソナを複数出して、プロダクトにとって重要なユーザー（アーリーアダプターかな？）にとって価値のある機能を決めることで、タスクの優先順位を付ける為に使われていたのに、こういう使われ方というか流れもあるのかと驚きましたね。確かにこれは分り易いし納得しやすい。

やってみての感想

とにかく純粋に楽しかったです。リーンキャンバスやリーンダイアグラムは一度ワークショップに参加したことありますが、難しくて楽しむというところまではいけませんでしたが、これはとっつきやすいですね。 そういった面では、利用できる層は広いように感じました。

また、終わってマップを見直してみると、とても広範囲であり全体の流れがよく分りました。 既にあるプロダクトを見直して新たな価値や発想の転換に使えそうにも感じました。また、ユーザーストーリや新しいプロダクト案の検証もユーザー視点でできそうとも感じました。

ここで、山本さんから「注意すべきところ」として「結論にしない」なぜならあなたはユーザーではないのだから！ということを紹介してもらいましたが、確かにそうですよね。ユーザーと一緒にするのならとてもいいかもしれませんが、そうでない場合はあくまで仮説でしかないんですから。

また、さらには「ユーザー視点になり過ぎて、プロダクトの収益を得る為の仕組みなどが抜けてしまう場合もあるということでしたが、これも納得です。

この辺りの話を聞いて、とても簡単に試せて効果も高そうというのは間違いないと思いますが、使い方は注意しないといけないんだな～というのも分りました。このあたりの気付きは山本さんの組み立てのおかげです。

他にも、実際に現場でやってみたときに感じたお話も頂き総じて勉強になりました。

これからもPOMeetupには積極的に参加していきますので今後ともよろしくお願いします。

↓最後に実際にワークショップで作った写真をのせておきます。

DevLOVE関西 ～Decision～ に参加しました

2013/11/16 に開催されたDevLOVE関西のDecisionに参加しました。

Decisionつまりは「決断」をテーマに個性豊かは8名の方がこれまでの「決断」についてお話をいただくというものでした。

キーノート

最初にDevLOVE関西を運営されている中村洋さんからのキーノートがありました。
今回初めてDevLOVE関西に参加された方もかなり多かったようで、横浜からわざわざ参加しに来られた方もいらっしゃいましたね。

そして、2セッションが同時に開催されるため、部屋の大きい方、小さい方のどちらでお話いいただくかを決めるために、スピーカーの皆さんが発表内容を1分間アピールして、拍手の大きかったほうが大きい方の部屋でするという、なんともスピーカーからすれば過酷なものが・・・

聞く側からすれば、どういった方がどんな内容をお話しされるかを聞くことができて、どちらを聞くかが選びやすかったです。そして、私が選んだセッションは以下の4つとなりました。

第1セッション【理想の就労環境とは何か 〜ある開発会社がブラックの真逆を徹底した先に見たモノ〜】

まずは、フィードテイラーの大石さんのセッションでしたが、東京であったイベントで聞きたいな～と思っていてましたが、イベント自体に参加できなかったので迷わず決定しました。
内容はご自身が開発者として理想の就労環境を求めて会社を転々と回ったが、なかなかないものだな～ということで、自分で『開発者による開発者の為の開発会社』を目指して起業し、取り組まれてきたことをお話しいただきました。
正直、お聞きして驚きましたね。ポイントは「Productivity」ということで、生産性・生産力に徹底してこだわって経営をされていました。普通の会社では「Production」生産高を高めようとしているが、これでは工場と一緒で、開発者がコマのように扱われる。生産性を追求することで、人を見るようになったというお話でした。
確かに私がこれまで経験してきたプロジェクトでも、開発者がコマのように数値上の計算であてこまれていて、いろんなところにオーバーヘッドが発生し、それを開発者が残業で補うという、本当に無駄が多く生産性が低いな～と感じることが多かったので心に響きましたね。
開発者は開発することに完全に専念する環境をつくり、非常に高い技術レベルを要求されながらも、ものすごいスピードで成長し、生産性が高まっていくという「専業」や「専念」という言葉がとても印象に残りました。そのかわり、その環境を作るために開発以外のことをすべてやる大石さんのポジションは非常に大変だということでしたが、私はそこのポジションにとても魅力を感じて興味津々で聞いているなかセッションが終わりました。う～ん、もっと聞きたかった。

第2セッション【プログラマから経営者へ変わる決断と、プログラマを一生の仕事にする決断】

続いては、ソニックガーデンの倉貫さんと伊藤さんのセッション。
こちらはお二人掛け合いトーク形式で行われました。まず圧倒されたのは倉貫さんのしゃべりのパワーですね。伊藤さんが5分のLTで30分しゃべったことがあるとおっしゃられてましたが納得のいく話でした。
倉貫さんが社内ベンチャーを買い取って起業された経緯や理由などを熱く語られていましたが、非常に明確なビジョンをお持ちで、そこに向けた行動力が素晴らしいと感じて聞き入ってしまいました。
特に印象に残っているのが「プログラマーをスターにしたい！」というところで、そのために考え出されたものが、「納品のない受託開発」という新しいビジネスモデルだったようです。開発者がクライアントの顧問となり要求を理解して提案していくスタイルで、最初に仕様があって、納期があってということではなく、信頼関係の上での本当のパートナーとして、価値あるものを作り上げていくような感じかな～。洋食屋のオーナーシェフを例えられていましたね。受託開発と派遣のいいとこどりをして、お互いハッピーになろうよという提案をされているようで、とても素晴らしいビジネスモデルだと思いました。
第1セッションの大石さんとは生産性を高めるという部分では同じでも、ある意味180度異なる方法で経営されていることがとても面白かったのと、それぞれのビジョンが明確であり、それが経営や制度にしっかりと反映されているという面では同じだな～と感じました。

第3セッション【SIerの中で技術を大切にする生き方とその秘訣】

さて、後半に入り熊谷さんのお話です。
スピーカーというかおそらく会場の中でも最年長組の方でしたが、非常に軽快なトークが印象に残っています。スピーカーの皆さんはどちらかといえばジョブホッパーとまではいかないにしても、自分の理想とする環境を求める・作るために起業や転職をされている方が多い印象でしたが、熊谷さんはSIerの中でずっと技術を磨きながらやってこられたお話を聞かせていただきました。
経歴のお話を聞くと海外含めてあちこちに赴任されて、数多くの経験を積まれている様子がうかがえました。オブジェクト指向もかなり早い時期から注目されており、アーキテクチャについても深い知識をお持ちのようで、ずっと同じ会社でこうして経験を積まれていることが素晴らしいな～と思うのと同時に、とても新鮮に感じました。
色々なお話をしていただきましたが、「自分が成長できる場所を選ぶことが大事」であり、常に成長し続けないといけないというのは説得力がありましたね。また、伸びる人のポイントとして「自分の弱点を認識できる人」というのは、ちょっと胸がズキンとしました。
熊谷さんは今でもプログラムを書くということでしたが、なぜ技術を大事にしてきたかというお話の中で「部下が困っているときに自分では解決できず、とにかく頑張れ！とだけ言って差し入れなどをすることしかできないような自分にはなりたくなかった！」というのは、まったくその通りだな～と共感しました。会場もあるある話に笑いが起きてましたね。しかし実際のところ、これだけ技術進歩が速い分野において、50代でも若いやつには負けないと技術を追い求められる人はほとんどいないんじゃないだろうか？と思ったりもします。何十年と変わらず情熱を持ち続けられている熊谷さんを素直にすごいと思いました。

第4セッション【大企業、未踏ソフトウェア、起業 - 様々な働き方から学んだ「モノ作り」のエッセンス】

さてさて、最後のセッションはヌーラボの染田さんのお話です。
まずセッション紹介の写真がなんとも印象的で、どんな人だろうか？と興味津々ではありましたが、たまたまお昼をご一緒させていただくことになりまして、かなり印象が変わりました。（いい意味でですが）
ヌーラボはBacklogやCacooといったWebサービスで伸びている会社ですが、外資系の大手、自分で起業されていた時代に苦労したこと、ヌーラボに入られて今ではエバンジェリストとして活動されてきたバラエティーに富んだ経験をされてきたなかで、「モノ作り」における自分の意識がどう変わっていったか？というのがとても興味深かったです。

ダイアログ【未来のために我々の帆をたてよう】

セッションが終わり市谷さんが壇上に立ちダイアログがスタート。
ちょうど、「リーン開発の現場 カンバンによる大規模プロジェクトの運営」
を持って行っていたのでサインをGET!昔は本の著者や翻訳された方と知り合うことなんてなかったですが、コミュニティに参加するようになって、少し身近になったのがうれしいですね。
ここでは4人一組になりまずは自己紹介。そして、各自で悩んでいることを付箋に書き出してそれを共有しました。4人の中で誰のものについて話し合うか？を決めたのですが、私の出したものに決定したので、3名から私へ質問をどんどんして答えていくというものをやりました。
ここで私の中で大きな発見がありました。最初書いていた悩みは実は本当に悩んでいたことではなく、もっと根本的に違うところで悩んでいたのだというのが分かりました。
おそらく4つのセッションを聞いた後だったから感じたことかもしれません。本当に参加してよかったです。

自分の決断

さて、長々と書きましたが、本当にたくさんの刺激を受けた素晴らしいイベントでした。
中村さんをはじめとする運営側の皆さんありがとうございました。
これを機に私の中で小さなものも含めていくつかの決断をしました。

• ブログを書く

まずは、最初のこのブログがそうですが、今年の2月ごろからコミュニティに参加させていただくようになり、たくさんの刺激をうけていますが、自分から発信することがなかったので、まずはブログを書くことを決めました。以前もチャレンジして3日坊主で終わったので、今回は続けられるように頑張ろう。

• WindowsからMacへ

これまでずっとWindowsしか使ったことがなかったですが、コミュニティに参加しているとなんともMacBookが多い。iPhoneやiPad miniも気に入ってるし、コミュニティで活動されている方と共通のプラットフォームにしたいというのと、オープンな世界を知っていくには避けて通れないかな～ということで、MacBook Proを買うことに決めました。今後、Macを使っていくなかでの気づきもブログに書いて行こうと思います。

• コミュニティ活動

2月からコミュニティの勉強会やイベントに参加をしてきましたが、参加するだけでなく運営側へも無理のない範囲で少しずつ参加していこうと思います。

• 仕事における決断

これは、まだ詳しく書きませんが、ダイアログで悩んでいることについて色々と質問をされる中で見えてきたものがありました。それを受けて、今後の仕事について方向転換をしていこうと考えています。これまではなんだかんだと理由をつけて逃げていたことを実感しました。本当に自分がやりたいことは何か？を見つめなおして、そこに向かっていけるように頑張ろうと思います。