主夫ときどきプログラマ

データベース、Webエンジニアリング、コミュニティ、etc

じぶん Release Notes (ver 0.41.8)

自分リリースノート

Shibuya

2ヶ月ぶりのリリースノートである。

手応えのあることをやってきたかというとそうでも無く、かといって何もしていないわけではない。やることはたくさんあり、気になることもたくさんあり、やりたいこともたくさんある。というようなことを思いつつ、前回のリリースノートを見ると同じようなことが書いてあった。今のポジションのまま仕事を続けるのであれば今年1年もそうなんだろうなと予感しかない。

じぶん Release Notes (ver 0.41.6) - 主夫ときどきプログラマ

今日は東京出張。冒頭の写真は適当に撮った渋谷。写真生成AIはすごいみたいだけど、興味がないので自分で写真を撮りたい。My Cameraは妻にほぼほぼ占有されてしまっているので、ここら辺で新しいやつ買っちゃおうかなと思いつつ、大きい買い物をしてストレス発散したいだけでは?と自問自答してしまっている。PENTAXを愛好しているが(他を知らない)新機種があるわけでもないのでそれも迷いどころ。15年ほど前の一眼レフカメラK20Dでも写真は綺麗にとれるのよね。

Work

年末に振り返りのスライドをつくった

年末の納会的な集まりで、開発チームの代表として全メンバーの前で一年間の振り返り的な話をした。プロダクトの変わった部分や組織として変わった部分、そのなかで進めてきたの様々な取り組みをその成果を目的と交えて紹介した。 持ち時間でしっかりおさめる感じは自分を褒めてあげたい。

その日を最後に現場を離れる方もいたので、たくさん褒めて送り出した。一緒にやってた1年ですごく成長したし、今後の伸び代もあり期待できる優秀な人だったので、個としても人材としても離れてしまうがすごく悲しい。けどそういう人材に選んでもらえなかった現場なんだよなぁっていうところがまだまだだなぁと感じるところ。

改めてのプロダクトマネージャー

昨年3月にプロダクトマネージャーという肩書きを拝命したものの、実際にやっていたことはプロジェクトマネージャーのそれだったり、エンジニアリングマネージャーのそれだったり、テックリードのそれだったりで、プロダクトを作る部分に近いところの課題にひたすら向き合ってきた印象だ。

そもそもプロダクトとして何を作るのか、の部分の決裁権がほぼない状態だったので、できることをやっていたらそうなったというのが現状だろう。そんな中で、気になるとこに手を伸ばし介入し対処し次へ行く、ということを繰り返していたが、代表からも特に何も言われなかったので、それなりの信頼と評価をもらっている。

で、今年に入ってからその辺のところ、組織編成と肩書と権限と責任範囲が整理され全体的に明示された。ので、今年は名実ともにプロダクトマネージャーとしてやっていくことになった。プロダクトをどういう方向に導いていくか、作っていくのかを決める権限と責任が与えられたので、ますますやることと考えることの範囲が広がった。

やる気に満ちている、と言いたいところだが課題は山積しているので、こなしていくしかない。

組織開発

ワークマネジメントの方は整備されてきているし、新しいやり方にも慣れてきている。その辺りの部分が得意な人たちがリーダーポジションに配置されたので、全体としても開発自体がうまく進んでいる。一方でピープルマネジメントの部分はまだまだ不足している。プロダクトチーム全体でのマインドセットを作るところ、チーム内・外における共通言語の醸成を今年はより進めていかない。あわせてチーム内の関係性強化と組織効力感を高める部分が一年を通してやりたい部分だ。

言語化を頑張る

考えることが多い。多いので、情報に溺れてしまいそうになる。色々な場面でもやもやすることも出始めている。そのもやもやを放置しても解決にならないし前に進めないので、まずはそれらを言語化しないといけない。また、関係者がビジネスチームとプロダクトチームの多岐に渡るので、そこから拾った情報を整理するためにも、構造化とあわせて言語化する必要がある。

