勉強会

1つのプロダクトには様々な立場があるんだな@DevLove関西 20170701感想

2017-07-02 勉強会

ビジネスマンを「めんどくさい」から解放する【RODEM】の開発の現場 に参加してきた。
特定のサービスが企画からリリース、そして現在までの2年間のLean開発の実践譚をデザイナ・PO・開発・PdMなどの各立場で一気に聞くことができて、なかなかの神回だったように思う。
なかでも全登壇者が思い出深く話す英断、「アプリつくってたけど、リリースすんのやめた」はまさにMVPの実践として強烈な印象を与えられた。

登壇概要と感想

1−1:はじめてサービスデザインを任されたデザイナーがいかにRODEMの開発についていくようになったか

  • Speaker: 深沢さん @witch_doktor
  • 立場: RODEMのデザイナー
  • 内容: 変化の激しい開発にデザイン側からどうついていったかというお話。深沢さん自身もサービスやアプリのデザイン経験がないなかで、SketchやInvisionを使って、プロトタイピングやデザインガイドを用意して進めていかれた実践話。
  • Slide: まだ公開されてない
  • 感想:
    • 素早い開発についていくために、デザインデータをどうしておくべきか。みたいな感覚はこれまでになかった視点なので非常に参考になった。Webサイトの開発でデザインは最後にエンジニアがデザイン融合するみたいな事がまだまだ多いが、デザイナーがプロトタイプ段階で参加できるという、UIや印象レベルのMVPがすぐに作れてめちゃくちゃいいなと実感させられた。
    • Atomic Designやプロタイプで実装者が比較的安心して仕様に疑念をもたずに進められるのは職種間の変なわだかまりも減らせるのでかなり大きなポイントだと思う。
    • あとヴァル研のお二人やギルドワークスの佐々木さんと、深沢さんが2年近く一緒に仕事していながら実際に会うのが初めてや2回目というのにも衝撃。デザインのような感性や非言語のやり取りが重要そうなものを、実際に会うことなく進めている事。そこにもプロトタイピングツールの力を感じた。
  • 自分のつぶやき


今度、深沢さんに相談にいこうと思うw

1−2:新規サービスの開発中にPOが何かを決断するために必要だったこと

  • Speaker: 伊藤さん(ヴァル研究所)
  • 立場: UXデザイナー/PO
  • 内容:UXデザイナーとPOという立場でプロダクトの企画から現在までどんなインタビューを重ねて判断をしてきたかというお話。
  • Slide:
  • 感想:
    • プロダクトのフェーズごとにUXデザイナーとしてどういう活動をして、POという立場でどう判断したのかというお話
    • Problem/Solution Fitの話で、経費精算の精算時だけでなく、「計画時」「当日」「移動時」「精算時」など一連の流れのなかで課題をみつけそれぞれのソリューションを検討し、それぞれMVPを見つけて検証していたのが分かりやすかった。
    • 移動時や当日の課題を解決しようとしたが、実際にはそれに対するソリューションはハードルが高いしなんなら自社の駅すぱあとと競合してしまうので、作ってきたアプリをリリースしない事を決める。というのは衝撃。
    • 伊藤さんがマーケティング/商品企画のための ユーザーインタビューの教科書の著者の1人ということに気づいてなかった!サインもらえばよかった。

  • 自分のつぶやき


相手からのフィードバックループを早く取り入れていくためにも、小さく作ったものを相手に確認してもらうってことが開発者とユーザーの間で重要だと感じた。

1−3:仮説検証に追随するソフトウェア開発をするために大切なこと

  • Speaker: 佐々木さん(ギルドワークス) @chachaki
  • 立場: 開発リード・開発マネージメント
  • 内容: 作ってきたアプリを捨てるなどの大きな決断に開発側がどうやってついていったのかのお話
  • Slide:
  • 感想:
    • ギルドワークスが単に外注として開発を行うだけでなく仮説検証からユーザーインタビューや事業ロードマップなどビジネス成功のために支援しているのがよくわかった。
    • 最大時、東京・宮城・大阪・愛媛というリモート分散体制のなかですばやい仮説検証と変化に対応できたのは、きちんと考えるべきときに考えて、決めるべき時に決めているから、都度そばでコミュニケーションとらなくてもやっていけたんだろうなという印象をうけた。
    • 佐々木さんとダイアローグで話したなかで、合宿を通じて、アプリをやめると決めた時、合宿に参加していない深沢さんや愛媛の開発チームちどう伝えるかという話題があり、リモート開発もいいけど一周回ってやっぱりFace to Faceの良さはある。という話題もあった。リモートでもやっていけるコミュニケーション力と責任感のあるチームがFace to Faceで仕事するとどうなるのか?ちょっと気になる。
    • あと、佐々木さん前から遠目や資料ではみたことあってもっと強面なイメージだったけど、実際あってみると声や口調がぜんぜんウェットな感じで予想外でした。やっぱり実際会うの大切ですねw
  • 自分のつぶやき:


