kikukawa's diary

都内で活動するシステムエンジニアが書いてます。 興味を持った技術やハマったポイント、自分用メモをつけてます。 最近はweb中心

必要なタイミングで必要なミーティングをする

マネジメント

Makuake Product Team Advent Calendar 2018 の6日目の記事です。 業務委託としてマクアケに参画させてもらってるので書かせてもらいました。 ここに書かれていることはすべて私見です。

前置き

仕様を決めるミーティングやモブプロ的なものもありますが、今回取り上げるのは、プロジェクトマネジメントを行う上で必要なミーティングです。
デイリースクラム、レトロスペクティブ、スプリントレビューのような繰り返し行うものじゃなく、 特にプロジェクトのこの時期にこういうミーティングをこういう内容でやるといいんじゃないかということを書いてます。

キックオフミーティング

いろいろなやり方があると思いますが、ここでは私が絶対に話すことを書きます。

タイミング

メンバーが固まって、用意ができ次第なるべく早くがいいと思います。
やること(プロジェクトの目的)が決まっていて動かないのであれば、遅くする意味はないです。

話すこと

  • 全体スケジュール
    • まずは見えている範囲で共有します。
  • 気持ちよく仕事をしよう
    • モチベーションは仕事の効率に影響を与えやすいので。
    • 月曜の朝が楽しみになるようにしてほしいといつも言っています。
  • 黙ってるのが一番よくない
    • 言いたいことは言うこと
    • 黙っているということは、ただそれだけでストレスになるので言うべき
    • 溜めて溜めてあとで、トリガー引かれるよりは、小出しにしたほうがいい
  • リアクションしましょう
  • デイリースクラム
    • ここではやるかやらないかを決めておく。
  • 振り返り
    • 2週間に一回はやることを伝える。

やり方

普通に上記のことを伝えればいいですが、内職している人がいないようにしましょう。
あとは、とにかくエモく伝えるといいと思います。

混乱期に必要なミーティング

タックマンモデルでいう混乱期に実施するとよいと思うミーティングです。
混乱期に入ってくると、徐々にメンバーに言いたいことや不満が溜まってきます。
大事なのは、時期を見極めることです。

タイミング

タイミングが早すぎると中途半端になり、遅すぎると解決不能になります。
時期の見極めには振り返りを使います。前回の記事に書いたとおりにチームを見ていると、プロジェクトを開始して1,2ヶ月すると状態が悪くなっている振り返りが2、3回と続くことがあります。
プロジェクトの進み具合にもよりますが、そんな状態のときに実施するといいと思います。

下準備

下準備というか日頃からみておくべきポイントですね。 形成期も中盤を過ぎると段々とメンバーに我が出てきます。
このミーティングする上で個人の特性を把握しておくとスムーズなので下記のような特徴に注目しておきます。

  • プロジェクトに対するモチベーション
    • 高いかどうか
    • プロジェクト開始当初より上がっているか下がっているか
    • どこ(使う技術？ビジネス？)にモチベーションを持っているか
  • 何を大事にする人か
    • 締切
    • 綺麗なソース
    • 対人関係
    • プライベート
  • 戻りを気にするかどうか
  • 言葉が足りる人かどうか
    • 書けるかどうか(issueやpull requestの説明)
    • 言えるかどうか(対面での会話)
  • リモートワークができるかどうか
    • リモートワークはそれ自体にスキルが必要なので素養があるかどうか
    • その人のプライベートと相性がいいかどうか
  • 他メンバーとの相性
    • マネージャー含め
    • 面倒見がいいとか
    • 上記他の項目での相性

やり方

いつもの振り返りの一つとして行いますが、事前に長時間になる可能性があることをメンバーに伝えておきます。
取りあえず2時間取っておきますが、まずそれでは終わりません。場合によっては、4-6時間かかることもあるでしょう。

また、言いたいことを言い切ってくれということも伝えます。
このミーティングで言えなかったことは後になっても扱わないとも伝えます。
ミーティングが始まる前のいくつかの振り返りで言いたいけど言えなかったことがあるはずで、それらをすべて吐き出してもらうことが大事です。

付箋が出きったら、あとは普通の振り返りと同じように処理していきます。
本当は外部からファシリテーターを入れたりすると良いかしいですが、私はチーム内で処理します。