なので今年は定期的に今の状況を言語化していくことを頑張る。定期的に言語化する時間を確保するのだ。

認知負荷の問題

今のプロダクト開発の状況は、なんだかいろいろと考えることが多くて面倒事がとても多い。認知負荷についてちょっと学んだので、その文脈で面倒ごとを分析・分類してみた。課題の内在性と外在性、煩雑さと複雑さ、を俯瞰してみることで考えもクリアになったし、解消できそうな部分が見えてきた。複数の仕事を同時にやると、コンテキストスイッチに時間がかかり効率が悪いという話はよくある話だが、その辺も認知負荷を考えるとよく理解できる。自分の仕事の進め方にも応用できそう。

ピープルマネジメント

チームビルディングのための取り組みを昨年はいろいろやっていたけど、しばらくお休みしている。組織編成が少し変わり(主にリーダー層)、仕事の進め方やコミュニケーションをとる相手もかわり、多かれ少なかれ全員に影響があったので、まずはそこに慣れてもらう必要があった。
そろそろ慣れてきた感じもあるので、チームビルディングについても取り組みを始めようと思う。

今年は組織効力感を感じられるようにするのが目標で、そのためのマインドセットの醸成とチーム内での関係性の強化を図りたい。とあるチームでは独自の取り組みとしてWorkingAgreementsを作成し、振り返りの中にも取り込んでおり良い影響がでている。まずはそれを全チーム向けに展開してやっていく。

Life

  • プロダクトマネージャーの仕事
  • チームトポロジー
  • 多様性の科学

最近買ったのはこの3冊。この1年はマネジメント関係の本ばかり読んでいる。「プロダクトマネージャーの仕事」はHowの部分について書かれているのが多い印象。他に「プロダクトマネジメントのすべて」も読んでいて、こちらはWhatの部分が体系的・網羅的に解説されている印象。プロダクトマネージャーをやるならどちらも読んだ方がいい。

チームトポロジーも参考になることは多いので、チームビルディングに活かしたいところ。コンウェイの法則はちょっと知っていた程度だったので、まとまった内容を読めてよかった。ただ、いまの自分たちの状況に当てはめると、プロダクトの構造がつぎはぎな部分と

多様性の科学は手をつけられていない積読状態なので春頃には手をつけたいところ。

山に登りたい

昨年は夏に甲斐駒ヶ岳仙丈ヶ岳に登る予定だったが、台風が来てキャンセルとなってしまった。他をふりかえっても全然山に行けていない。3月にキャンプには行った気がするが雨で寒かった。

今年はもっと気合を入れて山に登る計画をたてよう。今勝アルプスや鈴鹿山脈あたりに足を伸ばすのが今年の目標。子供達もキャンプに行きたいというし、どやらキャンプブームも去ったようなので、キャンプ場もきっと空いていることだろう。

じぶん Release Notes (ver 0.41.6)

masayuki14(ver 0.41.6)がリリースされました。更新内容は下記のとおりです。

とくに忙しいわけでもなく、とはいえやることは沢山あり、いろいろなことを少しずつこなし、いろいろなことを少しずつ進めてきた、そんな1ヶ月だった。なので、これといったものが思い浮かばない。 そう言いながらも、頭の中は仕事のことが何かしら巡っている状態で、直したいところばっかりが目について、あれもこれもやらないと、と堂々巡りしている。頭が休まっていないのだろう。

ここ2週間ぐらい風邪気味で、鼻周りがずっと調子が悪い。早く寝てちゃんと休め、と他人なら言うのだが、なんとなく夜更かししてしまう。お酒も飲んでしまう。ストレスがたまってるんだろうか。

パパ友にソロキャン行こうぜ、と誘われたので計画しよう。子供も大きくなり習い事などで家族キャンプができていないので、一人ででも行ってこようか。

Work

開発プロセスの標準化