最近の自分の業務的にもここらへんはすごく共感する部分があったw

1−4:顧客開発モデル2周目の自分が3周目の世界に向かうにあたって

  • Speaekr: 篠原さん
  • 立場: PdM
  • 内容: 事業責任者としてMVPをどう見極めてすすめてきたのかのお話。技術や開発以外の事業開発として参考になる点が多かった
  • Slide: https://www.slideshare.net/noritakashinohara/mvp-77415690
  • 感想:
    • MVPについてのよかある質問やMVPの勘所をわかりやすくまとめてくれた素晴らしい内容でした。フェース毎のMVPの違いなど実践者ならではの事例とポイントが多く、とてもよかったです。
    • やっぱりMVPって正しい物をつくるためであり、余計なものを作りすぎないためのものだよな。と思う。どうしても、人に見せる時につっこまれるのがいやで作りすぎちゃう事があるけど、もともと捨てる前提で価値を検証する最小単位をもっと見つけて集中しなければいけないと思った。
    • MVPで検証し、好感触の尖っている点・魅力的品質ををもっと伸ばしていくこと注力するのが大切と強く感じた。
    • リリースすぐは、契約よりもユーザーフィードバックを得るためにトライアルのほうが重要。トライアルアカウント増やすためにGoogleSuiteとActionScriptで1週間で申し込みフロー改善して前月比10倍になった話は観点も実行内容も共に軽快ですごく良い事例だった。
    • 法務チェック大切。特にUIとかは結構特許認定されやすいので注意。
    • ダイアローグでは、新事業の売上目標話(当然目標はあるが売上よりも重要な手前の指標をちゃんとレポートすることが大切)や、チャネル(代理店や連携先との関係)、プライシング(新規市場と既存市場での違い)の難しさについてもごにょごにょ。自分の仕事にも同じようにやっている点や応用できそうな点も多く、また機会をもうけて意見交換してみたい。
  • 自分のつぶやき:

篠原さんの事業責任者としての姿勢は本当にそのとおりで、覚悟が生み出す力って大切だなと実感。

Regional Scrum Gathering Tokyo 2017 報告会 にいってきた

2017-02-05 はたらきかた, 仕事術, 勉強会

201702_06 Devlove関西&スクラム道関西の合同イベントのRegional Scrum Gathering Tokyo 2017 報告会 にいってきたので、メモや感想をざっくり。

動機

イベント構成

  • 1部 RSGT2017の関西や名古屋の登壇者の再演
  • 2部 ビアバッシュで報告会

再演を聞いたあとに、会場を変えて、ピザとビール片手にビアバッシュな感じで行ってきた人の感想や、報告会の参加者同士で交流を深める2部って感じでした。
これで参加費500円だったのは安すぎるので、お金大丈夫なのかしらという心配をしてしまった。

再演の感想

つらい問題に出会ったら 開原 隆弘さん

こちらの再演。

かってな要約

  • 時間をオーバーするところまできっちり再演するという徹底した再演。
  • テーマ・キワードとしては対話
  • 福原 美砂さんに「自分を立て直す対話」という本を進められ、そこに書いてある智慧の車座を開催通じて得た気づきやポイントの共有
  • 初っ端からスクラムほとんど出てこないw

メモ

  • ロジカルに解決できない問題もある
    • ひとりだとぐるぐると悩みに陥る
  • 自分がとらわれている問題からの対話
    • 人の力を借りて「問題をほぐす」
  • 智慧の車座を開催
    − 一人の相談者、4,5人の賢者
    − 無責任に発言するという掟が難しいが大切

  • 問題をほぐしてテーマを再設定する
    − 例: お客さんにいいようにつかわれていざとなったら裏切られる
    → 信頼できないお客さんに、どう接したらよいか?
  • やってみて
    • 短時間で深い本気はなしになりやすい。
    • 居酒屋だとガス抜きににだけなるのがもうちょいすすむ
    • 相談者が自分自身を改めて知り「賢者」も得るものがおおい
    • フォーマットにそってやってれば簡単にできた
  • やってみて気づいたポイント
    • 同じような役割・立場の人をあつめたほうがいい。
      • 上司部下だといつも通りになってしまうのでファシリ力が求められる。
      • 問題解決ではなく、相談。
    • 仕事上の繋がりが薄い方がいい
    • 計画的に定期的にやる。なんかの場とからめてやったほうがいい

