年別アーカイブ: 2013年

2013年をふりかえって

2013年もいろいろあったので、どんなことがあったか記録しておきます。
DevLOVE関西関連のことは35回開催した2013年のDevLOVE関西に書いたのでそれ以外で。

1月

大阪リーンスタートアップ読書会 #5
傍楽いきいきプロジェクト~職場の景色を変えるワークショップ~
リーンカンファレンス2013 ~ヒット商品をつくる仮説検証型開発プロセスとスキル~

仕事面では普段のスクラムマスター業以外に、リーンキャンバスやインセプションデッキなどを使って企画やアイデアをもう少し違う形で考えてみるには?といったことに取り組んでいた時期でもありました。

2月

Scrum Boot Camp in 島根
その時のエントリ【「Scrum Boot Camp 島根」に行ってきました】です。
カラダで学ぶチームビルディング
デブサミ2013
11回目にして初めてのデブサミでしたが(デブサミ関西2013の実行委員長として)LTをやってきました。
その時のエントリ【デブサミ2013(やその他色々)に参加してきました
【勉強会】第1回リクリ勉強会「失敗しないアプリ開発を行うには〜 Getting Realを学ぼう 」
京都アジャイル勉強会 #京アジャ 春の特別編
2月25日 第16回 #TFSUG: 大阪vol.2(大阪府)

イベント以外ではマナスリンクさんで「DevLOVE関西」のことを書き始めたり、仕事面では社内でアジャイル開発の勉強会をやっていました。

3月

スクラム道関西「POStudy(第0回)」
京都アジャイル勉強会 #京アジャ 第18回
TOC/TOCfE関西分科会~成功事例から学ぶCCPM講座~

この頃には社内で毎週1回のランチ勉強会というのが始まりました。
そしてもう社外のイベントでは「デブサミ関西2013のキックオフ」というのがカレンダーに記録されていましうた。ここから半年以上に及ぶ準備が始まったわけです。

仕事面では、複数チームのスクラムマスターとして、スプリント計画やふりかえりなどに出たりして色々試行錯誤していました。

4月

第5回大阪Jenkins勉強会
第18回 #TFSUG TFS の今(大阪サテライト)
DevLOVE四国
XP祭り関西2013

仕事面では組織変更なんかがあって守備範囲が広がったりして提案活動に少しだけ足をつっこんだ時期でもありました。

5月

AgileJapan大阪サテライト
実は2013年で、あまり良い意味ではない方の印象に残っている発表でした。
参加者層や届けない内容などが本当にフワッとして、結果として「参加者の皆さん、どういうのをお聞きしたいですか?」的な形にしたのですが見事に盛り上がりませんでした(質問してくれた人は、なんとなく知っている方が多かった気がします)。

この頃からの2、3ヶ月での出来事(人との出会いや場)が、残り半年に大きな影響を与えているように思います。

6月

・Drupal Cafe 2013 vol.5 in OSAKA

7月

色々な人と会って、話して、当時考えていたことの仮説を検証をしたり、インタビューをしたりして、どういうニーズがあるか?など本当にお金を払うのか?など色々試していました。

それに呼応する形で、これまで以上に社外の人と一緒にプロジェクトを進めることが増えてきて、それぞれのやり方や振る舞い、多岐に渡った関心事などにも目が行って面白かったです。

9月

共感で駆動するプロダクト開発の始め方と進め方
XP祭り2013 ~XP~(東京都)
デブサミ関西2013
Scrum Boot Camp (スクラム道関西 presents)
2014年からやっていくことになるChangeHackersとして明確な最初のイベントをやったり、そこからXP祭り→デブサミ関西→Scrum Boot Campというコンボはなかなかにタフでした。

10月

Innovation EGG 第一回 IT系コミュニティ合同•未経験者向け勉強会

仕事面ではこの時期に「あぁ2014年からはまた次のステップに行くんだなぁ」と決めました。

11月

DevLOVE甲子園
1日で最大60人が話したDevLOVEらしいイベントでした。
「団」チームとして話したのは以下のスライドです。

12月

第28回 関西IT勉強宴会
アプリのペーパープロトタイピング勉強会

2013年のまとめ

DevLOVE関西以外でもスクラム道関西、デブサミ関西2013など色々なイベントに関係することができました。
何より2014年はまた違うステージに挑戦してみようと思ったのも2013年の大きな出来事でした。

※アイキャッチ画像:http://www.flickr.com/photos/4ever30something/451088722/

DevLOVE関西

35回開催した2013年のDevLOVE関西

DevLOVE関西、2013年は実に35回やりました。

各セッションで発表してくれた、そしてスタッフとして手伝ってくれた、そしてもちろん参加していただいた皆さん、ありがとうございました!

2013年色々やりました

自分の学習パターンを知る】や【原点回帰」しつつ「3年後の自分戦略」を考える】といったキャリア的なもの、【開発スターターキット】や【みんなに役立つ「テスト」を学んでみよう!】といったエンジニアリング的なもの、また【自律的なチームを育てるファシリテーションを学ぼう!】といったチームビルディング的なものもありました。
いずれもDevLOVE関西のコンセプトの1つである「現場を前進させる」を目標に色々なテーマでやっていきました。

色々なテーマでやっていることもあってか、毎回初参加の方がいてくれたのも嬉しかったです。
また、秋くらいからは「上司・同僚を誘ってきました」と言われる方もいてこれまた嬉しかったです。