開発組織全体での開発プロセスの標準化をしたいんだけどなかなかうまくいってない。これまでに品質が安定せず、開発の進め方も属人性が強く、障害もよく起こっていた経験があった。それを改善するために、開発プロセスをマニュアル化し、ドキュメントとテンプレートに落とし込み、プロセスとして複数人でのレビュー体制を整えて、さぁこれ通りにやってごらん、と、各チームのリーダーさん、よろしく頼むよ、と。そんなふうに進めてきた。

プロダクトを良くするため、品質を良くするために進めていた開発プロセスの標準化であった。が、意思の統一が全体でできておらず、うまく徹底できず一部でしかまともに運用されるに至らなかった。人間は変化を嫌うものだし、推進する部分を他の人に任せてしまうとうまくいかないですね。

なので、いまは自分で各プロジェクトに顔を出して、やってねやってね、こうやるんだよ、というのを伝えていっている。山本五十六の「やってみせ 言って聞かせて させてみて ほめてやらねば 人は動かじ」ってのは本当にそうだなぁと思う。

プロジェクト共有のミーティングをはじめた

いろいろなチームやプロジェクトがあるが、各所で何が起こっているか、何を作ってリリースしているかというのが全体に共有できていなかった。なので共有する場をつくった。毎週決まった時間にエンジニアリングメンバー全体を集めて、プロジェクトの担当者にプレゼンで情報共有してもらうようにした。

ミーティングは発表者がなにかしらの利益を得ること、全員が参加者となることを重点にして設計している。またの機会にまとめようと思う。

アドベントカレンダー

エンジニアとして発信すること、学んだことや考えたとをアウトプットすることは大事なことだと思うのだけど、そういう行動をとる人は決して多くない。でも、やはり、やった方がいいので、なかば強制的にアウトプットする機会を作ることにした。

社内でアドベントカレンダーをやろうという案が出たので様子を見ていたところ、5〜6人しか主体的に手を挙げなかったので、強制的に全員をカレンダーに振り分けて、業務としてやってくださいということで進めている。
意外とみんなちゃんとやってくれていて、自分にとっても記事を書くいい機会になった。人に読まれることを意識して文章を書くことはとても大事なので、その辺も皆に意識してもらえるとよい。

顧客に会いに行く

CSチームの協力もあり、開発しているプロダクトのユーザーの企業を訪問した。実際に使っているユーザーと直接会話をすることで、プロダクトに対する考え方も変わるし、自分自身のプロダクトについて考える時の視点も増えた。CSチームや文章に変換されたものから伝え聞く内容と、直接会話して得られる内容では情報量がちがうので、ユーザーと接点をもつことは大事だ。
ただ、ユーザーは他にも大勢いるので、変なバイアスがかからないようには注意したいところ。

SlackでTODO管理

timesチャンネルが普及してきた。あってもなくてもどっちでもいい派ではあるが、いざ自分用のチャンネルがあることで、そこにメモしてみたり、ぼやいてみたり、思考の吐き出し場所として良い使い方ができている。SlackのUIが変わって、BookmarkをTODOのように使うのに良い感じなので、毎朝溜まったBookmarkの確認をして、タスクの整理をしている。
ただ、情報を集めることと情報をまとめることを同時にSlackではできないので、その辺が面倒くさくなっている。Botでさーっと集めて加工して times に出力できるといいんだけどなぁ。作るしかない。

Life

伊藤若冲

伊藤若冲の企画展が開催されていたので、相国寺に行ってきた。書き込みも緻密だし、色使いや構図が秀逸、なんだと思う。鶏もたくさんいたけど、花の絵が好きだと思った。

若冲錦市場にあるどこかの商店の主人だったらしく、早々に弟に家督を譲って隠居し、好きな絵を好きなだけ描いていたらしい。当時の絵師は武家や公家に抱えられて依頼された絵を描くのが一般的な時代で、好きに絵を描くことはなかなかできなかったようだ。しかも画材も高級品なので、若冲のように好きなだけ自由に絵をかけるような人は稀だったそう。いつの時代もお金がたくさんないと芸術は育たないのだなぁということだ。