感想

  • ある程度、多様性を埋める人数規模の組織ででないと車座は上手く回しづらいかも。
  • 始めの第1回を始める蹴り出し方がポイントになりそう。
    • マネージャーから始めるかメンバーかはじめてみるかどうやるか気になった
  • とりあえず、本買った。

アジャイルカルチャーが 組織に根付くまでの挑戦 中村 洋さん

こちらの再演
スライドが違いすぎたので本当か?と思いつつ聞いてたら、どうやらスライドはこっちが正解っぽい

かってな要約

  • 中村さんが現場コーチとしてまわってきたなかで感じてきた変化に対する組織の反発とどう向き合っていくかのポイントと実際に活用しているコーチの道具箱の紹介。

メモ

  • 導入への3つの壁
    − 変化することへの壁
    − やりかたの壁
    − 役割の壁

  • 壁を崩すための姿勢

    • 視座をたかくもつ
      − あせればあせるほど自分の視座が下がっていく
    • ありたい姿がないと改善の余地がない
      − ゴールデンサークル:Why → How → What
    • 実験をくりかえす
    • 最近はプロダクトだけでなく、組織も実験を繰り返しやすくなってきてる
  • 道具箱
    組織のコンテキストによって同じ道具でも使いかたをかえている。

  • デリゲーションポーカーで役割と権限の認識をそろえる

    • 権限の7階層:命令する 説得する 相談する 同意する 助言する 尋ねる 委任する
  • 組織の変化 タックマンモデル:新しい人をいれたら安定してた組織も一度混乱期にもどるんだから人足せばいきなり上手くいくものではない。
  • お披露目会:できたものを説明したりフィードバックを得る機会
  • 星取表:今必要なスキルや今後必要なスキルを各自どんな状態かならべてみる。プロダクトで今後必要とされるものを誰ができるのか?などチームの状態を可視化。人事評価に使うと正直に答えなくなるからだめ。
  • メトリクス重要。

感想

  • スクラムやりはじめるのは簡単だが習得は困難
    • スクラムやアジャイルをやり始めることはできるが、当然そんなにすぐにうまくいくわけもない
    • 銀の弾丸的に即効性を求めて、効果が出て定着させる前にアジャイルはうちのチームやプロダクトにはあってないと評価されている現場もありそう・・・
    • そこらへんタックマンモデルを使って上に説明できるとよさそう。
  • とりあえず、紹介された道具から、お披露目会星取表は、近しいものがすでにあるので、取り入れてみたい。
  • デリゲーションポーカーもやってみたいんだけど、そもそもそういう事に対する妙な抵抗を示す人もいるので、タイミングを探ろう

結果的にスクラムになってる!なのがいいと思う! 椎葉光行( @bufferings )さん

こちらの再演

かってな要約

  • 椎葉さんが楽天大阪支社でやってきた経験のお話。
    • スクラムやるよ〜っていうと、スクラムおばけが出てきて上手くいかないんだけど、
    • それより問題解決しようよ〜っていって解決のためにスクラムのメソッドを一部使っていく
    • 結果スクラムになってるくらいがちょうどいい

メモ

  • スクラムを始めない
    • 先に問題を解決しよう
    • KPTのProblemがおもすぎるので、Good & Moyyatoの問題からその問題を解決するためのものにスクラムの道具を適用していった
    • スクラムをしようから始めるとスクラムお化けがでてくる
    • 正しいスクラムにとらわれてしまう
    • やってるだけで安心しちゃう
  • スクラムうまくいってないところでも結局は問題から解決をの形へ
    • 例)差し込みが多いとスクラムが上手くいかない、リリースが遅れる
    • ループする問題はどこかを解決すればループがとまる
  • 組織として価値を生み出す流れを意識
    • 開発はスクラムでもビジネス側がちがう・・・とか言ってたら上手くいくわけない
    • 全体最適で問題解決から始める、結果として組織の形にあったスクラムへ

感想

  • 問題解決から始めるアプローチは、報告会の中で、一番どこの現場でも適用できそうな内容だなぁと感じた。
  • 開発だけでなく、組織として価値を生み出す流れの中の問題を解決していく。というのは、僕も意識してるところなのでぐっときた。
  • 2部のテーブルで椎葉さんがファシリっぽく話す場面がありテーブルの全員にしっかり話ふっていたりとか質問の投げ方とか、声のトーンとか、椎葉さんの姿勢に学びを貰った。
    • もうちょい椎葉さんと話てみたかったけど、いまいち上手く話しかけれなかったのは反省。
    • 椎葉さんが登壇する理由は、「自分から話かけるのが苦手だけど、登壇してたら、懇親会で話かけてもらいやすいから」。共感。