やったことのリスト

02/09(土) 勉強会勉強会
02/26(火) SQLアンチパターン・レトロスペクティブ関西
03/06(水) 自分の学習パターンを知る
04/04(木) 関西人の自分戦略
05/11(土) SQLアンチパターン・レトロスペクティブ関西・リターン
05/16(木) WebDesign workshop of the programmer, by the programmer, for the programmer
05/18(土) アジャイルサムライDevLOVE道場 -ロールプレイング・インセプションデッキ-
05/20(月) 体系的に学ぶ 安全なWebアプリケーションの作り方 実践勉強会
06/10(月) わかりやすいアジャイル開発の教科書ワークショップ#1
06/22(土) セルフ・タスクマネジメント
06/29(土) 【「カンバンゲーム」と「宝探しアジャイルゲーム」】ワークショップ
07/07(日) 開発スターターキット
07/18(木) 今日から始める自動化~自動化入門講座~
07/20(土) テスト駆動開発による組み込みプログラミングのつどい@関西
07/30(火) WebDesign workshop of the programmer, by the programmer, for the programmer #2
08/23(金) 『統計学が最強の学問である』読書会 #1
08/24(土) 共感で駆動するプロダクト開発の始め方ワークショップ(β版) -ロールプレイング・インセプションデッキ-
08/29(木) 関西Excel方眼紙勉強会
08/30(金) Java EE 7 & GlassFish について語ろう
08/31(土) はじめてのGit ~たぶん関西でいちばんゆるいGit入門
09/07(土) デザイン思考ワークショップ
09/12(木) 「原点回帰」しつつ「3年後の自分戦略」を考える
09/28(土) キャンバス100本ノック
10/04(金) 『統計学が最強の学問である』読書会 #2
10/12(土) デプロイメントパイプラインの作り方を考えよう! ~CI環境をもっと “あたりまえ” に~
10/17(木) みんなに役立つ「テスト」を学んでみよう!
10/25(金) 「Lean Diagram」に学ぶProblem/Solution Fit(POStudy大阪出張編)
11/01(金) 「アジャイルな見積もり」を語ってみませんか?
11/11(月) 自律的なチームを育てるファシリテーションを学ぼう!
11/15(金) 「納品のない受託開発」を語る会
11/16(土) DevLOVE関西 ~Decision~
11/18(月) 共感で駆動するプロダクト開発の始め方と進め方
11/30(土) WebDesign workshop of the programmer, by the programmer, for the programmer #3
12/07(土) エンジニアのためのリーンスタートアップ
12/19(木) Dev(ice)LOVE デバイス祭り

こうやって眺めてみると本当にいろいろやっています。

もちろん回数が多ければ良いというわけではないので、参加してもらった方の現場が少しでも前進できるようなクオリティを意識してやっていきたいものです。

2014年も色々やっていきますので、よろしくお願いします!

2014年最初のDevLOVE関西は「開発現場に伝えたい10のこと」それぞれの後日談です。
10人それぞれの開発現場のエピソードが記された電子書籍をテーマにしたお話ですので、興味のある方はぜひお越しください。

DevLOVE関西のソーシャルリンク

Facebookページ
Facebookグループ

Doorkeeper

Twitterアカウント

DevLOVE関西

2013年12月のDevLOVE関西でやったこと

 2013年12月に開催したDevLOVE関西です。
 年末ということもあって2回でした。

エンジニアのためのリーンスタートアップ

 普段からこの分野でお仕事をされている和波さんのお話は刺さるモノがありました。
 ミニワークショップでの「やること1分ピッチ」では、慣れていない方もそうでない方も色々考えていることを話していました。

Dev(ice)LOVE デバイス祭り

 東京の中村 薫(@kaorun55)さんから「この日、大阪行くんだけど何かできない?」という一言から開催されました。

 募集前は、キネクトやセンサー周りの人があまりDevLOVE関西にはいないと思っていたので「あまり参加者は多くないかな」と思っていたら、募集開始半日でいったん満席になり、会場を替えて増席してもキャンセル待ちが出る状態でした。

 本編でも実際にさわってモーションを体験できたりして、ちょっとしたアトラクションみたいになっていました。

DevLOVE関西のソーシャルリンク

Doorkeeper

Facebookグループ
Facebookページ

Twitterアカウント

DevLOVE関西

2013年11月のDevLOVE関西でやったこと

 2013年11月に開催したDevLOVE関西です。

「アジャイルな見積もり」を語ってみませんか?

 参加者の方が後日社内でもやってみたとのエントリがありました。こういうのがあると「やって良かった」と本当に思います。

自律的なチームを育てるファシリテーションを学ぼう!

 チェックインから始まって、徐々に場を作っていき、ワークショップ(体験学習)でその場やそれぞれの役割を実感するという流れでした。
 またそこで感じたことを参加者それぞれがしっかり話し合う時間も持てました(さすがの時間配分と構成でした)。

 実際にこのような場を会社、チームなど現場でどのように作れるのか?作っていくのか?が「(簡単ではない)次のステップ」ですが、そのヒントは随所にあったように思いました。

「納品のない受託開発」を語る会

 セッションは早々に終わって、(ピザ、ビールが入ってからの)後半の質疑応答が本番という感じで、倉貫さんに様々な角度、視点からの質問が出ていました。
 その質問に軸がぶれずに回答している倉貫さんがいました。

 「納品のない受託開発」は私自身も広まって欲しいし、(希望だけでなく)広めたい形の1つだと思っていますので、興味ある方はぜひお気軽に声をかけてみてはいかがでしょうか?

