masayuki14(ver 0.41.0)がリリースされました。更新内容は下記のとおりです。
慌ただしく日々の仕事をこなしているせいか、1ヶ月たつのがあっという間に感じる。近年はわりとマイペースで仕事してきてたので、今のようにいろんなステークホルダーからの要求を考えながら仕事をするのはやっぱり大変だなぁ、と思う。
なのでここ最近で増員されたキャリアのある人たちに仕事任せられるようにしていって、自分が何もしなくてもいいような形にしていきたい。増員された人たちのこと全然わかってないので、まずは知るところから始めよう。
やばい！仕事のはなしばっかり！やばい！京都サンガ全然勝ってくれない！やばい！FujiRockも配信されなかった！
しごと
PdMになって約5ヶ月がたったのでざっくりとふりかえってみよう。 マネジメント対象だいたい以下の4つで、それぞれについて何をやったかを考える。
- プロダクトマネジメント
- プロジェクトマネジメント
- テクノロジーマネジメント
- ピープルマネジメント
プロダクトマネジメントとプロジェクトマネジメント
プロダクトオーナーが何を作るかをきめるのでそこの承認権限もなくPdMって感じでもないが、どう作るかについては権限を持っていたので狭義にはPdMをやっていた、というのが実際のところ。
そのなかでプロダクトというよりはプロジェクトのマネジメントをすることが最初の2〜3ヶ月ほどは中心になっていた。タイミングを同じとして始まったプロジェクトが2つあり、そのまま担当する流れでもあった。
コミュニケーション重要
営業側で作成された要件定義をもらうところからプロジェクト（開発）はスタートしていた。その時点では開発と営業の間でコミュニケーションを重視する土壌がなかった。プロジェクトは進んでいたが終盤にさしかかったところでいろいろな認識の齟齬や問題が発覚し、やっとその時点でお互いに密にコミュニケーションをとって、必要な限りステークホルダーも巻き込んで、全体でプロジェクトがゴールに近づけるようにしないといけないという事に、全体が気付いた。
自分も含め、個人単位ではそういうところに課題を感じていたり、「普通やるでしょ」という感覚のことができていない状況を良しと思っていない状況ではあったが、それが全体の共通認識になっていないと解決されることはない。それに全体が気付いて、次の行動に移せるようになっていったのでよい学びになったしチームとしては強くなったと思う。
その後、開発者だけのDailyミーティングには営業のメンバーも参加するようになったし、お互いの課題や問題を共有する動きができようになった。
また、開始時点でのキックオフのミーティングがないまま進めていたところも良くなかった。開発側にプロジェクトの背景、目的、ステークホルダーとの関係性などのコンテキストの説明がないまま「これやっておいて」的なスタートだったので、プロジェクトを進める理由が外発的動機づけのみなっていた。これが仕事なんでやってください、っていうそれだけ。そうなると言われたことだけやっておく、という意識になってしまい不確実なものへ対処する柔軟性が失われてしまう。納得感もなく非現実なスケジュールだけを言い渡されても、それをまっとうしようという気にもならないし、個人的にもプロジェクトマネジメントとしてそれを開発者に押し付ける気もなかった。
期限間近になっていろいろと揉めたけど、結果的にそいうことが必要だということも全体として認知してもらえたのでその辺りも改善された。
チーム運営
これまでは一人のマネージャーが、個人に対してタスクをアサインしていたけど、自分の担当プロジェクトではそれを完全にやめた。今回のプロジェクトではタスクをチームとして取り組むようにした。要件から仕様に落とし込んでいく作業も、設計も実装もテストも基本的にチーム全体で取り組んだ。そうすることで開発プロセス全体にチームメンバーがもれなく関わり属人化を低減させることができたし、相互にフォローする文化を作ることができた。
また、自分は完全に開発作業からは手を引いて、各タスクのゴール設定と目的の明確化をするようにした。ゴールまでのプロセスはメンバーに任せ、それを定期的にレビューし方向修正しつつメンバーが自発的に動ける環境やしくみづくりに注力した。
その結果、このプロジェクトが終わった後にはそれぞれのメンバーの行動は大きく変化したし、自由を得た彼らはそれぞれ別のプロジェクトでリーダーとして動けるようになっている。元々の資質はあったにせよ自信を得てくれたようだし、自分のやり方も間違ってなかったという結果がでたので、今はこのやり方を全体に広げようとしている。
得られた知見
チーム全体のこと
- プロジェクトに関係する人たちが所属（営業や開発など）を超えて協力しよう
- プロジェクト開始時にその背景や経緯などコンテキストを共有しよう
- 外発的動機付けとあわせて内発的な動機付けも行おう
- 個人ではなくチームとしてタスクに取り組もう
- ゴール設定を明確にし、プロセスの決定は開発者に任せよう（ただし委譲の程度は相手によって調整はひつよう）
- チーム内で相互に協力できるような土壌をつくろう
個人的なこと
- 「普通」や「あたりまえ」の感覚を共有するのは難しい
- それらをいかに揃えるかがマネジメントの仕事
- 自分の感覚を信じればある程度うまくいきそうなので、それを広めて積み上げていくことが必要
テクノロジーマネジメント
コードレビュー
コードレビューをかねてから行ってきていたが、人数も増えやることも増え、コードレビューに割ける時間がなくなってきて、そこで開発が止まってしまうことが多くなってきていた。コードレビューについてのドキュメントは整えていたし、レビューの観点は記してあるものの、ジュニアなメンバーは守られていないことも多く、レビューに多くの時間を要していた。コードレビューの目的として「レビュアー、レビュイーが協力してより良い状態をつくること」「コード全体が今よりも健全でBetterな状態になること」「継続的にコード全体が改善されていくこと」の3つを謳っているが、このままだとただのエゴの押し付けになってしまうなぁという懸念もあった。そいうことが重なってきて、流石にやり続けることが難しくなりやり方をかえる必要がでてきた。
はじめはチーム内でレビューをしてから最終コードレビューの依頼をしてね、という事にした。目的としては「事前に初歩的な指摘はクリアした状態にしたい」というところ。これにより多少の改善は見られたが、レビュアーとしてのスキルをはじめからみんなが持っているわけではないし、レビュー内容も個人でのばらつきが大きく望んだ状態にはならなかった。
次にやったのが、ベースレビュー、リーダーレビュー、エキスパートレビューの三段階にわけること。それぞれのレビューで満たすべき観点と担当者を決めてレビューを行い、順に進めていって段階的にコードの質をあげることを目的にしている。最後のエキスパートレビューを自分が行うようにした。この部分もできる人員を増やし、最終的にはコードレビューから手を引くのがゴール。
前提としてチーム単位での動きが全体に広がっていっていることと、キャリアとスキルが揃ったメンバーが増えてきたことがある。そのおかげで上手くコードレビューがまわりだして、全体のクオリティが上がる結果につながってきている。
おかげで次はチーム全体での設計思想やアーキテクチャをどうやったら統一・標準化できるかということを考えられるようになり、それが次の課題となっている。
コードレビューとフィードバック
コードレビューでのディスカッションや指摘事項がレビュアーとレビュイーの間だけで閉じていて、知見がシェアできず学習する機会が限定されていた。それをシェアして学習とフィードバックがうまくループするような仕組みとして、コードレビューふりかえりを行うようにした。
チームごとに振り返りを実施して、自分たちがレビュアー、レビュイーとして関わったPRを持ちよって発表していく形にしている。全員参加型にすることで見ているだけ、の人が出ないようにしている。
この取り組みは始まったばかりだけど、参加者からは好評いただいているので、今後も様子を見ながらいろいろと試していきたい。
ピープルマネジメント
先のプロジェクトマネジメントでも書いたが、小さいチーム（2〜4人）を作って、その単位で仕事を進められるようにしてきた。必要に応じて権限を異常し、各メンバーが自分で運転している感覚を持ってもらいながらプロジェクトを進めていくことで、自立し自走できるチームになっていった。
というある種の成功体験がえられたので、この方法を開発チーム全体に広げる事にした。少人数のユニットを作り、プロジェクトやタスクはユニット単位で取り組むことを前提にしている。基本的な行動はユニット単位にするので、開発プロセスはユニット全体で進めるし、振り返りななどの各種イベントもユニット単位で行う。各ユニットのリーダーには若手も抜擢しているので、サーバントリーダー的な働きを求めている。まずはユニット内での協力とコミュニケーションを重視して取り組んでもらう。
まだこの取り組みは始まったばかりなのでどう転がっていくか未知の部分が大きいが、自分と周りの役割分担がだいぶ見えてきているので、今後の動きは楽しみではある。
## なんとなくまとめ
いままでマネジメントはしてこなかったものの、マネジメントの書籍は定期的に読んでいた。それもあってマネージャーに対して要求することを厭わなかったし、不満を持つことも少なくなかった。そんなんで今はマネジメントする側になっているので、これまで自分が受けてきたよろしくないことは絶対にしたくないし、時間はかかってもいろいろな取り組みにチャレンジしたい所存。そんで自分が何もしなくてもみんながうまくやってくれる状態にしたい。ニコニコ笑っているだけけのポジションにおさまりたいなぁ。
新しいPC
開発しないことにしたのもあって、いままでどおりのiMacでたいてのことは事足りている。つまり移行できていない。
Varolantやる機運が高まっているが、どうやらWindowsでしかできないみたいなので、Windowsを再インストールしてデュアルブートにしようかなと思っている。
本
子供に国語辞典を買ったついでになんとなくで2冊買った。
以前メディアで紹介されていたのと、サイトがおすすめしてきたので買ってみた。序章 「好きなこと」とは何か？、を読んだだけでだいぶ興味を惹きつけられた。暇があると不安になるから気を紛らわせるために趣味などに時間を使っている、と言う部分、なんかわかる。時間を見つけて読み進めていきたい。
これもサイトがおすすめしてきたので買ってみた。レビューもよさそうだった。こちらもまだ冒頭部分しか読んでいないけど、今まで読んできた書籍とさほど違いはなさそう。いろんな要素のパッケージの仕方が違うという印象だ。悪い内容ではないし、複数の書籍で共通して語られることがだいたいにおいて正解なんだろうと思うので、その辺を意識して読み進めたい。
コミュニティとか娯楽とか
来月はKyoto.rbやはんなりプログラミングの会などコミュニティ活動に参加したいし、どっか遊びにもいきたい。