Scrumありがとう、そしてさようなら-Scrum 破- kyon_mm

こちらの再演

かってな要約

  • 守破離の
  • 守のスクラムなんて20年たってる枯れた手法。だれでも上手くいける。
  • いい加減スクラムを超えていいんじゃね?だって、20年前の言語で開発するとかだれもしたくないでしょ?
    • kyon_mmのチームは、破。そして世界最高のチーム、1スプリント1日。6分単位でのみつもり。さらには秒単位で見積もってソフトウェア開発から生産を目指すんだ。って話。

メモ

  • スクラム自体がうまくいってるかどうかもメトリクスとらないと、スクラムしてるんなんて言えないよね
  • プロダクトを最高にする以上にチームを最高にする必要がある
    • チームとしてのビジョン:
      • kyon_mmの例)世界最高のソフトウェア開発チーム、スクラムを超える、ソフトウェア工学に新たなページを作る
    • チームビジョンのマイルストーンを作る
  • スクラムは20年たってるからもう超えていいだろう
  • スキルマップ
    • できるかどうかじゃなくやったかどうかで星取表
    • 例)基本知識を活用して仕事をしたかどうか
  • レビューのメトリクスを常にとっておく
    • レビュー時間 x 何の品質にかかわるものか
    • 狩野モデル https://sites.google.com/site/techdmba/kanomodel
    • レビュー時間ながいけど指摘が無関心品質ばかりの人が出てきたりする
  • ソフトウェア生産へ
    − 徹底的に無駄を省く。できない人の無駄ではなくできる人の無駄を省く。もはや20%ルールどころか50%ルールで、仕事の半分は学習・研究に時間をさけるようになっている

    • 同じものを3,4回作る。最終的には1回目の4分の1くらいの時間で作れるようにする。この再現性があがれば生産にもっていけるのではないか。

感想

  • 発表の怒涛の勢いにかなり飲み込まれていく感じの発表
  • 6分単位での見積もり、1スプリント1日など、なかなかすぐには真似できそうにないので、未来とか、タイムトラベラーみたいなワードが飛んでた
  • 話を聞いていて、ぶっ飛んでいるようで理にかなっているし、日々改善していくというだけなので、実は当たり前のことかも。
    • 星取表を「できる」ではなく「やった」という事でマップするのもシンプルで運用しやすそうだし、発表のコアはとてもシンプルで案外他でも再現できるかも
  • 会社やプロダクトとしてのビジョンだけでなく、チームとしてのビジョンをシンプル持っているのも大切だよなぁ〜と共感。

  • 50%は新しいことに時間が使えるようになったというのがすごい
    • 開発の創造性・クリエイティビティ、ムダも必要みたいな話はあるが、徹底的に無駄をなくし生産を目指すアプローチで、結果として50%で仕事が終わる。
    • 単純に考えると、空いた50%に仕事を詰め込むこともおきそうだが、なぜなってないんだろう?というのを聞きそびれた。

2部のビアバッシュの感想

  • ビルの10階にカフェ的なスペースがあってそちらに移動。会場だったMOTEXの本社のファシリティーに感動w

  • トークセッション

    • 2部始まってすぐ、トークセッションとなり、実際に参加された方が会場やセッションの雰囲気を共有。
    • 雰囲気を聞いておくと初めて行くとしてもあまり身構えずにいけるので、そういう共有もあるのはいいですね。
  • テーブルトーク
    • トークセッション後にテーブル毎に登壇者をかこんで話ができた
    • 参加者の意識高いなぁ感もうける
    • 2部全体で1時間しかなかったので、15分くらいしか話はできず。すこし残念。

全体通して感想

仕事で多少はスクラムっぽいことも取り入れているけど、やっぱりやってる人たちの事例をどんどんInputしていきたいなとおもっていたので、大阪でRSGT2017の再演が聞けて、交流もできるイベントはまさにラッキーでした。
いつもなら二次会にいくのですが、予定いれてしまってたのが失敗。あと30分2部の時間が欲しかった・・・

しかし、ひさしぶりに自分の感想まとめてみようという動機にもなったステキな時間でした。運営の皆さんありがとうございました。

いくつか自分の現場で試してみたいネタも拾えたので月曜日からがんばります! Monday!

DevLove関西のWebデザイン勉強会 W2P3#2にいってきた

2013-07-30 勉強会

W2P3#2 WebDesign workshop of the programmer, by the programmer, for the programmer #2 にいってきた。

今回はペーパープロトタイピング。紙で実際の画面設計をやってしまおうという話。