DevLOVE関西 ~Decision~

 8セッション(キーノートとダイアログを含めると10セッション)のDevLOVE関西としては年1回の大きめイベントで、100人以上の方が参加してくれました。

 多くの方が書いてくれたエントリ、まとめなどはイベントページにまとめています。

#このブログ内のエントリはこちら
DevLOVE関西~Decision~を開催しました! | サウスポーなエンジニアの独り言
「DevLOVE関西~Decision~」を手伝ってくれたスタッフの皆さんへ | サウスポーなエンジニアの独り言

共感で駆動するプロダクト開発の始め方と進め方

 私達がやろうとしている「共感を持ちながらプロジェクトを駆動していくやり方」の核となるインセプションデッキの話を @papandaさんに話してもらい、私はタスクボードのお話をしました。

 どちらの内容もワークショップを含めて2、3時間で構成することが多いものですので、時間の都合上「こんなものだよ」というお話がメインでした。
 また機会があればこの会に参加した方向けにワークショップをやってみたいと思っています。

WebDesign workshop of the programmer, by the programmer, for the programmer #3

 デブサミ関西2013の再演から始まり、「アポを忘れないようにするためのサービスを考える」をテーマにしたワークショップをやっていきました。
 普段からこういうことをやり慣れているんだろうなぁという進行の流れや設計はスタッフとして見ていてさすがと思いました。

 6つある各グループを(サポートしながら)覗いていたのですが、それぞれ課題の定義もまた目指す方向も違っていて、(ほぼ初対面ながら)うまくチームができている所もあったりして興味深かったです。
#エンジニアリングが全面に出ているテーマの時とはまた参加してくれる方が違っていたのも印象的でした。

DevLOVE関西のソーシャルリンク

Doorkeeper

Facebookグループ
Facebookページ

Twitterアカウント

DevLOVEロゴ

いろいろな現場に深く関わっていく

 この記事はDevLOVE Advent Calendar 2013 「現場」の22日目です。
#大詰めを迎える12月後半などはまだ空いていますので、「現場」や「DevLOVE」に興味がある方はぜひお気軽に申し込みください。

自己紹介

 「お客様もチームもハッピーにするには?」を日々考えて、スクラムマスターとしてチームビルディング、ファシリテーションなど色々やっている大阪在住の認定スクラムマスター(CSM)です。
 コミュニティではDevLOVE関西スクラム道関西を立ち上げて、主催しています。
#SNSはTwitterFacebookなど。

 去年(2012年)のDevLOVE Advent Calendar「自分にとってのProfessional」では「【25日目】Professionalと思う3つの振る舞い」というのを書いているので、良ければそちらもお読み下さい。

私にとっての「現場」とは?

 これまでも書き手それぞれの「現場」の定義や考え方、関わり方が書かれていました。私は「プロジェクトの成功のために、できることを全力で出している場所」がその人にとっての「現場」だと感じています。

 開発プロジェクトにおいて、コードを書くPCの前がプログラマにとっての現場でしょう。
 お客様と時には厳しい交渉をする営業にとってはお客様との打合せの場などが現場になるでしょう。
 プロジェクトを俯瞰してうまく行くことに責任を負っているプロジェクトマネージャにとってはも色々なシーンが現場となりえます。

少し前まで悩んでいました

 私の考えはそういうものだと書いたものの、少し前まで「自分には現場感がないなぁ」と引け目のようなものを感じて悩んでいました。

 スクラムマスターやチームビルディングがメインの私にとってチームが開発に集中したり、お客様へ届ける価値を大きくすることができる環境を作ることが大きな役割の1つです。しかし、「コードを紡いでプロダクトを作り上げるわけではないし・・・自分は本当に貢献できているんだろうか?」と思うこともありました。

 そんな時にある人が「プロダクションコードを書く場所だけが現場ではない。ユーザーに価値を届けようと一生懸命やっていれば、そこがその人にとっての現場でチームに貢献していることになる」というようなことを言ってくれて楽になったのを覚えています。
#呑みながらだったので、ニュアンスですが・・・。

他の現場をもっと深く知りたく、関わりたくなった

 さてここからが本題です。
 DevLOVE関西をやっていて、特に2013年になって強く思うようになったことがあります。
 それは「他の現場にもっと深く関わりたい」という想い、欲求です。

 大阪を中心にやっている「DevLOVE関西」はこれまで37回開催し、DoorKeeperでの登録者数は610人を越えています(ありがたいことです)。
 そのコンセプト(「開発の楽しさを発見しよう。広げよう」と「開発の現場を前進させよう」)はぶれているつもりはありませんが、テーマはエンジニアリングからデザイン、アイデアの出し方、自分戦略と多岐にわたるため、本当に色々な方が参加しています。
#毎回「初めまして」な方がいるのもDevLOVE関西の特徴です。

 前で話している人、ダイアログや懇親会で繰り広げられる皆さんの話、1つ1つが私にとって興味深い現場の話で「もっと知りたい」という感情を掻き立てられます。
 一見「あるある話」に思えるその内容も、ベースとなる環境、原因と真因、そこに渦巻いている感情やこれまでの経緯など、どれ1つとして同じものはありません。当然、そういう現場の課題に対するアプローチや解決方法も違ってきます。