相国寺も拝観し、法堂の天井に描かれた蟠竜図も素晴らしかった。紅葉はまだだった。

www.shokoku-ji.jp

サッカー主審

少年サッカーの大会で主審の笛を吹いた。初めてだった。学生の時に試合の笛を吹いたことはあるものの、ずいぶん前なので始まる前は緊張していた。始まってしまえば大したことなかった。

少年サッカーだと副審がおらず、主審がタッチラインオフサイドの判断をしないといけないので、その辺は難しいところだった。視野的にむりだろ、って感じ。今後シニアの試合でもやることはありそうなので、練習試合などでも笛を吹いていこうと思う。

Kyoto.rb

久しぶりにKyoto.rbにいってきた。大阪のfreeeオフィスでの開催ということもあり、大阪のRubyistもいた。久しぶりにお会いする方もいて、懇親会も楽しかった。

懇親会で同世代の人とはなしたが、みんなこぞってマネージャーになっていて、「みんなマネジメントやりたがらないし、年齢的にも立場的にも自分がやるしかないよな」という覚悟のようなムーブもいっしょで「でもコード書いていたいし、開発者に戻るのが夢なんだ!!」というのも共感しかなかった。

仕事をどうやって任せるか、誰に任せるかというところで、コミュニティに出入りするエンジニア -> 10〜20人に一人、マネージャーになってもいい人 -> 10〜20人に一人 自分の仕事を引き継がせたいと思える人 -> 10-20 x 10-20 -> 100人〜400人に一人、なので、規模を大きくしないと仕事を任せられる人材が出てこないのでは?という意見があった。
コミュニティに出入りするかどうかはともかく、エンジニアリングが好きな人は希少なので、小さい会社がどんどん潰れてそういうエンジニアが野に放たれて大手に集まる方がいいんじゃないか、という考えもあった。

似た悩みを抱えている人たちがいて、それはそれで安心した。

kyotorb.connpass.com

DevOps本とReact本を買った。DevOps本を中心に読んでいるのでReact本はまだあまり読めてない。

エンジニアリング組織ついて書かれた書籍をいくつか読んできたが、チームビルディングの文脈やエンジニアリングとマネジメントの文脈と同じような内容が書かれていた。ただ、いろいろな手法や分析のような内容には示唆に富んだものが多く、組織づくりの参考にできる部分は多いので、買ってよかった。

React本は最近の動向のキャッチアップのために買ったので、流していい感じに読んでおきたい。今年発売されたものなので内容は新しいし、冒頭を読んだ限りはわかりやすい構成だった。

セキスペ

更新のためのグループ講習を受けた。オンラインだったので参加自体は楽ではあったが、やはり初対面の人たちとオンラインでグループ課題を進めるという難しさはあった。ただ、みなさん同じようにベースの知識はあるし、思考力や表現力もあるので会話や議論自体はやりやすかった。

グループ課題の発表もそれぞれのグループの発表者はうまいことやっていて、みんな優秀だしそれぞれの企業で要職についているんだろうなぁという感じだった。 ただ、みんなセキュリティ関連の仕事をしているわけじゃないとのことなので、どうなってんだ?感はある。

落語

近所で落語が聞ける機会があったので小学生の息子と行ってきた。息子はえらく気に入ったようで、また行きたい、また行きたい、と言っている。1ヶ月ほど経ってもまだ熱が冷めないようなのでまたいこうと思う。

かけられたネタは「転失気」と「親子酒」だった。若手がでる場所だし上方落語なので「芝浜」とか「死神」を聞く機会があるかはわからんが、やっているうちは定期的に足を運びたい。

じぶん Release Notes (ver 0.41.5)

masayuki14(ver 0.41.5)がリリースされました。更新内容は下記のとおりです。

平常運転の1ヶ月であった。子供の運動会やサッカークラブのレクリエーションなどのイベントもあり、スポーツの秋という感じ。