ペーパープロトタイピング 最適なユーザインタフェースを効率よくデザインするって本に詳しくのっているらしい

ちょっと途中からの参加になったので、そもそものところはよくわかってないかもしれないが

実際に与えられたお題(案件)で画面を一つ即興で作ってみた感じでいうと、

紙なので切ったり貼ったり、動かしたりできるので、早く、体感的に画面設計ができるな。

という印象でした。

実際やるには、相当な時間がかかるらしくかかった時間以上の成果を出すという覚悟と、途中で折れない心が必要らしいw

しかしメリットとして

関係者全員でやる事の認識合わせの効率化
実際に画面を作って問題に気づける
わいわいしながらやるのでモチベーションがあがる

というのは、面白い。

更にやりながら、写真をとってワイヤにしたり、動画をとって議事録や経験の思い出しに使うとよいそう。

逆に、やってはいけないことしては、
綺麗につくりすぎると、みための議論になりがち
大人数でやると収集がつかないので、コアなメンバー(各部署、クライアント)だけで。
実物大でやらないと、具体的な感覚がボケる。スマフォとかでかい紙で作りすぎるとぜんぜん実物はイメージが違う

やるためには、 時間をかける必要がある(5人で18時間とかw)し、
その場にいないと無理なので、はやりのSkypeMTGは通用しないし、
なにより、 ゴミがいっぱいでるので地球に厳しい(笑)

しかし、実際にやってみて

ペルソナつくてユーザシナリオを考えてまでは、他でもできるが

画面遷移や画面の動きをああでもないこうでもないといいながら、チームで話をするのは面白いし、イメージがどんどん膨らんでいくので面白かった。
今回はタブレットアプリっていうお題でやったが、充分にWEBサイトでも適用できるだろうし、今後新しいものを考えるときはいいね!

モックアップ的なパーツを色々とあつめて、付箋やはさみ、テープを集めて実際に一つアプリをつくって、開発までやってみたい欲求が激高まり中。

実際につくったペーパープロトタイプ。Facebookアプリ的にサイドのメニューが出たり入ったりするという動きまで作れた!

お題でつくったフットサル大会アプリのHOME画面 996546_539023599479999_929896054_n

DevLOVE関西「セルフ・タスクマネジメント」にいってきた

2013-06-27 勉強会

週末にDevLOVE関西の「セルフ・タスクマネジメント」にいってきた。

http://devlove-kansai.doorkeeper.jp/events/2882

今回はセルフ・タスクマネジメントに関するワークショップということで、最近自分のタスク管理が上手くいてないなぁという感じがひどかったので、いっちょいってきました。

まずは、始めは簡単に説明があって、吉池さんによるワークショップ タスクマネジメントやってみよう!グループ分け 違う視点のおおいほうがいいでしょうということで、普段マネージメントしているかorされる側、かんばん経験ありorなしなどでわけて、視点の違うメンバーでチームをつくりました。

タスクマネジメントを体験してみようというワークショップなので、今回は以下のようなお題をもらって、チームでどんなタスクがあるかを、検討し、実際にタスク管理をしながら進めていく作業をしました。

お題; 海外に転勤する先輩二人に思い出に残るBBQを開催しよう

ーどんなバーベキューにするか

ーどういう風にすすめるか

ー何を大切にするか

はじめにどんなバーベキューにするかを決めて、各自付箋でタスク出しをし、後で他のチームのものも見ながら振り返りました。
ひと通りやってみて、僕らのチームは以下のような課題を感じました。

・終了条件が不明確だった

・曖昧なものを具体かすることを考えるタスクが必要

・粒度が大きすぎた

1度タスクを出しきった後で、以下のような事を意識して見直す必要がありましたね。

・タスクの粒度はどうか

・タスクの過不足はあるか

・終了条件は明確か?

・お題の達成いはできるのか

普段から、タスクの粒度や前後関係を仕事の場でしっかりと話ができているかを改めて感じさせられました。

 

その後は、中村さんと前川さんによるセッション

中村 洋さん ; 自分が思うセルフタスクマネージメントのこつ(みたいなの)

自分としては、良いタスクの条件についての話がよかった。

良いタスクとは、Goalが明確であること Doneの定義(Defiition Done)

すくらむでいうINVEST は、良い要求定義、良いタスクにも通じるようです。

Independent ー>独立したタスクであること

Negotiable ー> 交渉しやすいこと、対話をひきだす。交渉の余地のあるもの

Valuable ー> ユーザー価値を提供する 何のためかが明確

Estimableー> 見積もれること

Smallー>ちいさい 把握可能な範囲

Testableー>テスト可能であること Doneの定義を確認することができること

 

