DevLOVE関西」カテゴリーアーカイブ

2020年のふりかえり

要約すると

COVID-19、ギルドワークスの体制変更など、大きな環境の変化がありました
またそれに伴い、大阪-東京移動がなくなりオンライン主体になったり、コミュニティ活動など自分の活動のやり方が変わった1年でもありました

現場コーチの仕事のやり方

COVID-19により仕事のやり方が大きく変わりました
これまでほぼ毎週2,3日、大阪と東京を行き来するリズムでしたが、これが無くなりました
3月以降に関東方面に行ったのはギルドワークスの合宿での1回だけでした

これに伴い、現場コーチの支援のやり方もオンライン中心になりました
オンラインミーティングでのファシリテーションやグラウンドルール、オンラインでの見える化のツール(Miroなど)、ちょっとした雑談や偶発的な会話が減ることによる影響をどうするかなど様々なことに取り組みました
幸いなことにギルドワークスは2014年の設立からリモートワークだったこともあり、この手のノウハウや知見、あり方などはありました
この点は、多くの支援先がリモートワークに関する課題に出会った時に役立てることができたようです

このような状況にも関わらず、いくつかの新しい現場から声をかけていただき、結果として例年とほぼ変わらない”新しい現場との出会い”がありました
正直、4月頃は「この先どうなることやら…」と不安に感じたこともあったので、とてもありがたいことだなと感謝しています

DevLOVE関西の活動

これまで毎年20〜30回開催していたDevLOVE関西ですが、2月に企画していた10周年イベントは中止になり、その後の活動も一切しなくなりました

オンラインイベントという形でやろうか?と思ったことも何度かあったのですが、「オンラインイベントを実施すること」自体に自分のモチベーションが湧かなかったというのが正直なところです
自分にとって毎回の”ダイアログ”と名付けた少人数のグループで「ああでもないこうでもない」と参加者のみんなが会話している雰囲気や光景が大きなモチベーションだったようです

ギルドワークスの変化

2014年の創業メンバーである市谷さんと増田さんが代表取締役と取締役をそれぞれ退任し、上野さんが代表取締役、私が取締役になりました
とは言うものの、それぞれこういうフォーメーションの変化に備えて1,2年前から動いていたこともあり大きな影響は今のところないように感じています

2020年のニュースやお知らせは全部で17本でした
2019年は37本だったのですが、主に発信していた市谷さんが抜けたので、この結果になりました

それでも支援先の事例をいくつか届けることができたのは良かったです
経営者とも、現場とも「共感」のスタンスで寄り添い、変化に強い組織に
コミュニケーションギャップを乗り越え、チームで作った「自分たちにあったスクラム」
バラバラだったメンバーが、気付くと本当のチームになっていた

勉強会やカンファレンスなどでの発表

Regional Scrum Gathering Tokyo2020 に参加してきました #RSGT2020 | サウスポーなエンジニアの独り言

JBUG 大阪 #4 オンライン! – connpass

スクラムフェス札幌 2020

読書数

読書数は53冊で2019年の85冊から減りました
これは東京-大阪の移動がなくなったことと、ゴールデンウィークや夏休みといった長期休みもあまり他の日と変わらない活動をしていたことが影響しています

雑談

2020年で増えたことの1つがオンラインでの雑談です
1対1や3人程度で、明確に決まったトピックがなくその時に話したいことを話していくことが多かったです
2,3週間ごとに数ヶ月継続した雑談している人もいます
ざっと数えてみると130回ほどでした

というわけで、また2021年もよろしくお願いします。

Photo by CHUTTERSNAP on Unsplash

2019年のふりかえり

2019年のギルドワークス

2019年のニュースやお知らせは全部で37本でした。
2018年は38本だったので前年と同じくらいです。

主な出来事

これら以外には、AgileJapanやプロダクトマネージャーカンファレンスなどカンファレンスへスポンサーという形で貢献できた2019年でした。

2019年の現場コーチ

2019年もいくつかの新しい現場から声をかけていただきました。
事業会社の現場でもっとうまくなりたいのでフィードバックや事例などを期待する現場もあれば、これからアジャイルに取り組んでいきたいがそのためには組織にある”当たり前”を壊していく仲間として期待されている現場もあり様々です。
また、長く支援させてもらってきた現場を卒業する話をする一方、もっと広い範囲で支援できないかと一緒に考えている現場もあります。

課題の傾向としては、開発のやり方がテーマの時もあるのですが、どうやったらユーザーに使ってもらえそうなものを見つけるか?といった仮説検証の話や”ビジネス側と開発側”といった組織構造やそれに起因する関係性がテーマが多くなっているように思います。

2019年の個人

読書

読書は85冊(2019年の読書グラフ)で2018年の86冊とほぼ同じ数でした。

勉強会やカンファレンスなどで発表したスライド

2019年はこんなことを話しました。

Regional Scrum Gathering Tokyo2019の感想(1日目) #RSGT2019 – サウスポーなエンジニアの独り言

Developers Summit 2019でお話してきました。 #devsumi – サウスポーなエンジニアの独り言


DevLOVE X でお話してきました #devlovex – サウスポーなエンジニアの独り言

「アジャイルコーチが見てきた組織の壁とその越え方」という話をします – サウスポーなエンジニアの独り言

2019年のDevLOVE関西

2019年は24回実施しました。2018年は27回だったのでほぼ前年と同じです。
話し手の皆さん、会場を貸してくれた皆さん、参加していただいた皆さん、ありがとうございました。

2020年にはDevLOVE関西10周年イベント「MIRAI 〜これまでの10年。これからの10年 〜」という場を持ちます。
2020年も引き続き、現場の前進のためにいろいろなテーマでDevLOVE関西をやっていこうと思います。

というわけで、また2020年もギルドワークス、DevLOVE関西をよろしくお願いします。

unsplash-logochuttersnap

DevLOVE X でお話してきました #devlovex

DevLOVE X(10周年記念イベント) でお話しました。

スライドとTogetter

#DevLOVEX 中村洋「「正しいものを正しくつくる」を探索し続けてきた10年とこれからの10年」 #DevLOVEXE Day1-2E - Togetter

DevLOVEへの感謝

あの場で伝えたかったことの1つはこのスライドです。

とにかく今の自分があるのはDevLOVEのおかげです。
このDevLOVEがなければDevLOVE関西もなかったと思います。
DevLOVE関西の誕生の経緯などは誕生!DevLOVE関西:Dev・Loveッ・関西!(2)外から見たDevLOVE関西(papanda編):Dev・Loveッ・関西!(3)に書いています。

そしてTwitterでこんな言葉をもらってすごく嬉しかったし、泣きそうでした。

もちろんDevLOVE関西は自分だけでなく、多くの話し手、会場を貸してくれるみなさん、参加者、そして一緒にやってくれる仲間のおかげで続いていると思っています。

最後に、DevLOVEのみなさん、ありがとうございました!

2018年のふりかえり

2018年のふりかえり

2018年は総じてどんな年だったか?

Five Fingerでいうと4というところです。

ギルドワークスとして

2018年のニュースやお知らせは全部で38本でした。

4月にロゴを変えたり(GuildWorksロゴのご説明)、「開発組織2.0」「いきなり最強チーム」「タイガーリープ プログラム」のように、これまでやってきた提供しているサービスや事業をよりわかりやすくし、より届けたいという狙いでそれぞれ個別の紹介ページを作ったりしました。

また、自分達もよく使っている仮説キャンバスオンラインツールの提供も開始しました。

現場コーチとして

ありがたいことに2018年も多くの現場から声をかけていただきました。久々に関西の現場でガッツリさせてもらったり、これまでとは少しコンテキストの違う現場やチームを知ることができました。
現場がいろいろと学んで自立できコーチがいらなくなった現場もあれば、期待のすれ違いでうまくいかず終わったものもあります。

またコーチを2人でやるパターンが何度かあり、お互い学ぶことが多く貴重な経験になりました。

ペアコーチングノススメ
Agileコーチと歩んだ学んだ3つのこと – @kajinari – Medium

印象として「アジャイルをやるために相談したい」の対象が少し前とは違ってきているように感じています。
相変わらず「開発チームを」というのは一定数ありますが、最近は開発チームにとどまらず「プロダクトづくりをアジャイルにやっていきたい」というご相談が増えてます。

そして実際に現場支援を始めるとアジャイルな度合いの高いプロダクトづくりのための組織の構造や組織運営をどうしていくか?などに向き合う割合が多くなっています。

個人として

読書

読書は86冊(2018年の読書グラフ)でここ数年で一番多かったです。
電子書籍の割合が大きくなっています。