地元で大きめの法要があり、子供たちが稚児行列に参加した。東京にいる親戚に会うこともできて良いイベントだった。ついでに甥っ子たちとリニューアルした恐竜博物館へ行き、久しぶりに旅行気分を味わえた。

事務所用の物件のDIYがやっとひと段落し、引っ越しすることができた。まだDIYする部分は残っているものの、仕事専用の場所ができ、仕事すること以外は何もできない状態なので、集中して仕事ができる。その分自宅の一部屋が空いたので有効活用していきたい。

しごと

人が減った

人が減り、人が減って、人が減った。半年前と比べ5〜6人増えたくらいだが、顔ぶれは随分と変わった。全体としてのスキル平均値は上昇したと思う。そのため組織全体にたいして考えることが減った、一方でより基準や水準を上げるために解消していかないといけない課題がたくさんあり、それらをどうこなしていくかをこれから考えないといけない。

チーム単位での様子を見ると、人が減ったおかげでシニアメンバーの負担が減り、より開発に集中できるようになっているし、メンバー間の連携や相互理解も深まってきているので、そういう意味では良い規模感に落ち着いたとは思う。

コミュニケーションとコラボレーション

これからの開発の方向性としてデザインエンジニアリングを重視したいというものがある。企画、検証、開発、テスト、リリースというようなフェーズでの分断を減らし、各メンバーが広くプロダクト開発に関われるようにしていく必要がある。 そのためには開発チーム全体のマインド・文化・行動をもっと理想に近づけていきたいと思っていて、それをするには日々発信し続けないといけない。と思うが、あんまり得意じゃないんだよなぁというのがこの半年の活動で分かったこと。これを越えてかないといけないのは分かっているので精進する。でも資料作ったりプレゼンしたりってMP消費が激しいんだよなぁ。

開発現場のマネジメント

開発の現場にこれまでよりも関わることが増えた。タスク管理に、設計等の上流工程、実装・テスト、など各段階に広く関わっている。自分基準のあたりまえが、チームでは当たり前になっていないので、チーム全体を当たり前の状態に持っていくのがなかなか大変。今までの担当者は何やってたんだよー、と言いたいところだがまぁそれができるような人材が豊富ならこれまでも困っていないわけで。鍛えていくしかないよなぁ。

チーム間のつながりについて

サイロ化してきている。チーム間をつなげたい。定期的に交流の時間はとっているが、はたして。

ペアプロなど

VSCodeのLive Shareを使ってペアプロをやってみた。良い手応えがあった。レクリエーション的にペアプロしながらAtCoderの問題を複数人で解く、というようなことをやった。会話しながらコードを書くのは単純に楽しいものだった。実際の開発でもやっていきたい。
AtCoderもひさしぶりにやったのでそっちも楽しかった。またABCに挑戦して勉強する気になった。

セキスペ

オンライン講習を終え、登録セキスペの更新があった。セキスペで想定されているようなセキュリティ関連の仕事をしているわけではないが、定期的に知識をアップデートするには良い機会にはなっている。ただそれを組織に対して発揮する場面はまだない。
次はオンラインのグループ研修があるのでその準備をしているが、題材となっているお弁当屋さんの設定がけっこう面白くて、ちょっとだけ楽しみである。

筋トレ

最近は週2〜3のトレーニングを継続できている。夏場に落ちたと感じていた筋力も戻りつつある。1年近く体重が変わっていないので、そろそろやり方をかえて増量を目指すか、現状維持を続けるのか、というところだがまぁ現状維持でいいよね。

リーダー、マネジメント、組織、みたいな本ばかり読んでいたのでだいぶ飽きてきた。フロントエンドのリファクタリングのプロジェクトも進んでいて、そろそろ最近のReact界隈のキャッチアップが必要なのでそのへんの技術書を探している同じようにSRE、DevOpsの部分が弱いのでその辺の体制を考えるための書籍も探している。