良いタスクにするポイント

ー>タスクを分割し、見えやすくする

ー>大きいと不安で進捗がわかりづらくなる

中村さんは、 2時間から4時間くらいの粒度にしているそう。

注意点として、1点見積りをしないー>A機能で2日とかせず、BestとWorstの幅も意識。

予実の原因把握もすることで、見積もりの調整が可能になる。

タスクをTODO,Doing,Doneとしてカンバン管理するにしても、

・ToDoにもっていける状態なのかどうかを確認する

・わかった気になってToDoにしない →厳しく質問をしてしっかりと確認する。→タフクエスチョン

なぜするのか、どうやってするのかを理解しなければいけない。

わからないことがあると、見積もりの幅は広く、荒くなる。

不確実性のコーンの右側へいけるように、質問をくりかえして、見積もりの精度をあげていくタフクエスチョンが大事ですね。

他にも、タスクをこなすTipsとして、

・タイムボックスを意識→何時間も集中できない。これまでできていないものが急にできるようにはならない。ペースを掴み見通しをたてる。

・マルチタスクのワナ→仕掛りを増やさない。多くても二つ。おねがいしてタスクの線をn本にする→人にお願いできるものを先にする

注意)ほわっとした投げ方をすると、問い合わせや手戻りでリソースがかかる→タスクの実行に必要な情報をまとめているとよい

・タスクのグルーピング→家でしかできないもの、会社でしかできないものわけて、今できるものをしっかりと行う

・優先順位付け→緊急と重要の2軸でわけておくのは基本だが、その中でも、優先度ではなく、優先「順」必ず番号を!

・IceboxとTodo ToDoの数は減らすー>ある期間のあいだで把握できるはんい

Iceboxー>ある期間以降に見直してToDo化を検討できるもの

最後は、タスクをこなす心がけ

できなくてもOK →ToDoにしてて終わらなくてもOK、自分を追い込まない

書き出しておく→安心感 頭をからっぽにする タスクの並び替えが可能に

自分の調子と相談→無理な時にはすっぱり諦める。日によってパフォーマンスが違うのは当然
でも、良いプレーヤーは不調な時期が短い。調子をあげるスイッチをもとう。

 

つづいて、前川さん@Posaune

僕の屍をこえていけ 失敗だらけのタスク管理戦記

こちらは、どうやったらうまくいくじゃなくて、いろんな方法があるよの話でした。

前川さんが紹介していた方法

Excelでwbsっぽいものを作成

パーソナルタスクカンバン

GTD(+R)

ポモドーロ

看板+ポモドーロ   タスクはかんばん。みつもりはカンバンで、時間単位をポモドーロ

等など、それぞれのツールの事を紹介してくれました。

どのツールにも良い点、悪い点があり、教科書通りの使い方には限界があって自分なりにためして、変えていくことがいいと言われてました。

前川さんは現在、看板2枚で、

・TODO、Should、Feature の1枚と

・WeeklyのASAP、Today、Inbox(どうするかまよってるのの置き場)

で運用されているそう。

物理的に各領域における量を制限するとかは一つのTipsでしたね。

ASAPまではざっくりでも、Todayにはいったら分けるってありですね。

かんばんでの見える化、gtdの優先度、タスクを作業直前でバラす手軽さはいいな。

そして、日々の振り返りは重要。しっかりと振り返って、自分の肌に合う手法を見つけてもらえればOK

 

チームでの振り返り

ワークやっての気づきから、明日からのタスクマネージメントをよりよくする3つのキーワードを決めるということで

ー 完了条件をしっかり定義する

ー タスクごとに優先順位と前後関係を決める

ー TODO、Doingに入れる時、タスクの粒度を見直す

をチームでキーワードとしました。

感想

よくわからない仕事をうけて、粒度整理できてないことが最近多かったなぁ

タスクにたいする見積もりをさぼっていたなぁ

完了条件が明示できていなかった

TODOとDoingをわけれてなかったな

ASAPとTodayをわけるのはよさそう

TODOは担当をわけない。Doingになってからわける

アイスボックスにいれて忘れておいて見直すことも必要

 

最後に、言われていた、「楽しかった、良かったよりも、役に立ったという感想をお待ちしてます。」

結構これが響いた。

ので、月曜日から会社のTodayとPending、Doneだったタスクボードを、Todo,Doing,Doneにわけて、ホワイトボード反面だったのを全面にかえてみた。色々と運用してみて、役に立った報告をしたいなぁ。

 

AgileJapan2012に参加してきました。

2012-03-26 勉強会

3月16日。AjailJapan2012のメイン会場が大阪で開催されるというこで、このチャンスを逃すものかと、AjailJapan2012に参加してきました。