#そもそも正解があるなんて限りません。

 DevLOVE関西では色々な現場の話を知ることはできます(=”広さ”)が、現場に依存する深い部分を知る(=”深さ”)のはその限られた場、時間だけでは難しいと感じていました。と同時に「そういう色々な現場に深く関わってそこの人達と一緒になって解決したい、お手伝いがしたい」という想いが強くなってきました。

2014年はもっといろいろな現場に深く関わっていく

 そこで2014年は、もっといろいろな現場を深く関わっていくように仕事のやり方を変えていきます。
#実際は今もゴソゴソやっていますが。

 たまたまDevLOVE関西で出会った方をきっかけにして、現場の雰囲気やチームメンバー、上司やステークホルダーの声を聞いて、一緒にその課題の解決や目標に向かって「現場を前進させる」ことの力になりたいと思っています。

 「あぁ、@yohhatuに相談したら、何かヒントになるかも」と思った方、お気軽にお声掛けください。

 最後は決意表明というか、2014年の挨拶みたいになりましたが、これが私の【DevLOVE Advent Calendar 2013 「現場」】のエントリです。
 

次の方へ

 @shokutoさんです。関西の方で、デザイナーとのことで、どんな「現場」のお話が聞けるのか楽しみにしています!

DevLOVE関西

「DevLOVE関西~Decision~」を手伝ってくれたスタッフの皆さんへ

 このエントリはDevLOVE関西~Decision~をお手伝いしてくれたスタッフへ向けてのものです。

 誰1人が抜けても「DevLOVE関西~Decision~は」できなかったと思います。
#4月後半に「今年もやりましょうか」と話題にあがったので、そこから約半年かけての企画でした。

Akiさん(@spring_aki)
 なんだかんだ言いつつ公私にわたって色々付き合ってくれています。
 この日も受付から始まり、カメラマン、またお金の計算など幅広いフォローありがとうございました。

吉池さん(@yoshiumi2010)
 Aルームの司会などいつものように安定した司会業、さすがだと思いました。
 また懇親会もお店の手配から何からなにまで一手に引き受けてすごく助かりました。

川辺さん(@kawakawa)
 小さいお子様がいる中で、Bルーム、懇親会LTの司会、ありがとうございました。
 「なんでそこまで手伝ってくれるんですか?」と聞いたら「だって、こんな面白い場に関われることってそうそうないじゃないですか」と即答してくれたことが嬉しかったです。

@picopico_39さん
 元社内読書会メンバーの@picopico_39さんに久しぶりにお会いしましたが、受付や細かな事務周りの仕事ぶりは相変わらず素敵だなぁと思いました。

@negokazさん
 これまた元社内読書会メンバーの@negokazさん。会場提供のための色々な事務手続きなど本当に助かりました。

市谷さん(@papanda)
 最後のダイアログを見て、やっぱりDevLOVE関西のダイアログは市谷さんだなぁとあらためて思いました。

 ここにはお名前をあげることができませんでしたが、会場設営など諸々お手伝いしていただいた皆様、ありがとうございました!

DevLOVE関西のソーシャルリンク

Facebookグループ
Facebookページ

Twitterアカウント

Doorkeeper

DevLOVE関西

2013年10月のDevLOVE関西でやったこと

 2013年10月に開催したDevLOVE関西です。

『統計学が最強の学問である』読書会 #2

 DevLOVE関西はほとんどスタッフなどで参加していますが、これは@Posauneさんが中心になって進めてくれているものです。

 「読書会」には黙々と本を読んでいくスタイル、読んで来ていることを前提にディスカッションをメインにするスタイルなど色々あります。
 これは「読んで来ていることを前提にディスカッションをメインにする」スタイルで、その日の範囲を読んでくればディスカッションは十分できますので、第3回以降に参加してみてはいかがでしょうか?

デプロイメントパイプラインの作り方を考えよう! ~CI環境をもっと “あたりまえ” に~

 継続的インテグレーション(CI)の基本となるのデプロイメントパイプラインの概念と実践です。
 しかしながら、これを現場でやるのは試行錯誤の連続だと思います。そもそも今動いているシステムにこの概念を導入するのはとても大変だと思います。

 そのデプロイメントパイプラインの概念を分かりやすくお話してもらい、そこから参加者それぞれの現場を思い描きながら「今どうなっていて、どうなって欲しいか?そのためにどこから手を付ければいいか?」というのを描き出していきました。

 少人数でしたが、それ故にそれぞれの個別のアドバイスや経験談が飛び交っていてなかなか濃い話になっていました。

みんなに役立つ「テスト」を学んでみよう!

#DevLOVE関西のFacebookページに書いている内容をご覧下さい。

「Lean Diagram」に学ぶProblem/Solution Fit(POStudy大阪出張編)

 東京を中心に活動されているコミュニティ「POStudy 〜プロダクトオーナーシップ勉強会〜」の主催者でもあり、かつての同僚でもある関さん(@fullvirtue)にやってもらいました。

 分かりやすい説明の後にグループで、実際にLean Diagramを書いていました。
 実際に書いてみると分かるのですが、頭では分かっているつもりでも、いざ書いて埋めてみて、さらに全体的に俯瞰してみると不自然な流れが見つかったり、流れ自体が切れてしまっている箇所がハッキリと分かったりして面白かったです。

