「レビュー」をもっとうまくやってみる - DevLOVE関西#93

devlove-kansai.doorkeeper.jp

DevLOVE関西主催の勉強会にまたまた参加してみました。というわけで遅くなりましたが書き起こしを。
個人的なメモかつだいぶ忘れてしまっている内容なので変なところも多々あると思いますがご了承ください。

シナリオレビューの紹介

登壇者:森崎修司(@smorisaki)
名古屋大学 大学院情報科学研究科 准教授

レビューの効果

テストのタイミングで確認して修正するとなると遅い
なのでレビューのタイミングで確認したほうがもちろんいいよね

ただし…
テストの工数が削減できるという観点のレビューでないと意味ない

じゃあどういうレビュー内容がテストの工数を削減できるのか?

レビューのアンチパターン

  • 一部だけしか見ない
    インデントはスペース4つで統一してください。とか
  • 人格攻撃
    こんなのもわからないなんてエンジニアとしてどうなんですか?とか
  • 説明会とか進行がおかしい
    ではこれから説明会レビュー会を始めます。お手元の資料を…とか

ではどうしたらいいか

レビューの準備

レビューの準備に必要なことは、レビュー前に適切な目的を設定し合意しておくということ
具体的には「問題種別の抽出する」と「検出シナリオを決めておく」(後述)
これらをみんなで合意することが一番大事!

レビューによる問題の検出

事前に設定した問題種別に沿って検出する
→どこをどうチェックしたかは予めチェックリストを作ることで明らかにしておく

レビュー技法

Defect-based reading Perspective-based reading

Defect-based readingとは

漏れ・曖昧・誤りの3つの観点でレビューを実施する技法
ちなみに漏れ(一番難しい)

  • 漏れ
    検討漏れ
    →そもそも検討ができていない場合がある
    あなたにとっての「常識」とは?
    →使う人にとっての常識を定義する
    ドキュメントを読んでしまうと先入観が入ってしまう
    →ドキュメントを読む前にソフトウェアのあるべき姿を想像して望む

  • 曖昧
    読み手にとって複数の解釈ができてしまうものは、読み手の想定や定義が必要となる

  • 誤り
    外部や内部で定義されたドキュメントやコードの不整合が原因であることが多い

Perspective-based reading

そもそもテスターはテストを実施できるのか?
のようににテスター・発注者・利用部門・プログラマそれぞれの立場で考えてレビューを実施する技法

シナリオレビュー

レビューの目的を共通認識として持つ
レビューの効果に応じて濃淡をつける
指摘は網羅性を確認する
(この辺駆け足だったのでメモできず…)

ワークショップ

その1
http://www.miyazaki-ac.jp/?action=cabinet_action_main_download&block_id=100&room_id=1&cabinet_id=1&file_id=1140&upload_id=3180
これをレビューして問題になりそうな箇所を5つ挙げて下さい。

問題種別の設定方法

トップダウンの例

「グローバルで使われる案件ワークフローシステム」について考えてみる
→どこが一番価値のある品質か
 →システムが停止しては困る
 →大容量ファイルを処理できる
 →日次処理に影響が出ないようにする

システムの停止の際に原因が分かるようにするとか
大容量ファイルは処理時間がどれくらい掛かるかとか複数アクセスされた場合どうなるかとか

つまりレビューで何を見るべきか、また何が大事かはそのシステムにとっての価値で決める
それを決めるのがシナリオである

ワークショップ

その2
http://www.city.matsusaka.mie.jp/www/contents/1340350276686/files/120188-3.pdf
このシステムにとっての価値を順位が高いものから5つ挙げて下さい。

まとめ

ワークショップは3人1組でやったのですが、その1ではレビューの観点がバラバラだったのが、その2では価値順位も含め、かなり近しい観点にまとまりました。
その価値順位に対してお互いが合意してからレビューをすれば、かなりいいレビューとなりそうです。

あとレビュー本すごく良さそうでした。