その自分の感想とメモ。

アジャイルJapn2012@ATCホール

9:15‐10:00 「Agile In a Nutshell」~ ざっくりわかるアジャイル開発 ~
Jonathan Rasmusson 氏

いきなりアジャイルサムライ著者による講演。
英語なれしていない自分の頭は、ウォームアップどこから、いきなりフル回転を迫られました(^_^;)

アジャイルの概要と、各手法の紹介のお話。

・伝統的なウォーターフォールにおける 分析、設計、実装、テスト を継続的にやるのがアジャイル
・XPからはじめて、スクラム、Leanへと進むのがよい。
・Scrum(framework) + XP(practices) + Lean(spirits) というのは、いい組み合わせ。

Agileをはじめるなら、まずは以下の4つを練習してみようとの事。
・UnitTesting・Refactoring・Test Driven-Development・Continuous Integration

10:00‐10:10 オープニング
今回のテーマ「いまこそ語りあおうAgileのABC」についての説明などがありました。

A;アジャイルの原点に立ち返る。
B;ビジネスにつながっているのか
C;変化できているか

Agileを知り、ビジネスをつくり、変えてゆく

なんと、参加者:250名が開催1ヶ月前にうまったそうです。
オープニングの中で、アメリカでは、60%が社内の半分くらいでアジャイルやっていて、8割が経験したことがあるという話を聞いて、驚きました。

10:10‐11:00;キーノート セッション1
「The Surprising Science Behind Agile Leadership」
~ アジャイルリーダーシップの背後にある驚くべき科学について ~
Jonathan Rasmusson 氏 解説:ヒラナベさん

Q;鉄工所の生産方式がソフトウェアにも適用できるのか?
・チームの生産性を比べる意味はあるのか?
・クリエイティブな仕事の効果をどう測定するのか。
・見積もりって絶対間違うよね。

※金のことを考える必要がなくなる程度の報酬を与えれば、金について考える代わりに仕事について考えるようになる

40年前のソフトウェア開発:
指揮統制、コンプライアンスは厳守された。工業的な開発。
命令、統制は、コンプライアンスにはいいけど、スタッフは積極的にはならない

ソフトウェアは鉄鋼の生産ではなく、クリエイティブなものだから、
「自律」「熟達の喜び」「目的」が大事
ソフトウェア開発は映画のようなものです

仕事の向かい方に組織がついてきていない。
仕事(アジャイル):フラット → 会社:階層

会社もクリエイティブな仕事を求めているが、計画や予算が深刻な問題。
信じているシステムの考え方の違い。
ニュートン力学(安定しているのが当然)から量子力学(カオスなのが当然)

・自由を与えましょう タスクに、時間に、技術に、チームに
・平均以上の給料を。→お金の心配しなくていいような、人が逃げ出さない程度

・自分より優秀な人をマネージすることを認めよう。
→マネージャーより若い人のほうが技術に詳しいのはあたりまえ。
てづなを緩めよう。一人一人はいい仕事をしたいと思っている。
彼らがやろうとしていることの邪魔になっちゃいけない。

11:00‐11:50 キーノート セッション2:
「全体最適のマネジメント改革」~ 変えるのは現場ではない、マネジメントである ~
岸良 裕司 氏 ゴールドラット・コンサルティング・ディレクター
日本TOC推進協議会理事

#朝日新聞で隔週土曜日に連載している。

仕事は人や組織とつながっている、人や組織の能力はばらついている。
仕事は繋がりと、ばらつきがあるもの。
ボトルネックに全体の余剰分を投入し、ボトルネックに集中することが全体最適となる。

8時間のうち自分しかできない仕事をどれくらいしていますか?
全体最適のために、お互いに助けあう。

プロジェクトのジレンマ。
・すべてのプロジェクトは早く終わらせなければならない。
・そのためには、新しいプロジェクトに早くとりかからないといけない

★マネジメントの集中
実験をしたら考察が大事→”現実は途中で割り込むがあるのでもっと過酷→どんどん納期は遅れて、品質悪くなって、手戻りが起こる(マルチタスクない方が)2倍のスピード”
組織において一番足りないのはマネジメントの時間

組織のボトルネック、貴重なリソースはのマネージャー(キーリソース)
マネージャーがやらない事を決めることが大事。

マルチプロセス環境では、早くやれば早く終わるというものではない。
今やらない事を決めて、今やることに集中する。

クリティカルチェーンの5つの要素
マネジメントが変われば工数が下がった。

現場を変えるのはリスクだが、マネージメントの変えるのはリスクがない。
現場は頻繁に改善・変化を繰り返す事がよくあるが、多くのマネージメントは旧態依然としている。
変わるのは現場ではなく、マネージメントである。