1on1

プロジェクトマネジメントをやっていると、1on1をやることがあるかと思います。
大事なのはタイミングだと思っているので、それを少し書きたいと思います。

タイミング

タイミングは非常に大事だと思っていて、良いタイミングでできるかどうかで全然結果が違うということも十分あると思います。
私はそれぞれのメンバーの状態をよく見て、必要なタイミングでやるようにしています。
メンバー全員に対して同時期に実施するのは意味がないと思っている派です。

メンバーそれぞれが抱える問題やもやもやすること、ポイントが違うはずなので、 同じ時期に同じテーマで一律聞いても、結局深いところまで引き出せないで終わると思います。

例外は、プロジェクトのキックオフ前後のヒアリングです。 キックオフ時は、状態も何もないので。

聞くこと

私は以下のようなことを聞くようにしています。
基本はモチベーション管理につながることを中心に聞きます。

  • やりたいこと
    • やりたいことがあるかどうか
    • 何がやりたいか
    • やりたいことが途中で変わっていないか
  • チームの状態につながること
    • チームが抱えていると思う問題点や対応策
    • チーム内でのメンバーの見え方(周りにどう思われていると思うか)
    • コミュニケーション(過不足ないか、方法は間違えていないか)

まとめ

  • キックオフミーティングはエモく話すこと(エモい話が大事)
  • 混乱期のミーティングは長時間とって解決を図る
  • タイミングが大事なミーティングがある

関連記事

kkkw.hatenablog.jp

振り返りでチームの状態を知る

マネジメント

Makuake Product Team Advent Calendar 2018 の5日目の記事です。 業務委託としてマクアケに参画させてもらってるので書かせてもらいました。 ここに書かれていることはすべて私見です。

振り返りの立ち位置

私は振り返りをチームの状態を確認するということに重きをおいてやっています。
本来の意味合いであるKPT的なことも意味はありますが、あくまでそっちはサブとして考えてます。
チームの状態とプロジェクトのフェーズを合わせて考えながらマネジメントをするためです。

やり方

2週間に一回

うちのチームは2週間を1スプリント(厳密にスクラムをやっているわけではない)としてやっているので、2週間ごとに1回金曜の昼に振り返りをやっています。
ただし、決めれられた日にやることよりも、メンバーが揃っていることのほうが重要なのでよっぽど先にならない限りは延期することもあります。

テーマの設定

テーマを設定しないと、漠然としてしまって、議論が発散する、結論もよく分からないということになりがちです。
なので、うちのチームでは振り返りのたびにメンバーに特に振り返ってほしいと思うテーマを1、2個提示しています。
そのスプリントを過ごしてからでないと、テーマを出しづらいので、大体振り返りの前日にテーマを伝えています。

テーマの例

  • XXXXに向けてやりたいこと
    • 次のフェーズに向けて今のうちに考えておきたいことです。
    • それぞれの考えを先に出してもらって次にやることのスケジューリングをしたかったためです。
  • プロジェクト進捗
    • 進捗が問題あっても問題なくても聞くことがあります。
    • マネージャーとメンバーの進捗に対する対する意識の乖離を防ぐためです。
  • リスケ後の進捗感
    • ちょっと無理そうだったリリース日を遅らせた直後のスプリントで設定しました。
    • まだ心配とか、これなら大丈夫とかを聞きたかったためです。
  • チームの状況が見えているか(他の人の動きが追えているか)
    • 個々でやること(技術的、機能的)がバラバラだった時期に設定しました。
    • お互いのことを知っていると安心感と信頼でチームがまとまります。より分かりやすくチームの状態を知りたかったためです。
  • チームの状態
    • ストレートに聞いてしまったときです
    • タックマンモデルで言う混乱期で何度か設定しました。
  • リモートワーク
    • 元々一部メンバーがリモートワークで、さらにリモートワークするメンバーを増やした直後に設定してました。
    • リモートワークを始めてからまだ少ししか経っていないので、度々出てきます。
  • pull request
    • タックマンモデルで言う統一期に入り始めくらいに設定しました。
    • 仕様が決まり、実装を頑張るフェーズに入る前だったので、レビューが効率良くなるよう事前に問題点を潰したかったためです。
  • 他
    • 情報共有(必要な情報は探しやすくなっている？)
    • 情報共有(お互いの作業の仕様など伝えられてる？)