#以前、XP祭り東京で関さんのワークショップを初めて受けたのですが、随所に仕掛けがあって、私自身の参考に大きくなったのを覚えています。

DevLOVE関西のソーシャルリンク

Doorkeeper

Facebookグループ
Facebookページ

Twitterアカウント

DevLOVE関西

DevLOVE関西~Decision~を開催しました!

 DevLOVE関西~Decision~を開催しました。
#お話してくれたスピーカーの皆さん、参加してくれた皆さん、会場提供してくれたTISさん、DevLOVE関西のスタッフの皆さん、ありがとうございました!

 各セッションのスライドやエントリの内容はイベントページにリンクを貼っていますので、そちらをご覧ください。
 このエントリでは主催者としてなぜこの人に話してもらおうと思ったのか?というのを書いてみようと思います。

8つのセッションと9人のスピーカー

理想の就労環境とは何か 〜ある開発会社がブラックの真逆を徹底した先に見たモノ〜(大石 裕一:@oishi)
 大石さんとは1度しかお会いしておらず、その1度も「このブログ面白いなぁ。大阪の会社?お話してみたいから、一度お食事に誘ってみよう」というものでした。
 それにも関わらず、快く引き受けてくださいました(これは他のスピーカーの方も同じですが)。

 色々考え、決断された末に今の組織の形に辿り着いたと感じたので、ぜひお話してもらいたいと思っていました。

現場より、真実に向かう意志(椎葉 光行:@bufferings)
 DevLOVE関西で会場を貸してもらったり、時には呑んだりしている間柄の椎葉さんですが、特に呑んでいる時にとても良い話をしてくれます。その良い話は信頼関係 開発チーム編などに書いています。

 1人のエンジニアとして現場で事実に向き合っている様がまさにタイトルそのもので嬉しかったです。

プログラマから経営者へ変わる決断と、プログラマを一生の仕事にする決断(倉貫 義人:@kuranuki・伊藤 淳一:@jnchito)
 最初は倉貫さんにお話してもらおうと思っていたら、ひょんなことから倉貫さん、伊藤さんの2人がそれぞれ選んだ決断を対談形式でお話することになっていました。

 伊藤さんには1年前のDevLOVE関西~Derive~でもお話してもらっています。

技術マネージャになってわかったこと〜技術とお金と評価〜(川畑 雄補:@ku_suke)
 デブサミ関西2013の実行委員会でも一緒だった川畑さんです。
 はるかに年下ですが、色々経験されていて、その視野の広さはすごく、ぜひその時々の決断を話してもらいたいと思ってぜひお声掛けしました。
 期待していた通り、換金性という普通のエンジニアではあまり思い至らないポイントで話をしてくれました。

キャラ立ちしたエンジニアになる!(新原 雅司:@shin1x1)
 当時ほとんど面識のなかった2012年12月頃に、コミュニティでも色々活躍されているのを見て「コミュニティについてお話しませんか?」とお誘いしてカフェで数時間お話したのがきっかけです。
 その後、DevLOVE関西「関西人の自分戦略」で興味深いお話を聞いて、今回もお話して欲しいと思いました。
#もう新原さんとあの「拍手ネタ」でお酒が呑めないかと思うと残念です。

SIerの中で技術を大切にする生き方とその秘訣(熊谷 宏樹)
 私の中で、他の皆さんに聞いて欲しい人を誰か1人選ぶとすれば、熊谷さんでした。
 前職のSIer時代の師匠で、この人がいなかったら今の自分の振る舞いの多くはなかったと思うほど、エンジニア人生に大きな影響を与えてくれた1人です。
 25年近く1つの大きな組織にいながらも、エンジニアとして活躍しているその色々な決断を(いつも通り)軽妙なリズムでお話してもらえました。

大企業、未踏ソフトウェア、起業 様々な働き方から学んだ「モノ作り」のエッセンス(染田 貴志:@tksmd)
 RedmineやBacklogなどITSつながりで出会い、時には呑みながら色々議論してきました。
 チームの話や親子チケットをどう扱うか?など本当に多岐にわたってお話して、特にキャリアの話が生々しく、魅力的だったので、お願いしました。

アジャイルに生きる:フリーランスのデベロッパーとしての生き方(江川 崇:@t_egg)
 DevLOVE四国で初めて江川さんにお会いし、お話を聞きました。
 そのエンジニアとしての生き方や仕事への接し方が面白く、いつかDevLOVE関西で話して欲しいと思っていました。
#これより先にデブサミ関西2013でお話ししてもらったのですが。

最後に

 多くの方がお話されていましたが、どの決断が正解というのはないと思います。
 でもその時々で「これだ!」と思う決断をされてきたお話は私自身はどれも面白かったですし、聞き応えのあるものでした。
 そして、終わった時に心地良い疲れと共に「やっぱりこの8人にお願いして良かった」と感じました。

DevLOVE関西のソーシャルリンク

Facebookグループ
Facebookページ

Twitterアカウント

Doorkeeper

「アジャイルの好きなところ」(Ultimate Agile Stories2)

そろそろUltimate Agile Storiesの季節です。
というわけで、Ultimate Agile Stories1に続き、Ultimate Agile Stories2で書いた内容をほぼ原文で公開します。

題名:アジャイルの好きなところ

2. はじめに
皆さんは「アジャイル」のどういうところが好きですか?

