『コミュニケーションツールと“持ち寄り型”プロジェクトマネジメント』#DevKanに参加してきました
2015.04.11にあった表題のDevLove関西の勉強会に参加してきました。
ポエム駆動開発エンタープライズ
Poem Driven Development Enterprise // Speaker Deck
今回のテーマ：再現性を作りたい
元になった考え
ポエム駆動開発によるWebサービスの作り方pplog
ポエムとは： サービスを開発する上での思い サービスを開発する前にポエムを書くこと。 開発で迷ったらポエムに立ち帰る。 設計内容のドキュメントというような堅苦しい話ではなく、開発のコンテキストを共有したい。
『ピクシブ株式会社のビジョン・ミッション』
創作活動がもっと楽しくなる場所を作ること
ポエム駆動開発「エンタープライズ」
エンタープライズであることによる違い
- 情熱を大事にはするが、経営資源の投入を行うので「ほかをやらない理由」を書かなければならない。
- 「人をよこせ サーバーを使うぞ」といった要求が飛び交う。
ポエムから起ち上がるプロジェクトの実例
pixivチャット：
メンテされない。塩漬け状態。やめようという話になっていた
数人がpixivチャットにかける思いをポエムに書き始めた
『pixivチャットをやめるのは良くないと思います』というポエム
→ 肉付け: 何人がどれくらいでどういうものを作ります
結果としてポエムをきっかけとしてサービス改善として開発することになり、開発計画もポエムからできた。
pixivでの開発について
開発スタイル：アジャイル
エンジニア勉強会を行っている
ある日、開発の天啓を得る
- 計測結果
- お問い合わせ
- 世の中の趙声
天啓は揮発性が高い: 飲み会 含む 普段の会話
なぜポエムか？
- 日報 その日のことしか書けない
- ビジネス文書 エモいことを書けない
- チャット 流れてしまう
オフシャルな形でポエムプラットフォームを導入
ドキュメント共有ツール＞esa
結果：
- 議事録などもポエムで書かれるように
- 参加していないメンバーでもわかりやすくなった
- ポエムを通じていろんなプロジェクトが持ち寄られる状態になった
- 社内のサービスはリリース後も開発者以外も触ってみて感想を書かれるようになった
導入のためにやったこと
- オフィシャルなプロジェクトとしてesaとポエムの導入をきちんとプロジェクトとしてたちあげ
コミュニケーションツールの炎上 導入には慎重になっていた - ツールの意図の説明
- 理想の利用者を演じる
- 意図と違う使い方を黙認
してないこと
- カテゴリー分け
- 細かいルール策定
社会活動を起こす方法を参考にする。→ハブみたいな人が乗ってくれた
感想
プロダクトやサービスにかける思いなどは確かに共有することは難しいです。
自分の会社では週報の所感として、そういう思いを書くことはありますが、それが他の開発をしている人などには伝わっていないのでもったいないなとおもいました。
ポエムという形で、設計というような堅苦しい話ではなくほかのチームやメンバーの開発がどういう思いでプロダクトを作っているか共有するのは素晴らしいと思います。
そこから実際のプロジェクトの起動までつながるのがちょっと想像の範囲外でした。
ちゃんとしたプロジェクトとしてポエムやesaの導入をやっているのでトップダウンな面もあり、ポエム自体の布教というボトムアップな面もあり、といったことがコミュニケーションツールとして幅広く受け入られた理由だと思います。
参考にしていきたいです。
ストック型＋フロー型ツールで周りを巻き込んで導入した話
株式会社TAM 白石 尚也さん
コミュニケーションツール
ストック型 Qiita Team, DocBase, esa
フロー型 Slack
今回はDocBaseを導入した話
導入前に困っていたこと
やっている仕事はパートナー型デジタルプロダクション 。 お客様とタッグを組んでPDCAを回す。
- Web連携CRMSalesforce連携開発の受託開発業務
社内では誰もやっていないことをチャレンジする案件がほとんど。
必ずはまるポイントがある。
お客様満足度 品質を追求
昼夜を問わず働くことも。
疲弊しない受託開発をするためにチーム力向上を図る
自分がはまったことは必ず他の人もはまる。
どうやって解決したかを共有し、他の人が同じことではまらないようにしたい。
ストック型のコミュニケーションツールを使ってみよう
導入のコツ
Qiita Team : Qiitaが有名
esa : デザインがかわいい
DocBase : シンプル
エンジニアじゃない人が大半のメンバーである中で１週間ずつ試用してみた。
Qiita Team
機能は一番豊富だが、プロジェクト・タグ・メンバーから記事が探しにくい。
エンジニアじゃない人が多いため、マークダウンなどに馴染みがない。
投稿ボタンの場所がわからず投稿できなかった（解像度の問題）
esa
女性に好評 かわいい。
なぜ英語？直感的に使いづらい。
カテゴリやタグ付けがわからない。
WIPの意味がわからない インターネットカフェ？
DocBase
シンプルでわかりやすい。 エディタ機能でMarkdown出なくても描きやすい。 投稿ボタンも見える。 メニューから記事が探しやすい。 自分の活動、ほかの人の活動が見えやすい。
リーダーの説得を行い、DocBaseの導入を少人数(3人)でスタート
振り返りでわかったこと
何をかいてよいかわからない
→ 暗黙知をつくるな、すべてを形式知にかえよ
全部をドキュメントに変えよう。
誰か一人が知っているではなくて、全員が知っている状態にしよう投稿を通知して読んでもらう仕組み
- 読んだということを知らせるために いいね や コメント
- あのコメントを書いた人ならもしかして知っているかもということからコミュニケーションが取りやすくなった。
課題：
- 記事の精度
- タグ煩雑になりそう タグの運用はどうすれば
やってよかったこと
- やりたいことがある人は少人数で試してみる
- どんなことでも残っている安心感が得られる
感想
うちの会社ではAtlassianのConfluenceをドキュメントベースの情報共有に使っていますが、使っているのはまだエンジニアがほとんどだと思います。
エンジニアじゃないひとに情報共有の仕組みを広めていくためには、Qiita Teamやesaを試用してみたときの課題が大変参考になると思いました。
投稿を通知して読んでもらう仕組みに関してはまだまだできていないのでこれから考えていかなければと思います。
「あのコメントを書いた人ならもしかして知っているかもということからコミュニケーションが取りやすくなった。」というのを実現していきたいです。
SlackをTAMに導入した話
株式会社TAM CTO 松尾 浩志さん
Slackとは
既存のコミュニケーションツール：メール・チャット(Skype)
Skypeプライベート クローズドなツール
グループチャットをすると他のメンバーには存在すらわからない。
Slack導入に向かった経緯
- ふわっとした情報の共有がしたい。
- 便利なショートカットがあった
- Wordpressのプラグインがある
- あれはバックログに書いた あれはチャットに書いた という状態をなくしたい
- GitHubなどの通知がタイムラインに流れてくる
- さわってみて これいけてるという感じがあった
チャンネルのタイプ
- 全員が参加するオープンなチャンネル
- 誰でも入れるオーブンなチャンネル
- クローズドなプロジェクト単位でのチャンネル
- 一対一のチャンネル
導入してみて
- デフォルトで通知の設定が簡単にできる。
- heroku jenkins githubとの連携が簡単。IFTTTも活用
- Slackの画面をみていると情報が集まるようになってきた
Hubotの活用 ChatOps
Javascript (Node.js) + Herokuで手軽にOK
コミュニケーション上の工夫
どうやって使ってもらうか？
導入時のみなさんの反応タイプ
- 新しいもの好き、積極的 少数派
- ツールは特になんでもいい 多数派
- めんどくさい・・・ 多数派
- 絶対イヤ 少数派
導入の障壁を壊すために
和む雰囲気をつくる。
お堅い雰囲気だとなかなか浸透しない。
業務外のチャンネルを作って、好きそうな人を招待。
例：今日飲みたい人のチャンネル
TAMくんbotがなごませ要員
- 定期的に投稿
- 人の話に反応
お昼 〜が食べたい ビールが飲みたい - 画像を検索： Tamくんimage 「明日も勝つ」
「質問たらい回し作戦」
誰かが全体に質問する。
誰も答えない・・・
→ このままだと質問してくれなくなる
答えがわからないときは、中継して他の人に聞いてみる メンション
Slack導入してみて
「持ち寄れる下地」がやっとできた。
全社メールしかなかったら質問ができなかった。
「良い仕組み」を持つツールがフィットすると仕事の流れが予想以上に良い方向に変わるケースもある。
遊び要素、和み要素が重要
仕組みを作った はい終わりではなくコミュニケーションを活発にしていく努力を継続的にしていく必要が有る
感想：
「Slack羨ましい。使ってみたい」という気になりました。
興味を持ってくれそうな人、積極的に使ってくれる人をハブにするのと、継続的に使ってくれるように努力していくことがコミュニケーションツールの導入には大事だなと感じました。
とくに、チャットルームに仕事に直接関係すること以外の「部活」「今日飲みに行きたい人」などを用意することや、botに面白いリアクションを返させるなどの和み要素を設けることはうちでは全然できていないので参考にしていきたいです。
『農業の「現場」から生まれた業務改善サービス「houren.so」の話を聞いてみる』#DevKanに参加してきました
2015.04.10にDevLove関西の表題の勉強会に参加してきました。
www.slideshare.net
株式会社日本情報化農業研究所 農業技術部部長 齋藤 毅さん
houren.soとは
体を動かして作業する人がいる現場のツール・グループウェア 何かの作業をした後、画像を投稿することで、誰がいつどんな作業をやったか報告できる
植物学「低コストの栽培技術をまとめる」 というところから プログラミングの道へ
なぜこのアプリが開発されたのか？
研究のための農作業の日報
報告する側
農業で１日作業すると疲れきっている。 会社への報告を業務アプリで書いていたが、疲れすぎた状態で日報を書くのはツライ。 しかし、報告しないとサボり扱い。。。報告される側
面倒なので読まないが提出だけはチェックしている
夜、無理をして作業日報を書く → 睡眠不足 → 翌日の作業が危ない！
怪我や命にかかわることも多い
作業ブログ → 事細かく書くように要求されているため「メモ」が必要
だが、メモを残しづらい
- 雨が多過ぎる気候 → メモ帳はすぐ使い物にならなく
- 寒いときは手袋を外したくない
- 農薬散布はフル防護服 （散布する人は超危険）
なんとか簡単に情報を伝えることができないかと、試しに作業時に写真を撮って熟練者に見せてみた。
- 作業前、作業後、使った機械
写真を見たら作業した面積がわかる
仮説：大事なことは写真だけで大半が伝わるのではないか？
→ Exifの情報を並べるだけで十分な日報に
検証：写真による報告の効用
- Webで販促を行っている とにかく写真が欲しい
例：トマトが熟している写真が欲しい → 報告で使っていた写真を検索で使う - 報告以外でも、農業の作業場の風景などをなんとなく写真に
→そのまま栽培の教科書に - 報告はテキストより写真のほうがわかりやすいことがわかった
- 農業では写真を活用する文化がまだなかったが、活用方法は多岐にありそう
- Exif（撮影日、GPS）があるので、後日投稿でも質が落ちない
→ 雨の時にまとめて送信など - 相談も写真があればわかりやすい
熟練者が見れば、畑の画像などから『「この色のおかしい箇所」はなんだ？』というところから、実際にはカビがあるということの発見につながる。
→ 画像でノウハウなどの弱い共有ができる
設計：
* 写真と日付 を グループ単位で クローズドに投稿する
* シンプルで便利にする
* 狙いは、写真の投稿者の負担をかけず、投稿のハードルを下げるため
* 時系列のまとめ機能
* 投稿者はほとんど情報を持たず、グループがもつ情報がほとんどにする
投稿するだけで報告になるというUX主眼の機能設計
検索の仕方
- タグで検索
- 月で検索 ： ７月 → トマト
感想
開発の話について、以下のことがすばらしいとおもいました。
- 開発までいたるプロセスとして、きっかけがあって仮説をたて、それを最小限の単位で検証している
MVP的なアプローチ - 完全にUX主眼の設計になっており、デザイン主導になっていない
houren.so自体は、目視確認を行う作業がある現場は農業以外でも様々な場面で活用ができそうです。
『メトリクスによる「見える化」のススメ：エッセンシャルリーン』ワークショップに参加しました
Devlove関西『メトリクスによる「見える化」のススメ：エッセンシャルリーン』
楽天株式会社 伊藤 宏幸(@hageyahhoo)さん
楽天の部門やチームに対してエナジャイズするお仕事をされている。
状況が見えないことを人のせいにしてませんか？ メトリクスの工夫や活用で状況を「見える化」しよう ＝ 今回のメインテーマ
セッション
落ちないバーンダウンチャート。原因は？
- レビューの負荷が大きい
- 本当にそうなの？実際に計測
日毎人毎にプルリクエストの来ている数を表にして計測した。（スライド参照）
- 特定の人に集中
- 他の人にも均等に
- 日によって頻度の波がある
- ならせないか？
- レビューの突き返しが多い。
- レビュー以前の問題かも
- レビュー依頼前に最低限やることを決める
- どこまでやったらレビュー依頼を出してよいかの共通認識
- レビュー以前の問題かも
ちょっと計測する手間を挟むだけわかる
身近に意外とヒントが転がっている
アジャイルのカンファレンスのセッションの中で「メトリクス」をテーマにしたものが３分の１ 実はブームが来ている
- Cummulative Flow Diagram
- スループット
- サイクルタイム
- リードタイム
これらはJIRAで全部見られるとのこと。(会場にAtlassianのエンジニアさんがいました。)
- 考えることのプラスになる情報をみつける
- 数値の変化に意味を見出そう
- メトリクスを定期的に振り返り改善していこう
- コミュニケーションの手段として活用していこう
もっと知るために「見える化勉強会」に参加しよう！
ワークショップ 1
メトリクスを考えてみる。
手法としてはトレードプレゼンテーション
- 開発者としての視点
- マネージャとしての視点
の双方でできるように、
- 開発者的役割をしている人と、マネージャ的役割をしている人がどちらもいるように参加者をグループ分け
- 自分たちの抱えている課題を話し合い、それを見える化するためのメトリクスを考えてみる。
- メトリクスの内容が決まったら別のグループの人にその内容を伝える
- さらに、内容を伝え聞いた人が今度は聞いた内容でまた別の人にプレゼンする。
自分の参加したグループでは、
- チケットに作業時間は書くけれどブロッカーの待ち時間はどうなのか
- 案件を起こしてから実際にリリースが出来るまでのリードタイムでどこに滞留が発生しているのか
といったことを見える化したいということになりました。
メリットとしては
- 開発者側はプルリクのレビュー待ちなど、案件担当者が操作できない状態で進捗が止まっていることを見える化できる
- マネージャ側はリードタイムのどこがボトルネックになっているかを発見しやすくなり、改善の施策を考えやすくなる
ということです。 実際の見える化手法についてはこの時点では決めていません。
この内容について上記のワークショップ手順でほかのグループの人にプレゼンを行いました。
セッション 2
Q&A
チームのメトリクスを他のチームに伝えるには？
- 事例はないことが多い ** 逆に言えば０を１にできる
- 成功事例を見せて デファクトスタンダードにするとよい
割り込みの見える化について 「コントロールできる割り込み」と 「無茶な割り込み」の２種類がある
focus factor １月１スプリント 予定していた作業にたいしてどれだけ割り込みがタスクが入ったか ３０％入ったとしたら、次のプランニングでは７０％で見積もりする。３０％はバッファー
振り返りできる定量化ができていない
- タイミングがない＞いつ誰がどうきめる？
補足資料 正確なものだけじゃなく、マネージャ・経営者が見て理解できる指標がよい コミュニケーションミスをなくす
具体的なメトリクス化の手順
- 仕込みをできる場所を探す
- 仕込みをしておく
- 仕込みがうまくいくように施策をしていく
- 段階的に調査する
簡単な方法でわかりやすいのがベター
週次報告でメンバーがやる気出る > 次につなげる
最初から全部ではなく できるから徐々に集めていけば良い
全部が役に立つわけではない
役に立つ情報だけを計測すれば良い
プロジェクトを定期的に振り返り、適宜見直しを行う必要がある
ワークショップ２
メトリクスを明確化 計算式も考えてみよう
その内容をA3の紙にまとめてみんなの前でプレゼンしよう
他のグループの発表では「割り込みタスクの見える化」「案件ごとの感謝された割合の見える化」などが面白かったです。
自分たちのグループでは、「プルリク」などでブロックされるというストーリーに絞りました。
進捗の状態(ステータス)をコード、プルリク、リリースとしたときに、それぞれのステータスでどれだけ滞在しているかの時間を「そのステータスの担当者」とタスク毎に記録しておきます。
そのあとでスプリントの振り返りなどでステータスの滞留時間をいろんなビューでみようという感じです。
ワークショップに参加しての感想
身近なところに計測できそうなことがたくさんあって、それを実際に計測して、分かりやすい形で表示することで課題自体が見えるようになると思います。
割り込みタスクについては、自分の働いているチームでは結構見える化できている部分がありますが、その実現方法は下準備的なことからこつこつと見える化につなげていっていると感じます。
今後も課題解決のための見える化ができるように考えていきたいです。
DevLOVE関西『「駅すぱあと」を支える開発 〜９２６２の可能性を繋げ！〜』に参加してきました。
５つも発表があって盛りだくさん。 中でも気になった１つについて感想を。
「AWS,DevOps絡みの話（仮）」見川 孝太さん
スライド背景のスターウォーズのレゴがかわいい。
内容の紹介
ずばりDevOpsではなくて、協力する文化をどう作り上げるかというお話。
- Dev = 開発
- Ops = インフラ
開発側：
仕事としては設計、開発、本番環境の構想、デプロイ、アプリケーション補修、アプリケーション運用などがある。
そんな中でインフラ側への不満として、「要求した環境にならない」「開発じゃない運用の増大」などがある。。。
インフラ側：
仕事としてはネットワーク保守（内外）、サーバ運用保守（OSまで）、セキュリティ対策、サービスの監視などがある。
インフラ側としては「不透明なアプリケーションのデプロイ」、「検証不足をネットワーク責任転化」「監視の増大」、「(ネットワークレイヤを開発のひとが)よくわかっていない要望」、「開発の理想押し付け」などの不満があった。
セグメント主義的な問題もあり、お互いに不満もあったが、どうにかしたいと思っていた。
そこで、運用負荷、環境を解決するためにAmazon Web Serviceを導入した。
AWSの導入はツールとして有用なだけでなく周辺の文化もついてくる。
開発もインフラも基本エンジニアなので共通の話題ができ、APIベース、コードベースで使用できる。
開発側はインフラに踏み込むことができ、物理的な制約に縛られない構成を自分たちでコントロールでき、運用の増大(スケール)も自動化できる。
インフラ側はインシデント対応、火消し的な仕事ではなく新しいことを試す創造的な仕事ができる。
AWS導入でお互いの得意分野を補い合って業務効率化できました。めでたしめでたし？
ではなくビジネスレイヤーのことも考えよう。
Biz = 営業
ビジネスの成功には三者の協力が必要 本来目指しているものは同じはずなのに主とする仕事の違いで食い違いが起きる。
インシデントの対応でも
- 営業->ユーザへの報告優先
- 開発、インフラ->復旧優先
二者間の会話が不足していると収束した後に問題になったり
問題点：
- 同じ技術系であるインフラと違い、共通言語がない。
そのため現場がテクニカルなところに踏み込んで話せない。 - 積もり積もった不満が表面化
改善：
古い決め事の見直しと意識合わせ 開発・インフラが知ってる取り決めと、営業が知ってる取り決めが一致してなかった DevOpsをするということじゃなくてもお互いが同じところを目指していることを意識合わせ
参考：The Phoenix Project壁を越えるためのスタンプカードを導入
- 部、チームではなくプロダクトのゴール の話をもっとしましょう
目指すのは協力する文化の定着
感想
自分もこの開発とインフラの問題の開発側で同じようなことを経験してるので身にしみます。
デプロイの自動化を実現するためにこういうサーバがほしいんだ、ということを伝えてもやはりネットワークレイヤなどの知識が不足していて、「よくわかっていない要望」を出すことになってしまっていないか気をつけねばと思います。
DevOpsやアジャイル開発を追求するのは結構なことだけども、協力する文化を築き上げなければと思います。
というより、そういった開発を目指すのであればまず「仲良くなる」ことからですね。
ビジネスレイヤの人でいえばうちの会社では商品開発やマーケティングの人なのですが、やっぱりビジネスのゴールを共有することが大事だなとこの話を聞いて痛感しました。
マーケティング領域の方からは会社の目標は一つですよ！(だからマーケティングのデータ分析のためにエンジニアをこっちにください)とよく言われるのですが。。。
ビジネスレイヤの人と共通の言葉で語れる基盤を用意することもすごく重要だと思います。
別の方の発表でありましたがDSLの活用などはその役に立つのかな？
ゴールや会社全体のオペレーションをビジネスレイヤ、Dev、Opsで共有して、もっとよいプロダクトを世に出せるように頑張りたいと思いました。
「勉強会の感想ははてなブログで」
何度か言われている表題の言葉、実行するためにはてなブログを始めました。 よろしくお願いいたします。