GoodとBadのみ

よくあるKeep,Problem,Tryではなく、GoodとBadを使っています。
なるべく感情を出してもらいたいという意味で実際にはもう少し言葉は変えてますが。 それぞれこんなことを書いてもらっています。

  • Good
    • うまくいったと感じたこと
    • 感謝
    • お祝い
    • 他メンバーのいい動き
  • Bad
    • 言いたいこと
    • 直したいところ
    • 心配なところ

メンバーに気をつけてもらうこと

書きたいことを書く

私がマネジメントで大事にしていることの一つに 言いたいことを言う というのがあるんですが、 振り返りでも同じで、ちゃんと書きたいことを書くということを気をつけてもらっています。
それを書いたことで議論が勃発する可能性もありますが、 黙って抱えていることのほうがずっと良くないのでなるべく書いてもらうようにしています。

書くべきことを忘れない

バランスを読み取るためにはある程度の付箋の枚数が必要です。
ただ、枚数を出すこと自体が大事ではなく書くべきことが書かれないのが問題です。
2週間という長い期間だと、前半のことは忘れがちなので、工夫して忘れないようにしましょう。
うちのチームでもこの辺いろいろありましたが、今ではチーム用のtimesチャンネル作ってそこにポストしてもらってます。

無理に枚数を書いてもらう必要もないですし、枚数のノルマを設けているわけでもありません。
あくまで、書こうと思ってたことがあって、それを忘れてたらもったいないよね。という話です。

チームの状態を読み取る

GoodとBadそれぞれの付箋の枚数とバランスからチームの状態を読み取ります。
付箋は事前に書いて貼ってもらっておいてもらいます。
そんなに細かくは分からないですが、ざっくりとチームの状態を知るには十分です。

ここで注意が必要なのは日本人はあまり人を褒める文化がないということです。
なのでどうしてもGoodの数が少なくなります。
そこを考慮にいれた上で考えます。

また、もう1つの注意点としては、小さい声でも耳を傾ける必要のあるものはあるということです。
付箋の枚数とバランスで全体を見ることはできますが、個人の状態までは分かりません。
仮にチーム全体がうまくいっていたとしても、個人単位では問題を抱えていることもあるかもしれません。

Goodの付箋の枚数 >> Badの付箋の枚数

Goodが大幅に上回っているときです。
この状態なら絶好調と言えるでしょう。
ただ、あまりこの状態を見たことはないです。

Goodの付箋の枚数 > Badの付箋の枚数 or Goodの付箋の枚数 = Badの付箋の枚数

Goodが少し多いか、同じくらいのときです。
大抵のメンバーがうまく回っていると思っているはずです。
この状態をキープしたいです。

Goodの付箋の枚数 << Badの付箋の枚数

チームの状態が悪いときです。
本来は、ここまでになる前にマネージャーとして何か手をうつべきです。

メンバーに伝えるかどうか

チームの状態をみることは大事ですが、それをチームメンバーに伝えるかどうかは チームの成熟度によると思ってます。

私はチームができた直後はそもそもそこを見ていることも伝えてませんでした。
今ではもう前述のような読み取りをしていることも伝えています。

最初からやり方を知ってしまうと、意図的にGoodを増やそうという意思が働いて 本当の状態よりも良い状態だと思われるからです。
それを考慮した上で読み取り、伝えてもいいんですがね。

まとめ

  • 振り返りはチームの状態を知るために使える
  • 書きたいことをちゃんと書いてもらう
  • メンバーにどこまでやり方を伝えるかは考える

関連記事

kkkw.hatenablog.jp

Docker内でGithubのプライベートリポジトリのdepを解決する

Golang Docker

goのパッケージ管理ツールのdepに 自作のプライベートリポジトリを登録している状態で Docker上で、dep ensureすると Githubの認証に弾かれます。 それを解決する方法です。

基本的には dep公式のFAQに書いてある通りです。 depは、 .netrc を頼りにGithubの認証を解決するので、これをDockerfileで作って上げます。 ただ、FAQに書かれているフォーマットは