「そもそもアジャイルとは何か?」という議論も色々ありますが、ここでは「アジャイルソフトウェア開発宣言」を理解して実践しようとしていることとします。
私が「アジャイル」に感じた好きなところは以下のようなものです。
 
(a)顧客により価値の高いものを提供することができる
(b)自分達の成功体験を短いスパンで感じることができる
(c)携わったプロダクトやサービスに誇りを持つことができる
(d)またこのチームで仕事をしたいと思うことができる

以降、それぞれについて書いていきます。

3. 顧客により価値の高いものを提供することができる

アジャイルでは顧客に実際に動くものを見てもらい、フィードバックを得ます。
そのフィードバックを次のスプリントの開発に活かすことで、本当に顧客が欲しかったものを提供できる可能性が高くなります。

スクラムだと、各スプリントで行う「スプリントレビュー」でデモなどを行い顧客に確認してもらいます。
私が過去に経験していたやり方のいくつかでは、システムテストまで顧客が実物を見て触る機会がなかったこともありました。
実際に使うユーザにいたっては、リリースするまでその機会がなかったこともありました。

常にユーザに見てもらえる状態を維持するのは、それほど簡単なことではありませんが、それにチャレンジする価値はあります。

要件定義や基本設計の工程の成果物を変更したりできず、またより良い方法をマネージャなどに提案しても力ない笑みや苦笑と共に…「もう決まったことだから」「お客様はそれで良いと言ってるから」という返答を聞いたことありませんか?

社内定義のQCDは充足していたとしても、発注者だけでなく、実際に使うユーザも含んだ顧客の満足度をもっとトレースしたいと思っています。

プロジェクト終盤によく聞く「自分達が欲しかったのとは少し違うなぁ…」という声よりも、プロジェクトの途中に何度も「こういうことをしたかったんだよ。後、ここをこうすればもっと嬉しい」というユーザの声を聞きたくないですか?

4. 自分達の成功体験を短いスパンで感じることができる

「スプリント・レトロスペクティブ」(ふりかえり)が大事な理由の1つとして、チームの良い点をより強化して、改善し、顧客への価値の提供のスピード、質を上げるというのがあると思います。
そして、それと同じほど大事な理由に「自分達チームのことを知って、成功体験を得る」があると思います。

私が過去に経験していたやり方のいくつかでは、「ふりかえり」はプロジェクト終了時…それこそカットオーバー後…に行うことが多くありました。
いくつかは詳細設計などの工程の終わりで実施していたこともありました。
途中でプロジェクトから抜けたり、あまりに大きなプロジェクトの場合、ひょっとすると「ふりかえり」の場すら無いかもしれません。
いずれにせよ、そこで得た改善や成功体験を活かすまで、長いスパンが必要になります。
これでは何度もあるレベルアップのチャンスを逃しているようなものです。

特に経験が浅いエンジニアほど「自分達のチームがどの程度イケてるのか?」に敏感な傾向があり、「ふりかえり」によって成功体験を得ることで一段と伸びていきます。

またチームメンバー同士でフィードバックをし合うことで、個人の成功体験を得て、自信を持つことができ、レベルアップにつながります。
さらに相互理解も深まりチーム全体のレベルアップにもつながります。

「明日からこのふりかえりで出た〇〇をやってみます」とメンバーが宣言しているのを聞きたくありませんか?

5. 携わったプロダクトやサービスに誇りを持つことができる

ある尊敬できるエンジニアが「コードのAuthorに自分の名前を入れたくないようなコードを書くな」と言っていました。
これはプロダクトやサービスでも同じようなものだと思います。

自分達チームがリリースしたプロダクトやサービスを街中やインターネットで見かけた時に胸を張って「自分達が作ったもの」と言えますか?

前述した「顧客により価値の高いものを提供することができる」内容にも関係しますが、私が過去に経験していたやり方のいくつかでは、不本意なコード、ユーザインターフェース、機能群を持ったシステムを提供せざるを得ないことがありました。

アジャイルでは徐々に顧客と一緒にシステムを作り上げていくので、顧客はもちろん自分達チームにとっても「誇り」と思えるものになる可能性が高いと思います。

「このサービスは僕が作ったんだよ」と家族や友人に言いたくありませんか?

6. またこのチームで仕事をしたいと思うことができる

私自身はアジャイルで一番好きなのはこれです。
これは「アジャイルな開発をしたから思った」「アジャイルな開発でないから思わなかった」わけではありませんが、感覚としてアジャイルなチームで開発をすれば、ほぼ間違いなくこの感情を持ちました。

私が過去に経験していたやり方のいくつかは「二度と〇〇の顔を見たくない」ということも残念ながらありました。
でも顧客から「これが欲しかったんだ」という声をもらい、成功体験を積み重ねて、プロダクトに誇りを持っているチームだとそうはならないと思います。

「またこのチームで仕事したい」という言葉を聞きたくありませんか?

7. 最後に

私は「これまで書いたようなことをできる/したいからアジャイルをやろうとした」わけではありません。

当時は色々悩んでいました。もちろん今も悩んでいます。
「どうしたらお客様もハッピーになってチームも楽しく良い価値を提供できるんだろう?」を日々考えて、動いて、フィードバックを得て、改善してまた動いて…を繰返していく中でたどり着いた「こういう状態で働きたい」という形が自分なりのアジャイルなプラクティスや姿勢に近かったという感じだと思っています。