Qiita:Teamとesa.ioを使ってみた感想

はじめに

今の会社ではQiita:Teamを使っている。
一番古いのを見たら1年以上前の投稿があったので、けっこう使ってますね。
で、使っているうちにいろいろ気になるところが出てきた。

なので、今お手伝いしている会社にesa.io使ってみません?と言ったら使ってくれることになった。 使ったのは大体5ヶ月くらい。

両方ガッツリ使ったので、誰かのために書いておこうと思う。

情報をどうやって分類するか

Qiita:Teamではストック型ツールにもかかわらず情報が流れちゃうっていうのにすごくストレスが溜まっていた。
投稿した時に分類がされないから、どんどんいろいろな情報が流れていってしまう(日報とか書いてたときはエライことになってしまってた)。

まあ、気をつけてタグ付けしていったらいいんだろうけど、タグ付け自体エンジニア以外の人にとってはハードルが高い。

esa.ioは/で区切ってね。と教えるだけで階層分けしてもらえた。
このアイデアは素晴らしいと思う。

記事が書きやすいか

僕もエンジニアなのでそんなに気にならなかったんだけど、どうやらQiita:TeamのUIは記事を書きにくいらしい。
個人の資質とか企業文化とかももちろんあるんだろうけど、投稿してる人の属性がかなり違う。

Qiita:Teamに記事を投稿するのは9割がたエンジニアばかりなんだけど、esa.ioはそれが6割くらいになっている。
UIについてはそんなに詳しくないからなんとも言えないんだけど、データ的にはそんな感じで、esa.ioは非エンジニアにとってはすごく書きやすいみたい。

他の人がどういったことに興味があるか

Qiita:Teamの前のバージョンではその記事を誰がストックしているかが見れていたんだけど、なぜか見れなくなってしまった。
その記事に誰が興味あるかって結構大事だと思う。

esa.ioではwatchっていうのがストックに当たるんだけど、これは誰でも見れる。
XXXさんがこの案件に関わっているのにwatchしてなかったら、watchしといてねと言えば暗黙知もなくなると思う。

まとめ

エンジニアがほとんどの会社だったらQiita:Teamでいいんじゃないかな。
もともとQiitaから派生したものなので、使い心地は似ているし。
ただ、その分ストック型ツールとしては非エンジニアが使いにくい部分も多い。

@bash0C7さんも言ってたけど、エンジニア以外の職種の人にも書いてほしいならesa.ioのほうがいいと思う。

あと、Qiita:TeamはちょっとずつUIとかも変わったりしていってるんだけど、どこが変わったのかをユーザーに教えてくれないのはすごくもったいないなーと思ってしまう(先日大幅に変わった時くらい?)。

リリースノートとかもそうだけど、esa.ioはユーザーとの距離感をいちばん大事にしている会社だと思う。
不具合修正の対応とか見ててもOSSみたい。
サービス運営のあり方として見習いたいところです。


追記

ちなみにesa.ioExcelもアップできちゃう。Qiita:Teamもそのうちできるようになるのかな。


コミュニケーションツールと“持ち寄り型”プロジェクトマネジメント - DevLOVE関西#87 その2

devlove-kansai.doorkeeper.jp

その2です。その1はこちら

ストック型+フロー型ツールの導入で社内を巻き込んだ話

登壇者:白石尚也さん
    松尾浩志さん
TAM株式会社

はじめに

ストック型とフロー型とは…
ストック型:Qiita:Team、Docbase、esa.io
フロー型:Slack

ストック型ツールについて

登壇者:白石尚也さん
TAM株式会社 クラウドアプリケーション事業

TAMについて

パートナー型デジタルプロダクションを行っている
→身も心もどっぷり受託

体制としてはプロジェクトチーム制
最大20人でディレクター、デザイナー、マークアップで構成

発生していた問題点

顧客の満足・品質にこだわっているため、勤務時間が長くなり疲弊していく
→疲弊しない受託開発をするためにチーム力向上を図る必要あった