勉強会やカンファレンスなどで発表したスライド

2018年はこんなことを話しました(他にも公開できないプライベートセミナー的なものもいくつか)。

Regional Scrum Gathering Tokyo2018(Regional Scrum Gathering Tokyo2018に参加してきた #RSGT2018 – サウスポーなエンジニアの独り言)

Backlog World | プロジェクト管理に関わる全ての方のための祭典

DevLOVE関西でタスクマネジメントについて話してきた #DevKan – サウスポーなエンジニアの独り言

DevLOVE関西のこと

2018年は27回実施しました。
話し手の皆さん、会場を貸してくれた皆さん、参加していただいた皆さん、ありがとうございました。

越境し、現場を前進させるための人の巻き込み方
関西の地で現場を前進させんとする者達の話
リーンスタートアップで事業を駆動している者達の事例
人が自ら考え、判断し、行動するように成長をうながすフィードバック
モブプログラミングを実践してみよう!! 〜アジャイルモンスターのモブプロ入門〜
あるエンジニアがプログラムを紡いでいく様を見てみる
ユーザーストーリーマッピングを使って、要求の全体像を把握しよう
カイゼン・ジャーニー / たった1人からはじめて、「越境」するチームをつくるまで (発刊イベント)
プロジェクトの組み立てに悩むリーダーのための 本当に使える開発プロセス(ダイジェスト版)
“個人のタスクマネジメント”のコツや悩みを話す場
モブワークをやってみる
カンバンによるムダのカイゼンの事例
現場の問題をみんなで話し合って、現場の前進の一歩とする
デビューの遅かったエンジニアの自分戦略
UXリサーチ手法#5「ジャーニーマップ」早わかり講座
”効率が良い”を考えてみる〜フロー効率性とリソース効率性のお話〜
Sansanの開発の現場
KPT以外のふりかえりのやり方を話してみる 〜現場改善の四方山話〜(DevLOVE関西番外編)
それぞれの現場を変えようとしている者達の話〜越境者の活動談〜
アウトプットを習慣化しようとしている人たちの話
KPT以外のふりかえりのやり方を話してみる #2 〜現場改善の四方山話〜(DevLOVE関西番外編)
UXデザインのはじめの一歩を体験しよう! ユーザーインタビュー、ユーザー心理分析の基本
継続的インテグレーション(CI)・継続的デリバリー(CD)のお話
ScrapboxやGyazoを生み出しているNOTAの開発の現場
Engineering Manager を語ろう
現場でレガシーコードに立ち向かっている者達の話

自分がきっかけになるより誰かの現場の話題や関心ごとから開催に至ったものが例年に比べて多かったようです。

というわけで、また2019年もよろしくお願いします。

DevLOVE関西でタスクマネジメントについて話してきた #DevKan

DevLOVE関西“個人のタスクマネジメント”のコツや悩みを話す場で「リズムを作ってやる自分なりのタスクマネジメントの話」を話してきました。

言いたかったこと

タスクが積み上がってくると、時間も気持ちも余裕がなくなっていき、「どうやったら効率良くこのタスクを片付けることができるか?」と”やること”を前提に考えがちです。

しかし、落ち着いて一歩引いて見てみると、積み上がったタスクの中には、しなくてもなんとかなるものもあります。
少なくとも”今すぐ”でなくてもそれほど困らないものはけっこうあります。

まずは”やらないとどうなるか?”を小さく実験して、何が起きるのか観察してみることで、いらないタスクを見つけることができるかもしれません。

発表を終えて思い出したこと

発表ではデジタルツールの話しかしませんでしたし、付箋やA4の紙にタスクを書き出して消し込んでいくというアナログな運用もしています。

自分のデスクで仕事をする時にはA4のメモ用紙にタスクを書き出してやることが多いです。
ポモドーロをやっている時に思い出したものは(Trelloではなく)、手元にある紙に書いてすぐにそれまでやっていたタスクに戻ります。
そしてそのポモドーロが終われば、(目安として)15分以内に終わりそうなものはそのままやりますし、そうでなければTrelloにcardとして記録しておきます。

このあたりはアジャイルな時間管理術 ポモドーロテクニック入門の内容を応用しています。

このA4に書いていく+ポモドーロテクニックの組み合わせは自分なりのリズムづくりになっています。
すぐにするタスク達なので、自分だけにわかれば良いという乱雑な感じで書いていますし、それをリズム良く、ペンでシャッと消す感覚が自分の仕事のエンジンがかかる一因にもなっています。

Trelloの話

松尾さんもTrelloのお話をけっこうされていましたが、自分なりのTrelloの使い方などです。

Chrome拡張

  • Scrum for Trello:cardに見積時間、実績時間を入力することができるようになります(デフォルトだとプランニングポーカーで使われるフィボナッチ数列)。
  • Card Color Titles for Trello:ラベルの名称を表示してくれます。
  • CardCounter for Trello:それぞれのlistのcardの枚数を表示してくれます。

PowerUPS

Card Aging はちょっと変わり種で、放置されているとcardが”ボロボロ”になっていくエフェクトがかかります。

ステージ(Trelloではlistと表現)

  • いつかやる
  • 来週やる
  • 今週やる
  • 今日やる
  • 今やっている
  • もう終わった

「来週やる」「今週やる」は見積もった時間が週の働く時間を越えていないかチェックしています。
「今日やる」は見積もった時間が週の働く時間を越えていないかチェックしています。

2017年のふりかえり

2017年のふりかえりです。

2017年は総じてどんな年だったか?

5段階なら4という感じです。

ギルドワークスとして

「正しいものを正しくつくる」という旗を掲げて活動しているギルドワークスとして、そこにより向かうためにいきなり最強チーム仮説検証型アジャイル開発などを公開しました。

また情報発信という意味ではなかなかできていませんでしたがギルドワークスアドベントカレンダーをコンプリートできたことも大きかったです。

現場コーチとしては、引き続き、クライアントにも恵まれました。順調に成長して卒業した現場もあったり、新たな現場支援をお声がけいただきました。

個人として

2月に人生初の入院をしたり、個人プロジェクトを断念したりと少し凹みもありました。
一方、DevLOVE関西の活動も例年通りできましたし、個人としても色々発表できました。

2017年後半は意図的に人と会うことを増やしたりして、自分の考えの枠を変えたり、引き出しを増やしたりする活動もできてきました。

勉強会などで発表したスライド

2017年はこんなことを話しました。

Regional SCRUM GATHERING Tokyo(Regional SCRUM GATHERING Tokyoに参加してきた)

Agile Japan 2017 大阪サテライトでのLT

DevLOVE200 Bridge

KANJAVA PARTY 2017 !!!(KANJAVA PARTY 2017 !!!で「DevLOVE関西からギルドワークスへの越境」を話してきました。

Geeks Who Drink in Tokyo-Agile Team Edition-

ギルドワークスのイベント

「正しいものを正しくつくる」とは何か

プロジェクトの全体像をみんなで考える「インセプションデッキ」

DevLOVE関西のこと

2017年は20回開催しました。2016年は21回だったので、ほぼ同じ数を開催できました。
話し手の皆さん、会場を貸してくれた皆さん、参加していただいた皆さん、ありがとうございました。

2017年は久しぶりに大きなイベント【DevLOVE関西2017 commitment 〜”何”にコミットするのか?〜】を開催できました。

Regional Scrum Gathering Tokyo 2017 報告会 (スクラム道関西共同イベント)
マネージャーによるメンタリングの話
プロジェクトマネジメントの勘所
リンスタ関ヶ原 (新大阪の変)
自分のメンタルモデルに気づく
自分の生産性と組織の生産性を向上するための8つの習慣
How to Energize People: Management 3.0ワークショップ体験
デザインリニューアルの難しさ
自分戦略〜CTO編〜
現場を前進させる若者たちの話
ドローンやGPSとGIS(地理情報システム)で、次世代サービスを考えてみる
モブプログラミングをやってみる
ビジネスマンを「めんどくさい」から解放する【RODEM】の開発の現場
「心理的安全性」のことに思いを馳せてみる
シリコンバレーから学ぶサーバントリーダーシップ
「現場で役立つシステム設計の原則」読書会(第1回)
製造業の現場での反復開発の事例
大きなSIerの中で「アジャイル開発で飯を食う」までの歩み
「グラフをつくる前に読む本 一瞬で伝わる表現はどのように生まれたのか」を語り尽くす
DevLOVE関西2017 commitment 〜”何”にコミットするのか?〜

2018年1月に越境し、現場を前進させるための人の巻き込み方関西の地で現場を前進させんとする者達の話があります。

2018年はどんなことをするか?

ギルドワークスとして

5年目になるので、これまで積み重ねてきた学びをより伝わりやすく言語化していく活動に力を入れていくとともに、新たな発見が得られるよう、より越境していきたいと思います。

個人として

DevLOVE関西を続けつつ、機会をいただければ積極的に話していきたいと思います。
嬉しいことに1,2月で話す機会をいただけています。
1月:Regional Scrum Gathering Tokyo 2018での「ふりかえり」の始め方と続け方
2月:Backlog World | プロジェクト管理に関わる全ての方のための祭典での「アジャイル開発でのデジタルツールとアナログツールのバランス(仮)」

2017年はやりきれなかった個人プロジェクトを何か1つでも形にできればと思います。

というわけで、また2018年もよろしくお願いします。

Photo on VisualHunt

KANJAVA PARTY 2017 !!!で「DevLOVE関西からギルドワークスへの越境」を話してきました。 #KanJavaParty

KANJAVA PARTY 2017 !!!でお話してきました。

お話をいただいた時に「最近、Java書いていないし、何話せばええんやろうなぁ」と少し困っていたのですが、DevLOVE関西というコミュニティとギルドワークスが価値にしている越境を軸にお話しました。

エモい成分が高く、抽象的な話ですが、タイムラインを見ると、何人かには印象的だったみたいです。

お声がけいただいた関ジャバの皆さん、聞いてくださったみなさん、ありがとうございました〜

2016年後半のDevLOVE関西の活動記録

2016年後半のDevLOVE関西の活動記録

2016年は月1、2回ペースで21回開催することができました。
参加していただいた皆さん、話し手の皆さん、会場提供していただいた皆さん、そしてスタッフの皆さん、ありがとうございました!

このエントリでは後半(7〜12月)の活動記録をふりかえってみます。
また2016年前半の活動記録もよければご覧ください。

7月〜9月

早く本物のチームになるためにすること

より早くチーム本来のパフォーマンスを発揮するために、“メンバーの特性を知る”というワークショップを行いました。

エンドツーエンド(E2E)のテストを手なづけてみる

増田(@whosaysni)さんには「Taming Robot Framework」と題し、Robot Frameworkの話をしてもらいました。
またバタール・フロラン(@shenril)さんには「ゼロから自動までテストの旅」と題し、過去2年間で、ゼロからテスト環境や社内文化を作った話をしてもらいました。

カンバンを作ってみよう

見える化の1つの手法であるカンバンに関するセッションとワークショップを長沢 智治(@tnagasawa)さんに行ってもらいました。
ワークショップでは実際にカンバンのレーンを作り、ボトルネックを計算してみるところまで行いました。

長沢さんのスライド「カンバン クイックスタート」。

プログラミングを楽しく続けるための健康Hack

良いコードを書き続け、良いプロダクトを継続的に生み出していくには健康であることも必要な条件の1つです。
一方でそのコードを産み出し、プロダクトを世に送り届けるエンジニアは不規則な生活や運動不足になりがちです。

健康でありつづけるためのヒントとして、「ヘルシープログラマ ――プログラミングを楽しく続けるための健康Hack」を訳した玉川 竜司さんと、走ることをきっかけとして、「レガシーボディの改善」のための工夫をパタンランゲージにしようと取り組んでいる懸田さんにお話してもらいました。

SIerから飛び出して、それからどうするの?

SIer→事業会社→起業と一見似ているように見える道を歩んできた者の話を聞いて、自らの「自分戦略」と向き合うという場でした。

10月〜12月

社内勉強会を続けるコツ

DevLOVE関西でも3回目となる「社内勉強会」をテーマにしたものでした。
数ヶ月前に社内勉強会を始めた人(藏さん)と数年前から社内勉強会をしていた人(佐藤さん)、それぞれの話を聞いた後は、参加者それぞれの現場で社内勉強会をするために困っていることなどを話し合うことができました。

ドメイン駆動で開発する〜初期のラフスケッチから実装まで〜

初期のモデリングを実際にどうやっているかの事例の紹介と、モデルのラフスケッチをコードに落としていく勘所をみなさんと共有することで、よりスムーズに現場に導入できるのでは?と考えました。

日々現場でドメイン駆動設計を実践している増田亨(@masuda220)さんに実践の事例と勘所を話してもらい、その後は活発な質疑応答の場となりました。

ビブリオバトルであの人のおすすめの本を知ろう

飛び入りも含めて9人の話し手がそれぞれオススメの本を伝えました。

優勝はこの「みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド」でした。

『リレーコーディング』でチームで楽しくプログラミングを学んでみよう

2016年最後のDevLOVE関西は「1人1行ずつ順番にコーディングしていき、みんなでお題を満たすプログラムを完成させる」という「リレーコーディング」というアクティビティをしました。
Pythonチーム、C#チーム(2チーム)の3チームで「Hello World」「1 〜 10の数字を表示するプログラム」「FizzBuzz」とお酒を呑みながら、ツッコミしながらという楽しい雰囲気の中、行われました。

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

Facebookページ
Doorkeeper
Twitterアカウント

Photo credit: Menlo Innovations via VisualHunt.com / CC BY

2016年前半のDevLOVE関西の活動記録

2016年前半のDevLOVE関西の活動記録

2016年は月1、2回ペースで21回開催することができました。
参加していただいた皆さん、話し手の皆さん、会場提供していただいた皆さん、そしてスタッフの皆さん、ありがとうございました!

このエントリでは前半(1〜6月)の活動記録をふりかえってみます。

1月〜3月

それぞれの現場で実践した【自動化】の話

コンシューマゲームの現場からプラチナゲームズの森田さん(@pg_morita)、そしてECサービスの現場からMonotaROのクツさんの2セッションを行いました。
セッションの後はダイアログでそれぞれの現場の自動化について話し合いました。

「エンジニアが幸せな人生を過ごすための学び方、関わり方、あり方」の再演

DevLOVE現場甲子園2015『西日本大会』で「どうしてももう1度聞きたい賞」だった「エンジニアが幸せな人生を過ごすための学び方、関わり方、あり方」を久保さん(@HappyLuckyAkira)に再演でした。

「インフラエンジニアの現場における仕事と文化」のDiff

Wantedlyの坂部さん(@koudaiii)はWantedlyのインフラがどのように変化しているのか(まさにその日に変化した話も含めて)というテーマでした。
またAWSの永田さんはこれまでの経験を元にした構築作業の自動化に取り組んでいるお話を「地道にAWS構築自動化に取り組んでいるお話し」として話をしてもらいました。

グラフィックレコーディング〜構造化のコツ〜

議論を構造化して、可視化するテクニックであるグラフィックレコーディング。この日は「構造化」にフォーカスし、和田あずみさんたちにワークショップ形式で実際に手を動かして構造化するとはどういうことか?を体験する場を持ちました。

ワークショップの様子はDevLOVE関西のFacebookページでも見ることができます。

『ShareWis』のサービス開発の現場

サービス開発の現場シリーズ。
この日は「学ぶ希望が見つかる場所をつくる」をミッションにShareWis(シェアウィズ)を開発、提供しているシェアウィズの辻川さんに「EdTechサービスを4年間やってみて気づいたこととこれから」を、また国平(@Kuchitama)さんに「ShareWisの文化を支えるエンジニアリング」という話をしてもらいました。

3月〜6月

リモートワークの現場の知恵

DevLOVE関西で過去2回実施しているリモートワークをテーマに粕谷(@daiksy)さんに「なぜチャットツールには絵文字補完機能があるのか」というセッションをしてもらいました。
その後はリモートワークをやっているグループ、まだ経験したことがないグループで、「リモートワークのよかったところ、むずかしいところ」「リモートワークを導入するにあたって、個人、組織それぞれで不安に感じているところ」などをテーマに知見を披露し合いました。

myThingsを通じてIoTの一端を知ってみる

myThingsを通じてIoTの一端にふれてみるハンズオンでした。
こんな感じでRaspberryPiを用いたハンズオンだったので参加者の皆さん、楽しそうに手を動かしていました。

難しそうな「情報設計」に実際にふれてみる

知識やデータの組織化を意味し、「情報をわかりやすく伝え」「受け手が情報を探しやすくする」ための表現技術である「情報アーキテクチャ (Information Architecture)」について山下 一樹さんにお話してもらいました。その後は、情報設計のコツなどを体験する簡単なワークショップをしてもらいました。

スクラム現場ガイド出版記念。現場の物語を共有しませんか?

スクラム現場ガイドの翻訳者の1人である原田 騎郎(@haradakiro)さんと共にほぼQ&A、ディスカッション形式で進んだ場でした。

サイボウズの開発の現場

サービス開発の現場シリーズ。
サイボウズさんのプロダクト「kintone」。その開発チームのKAIZENの文化、品質に関する現場の取り組みを三苫さん、酒井さん2人のエンジニアに語ってもらいました。

技術選択の難しさ、指針を考える

どの現場でもほぼ出くわすことになる技術選択の難しさ、指針というテーマで、後藤 知宏(@mkkn_info)さんには「フロントエンドエンジニアがみる生存戦略入門 〜 なぜ我々は学び続けるのか 〜」を、足立さんには「10年目の大変更。シェアNo.1が新しい技術を選択する時。」をお話していただき、その後は、それぞれの現場のコンテキストに応じた対話をして悩みを話したり、それに対する知見を伝え合ったりしました。

それぞれの現場におけるチームづくりの試行錯誤

「どうやってチームを作るか?」「どうやってチームを育てていくか?」について、それぞれの現場…事業会社におけるサービス開発、受託開発、現場コーチからの視点…での試行錯誤の話をしてもらいました。
その後は参加者からの質問を「3人ならどうするか?」と意見を出し合う場となりました。



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

Facebookページ
Doorkeeper
Twitterアカウント

DevLOVE関西

28回開催した2015年のDevLOVE関西

DevLOVE関西、2015年は28回開催することができました。
2014年の40回2013年の35回に比べると減り、一月に2回というペースでしたが、100回を越えることもできました。

参加してくれた皆さん、話し手の皆さん、会場提供していただいた皆さん、そして裏方スタッフの皆さん、ありがとうございました!

2015年も色々やりました

DevLOVEの2つのコンセプト「開発の楽しさを発見しよう。広げよう」「開発の現場を前進させよう」にあるように、1つに偏らず色々なテーマでやることができました。
2015年の特徴は、特定の技術ではなく、事業会社の現場の話、サービス開発の現場の話といった「現場」に着目したものも多かったことです。

事業会社の現場シリーズでは、クックビズさん、モノタロウさん、ロックオンさん、またサービス開発の現場シリーズでは駅すぱあとから始まり、houren.soboardMackerelesaDocBaseといった様々な現場のお話をしてもらいました。

年に1回の大きめの場としてDevLOVE現場甲子園2015『西日本大会』を実施し、全15話の現場の話をお届けるすることもできました。

ずっと感じていることですが、毎回初参加の方が一定数いてくれることは主催しているスタッフとして嬉しいことでした。

やったことのリスト

※各イベントの詳細はこちらでご覧ください。

01/19 事業会社の現場を知ろう~クックビズ編~
01/26 JavaScript フレームワークは Angular JS だけじゃない!
02/02 ウェブデザイン・ウェブ開発に必要なこと(DevLOVE仙台共同企画)
02/04 「APIデザインの極意」読書会#2
02/07 「駅すぱあと」を支える開発 〜9262の可能性を繋げ!〜(DevLOVE関西Ver)
03/07 メトリクスによる「見える化」のススメ: エッセンシャル・リーン
03/20 事業会社の現場を知ろう~モノタロウ編~
04/04 システムテスト自動化ワークショップ
04/10 農業の「現場」から生まれた業務改善サービス「houren.so」の話を聞いてみる
04/11 コミュニケーションツールと“持ち寄り型”プロジェクトマネジメント
04/18 自分戦略〜エバンジェリスト編〜
04/20 現場主導によるITS導入
05/11 現場の課題や困りごとをライトにトークしてみる
05/15 クリエイターの技術持ち寄り発表会〜デザインそもそも論〜
05/25 事業会社の現場を知ろう~ロックオン編~
06/11 「レビュー」をもっとうまくやってみる
06/26 TOCを初めて知ってみる
07/18 議論を楽しく見える化しよう!グラフィック・レコーディングワークショップ
07/24 クラウド時代のエンジニアの役割〜AWSを使い続けて気づいたこと〜
08/15 プレゼンの技術
09/12 妖怪と一緒に現場のコミュニケーションの問題を解決しよう! ー 最新のパターンランゲージ技術とカウンセリング技術の応用 ー
09/14 現場のアーキテクチャの話をしてみませんか?
09/18 『board』のサービス開発の現場
09/19 DDD(ドメイン駆動設計)実践者の話を聞いてみよう
11/09 『Mackerel』のサービス開発の現場
11/16 クリエイターの技術持ち寄り発表会〜仕事の考え方、回し方編〜
11/28 esaとDocBaseのサービス開発のDiffの話
12/05 DevLOVE現場甲子園2015『西日本大会』

2016年はそれぞれの現場で実践した【自動化】の話、そして「エンジニアが幸せな人生を過ごすための学び方、関わり方、あり方」の再演といったDevLOVE現場甲子園の再演からスタートです。

2016年もDevLOVE関西の場に関わった話し手、皆さんの現場が前進できることをやっていきますので、よろしくお願いします。

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

Facebookページ
Doorkeeper
Twitterアカウント

メトリクスによる「見える化」のススメ: エッセンシャル・リーン #DevKan

2015年3月7日(月)に「メトリクスによる「見える化」のススメ: エッセンシャル・リーン」を開催しました。
#会場を提供していただいたシナジーマーケティング様、ありがとうございました。

きっかけ

2014年秋頃に発表されたスライドを見た時に「自分の現場でもこのエッセンスは役に立つので、ぜひ話を聴いてみたい」と思ったのがきっかけで、伊藤さん(@hageyahhoo)にお声がけをしました。

私は「現場コーチ」という肩書きで色々なクライアント様の開発チームと一緒に、プロセスや開発の改善をしていくことを多くしています。

その際に闇雲にやるのではなく、狙いを絞る必要があります。そのためにも「今どのような状態で、それをどのようにしたいのか?」という現在地点と目標地点を見極め、その途中経過を計測して、把握することが大事です。
その見極めや把握は定性的なものではなく、定量的であることも大事です。

その定量的に計測するポイントなどを学ぶことができればと期待していました。

内容

セッション、ワークショップの内容やその裏での狙いなどは伊藤さんのブログに詳しく書かれていますので、そちらをどうぞ。

改めてメトリクスをどう設定して、見える化するのか大事さを感じました。
この手のメトリクスは1つ(例えばディベロッパー)の視点になりがちなのですが、このワークではマネージャ・デベロッパー双方の視点をぶつけ合うことで一方的なメトリクスにならないようにしていました。
これは実際の現場でも同じで、開発チーム以外にもマネージャーをはじめ、様々な視点を持った違うロールの人がいます。その人達にも納得感のある内容、見せ方が大切になってきます。

実体験と重ね合わせて感じたこととしては、メトリクスを実際の取るのに手間がかかるやり方では定着しないということです。
一手間で誰もが見れるようにする、自動化していつでも見れるようにするというのもこの手のプロセスでは大事です。
ただ様々な理由でそこまでできていないこともあるので、まずはうまくリソースを使いながらメトリクスの重要性を見せていって、より効率良くするためのリソースを獲得する…といった戦略も大事になってきます。
#その最初の段階をクリアするために伊藤さんのような内部のコーチや外部のコーチの力を借りるという方法もあります。

後は、なかなか他の人のワークショップの進め方を見る機会はないので、伊藤さんのワークショップの進め方などを垣間見れたのは面白かったです。

今後のDevLOVE関西

FacebookページDoorKeeperでお知らせしますので、興味ある方はお越しください。

「駅すぱあと」を支える開発 〜9262の可能性を繋げ!〜(DevLOVE関西Ver) #DevKan

2015年2月7日(月)に「「駅すぱあと」を支える開発 〜9262の可能性を繋げ!〜(DevLOVE関西Ver)」を開催しました。
#会場を提供していただいたはてな様、ありがとうございました。

きっかけ

東京のDevLOVEページでこれを知り、「四半世紀前からのソフトウェアの話ってきっと学びが色々あるんだろうなぁ」と思っていました。
そんな時、たまたま話し手の一人である新井さんに「今度DevLOVE関西でもやって欲しいです」と相談したら、「じゃ前回の話し手全員で行きますよ!」という嬉しいお返事をいただきました。

#ちなみに新井さんはDevLOVE Advent Calendar 2014 「越境」で1人10エントリを書いた猛者です。

内容

募集ページにスライドやブログのリンクをまとめています。

駅すぱあとの産みの親である宮本さんのセッションからスタートしました。

プロダクトに四半世紀も携わってきただけあって、どのエピソードもとても面白かったです。
最後の方の「自分の経験がこれからの人に少しでも役に立てばと思って今日は話しました」という言葉がすごく印象的でした。
主催者の1人としてはこの宮本さんのお話を聴けただけで本当に満足していました。

次のセッションは一転してDSLの話。
しかし「運賃計算ってなんでこんな複雑なんだ?」というのが印象でした。その中で技術と業務(ドメイン)の会話をスムーズにするためにチャレンジされているお話でした。

さらにDevOpsBizのお話。これもあるある話だったのですが、「あるよねぇ、仕方ないよなぁ」で終わらずに関係者を巻き込んで進めているというお話でした。

新井さんのお話。組織改善、変革をすごいスピードと情熱でやっているその実例のお話でした。これだけやるのもすごいですし、何よりそれを自分のところだけで終わらずに他の部署や社外にも向けてアウトプットしているのがすごいです。特に人材交換はホンマにやってみたいなぁと強く思いました(ギルドワークスとヴァル研究所さんでできないかな)。

最後は新規サービスのProduct/Market Fitのお話。ギルドワークスでも新規サービスに色々関わっているので、この辺の難しさを共感しました。いいなぁと思ったのは、本やサイトに載っていることを鵜呑みにせず、ぶつかった壁に対して「じゃ自分達の現場ではどうやったらうまく行きそうか」を色々試している点でした。

セッションが終わった後は、そのままピザとビールを投入しての懇親会をしました。ここでも話し手ごとのテーブルごとに色々な話が盛り上がっていました。
20150207_164414

今後のDevLOVE関西

FacebookページDoorKeeperでお知らせしますので、興味ある方はお越しください。

ウェブデザイン・ウェブ開発に必要なこと(DevLOVE仙台共同企画) #DevKan

2015年2月2日(月)に「ウェブデザイン・ウェブ開発に必要なこと(DevLOVE仙台共同企画)」を開催しました。
#会場を提供していただいた楽天様、ありがとうございました。

きっかけ

DevLOVE仙台のスタッフの佐々木(@chachaki)さんが、今回の話し手である細川さんが書かれているブログ「バニレートデザイン」のファンで、特に「ウェブデザインに関する知識や技術の相互関係チャート」が面白そうなので、これを元にしたお話をしてもらいたいというのが、そのきっかけでした。

そして久々にDevLOVE関西、DevLOVE仙台での共同企画がスタートしました

内容

まずバニレートデザインのブログの書き手、細川富代さんのセッションからスタートしました。

ウェブデザインの歴史から始まり、ウェブデザインに関係する要素という流れでした。
スライドにはそれほど説明はありませんが、細川さんの話は整理されていてとても分かりやすかったです。

続いてDevLOVE仙台の角銅さんのセッションです。
こちらは角銅さんが自分達がされている開発の流れをその必要性などの面にフォーカスしてお話してもらいました。
このお話はギルドワークスでやっているプロセスにも似ていたので、参考になりました。

セッションの後は以下のテーマでダイアログとしました。
ダイアログ

ダイアログの時間は少し短めでしたが、DevLOVE関西、DevLOVE仙台それぞれでどんな話をしたかを(一部ですが)共有したりしました。

今後のDevLOVE関西

FacebookページDoorKeeperでお知らせしますので、興味ある方はお越しください。

DevLOVE関西「JavaScript フレームワークは Angular JS だけじゃない!」 #DevKan

JavaScript フレームワークは Angular JS だけじゃない!」を開催しました。
#会場を提供していただいたシナジーマーケティング様、ありがとうございました。

きっかけ

きっかけ

話し手の一人でもある中村 久司さんのこんな言葉がきっかけでした。
当時、私はいくつかのJavaScriptのフレームワークを調べていて「いっぱいあるなぁ…」と思っていたこともあって、これをDevLOVE関西のテーマにしてみようかと企画を蹴り出しました。

結果的に(DevLOVE関西の企画にしては珍しく)半年以上後になりましたが開催できました。

セッション

話し手3人それぞれのスライドです。

セッションの後は、セッション毎=紹介したJavaScriptのフレームワーク毎にグループに別れてQ&Aを行いました。
KnockoutJSやVue.jsのグループには割と自分でガリガリと使っている人が集まり「このブラウザでこの場合にうまく動かないんだけど、みんなどうしている?」と言った話が盛り上がり、一方、Senchaではセッションのタイトル通りエンタープライズでお仕事をされている方が多く集まっていて、「現場への導入トレーニングをどうスムーズにするか」などの話がメインで特色が出ていました。

今後のDevLOVE関西

FacebookページDoorKeeperでお知らせしますので、興味ある方はお越しください。

DevLOVE関西「事業会社の現場を知ろう~クックビズ編~」 #DevKan

2015年最初のDevLOVE関西として「事業会社の現場を知ろう~クックビズ編~」を開催しました。
#会場を提供していただいたファーストサーバ様、ありがとうございました。

クックビズさんとはギルドワークスとして…厳密にはギルドワークスを立ち上げる前から仕事を一緒にさせてもらっていました。
CEOの藪ノさんや杉田さんとやり取りが楽しく、またその考え方も自分にとっても考える内容が多かったので、一度DevLOVE関西でお話してもらおうと思い、お願いしました。

また事業会社のエンジニアが普段どのようなことを考え、行動しているか?という話はあまり関西では聞かないのでは?と思ったこともありました。

藪ノさんの採用の話はギルドワークスも常に仲間を見つけているので、自分達の採用や「どんな人と働きたいだろうか?」と色々と考えることがありました(この辺はまたまとまったら書きます)。

杉田さんのスライドは以下で、特に事業会社と受託会社のマインドセットの話は共感しました。

2人のセッションの後は数人のグループに別れ、以下の4つのテーマでダイアログ(対話)をしました。
ダイアログテーマ_20150119

参加していただいた皆さん、話し手の藪ノさん、杉田さん、ありがとうございました。

DevLOVE関西

40回開催した2014年のDevLOVE関西

DevLOVE関西、2014年は40回開催できました。
#2013年の話は「35回開催した2013年のDevLOVE関西」をご覧ください

参加してくれた皆さん、話し手の皆さん、会場提供していただいた皆さん、そして裏方スタッフの皆さん、ありがとうございました!

2014年も色々やりました

開発現場に伝えたい10のこと」という電子書籍の話【「開発現場に伝えたい10のこと」それぞれの後日談】から始まり、【アーキテクチャについて知ってみる】まで、いずれもDevLOVE関西のコンセプトの1つである「現場を前進させる」を目標に色々なテーマでやっていきました。
また年に1回の大きめの企画も【DevLOVE甲子園2014 西日本大会】を実施することができました。

色々なテーマでやっていることもあったせいか、毎回初参加の方がいてくれたのが嬉しかったです。

やったことのリスト

※各イベントの詳細はこちらでご覧ください。

01/14 「開発現場に伝えたい10のこと」それぞれの後日談
01/25 ファシリテーショングラフィックで議論の見える化をしよう
01/26 UXデザインのためのユーザーの価値観分析ワークショップ 〜KA法を試してみよう〜
02/01 「SCRUM BOOT CAMP THE BOOK」片手にアジャイル開発を考えてみよう!
02/08 「Sencha Touch」でHTML5を使ったモバイル向けWebアプリケーションを作ってみませんか?
02/18 TrelloやBacklogを活用して仕事に追われないようにする方法
02/21 StartupWeekendTokyo × DevLOVE関西 〜開発の現場 meets Startup〜
02/25 顧客を理解する!インタビューの基本
03/15 ぐるぐるDDD/Scrum – ドメイン駆動設計。モデリングと実装のうずまきをまわしてみよう
03/17 再演「DevLOVE関西 ~Decision~」
03/25 レガシーコードと対峙する方法を考える
03/27 勉強会勉強会 〜君がッ 参加するまで 勉強会をやめないッ!〜
03/29 プログラマ35歳定年説勉強会
04/19 自動テストの誤解とアンチパターン
04/22 技術書の海から脱出しよう!エンジニアがおすすめ本を語り合う、ビブリオバトル in DevLOVE関西
04/24 Vagrant体験入門
05/17 泥臭い受託開発を語り合う(DevLOVE関西×DevLOVE仙台コラボ企画)
05/21 継続的デリバリー(Continuous Delivery)のお話を聞いてみよう
05/29 ユーザテストLive! 見学会 in KYOTO – 「あなたは”ユーザーテスト”を見たことありますか?」
05/31 組織に新しいアイデアを広める方法(パターン)を学んでみる
06/12 テスト自動化の様々な道具を使ってみた四方山話
06/27 WebDesign workshop of the programmer, by the programmer, for the programmer #4
07/08 リモートワークを実際にやってみてどう?
07/11 Selenium 2 WebDriverハンズオン
07/15 知っておいて損はない!エンタープライズiOSアプリ導入のいろは
08/09 進め、現場のチーム開発 〜チーム開発実践入門〜 (DevLOVE関西Ver)
08/23 DevLOVE甲子園2014 西日本大会
09/08 「エッセンシャル・スクラム」読書
09/27 ワークショップをうまくやってみる方法を学ぶ
10/03 運用現場の話を聞いてみる
10/17 それぞれのリモートワークの軌跡とこれから
10/20 NoSQLの1つ「MongoDB」を知ろう
10/30 5年目、10年目の自分戦略
11/01 「CakePHPで学ぶ継続的インテグレーション」ハンズオン
11/17 エンジニアとして、英語と向き合ってみよう!
11/25 観察からはじめる「仮説の立て方・想像の仕方」
11/28 エンジニア×営業
12/02 「APIデザインの極意」読書会#1
12/19 Dockerを現場に取り入れてみよう!
12/20 アーキテクチャについて知ってみる

こうやって眺めてみると本当にいろいろやっています。
もちろん回数が多ければ良いというわけではないので、参加してもらった方の現場が少しでも前進できる内容をこれからもやっていきたいです。
2015年も色々やっていきますので、よろしくお願いします!

2015年最初のDevLOVE関西は「事業会社の現場を知ろう~クックビズ編~」です。事業会社の開発現場をテーマにしたお話ですので、興味のある方はぜひお越しください。

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

Facebookページ
Doorkeeper
Twitterアカウント

コツ

最初に行う3つのプラクティスと継続していくコツ

このエントリは?

このエントリは達人出版会から出版された電子書籍【開発現場に伝えたい10のこと】で私が書いた内容を許可を得て転記したものです。

2014/01/14(火)にはDevLOVE関西で書き手が集まる【「開発現場に伝えたい10のこと」それぞれの後日談】を行います。
よろしければご参加ください。

では少し長いですが、お付き合いください。

最初に行う3つのプラクティスと継続していくコツの目次

前半はチームビルディングにフォーカスを当てて、私がチームに参加した際にまず最初に行うことが多い3つのプラクティスについて書きます。後半はそれらのプラクティスを導入し、継続していく時に気をつけている点を書きます。

前半:私がチームに参加したら最初に行う3つのこと

  1. 朝会
  2. ふりかえり
  3. タスクボード

後半:変化を起こそうとした時の心構え的なこと

  1. 「やり始める」のは簡単
  2. 「やり続ける」ことの難しさ
  3. 「効果を出しながらやり続ける」には……

最後に

前半:私がチームに参加したら最初に行う3つのこと

私が新しく開発チームに入った際に最初に何をするか?と聞かれるとまずは、次の3つです。それは”朝会”、”ふりかえり”、”タスクボード”です。

いずれもチームの状況を「見える化」して透明化をします。こうすることで、チームが自分達で工夫して少しずつでもレベルアップしていく状態になることが目的の1つです。もちろんレベルアップすることでユーザー、顧客へ届けるモノ、価値を期待以上にします。

透明化が十分でないチームでは、「誰がどのタスクを持っていますか?」という小さな話から、「今回のリリースの日はいつですか?」という大きめの話のいずれでも「知らない」とか、全然違う答えをそれぞれ持ってしまいます。しかも答えが違うことを分からないまま進んでいることもあります。これではチームがうまく回りませんし、レベルアップして良い成果を出すことは難しくなります。

一方、”朝会”、”ふりかえり”、”タスクボード”がチームに馴染んでいれば、”ふりかえり”で、「これまでと比較して何がうまくできなかったのか?」「これまでより何がうまくいったのか?」を検査することができます。検査によって様々な情報を得ることで、どう適応すれば良いか分かり、アクションをしやすくなります。そして、そのアクションは”タスクボード”や”朝会”によって「見える化」されていきます。

以降はこの3つのプラクティスについて詳しく書いていきます。

朝会

参考:プロジェクトファシリテーション 実践編 朝会ガイド(リンク先はPDF)

“ちょうかい”ではなく“あさかい”と読み、アジャイルな開発手法では、デイリー・スクラムやスタンドアップ・ミーティングと呼ばれることもあります。

特徴として以下が挙げられます。

1:朝行う
2:15分以内
3:チーム全員が参加し、発言する
4:昨日やったことの確認、今日やること、困っていることを簡潔に話す(長くなりそうなら別途設ける)
5:立ったまま行う

目的の1つは、メンバーが「お互い何をやったか?やっているか?困っていることはないか?」を共有し、必要であればチームが何らかのアクションを取る状態になることです。それを毎日同じ時間に同じやり方で行うことで、チームに一定のリズムを刻むことも大事なことです。詳しいやり方は上記の参考文献に掲載されています。

以下は、私が見かけたアンチパターンと私なりの解決方法です。

1:長時間ダラダラする

Scrumではデイリースタンドアップとして「15分」と定められています。それ以外のプロセスでも「短く」というのは共通しています。長くなると集中力が途切れ、しんどくなります。それぞれの状況を短い時間の中で把握できないということ自体が課題でもあります。

また、個別の課題にこだわりすぎて時間が長くなるパターンもあります。このような場合、朝会の進行役が「その話は後で個別にやりましょうか?誰と誰とができますか?」と提案するとうまく収まることが多いです。

2:誰も聞いていない

メンバーが話している時、他の人(ひどい時にはリーダーさえも)が誰も「我関せず……」という感じで聞いていないことがあります。関心事が「自分のタスク」に向かっていて、「チームとしてこのプロジェクトをどうするか?」ということに向かっていないのが原因の1つです。

このような場合、ペアでタスクに取り組むことで、お互いの状況を把握し、チームを意識しやすくします。またインセプションデッキを使って、「プロジェクトの目標を明確にし、チームとして成功させる」大事さを伝えたりします。

時には、メンバーがリーダーに向かって「のみ」話して「報告」になっていることもあります。朝会はリーダーとメンバー間のみの進捗確認や詰問の場ではありません。これが悪い方向に進んでいくとリーダーは「指示」を出し、メンバーは「指示待ち」の姿勢になってしまいます。さらには報告しているメンバー以外は他人に感心を持たなくなり、チームでなくなっていきます。

3.:見えるものがない

それぞれのタスクの量や状況が見える化されていない中での朝会もありました。WBSがファイルサーバーの奥底に眠ったままだったり、リーダーしかメンテしないとこのようなことが発生しやすくなります。まずはその日と前日の分だけでも、見える化するところから始めます。

あるチームでは、タスクボードではなくRedmineを使っていたので、スプリントでやるチケットの一覧を印刷して貼り出し、それを見ながら朝会をしていました。余談ですが、このチームが成熟してスピードが上がっていく中で、Redmineにアクセスして、チケットを操作することがボトルネックになったこともあり、最後にはRedmineを使わなくなり、タスクボードのみ使うようになっていきました。

また別のチームでは、大きいモニタの前に集まって、Redmineのチケット一覧を表示しながら朝会をやっていました。この方法は効率は良いのですが、朝会までに最新情報に更新しておく文化がないと、朝会でRedmineの操作役が他のメンバーのタスクまでいじることになり、自分のタスクを自分でマネージメントする(自分でいじる)感覚が薄くなってしまいます。

これらのアンチパターンに陥らないように、また、良い朝会をするために私が工夫してきたことです。

1:観察する

(リーダーやスクラムマスターは)できるだけ口を挟まずに場の雰囲気やメンバーそれぞれの話し方や表情などを観察します。そうすると徐々に「AさんとBさんは息があってそうだな」、「気にかかっていることがあるのかな?」とか「体調が悪そうだな?」ということが分かることもあります。

「昨日やったこと」を意識して聞いてみるのも時々行います。もし昨日やったことが当初の予定と大きく違っていることばかりであれば、(割り込みタスクが多いなどの)何か問題を抱えているかもしれません。

2:質問の形を工夫する

「課長」や「プロジェクトリーダー」のような肩書きは、その人の発言が命令になり「自分達で考える」ことを阻害してしまう場合もあります。

よく言われていることですが「You(あなた)」でなく「(止まっている)このタスクを片付けるのに、私達がやれそうなことはあるかな?」のように「We(私達)」を使った形で話すようにすると「(話している本人も含めた)チーム全員で考える」意識を持ち続けやすくなります。

3:その場で貼る

「貼っていないですがXというタスクをします。付箋は後で貼っておきます」という話が出たら、その場でさっと書いて貼るようにします。「後でする」というのは忘れてしまいがちですし、目に見えないタスクが多くなってくるとチームの透明性を徐々に奪っていきます。そのために朝会で使うタスクボードには付箋紙とペンを用意しておくとさっと書けるのでオススメです。

ふりかえり

参考:プロジェクトファシリテーション 実践編 ふりかえりガイド – オブジェクト倶楽部(リンク先はPDF)

次にふりかえりです。特徴は以下のようなものです。

1:チーム全体が、行動可能な改善策を探し、試す勇気を得ること
2:チーム全体が、これまでの行動を思い返し、新たな気づきを得ること
3:チーム全体が、やってみてうまくいった行動を、チームに定着させること
4:チーム全体が、メンバーの多様性を受け入れ、信頼関係を築くこと

ふりかえりでは「KPT」(Keep/Problem/Try:けぷと)というフレームワークを多く使うので、主にその「KPT」のことを書きます。ふりかえりの目的は、「自分達がうまくできていること、もっとうまくできそうなことはないか?」を共有して、さらに「もっとうまくできるために何をすれば良いのか?」というアクションを共有することがその1つです。

以下はそんなふりかえりでの経験談です。

1:KeepはGoodなことから導き出してみる

慣れていないとなかなかKeepが出てこなかったりします。その場合、些細なことでも良いので「良かったこと(Good)」という観点で出してもらうようにします。その良かったことを起点にして「なぜGoodと感じたのか?」→「これからもGoodと感じることができるにはどうすれば良いだろうか?」→「それはKeep(継続できる習慣)だろうか?」という流れで出てくることもあります。

なぜそのKeepが出てきたのか分からないと、偶発的なものになってしまい次に活かせないこともあります。その場合、「それは続けることができそうか?チームの習慣になりそうか?」と話し合います。

2:Problemは「それで何が困ったのか?」を意識する

「○○ができなかった」というProblemがあった時に、「それでチームは何が困ったんだろう?」と話し合うことがあります。

できなかったことは事象ですが、それで何が困ったか?を共有していないと、それに対する効果的なアクションであるTryを出せないこともあります。話し合った結果、その○○ができなかったことではチームの誰も困っておらず、○○という行為自体が不要なことであることが分かるかもしれません。

3:Tryは「それでPはなくなるか?」を意識する

1度に全てのProblemに対処するのが難しい場合もあります。その場合、ドットシールなどで投票して、どのProblemに対処していくかを決めた上で、Tryを出していきます。

一通りTryが出た後に「これらのTryができれば、次回のふりかえりではこのProblemはなくなっているだろうか?」と話し合うことがあります。その答えがNoなら、まだ何かTryが足りないかもしれませんし、もしかしたらProblemの深掘りが足りないのかもしれません。

4:観察する

何度かふりかえりをやっていると、Aさんはテストに関するKPTが良く出るなどのように誰がどの領域に強い関心事を持っているか?など色々なことが分かってきます。意外と自身では何に強い関心事を持っているかハッキリ分かっていないことがあるので、それを認識することでチームのレベルアップに繋がることもあります。

これまでのKPTを写真に残しておき、定期的に時系列に見て、KPTの割合、それぞれの内容などを話し合うこともあります。その時に過去のTryが次のKeep、Problemのどこに行っているのかトレースしてみるのが良いです。

またタイムラインという表現方法を使って、この半年や1年などでチームやプロジェクトにどのようなイベントがあったか?またどんな感情の変化があったか?などをプロットして、そこからチームの変化や成長を実感するということもします。

タスクボード

最後はタスクボードです。
参考:川口 恭伸(@kawaguti)さんの「Kanban and Scrum

タスクボードの目的の1つは自分達がどのようなことをするのか、そして今それがどのような状態なのか?を分かるようにすることです。これには、見える化、透明性の維持、周囲へのコミットメントなどが関係しています。また付箋紙などを動かしていくので、Doneに溜まった付箋による達成感、開発のリズムというようなものを感じることもできます。

私はまずはシンプルにTodo、Doing、Doneの3レーンからスタートします。

Todoのレーンでは「Doneの定義」や「Readyであるか?(タスクを着手できるか?)」などをチームと一緒に話し合ったりします。このようなポイントを見逃してタスクをやり始めると、手戻りが発生し、貴重なリソースをムダに使ってしまいます。

DoingのレーンではWIP(work-in-progress=作業途中)の数に気をつけます。これを意識しないとすぐにマルチタスクの状態になってしまいます。マルチタスクはタスクのスイッチングコストが多くなって効率が悪くなります。これもリソースのムダになってしまいます。私はWIPは多くても3までとしていて、チームができたてだったり、メンバーのタスクマネジメントの経験が浅い場合は、1にすることもあります。

開発プロジェクト以外にも、保守プロジェクトや問合せなどがタスクとして存在しているチームの場合、このWIPの制限によって「どういう優先順を付けると顧客やチームにとって良いのか?」と真剣に考えることになります。このことで自分達の生産量が向上したり、周囲との仕事の受け渡しや頼み方などにも改善が見られることもあります。

Doneのレーンでは、Doneに付箋を移動する時に「Doneの定義」に注意します。タスクを開始するとDoneの定義が修正することも時々あります。それが共有されていないといざDoneになった時に、その際に「あれ?そうだったの?」というすれ違いが発覚し、リソースをムダに使ってしまいます。

アンチパターンとしては、タスクボードの更新が全然されないことがあります。これは、タスクボードがチームから物理的に遠かったり、普段見えていなかったりすると発生します。

また、更新がされない状態はタスクの粒度が大きすぎる時にも発生します。最初はタスクの粒度が大き過ぎ、進捗が分かりづらいという状況になります。しばらくすると(チームが工夫することによって)タスクの粒度が細かくなっていきます。すると今度は細かすぎたりして、タスクを書き出す手間がメリットを上回ってしまう感覚を持ちます。その結果として「チームにとってちょうど良い感じ」のタスクの粒度が共通認識として出来上がる……というパターンとして経験したことがあります。

タスクの粒度は、チームの成熟度などのコンテキスト次第ですが、私の感覚では見積もりの最大時間が4時間程度を1枚の付箋紙(タスク)とするのが良いと思います。だいたい1日で1枚はDoneに持っていける粒度でもあり、精神的にもリズム的にも良い状態だと考えています。

タスクボードは時間が進んでいけば、そのチーム独自のタスクボードになっていくことが多いです。Readyレーンを用意してそのタスクをTodoレーンに移動できるか検討したり、Doing以外にWillDo(やる予定)レーンを作ったりしたこともあります。またタスクの付箋紙自体も追加されたことを分かるよう印をしたり、バグを付箋の色で一目で分かるようにしたり、Small/Medium/Largeの見積もりを色で分けるようにしたこともあります。

後半:変化を起こそうとした時の心構え的なこと

後半は、前半で書いたプラクティスなど新しいこと、ちょっとした変化を持ち込もうとする際に私が心がけていることなどを書いていきます。

「やり始める」のは簡単

「最初の一歩が難しいんだよ」という声もありますが、今回前半に書いたことは、いずれも1人でもできることであり、その効果を周囲に伝えることもしやすく、比較的始めやすいことです。

タスクボードは「Myタスクボード」を作り、自分のタスクをそこでマネジメントしていくようにします。

リーダーや同僚などに「今の進捗はどんな感じ?」や「後はどんなタスクが残っているの?」などと聞かれた時に、そのMyタスクボードを見ながら、サクサクと答えていくと興味を持ってもらえることもあります。このようなことが何度かあると「チームでタスクボードをやってみよう」という流れも起きやすくなります。私もMyタスクボードを出発点として、最終的にはチーム全員のタスクボードまで成長していったこともあります。

ふりかえりも1人で始めることができます。

私は(チームのふりかえりとは別に)、自身のふりかえりとして週単位で行っています。1人だと、Tryなどに対するモチベーションを保つのが(チームでやるのに比べると)一工夫必要だったりします。私は、リーダーや同僚との雑談で「こういうことを今週は自分なりにTryしてみようと思う」と宣言したりして、アクションをするようにしています。

「やり続ける」ことの難しさ

ダイエットでも経験がある方もいるでしょうが、やり始めてすぐに効果が出るわけではない……と、頭では分かっていても、数日して何も変わらないと「これでは効果が出ないのかな?」「前の方が良いのではないか?」というような考えがムクムクと頭をもたげてきて、「続ける」モチベーションが弱くなってしまうことがあります。

それまでのやり方とあまりに違うような方法をとっている場合、「前の方が(慣れていたし)良かったんじゃないか?」という声も聞こえてくることもあります。忙しくなってくると優先順位を落としたくなるのも分かります。が、このようなプラクティスは即効性のあるものではなく、じわじわ効いてきて、気がつくとチームに変化が起きていた……ということも多くあります。

一方で、それなりに続けていると今度は「マンネリ化」という課題が出てくることもあります。「なぜそれをしているのか?」という理由が消えてしまい惰性になり、「もっとうまくやる方法があるのでは?」という考えやアクションへの意識が弱くなり、すでに実状と合わなくなっているにも関わらず、「前からやっているから」という理由だけで続けてしまっている……という状態です。

このように「効果を出しながら、やり続けていく」ことは、言い訳の天才でもある人間にとってなかなか難しいことです。

「効果を出しながらやり続ける」には……

自分達はもっとうまくできるようになるという「信念」(のようなもの)、「交渉力」そして「ちょっとした幸運」が必要だと感じています。

1:「信念」

「自分達はもっと成長していき、うまくでき、それで良い結果を出すことができる」という「信念」が必要です。

すぐに効果が出なかったり、社外の成功事例が耳に入ったりすると「やり方が間違っているのか?」と思ったりすることもあります。しかし成功事例はあくまでそのコンテキストでの話に過ぎませんし、自分達が同じ状況、同じ能力を持っていない限り同じ結果にはなりません(おそらく持っていても同じ結果にはならないでしょうが……)。

すぐに成功事例に飛びついたりせず、自分達にあったやり方、エッセンスを抽出して、また「どこがうまく行っていないのか?」を冷静に客観視していく必要があります。

自分達のコンテキストは自分達が一番分かっているはずですので、ある程度は「信じる」気持ちが必要になります。もちろん自分達のやり方に(無条件に)固執することは成長を阻害する大きな要因ですので、バランス感覚も必要です。

2:「交渉力」

従来の管理手法との違いや(形骸化した)社内ルールとの衝突など外圧が発生することもあります。その外圧に負けてしまうと、新しい取り組みが定着し、効果が出るまで続けることができなくなるかもしれません。また鶏(=チーム外)の大きな声などによって自分達のやり方が脅かされることもあります。

そのような戦いに負けないように、そもそもそういう戦いをしないで済むように”根回し”などと言われる交渉力も少しは必要になってきます。

様々なタイプの上司や組織風土があります。「やり方は問わないので、とにかく結果が出れば良い」から「やり方は問わないがプロセスも報告し、もちろん結果も」というタイプ、そして「やり方もプロセスも詳細な報告を……」という感じです。

マイクロ・マネジメントが良い結果を生むことが少ないことは知られていますが、「何か得体の知れないこと」をされるのは気持ち悪い、そして自分の管理責任を問われると感じる上司や組織風土もまだまだあります。それぞれのタイプごとの関心事などを考え、うまく伝えるたり、見せることで味方にする……少なくとも敵にならないことが大事です。

多くの場合、これら「確実な成果は約束できないけれど、今より少しうまくできるようになる可能性がある」アクションに対しNo!と頭から否定されるフィードバックはあまり返ってこないと思います。もしあるとすれば、うまく「なぜするのか?」という理由や「どこを目指そうとしているのか?」などのゴールが説明できていなかったりするかもしれません。このように話を聞く側の心理的不安を取り除くようなアクションをすることも必要かもしれません。

3:「ちょっとした幸運」

本当に入ったプロジェクトがデスマーチの場合、なかなかこれらをやり始めることすらできないかもしれません。しかし、本当のデスマーチになる前であれば、少なくともこれらをやり始めることはできます。

また(数少ない話だとは思いますが)このようなアクションを一切認めない上司や組織風土も存在するかもしれません。そういう本当に「ひどい状況」に当たらないというのも、これら続けていくために必要な「ちょっとした幸運」です。

最後に

3つのやること、そしてそれらを続けることの私なりの方法を書いてみました。もちろん3つのことは他にもあるでしょうし、続けるコツも他にもあるでしょう。ぜひ皆さんのそういうコツなどを教えて欲しいですし、話し合ってみたいです。

これらをやり始めて、続けていったとしても、世界を、組織を変えることはできないかもしれません。しかし、チームは、自分は確実に変わっていくことができます。

DevLOVE関西のような多くのコミュニティでは、このような課題をテーマとして扱うこともあります。実際にアクションして解決するのはそれぞれの現場でのことかもしれませんが、ぜひコミュニティと現場を循環していくことで、自分の課題が解決し、その解決したことが、別の現場で困っている別の誰かの課題へのヒントになるサイクルが回るようになることを願っています。

※アイキャッチ画像:http://www.flickr.com/photos/stevendepolo/3605321899/in/photostream/

「開発現場に伝えたい10のこと」を出版しました

2013年の出来事の1つとしてDevLOVE関西【開発現場に伝えたい10のこと】という電子書籍を出版し、私もその1章を書かせてもらいました。

どんな内容?

所属する組織や立場が異なる10人それぞれの経験を書き記した10本の話が詰まった内容になっています。

目次はこんな感じです(サイトより抜粋)。

出撃の前に
第1章 チームをビルドする (栗栖 義臣(id:chris4403))
第2章 アジャイルな乙女ゲーム開発のおはなし (粕谷 大輔(@daiksy))
第3章 道具に関するよしなしごと (いろふ(@irof))
第4章 大きな会社の小さなマネジメント (川畑 雄補(@ku_suke))
第5章 インセプションデッキによる期待マネジメント (市谷 聡啓(@papanda))
第6章 「どうすれば価値を生み出すか」を知るためにヌーラボで行っていること (染田 貴志(@tksmd))
第7章 ゲーム業界と私 (田口 昌宏(@masahirotaguchi))
第8章 最初に行う3つのプラクティスと継続していくコツ (中村 洋(@yohhatu))
第9章 エクストリーム開発者満足&エクストリーム顧客満足のアジャイル開発~アジャイル開発から考える、究極の「生産力」~ (株式会社アジャイルウェア 代表取締役CEO 川端光義 (@agilekawabata))
第10章 ふつうの受託開発 (川島 義隆)

「DevLOVE関西~Decision~」でもお話してくれた染田(@tksmd)さん、川畑(@ku_suke)さん、他にもirofさんなどDevLOVE関西にゆかりのある10人の皆さんです。

達人出版会さんから1コインでお買い求めできますので、お年玉の使い道にしてもらえれば幸いです。

2014年最初のDevLOVE関西

そして2014年最初のDevLOVE関西では、これをテーマにした【「開発現場に伝えたい10のこと」それぞれの後日談】を行います。
書き手の皆さんがあの話の後日談や書ききれなかった裏話など少しずつですが話す予定です。
#場所の関係もあり全員集まるというわけでには行きませんでしたが。

以下にこの本にある「はじめに」を抜粋しておきますので、よろしければお越しください。

人ひとりが経験できることには限界があります。かつてのパイロットたちも、自分ひとりでは不足してしまう経験をハンガーフライトで補ったはずです。他のパイロットの語りを聴くことで、自分の経験を拡張したわけです。

これは、私たちの生業であるソフトウェア開発でもあてはめることができるのではないでしょうか。デベロッパーひとりが経験できる開発には限界があります。現場第一線での開発を仮に30年近く続けたとしても、ひとりが投入できる時間はせいぜい300ヶ月です。人月でいえば、300人月のプロジェクトです。これは、規模としてはかなりのサイズですね。

しかし、300人月のプロジェクト1つだけを仕上げて、自身のデベロッパー人生を終えている場合ではないのです。実際には、来月から50人月、100人月程度のプロジェクトに挑む方もいらっしゃるでしょう。そう、私たちの開発現場は、それまで自分が経験したこともないような規模や知識領域、技術に挑まなければならない状況を迎えているのです。空とビットで世界は違えど、先人のパイロットたちの知恵を借りない手はありません。私たちも、現場や職場、コミュニティでハンガーフライトしましょう。

いま、皆さんの目の前にあるものは、文字になったハンガーフライトです。ここには、10人のデベロッパーたちの、さまざまな経験が詰まっています。それぞれの語り口調で、経験したことを語ってくれます。

さあ、現場に行く前に、彼らの語りに耳を傾けてみてください。あなたが、あすの現場で飛び回るためのヒントがここに、きっとあります。

(「はじめに」より)

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アカウント