machine github.com
    login [YOUR_GITHUB_USERNAME]
    password [YOUR_GITHUB_TOKEN]

ですが、これだとうまく行かなかったので

machine github.com
    login [YOUR_GITHUB_TOKEN]

という形にしています。

Dockerfileはこんな感じになります

FROM golang:alpine

RUN apk --update add tzdata git && \
    : "depのインストール" \
    mkdir -p $$GOPATH/bin && \
    go get github.com/golang/dep/cmd/dep

ADD . /go/src/github.com/foo/bar
WORKDIR /go/src/github.com/foo/bar

EXPOSE 8080

CMD  echo machine github.com > /root/.netrc && \
     echo login [YOUR_GITHUB_TOKEN] >> /root/.netrc && \
     dep ensure -vendor-only

生成するGithubトークンのパーミッションは、 repo にだけチェックがついてれば十分です。

composer.lockのhashがコンフリクトしたとき

PHP

毎回調べてるのでメモ

git管理しているcomposer.lockがコンフリクトし、
かつそのコンフリクトの内容がhash, content-hash だけだった場合は、 そこを更新しなおすだけで良いです。

git checkout --ours composer.lock
composer update --lock

上記では --ours でcheckoutしてますが、どっちの内容残しても結局更新し直すので --theirsでも問題ありません。

phpmdでFileCacheDriverのエラー

PHP

自分用メモ。
vagrant環境で、phpmdを走らせててエラーが発生しました。
原因は、vagrantのhdの容量不足でした。

エラー内容

下記のようなエラーが大量に流れてて、
原因が分からずしばらく悩みました。
細かいエラーメッセージはちょっとずつ違いますが、
共通しているのはFileCacheDriverでエラーを起こしていることです

PHP Warning:  fopen(/home/vagrant/.pdepend/4q/4q542z177ea.5.6.cache): failed to open stream: No such file or directory in /path/to/vendor/pdepend/pdepend/src/main/php/PDepend/Util/Cache/Driver/FileCacheDriver.php on line 163
PHP Stack trace:
PHP   1. {main}() /path/to/vendor/phpmd/phpmd/src/bin/phpmd:0
PHP   2. PHPMD\TextUI\Command::main() /path/to/vendor/phpmd/phpmd/src/bin/phpmd:122
PHP   3. PHPMD\TextUI\Command->run() /path/to/vendor/phpmd/phpmd/src/main/php/PHPMD/TextUI/Command.php:173
PHP   4. PHPMD\PHPMD->processFiles() /path/to/vendor/phpmd/phpmd/src/main/php/PHPMD/TextUI/Command.php:133
PHP   5. PHPMD\Parser->parse() /path/to/vendor/phpmd/phpmd/src/main/php/PHPMD/PHPMD.php:222
PHP   6. PDepend\Engine->analyze() /path/to/vendor/phpmd/phpmd/src/main/php/PHPMD/Parser.php:123
PHP   7. PDepend\Engine->performParseProcess() /path/to/vendor/pdepend/pdepend/src/main/php/PDepend/Engine.php:323
PHP   8. PDepend\Source\Language\PHP\AbstractPHPParser->parse() /path/to/vendor/pdepend/pdepend/src/main/php/PDepend/Engine.php:575
PHP   9. PDepend\Util\Cache\Driver\FileCacheDriver->store() /path/to/vendor/pdepend/pdepend/src/main/php/PDepend/Source/Language/PHP/AbstractPHPParser.php:403
PHP  10. PDepend\Util\Cache\Driver\FileCacheDriver->write() /path/to/vendor/pdepend/pdepend/src/main/php/PDepend/Util/Cache/Driver/FileCacheDriver.php:151
PHP  11. fopen() /path/to/vendor/pdepend/pdepend/src/main/php/PDepend/Util/Cache/Driver/FileCacheDriver.php:163

容量を喰う理由

phpmdを走らせると、依存ライブラリのpdepend がhome配下に、.pdepend というディレクトリを作り、
そこにファイルのキャッシュを溜め込みます。
このディレクトリの容量が増え続けるので、容量が足りないと正常に実行できません。

検証ファイル数が膨大というわけではないですが、 最終的に500M程度の容量が必要でした。