新しいことにチャレンジする案件がほとんど
つまり必ずどこかでハマるポイントがあり、自分がハマったことは他の人も必ずハマる
→どうやって解決したか共有、コミュニケーションを取れるようにしたい

案件が複数(常時5〜7件)同時進行
時期によっては1人に業務が集中する
→チーム全体がメンバーの仕事状況を把握し、お互いが助けれるようにしたい

問題解決のためにDockbase導入へ

Dockbase導入の苦労

3つくらい壁があった

  1. どのツールを使ったらいいのか問題
  2. リーダーを説得するにはどうしたらいいか問題
  3. 書いてもらう、読んでもらうにはどうしたらいいのか問題

どのツールを使ったらいいのか

有名なストック型ツールは3つあった

  • Qiita:Team … 一番有名
  • esa.io … デザインイケてる
  • DockBase … シンプル

さてどれにしよう…?

ツール選定のポイント

誰でも使えるわかりやすいUIのツールにしたい
エンジニアではない人が大半であることを考慮しないといけない(そもそもMarkdown書けない)
→つまり、たとえ機能が多くても直感的でないと使われない
使用ツールが増えてきているので学習コストを下げたい

3大ツールの検証

有志を募って1週間ずつ使ってみた

Qiita:Team

機能が一番豊富だが、プロジェクト・タグ・メンバーから記事が探しにくい
投稿ボタンどこやねん(解像度が低いと見切れる)

esa.io

かわいいデザインはGood!でもなんで英語?
カテゴリとタグの付け方がわからない
→結局だれもタグ付けしない
WIPって何?という意見も

DockBase

シンプルで分かりやすい(最後に試したというのもあるが)
エディタ機能付き、かつMarkdownの書き方がすぐ分かる
投稿ボタンが見える笑
メニューから記事が探しやすい
自分の活動、他人の活動が目に見える

結論

シンプル・見やすい・探しやすいということでDockBaseを採用することに

リーダーを説得するポイント

いきなり全員で使うのではなく、少人数でスタートし巻き込んでいく
リーダーが気になることを書く(朝会、日報)
リーダーになんとなく効果を実感してもらう
DockBaseは今なら無料!
→無料のうちにメチャクチャ使って寝技にもちこむっていうのもアリ

書いてもらう、読んでもらうポイント

何をかいてよいかわからないし、書く時間がないという意見がツールの振り返りで判明した

「暗黙知を作るな、すべてを形式知に変えよ」

とにかく書けるものから書く
朝会、日報、ふりかえり、議事録など
→なるべく所感も書いてもらう
調べたこと、解決した方法も形式張らずに書く
さらに、投稿を通知して読んでもらう(チャット通知に連携)
読んだら反応する風習を社内につける

壁を乗り越えた結果

チームの会話、コミュニケーションが増えた
→答えはそこになくても、あの記事を書いた人なら分かるかも
チームメンバーの状況が可視化された
→朝会、日報、ふりかえりによってお互いがフォローできた

今困っていること

記事の精度をどこまで求めたらいいのか
→記事のレベルアップ最終盤は別のWikiにまとめるとか?
タグが煩雑になりそうな予感
→すでに独自の見解による謎タグの氾濫が…笑
より活発に使われるためにはどうしたらいいんだろう
→この後のワークショップで話しましょ!

まとめ

やりたいと思ったらまずは少人数で試してみる
→協力してくれる人は必ずいる! どんなことでも残っている安心感が得られる
記事の内容も大事だが、記事を書いた人とコミュニケーションするきっかけ作りになることがとても重要

フロー型ツールについて

登壇者:松尾浩志さん
TAM株式会社 CTO

導入前の問題点

メール+チャット(Skype)が中心だった

Skypeはプライベートなやりとり向きでクローズド
オープンな場所に情報が集まらない
オープンな場所は全社メールくらい
気軽に質問・共有できない