「アジャイルをやりたいんです」とたまにを聞きますが、その前に自分達とチームがしたいことが何なのか?を考えてみるってことも大事かと思います。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo by palooja on VisualHunt.com / CC BY

SCRUM BOOT CAMP THE BOOKを読みました

SCRUM BOOT CAMP THE BOOKはいい本です!マネージャーも開発者もみんな読んでみてください!」で終わらせようと思ったら・・・


・・・と言われたので、もう少し書いてみます。

さらに「なかなか書けないなぁ」とウダウダしているうちに長沢(@tomohn)さんにも先を越されてしまったりしました。

いや、でも本当にいい本なんですよ。
私の説明や感想なんかより「とりあえず(2時間もあれば読めるから)読んでみてよ!」です。

読書感想文ですが

Scrumを構成する事柄(原則やロール、イベント等々)について、「どういう背景で、なぜそれが必要なのか?そしてそれがなかったらどうなるのか?」とかなり深く書かれているように感じました。
正解がない中でボクくん達のチームが何を考え、決断して、振る舞えば、より良いゴールに辿り着けるのか(これもあくまで”可能性が高くなる”の話ですが)がテンポの良いマンガとして描かれています。

実際にScrumをやっていると、陥りやすかったり、悩みやすかったり、はまったりしやすい色々なポイントに対して「自分(著者達)ならこう考えて、こうするよ」と考えや豊富な経験を見事に文章に書かれている点も素晴らしいと思いました。
#章やコラムによっては3人それぞれの声が脳内再生されたりして、ニヤニヤしました。

マンガのように最初のScrumでこれほどうまく行くこと(それでも、ボクくん達チームはリリース間際は深夜残業な様子でしたが)は簡単ではないでしょうし、もしかするとプロダクトオーナー、チームメンバーが最初から前向きなのも、なかなか珍しいかもしれません。

繰り返しになりますが、そんなところも含めてScrumの嬉しいところも、難しい(そんな簡単に上手く行かないよ)ところが余すところなく書かれています。

Scrumを実践者はもちろん、「アジャイル、スクラムって聞いたことがあるんだけどなぁ」という方もぜひ読んで「こういう方法もあるんだ」と手持ちのカードを増やしてもらえたらと思いました。
#自分が読みながらつぶやいたまとめ

最後になりましたが、こんな素晴らしい本を届けてくださった著者のみなさん、ありがとうございました!

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

社内勉強会の初めの一歩

先日のDevLOVE関西「勉強会勉強会」のビアバッシュでの話です。

社内勉強会を始めようと思った時の2つの不安

20人位の組織にいる人で「どうやって社内勉強会を始めて良いか分からない」という課題を持っていました。さらに聞いてみると以下の2つのことを強く気にしているようでした。
1:人が集まらなかったらどうしよう?
2:講師出来るほど教えることもないので、どうしよう?

「1:人が集まらなかったらどうしよう?」の自分なりの答え

「(自分以外に)もう1人いたらやってみる」
「勉強会勉強会」でもお話しましたが、自分以外にもう1人いれば、それは「勉強会」だと思っています。
2人以上いれば勉強会と呼べば良くて、呼び名や定義は些末なことかと。

2人でそのテーマについてお互いの知見や考えを話し合い、共有することで、それぞれが持っていた暗黙知が、2人にとっての形式知となりお互い勉強になります。
仮に新しい知識そのものに出会わなくても、自分とは異なる考え方を知るというのはそれだけで十分な価値があります。

特に小さな組織の場合、2,3人でも何かやっていたりすると「なにやっているんだろう?」と目に止まったりします。そういう興味を持っていそうな人も、勉強会をやっている人から見つけやすくなり、「一緒にどうですか?」と巻き込みやすくなります。

その相談してきた人は、アイデアとしてお茶の時間に休憩スペースにお菓子を用意して、そこでまずは始めということで軽くに30分程度でやってみようと話をしていました。

「2:講師出来るほど教えることもないので、どうしよう?」の自分なりの答え

「みんなで考えて、教え合えば良い」
 
誰か1人が参加者の中で一番そのテーマについて知っている講師である必要はどこにもないと思います。
もちろんテーマによっては、有識者がいる方が進めやすいというのもありますが、それこそみんなが持っている知識を持ち寄ることで解決できることもあります。
またそういう解決できない問題が実際に出てから、それを解決できる有識者を見つけに行っても良いと思います。

その相談してきた人は「【勉強】会」という名前からか、ロールとして「講師」「生徒」なイメージを持っている感じでした。
「自分はこう思うけど、みんなの考えはどう?」「ここのコードがわからなかったから、一緒に読み解いてみない?」と一緒に考えれば良いと思いました。
エンジニアの現場で出会う課題は、ほとんどが唯一の正解があるわけではなく、むしろそのコンテキストに応じた「より正しいと思われる選択を見つけに行く」必要があります。

なので、自分ともう1人が興味あることを見つけて、軽くやってみるのがまずは第一歩だと思ったわけです。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Lindsay Henwood via VisualHunt.com

プロジェクト完了報告書の問題

プロジェクト完了報告書

昔のいたある会社に「プロジェクト完了報告書」というドキュメントがありました。

「そのプロジェクトで得られた教訓を(自分も含めた)組織の別のプロジェクトの改善につなげる」ために作られ、プロジェクトの情報、経緯、様々な指標をまとめられているものです。
当時は規模や金額など一定条件のプロジェクトに対し、作成することが義務付けられていました。