11:50‐12:10 IPAによる発表:
アジャイルのABCに向けたヒント ~IPA/SECの調査検討から見えてきたもの~
山下 博之 氏 独立行政法人情報処理推進機構
基本契約・個別契約モデル

プロジェクト管理にアジャイルのプラクティスを使う現場:部分的には50%程度

13:15‐14:35 Agile セッション アジャイル開発 基本のキ

14:45‐16:05 Businessセッション アジャイルをも活用した新しいビジネスモデル
市谷 聡啓 氏 株式会社永和システムマネジメント
藤原 士朗 氏 株式会社ソニックガーデン
濱 勝巳 氏 株式会社アッズーリ
ファシリテーター 羽生田(豆蔵)

第1部:各サービス紹介
永和システム;新しい受託開発サービス価値創造契約
・papanda
お客様に価値を提供し続ける
変更を受け入れるシステム開発を契約スキームでどう実現するのか?
システムを初期費用0円で提供。サービス利用料を月々お支払
→初期投資が不要、追加開発もサービス利用料内なら新規稟議不要
月額15万円〜(1チケット)S;2チケット M,L,LL3~10チケット
※協同で価値を創りだしていくという思いの実現、
なお、お客様によっては既存の受託開発も並行しておこなっている。

ソニックガーデン:アジャイルxルビーxクラウド
ソフトウェアパートシップモデル IT投資に対するソフトウェアの価値を最大化すること
納品しない受託開発(サービス型の受託開発)
「オーダメイドの受託開発」「納品しないこと」「派遣しないこと」
・定額のみ。見積もりしない。大きくなれば期間がのびる。チケット販売ではない。
・見積もりしないので早くなる。いつでも動くテスト環境をお客様に確認いただく。

要件変更にはどう付き合うのか?
・リソースはいっていなのでしっかりお客様が管理しなさいよ。
・まず最初につくるものをきめて、その後、変化は聞いていく。

アッズーリ:アジャイル・サービスデスク
・株式会社アジルコアの代表でもある。
ソフトウェアは開発から保守の時代へ。
何かをつくってものにしていくのではなく、社会の一つであろう。
非SI企業のIT部門や、アウトソース部門が対象。
ITはインフラ(水道・電気)と一緒で、もしければ手に入るものになってきた。
ソフトウェアセルという単位でうけている

第2部;サービスビジネスの立ち上げから
永和システム:
アジャイル導入を検討するお客様と、既存契約のお客様とに差異がある。
Q:チケットの概念を顧客は理解さされているのか?
はじめの開発の中で、チケットになれてもらう。

ソニックガーデン:
当初、チケットでやっていたが、結局見積もりが発生するのでやめた。
これだけやります!といってやるけど、
早く終わったらもっとやるし、遅くなったらごめんなさいする。顧客との協調。
営業:自社サービス経由のお客様や、中小の社長と1:1で考えを併せていくことも多い。
顧客にも相談してもらえる関係を作る。
人材育成は?
→ 完全なる新人はまだとってない。お客様と師匠のやりとりで。
研修生が担当する研修生プランもある。
コンサルティング事業のほうで、OJTを受け入れるアカデミープランもある。
→プログラミングを一番力をいれておしえるが、感想では働き方を学んだという声がおおい。

アッズーリ:
セル単位、セルをどの程度稼働させるかで金額が決まる。

最後にこれからについて:
永和システム:
協調できるお客さまを増やす。仲間づくりの関係づくりをしたい。
ソニックガーデン:
上場しない。大きくする気はない。
同じような働き方ができる人をふやしたい。
アッズーリ:
ITを作ると使うは同じになり、プログラマーは減っていく?

16:15‐17:35 Change セッション

現場に続くAgileの道を語ろう~アジャイルサムライ読書会が変えてきたこと~
→タイトル変更:アジャイル道場から盗め!
講演者:
梶浦 毅一 氏(湯島道場)株式会社アルティネット
矢島 卓 氏(エイチーム道場) 株式会社エイチーム
中島 隆一 氏(金沢道場) サイバーステーション株式会社
市谷 聡啓 氏(DevLOVE道場)
中村 洋 氏(TIS道場)
木村 卓央 氏(横浜道場)株式会社アットウェア
宇畑 洋介 氏(島根道場)
栗毛野 友美 氏(新宿道場)
上田 佳典 氏(BIGLOBE道場)
大友 聡之 氏(京都道場)

アジャイルサムライは1万3千冊売れた。
全国で読書会が行われている
読書会はとりあえずやってみればいい。