どうにかしたい どうしたい?

知らなかったことを知ったら「これ知ってた!?」って気軽に言いたい
分からないことを知ってそうな人に気軽に聞きたい

なぜSlack?

チーム全員参加のチャットルームがデフォ
Githubなど他ツールからの通知をSlackに流せる
イケてるもん触ってる感

Slackを情報共有のハブとして

IFTTT連携も活用することでタイムライン的に情報が集まる
いろいろな社内ブログを更新したら流すようにみたいな情報共有の仕組みができた
hubotでカスタマイズしたりもできる

社内へのアプローチ

新しいモノを試すときの人の反応タイプはこんな感じ

  • 新しもの好き、試行に積極的 →少数派
  • ツールは特に何でもいい   →多数派
  • めんどくさい…       →多数派
  • ぜったいイヤ!       →少数派

まずは新しいもの好きの少人数で試行してみて、のちに多数派にアプローチしていった

コミュニケーション上の工夫

なごむ雰囲気を作る
→業務外のチャンネル作ったり絵文字を登録したりとか
→TAMくんbot

TAMくんbotとは?

→人がなごむpostするには限界がある、スベったら凹む
→かわりにTAMくんbotになごむ返信をしてもらう

TAMくんが使われる場面はこんな感じ
→お昼時を知らせたり、明日は雨の予報のときに通知したり
→ビールアイコンに反応したり
→よろしくお願いしますに反応したり

どうでもいいことを書いてOKな雰囲気に

たらいまわし作戦

誰も答えない場合はたらいまわす!
どういうことかというと…

誰かが全体にふわっと質問する

誰も答えない

やばい、このままでは誰も質問してくれなくなる

分からないなら分からないと返答しつつ詳しそうな人を名指ししてしまう

そうすることでコミュニケーションが止まらない

Slackを導入してみて

持ち寄れる下地ができた
→気軽に質問したり教えたりできる場所ができた
→チャットにいるだけで情報共有できるようになった

まとめ

「良いしくみ」をもつツールがフィットすると、仕事の流れが予想以上にいい方向に変わるケースもある
遊び要素・和み要素は重要
しくみを作って終わりではなくコミュニケーションを潤滑にまわす努力は必要

コミュニケーションツールと“持ち寄り型”プロジェクトマネジメント - DevLOVE関西#87 その1

devlove-kansai.doorkeeper.jp

DevLOVE関西主催の勉強会に初めて参加してみました。というわけで書き起こしを。
だいぶ長くなったので端折ってる&整理してます。

ポエム駆動開発 エンタープライズ

登壇者:こしば としあきさん(@bash0C7)
ピクシブ株式会社

ポエム駆動開発とは?

pplogさんのこの記事にものすごく共感した
→ポエムの共有をして意思決定のスピードを上げる
→サービスを開発する前にポエムを書く
→思いを共有しておき、いつでも立ち戻って振り返れる

つまり『コンテキストの共有』が大切

ではポエム駆動開発エンタープライズとは?

エンタープライズとは経営資源の投入
投入するからにはやる理由やらない理由を説明しないといけない
→それをポエムから始めようということ

pixivchatの例

pixivchatはクローズの判断を一旦下したのだが…

社内のメンバーがpixivchatへの思いをesa.ioに投稿

あれこれコメントがついた

なんか新しいプロダクトを創りだした

ロードマップまで笑

『新サービス現在開発中』とユーザーに告知するまでになった

イデアについて

  • 上から降ってくる
  • 横から割り込まれる
  • 足元から湧いてくる

この3つのパターンに分類される

足元が湧いてくるとは?

こういうのやったほうがいいんじゃない?っていうのがメンバーや役員から持ち上がってくる
KPI・お問い合わせ・プラットフォーム・自分たちの理想が源泉となっている

でも湧いてくるというのは賞味期限が短い
→飲み会で盛り上がって終了
→じゃあポエムを書こう

ポエムの書き方