ただそれが当時は有効に活用されていないと感じていました。

書くタイミング

1つは書くタイミングが遅いため、有用な情報が記載されにくい問題がありました。

当時、プロジェクト完了報告書は、カットオーバーやお客様が検収を終えた時など「プロジェクトの終了時」に書くことが大半でした。

そのため、「プロジェクト完了報告書」を書けるほど最初から最後まで携わり、内容を理解しているリーダーは、すでに別プロジェクトに参画していることが多くありました(そしてそういうリーダーは新しいプロジェクトでも忙しくなっています)。
それが原因で「プロジェクト完了報告書」を書く時間もなかなか取れず、さらに時間も経っているので記憶も薄れがちでした。その結果、既存資料からの抜粋などが多くなり、教訓や改善ポイントなどが抜け落ちてしまいます。

#リーダー以外のメンバーも、プロジェクトやお客様の目的、経緯、改善ポイントなどを把握できていることが望ましい形だと思います。しかしながらインセプションデッキとか書くと驚く程、違うってのも普通にあるので、これはこれでなかなか難しい問題です。

「終わってから作る」ことが原因の1つなので、ウォーターフォールであれば工程毎に数字や背景、ノウハウなどをサマリーして「少しずつ」完了報告書を作っていけば良かったと今になっては思います。

活用の仕方

守秘義務などもあるのでしょうが、ポイントとなる情報などは公開されていないことが多く、あまり有効に活用できませんでした。
「何かあって情報漏洩と言われたら困る」というディフェンシブな発想からか、隠さなくても良いノウハウなども書かれていないことも多くありました。

結局、当時の感じたところは以下のようなものでした。
作る側:(管理する側から)やいやい言われてうるさいから仕方なく作っている。
管理する側:これまでプロジェクト完了報告書を未提出のプロジェクトがありますた!が、注意したところこれだけ提出されるようになりました!!(えっへん)

その完了報告書がどれだけ他のプロジェクトに活用されたかを評価の指標に組み込んだり、作り手にフィードバックすれば良かったとこれも今になっては思います。

そのアクションや成果物の目的が何のためで、それが「期待通りに活かされているか?」「より良い活かし方がないか?」などを計測したり考えていかないと、せっかくの良い施策もムダになってしまいます。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

※アイキャッチ画像:http://www.flickr.com/photos/printhousecorp/6543078999/

ビジネスモデルを見える化する ピクト図解

ビジネスモデルを見える化する ピクト図解

少し古い本ですが、冒頭の例とその説明が分かりやすくて、一気に読みました。

冒頭の例

1:デジタルカメラ・電動ハブラシ・ヘアドライヤー・インクジェットプリンタ・ヘルスメーター・パソコン・・・カテゴリーが異なる商品の中で「儲ける仕組み」が同じなのはどれか?
2:Hanako・Goo・赤すぐ・週間少年マガジン・・・どれも雑誌だが、「儲ける仕組み」が微妙に違う。どのように違うか?

「ピクト図解」とは?

・「ビジネスモデルを見える化する」ツール
・1枚の図に「3W1H」をまとめる
 ※3W1H:「誰が(Who)」「誰に(Whom)」「何を(What)」「いくらで(How much)」
・オブジェクトは3つのエレメント、2つのコネクタ、2つのオプションとシンプル
・3つのメリット

1:”経営者の視点”を手に入れられる
2:説明不要で誰とでも共有できる
3:画像パターンを応用してアイデア発想ができる

#本書後半では、ピクト図解を応用した発想法として「ダイアグラム発想法」「アナロジー発想法」も紹介して、これも興味深いです。
 

読書メモ

・似たように見えてもそれぞれビジネスモデルが違う。
 また(一見売っている物や業界自体が)違って見えても(ピクト図の上では)同じようなビジネスモデルもある。そのビジネスモデルを見抜くことが大事。

・代表的な8つのビジネスモデル。
・いくつかの企業のビジネスモデルの話が出ているが、どの例も分かりやすいし、「なるほど、そうか」と思うのが多かった。(ユニクロのフリースの話、土間土間のメニューの話、アスクルの事業発展の話)

自分やお客様のビジネスをピクト図に描いていくのは割と費用対効果が良いと感じた。
 実際に自分の組織や考えているのを描いて、眺めて、色々いじっているといくつかアイデアが出てきたし。
 本格的な業務コンサルタントでなくても、このレベルのお客様のビジネスモデルを知っていることは損にならないし、知っておかないと”御用聞き”から抜け出せないかと。

・「めざすゴールによって、選ぶべきビジネスモデルは変わる」というのは当たり前なんだけど、「ビジネスモデルを考える」ことだけが目的になりがちなので、いつも意識しよう。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Visualhunt.com

自分のTwitterアイコンの変遷

Twitterアカウントのアイコンは干支をモチーフにしたものですが、元ネタはヨメさんが年賀状用に描いていたものです。
#コミュニティなどで使う個人名刺にも使っていて、名刺の作成は前川企画印刷さんのブロガー名刺にお願いしています。

描き始めて5年が経ったので、アップします。

2009年:丑(うし)

2010年:寅(トラ)

2011年:卯(うさぎ)

2012年:辰(龍)

2013年:巳(蛇)

番外編:@papandaさん

ヨメさん曰く「辰と巳て同じようなもんだから難しい」とのことでした。
というわけで、2013年もよろしくお願いします。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。