仕事が忙しい時は、空いた時間に漫画しか読む気にならなかったけど、仕事が落ち着くと技術書が読みたくなるので不思議。やっぱり余裕がないと勉強する気にもならんよなぁ。

じぶん Release Notes (ver 0.41.4)

masayuki14(ver 0.41.4)がリリースされました。更新内容は下記のとおりです。

8月下旬に大きめのリリースを終え一段落。リリース後にバグが出てしまったのでそれの対応やら体外的な対応やらなんやらがあったが、これまでに比べたら久しぶりに落ち着いた時間を過ごせたと思う。

そろそろ暑さも落ち着きそうだから秋山登山にいきたい。

しごと

4月以降増え続けた開発者は約倍になり、8月以降4人単位でユニットを組んでいろいろな仕事に取り組んできた。ジュニアメンバーがシニアメンバーのフォローを受けながら仕事を進めるので、ある程度予想していたことだが、パフォーマンスは下がりシニアメンバーの負荷が上がってしまった。そもそも一時的な増員ではあったため、段階的にメンバーを減らし、だいたい4月時点での人数に戻っていきそう。残るメンバーは技術スキル的にソフトスキル的にも信頼性の高い人達なので以前よりはちゃんとした開発はできそうだと思う。

この2,3ヶ月は現場との関わりが少なくなっていたけど、今後はジュニアメンバーの人数も減って、考えることも減りそうなのでもっと現場に入っていこうと思う。コード書く機会も激減しているので、コード書く仕事を勝手に作って勝手にやる予定。

新しいPC

ThinkPadUbuntuをいれて使っていたけど、Varlorantやろうぜということでもう一度Windowsを再インストールすることにした。
が、事前に作成していた回復ドライブではWindowsのインストールはできず、インストール用のISOイメージを使ってのインストールもできずだった。最後にLenovoが配布しているRecoveryToolで工場出荷状態に戻すことでWIndowsの再インストールに成功した。

RecoveryToolを作るにはWindows環境が必要だったが持ち合わせてなかったので、またUbuntu入れてVirtualBoxWindows入れて、その中でRecoverToolのメディアを作って、そんでやっとThinkPadWIndowsがインストールされた。

Valorantをやってみるけど、はたしてゴールであるデュアルブートはできるんだろうか。

勉強会

久しぶりに読書会に参加した。課題図書はリーダーの作法で、前から気になっていたのでこれを気に購入して参加した。リーダーといっても色々あって、マネージャー、ディレクター、エグゼクティブのリーダーシップについて書かれているので、このままマネジメントを続けることを想定すると、どれも役に立ちそうな内容である。

勉強会には同じような立場で仕事をしている人が集まっているので、本の内容よりも実体験も交えたディスカッションが楽しい会になった。2,3回目に参加できてないので、今月の4回目にはまた参加したい。

hannari-python.connpass.com

サッカー

京都サンガのホームゲームにも3回行ってどれも勝ち試合だったし、推しの武田も怪我から復帰したし良い傾向だ。

自分が所属するシニアチームの公式戦でCBながら1点取って攻守両方で勝利に貢献したし、サッカー関連は良いことばかり。

そして子のサッカークラブのコーチに就任したので、たぶんいろいろ勉強しないといけない。 今までは子の練習の様子を頭から全部見たことなかったし、見ていても遠目だったので実情はよくわかっていなかった。そもそもクラブ自体は保護者やOB/OGの保護者がボランティアでコーチや運営をしているので、ちゃんとした指導者がいる訳では無い。想像していたよりも、子どもたちの扱いや練習がうまくいってない印象だった。まずはこどもたちと信頼関係つくるところからかなぁと思っている。マネジメントに大人も子供も無いと思うので、そのへんは仕事と同じように試してみたいなぁと言う感じ。

じぶん Release Notes (ver 0.41.2)

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やはんなりプログラミングの会などコミュニティ活動に参加したいし、どっか遊びにもいきたい。