好き勝手に書くのではなくポエムの書き方をこしばさんが決めてみた

理由としては

  • 理屈ではなく熱意を感じたい
  • 日報は遠い日の話を書けない・エモいことも書けない
  • チャットは端的な発言になってしまう

だから反芻して発信しよう!ということ

ポエムの流れ

  1. 天啓を得る
  2. ポエムを書く
  3. 興味ある人からコメントが集まる
  4. プランとしてまとめる
  5. 有志が集まってMTG
  6. 承認を得る
  7. プロジェクトが立ち上がる

現在

数十から百数十のポエムが存在する
新卒が入社数日でポエムを書く
→議事録やアイディアメモが陽の目を見るようになった

ポエムを書くまでの悩み

マネージャーは発言しやすい
→そんな立場の人でも思いを発信する場がないことに気づいた
wikiは書いたら消えない
issueは閉じることに意味がこもってしまう(お前の話は聞かんみたいな)
飲み会は話が散らかる
言い出す勇気が必要

自分自身の、会社でポエムを発信することへの躊躇に気づいた

ポエムスタート

オフィシャルにesa.ioを使うことにした

全体の会議でポエムを書こうと言った
また自分でポエムとは何かを述べた
esa会もした
ピクシブのエンジニアブログにもポエム駆動開発エントリーを書いた

持ち寄られるようになった(なんかしらんけどとのこと笑)

ポエムを書くようになって

ふと浮かんだアイデアを意見提案してくれる(プロジェクト横断で!)
プロジェクトで試してみたことを書いてくれる
一ユーザーとしての観点として、リリース後のものに対するフィードバック
開発スケジュールの管理
広告についても、みんなが知ってほしいから書いてたりする

やったこと・してないこと

やったこと

ツールの意図の説明をした
自分から理想の利用者を演じることにした
→率先してスター・コメント・介入をしていく
意図と違う使い方を黙認した
→タスク管理ツールじゃないけどまあいいよ

してないこと

カテゴリ分けはしなかった
細かいルール策定もしなかった
→それでも使われているのは何でだろう?再現性を作りたいと思っている

質疑応答

Q.ポエム導入を小さくはじめなかったのはなぜ?
A.導入についてどう進めるかをトップに相談してみたところ、全社的にやってみたら?というアドバイス
じわじわよりパワーで進めるのもアリだなと思った

Q.esa.ioを使うことにしたのはなぜ?
A.docbaseやQiita:Teamというツールがあったのは知ってたけど、見た目がかわいかったからesa.ioにした
理由としては技術者以外にも使ってほしかったから
→エンジニア主体ならQiita:Teamでいいんじゃない?

Q.声の大きい人のほうが力が強くなってしまうのでは?
A.プレゼンではなく文章に書くからこそ、そういったことがそれが抑えられたのでは
1行はするどいから数行かこうとかのポエムのルールも寄与した
また、ポエムを読んで、誰がどう思うかっていうのを考えていながら書いてもらっている
肩書で左右されてしまう問題はピクシブの組織の性質上今のところはない

Q.長い文章を書いてくれるけど意味不明ということはないか?
A.長い文章を書いてくれるけど意味不明っていうのもあるにはあるが、書くこと自体に責任が伴うということを伝えている
またマネージャーとして寝かしたほうがいいとかのアドバイスはしてあげる
Save as WIP Ship it!という機能を使って通知が飛ばないようにできるから、それも有効活用している

Q.導入してみて盛り上がりに欠けたりかもしれないが…
A.初動を起こす人フォローする人それぞれが個性として認めている
やはりhubとなる数人のフォロワーからスタートするのがいい
人事考課とかでも賞賛するようにしている(楽しく意見を言えるように会社側もフォロー)
結果としてドキュメントを書くことが楽しいと言ってもらえたのが嬉しい


追記

こしばさんがスライドをアップしてくれていたので載せておきます。 inside.pixiv.net


その2へつづく。