// チームでの振り返りなどを受けて更新。2021.02.11
スペック
筆者のスペック：Delphi の人です。業務アプリたるやみたいなことを普段は考えています。
- ERP業務アプリケーション開発17, 8年 (ちゃんと数えられてない)
- 言語：Java, JavaScript (Delphi, COBOL, C++, SQL？, HTML？, CSS？, 趣味では色々
- フレームワーク？：Spring, jQuery,
- 他：Windows, UNIX全般, LINUX, データベースは何でも
で3層構造を主に触って食ってきました。プライベートは1女1男（両方保育園児）の母親業をしています。兼務です。いうなれば副業状態です。
働き方
リモートワークがメインになりもうすぐ1年になります。去年の春先は泣きそうだった記憶があります。主に朝型で生きてきました。慣れすぎて24/365稼働にならないことだけは気をつけたいものの、自分の上司は自分、思い切りチケットを駆逐する。
1プレーヤーとして主に全力でうごける存在を目指していました。
そんな私に転機の2021年、1月です。
大きな変化
良く知れた戦友のひとりのようなマネジャが弊社をご卒業されることになりました。（正確には先月から分かっていたんだが）空いたポスト、残る私 
玉突きが当然というほどの大企業でもなく、若手を大抜擢と言うほどのベンチャーでもなく、
程よい湯加減の弊社。結果、マネジメントをやることにしました。
ワタシ結構ベテランと呼ばれる年なのですが、
ええ年だから敢えてマネジメントはやりません（若手に期待）も良いんだが、
ワーママだからマネジメントはやりません は納得できないな。
、がそれなりにやろうと思った動機です。
とはいえ自覚はあります。戦力というかスペック（主に私起因）堕ちすぎ
私の問題点
- 開発におけるコーディング知識不足（知識が古い）
- 家事育児による時間不足
- 何より、私はわたしの関係性の中で生きていて、前任者とは完全に互換しない。つーか前任者、超できるヤツだった！（厳密には入社年次は後輩なんだけど、そういうの関係ない、尊敬する一人）
意識したこと
でも泣いていても始まりません。泣き落としてとどまる人も別に好きではありません。何人も卒業していく人を見てきました。我々には笑って彼の新しいチャレンジを応援する責務もあります。知らんけど。なので以下、今月私も、チャレンジしたことを書きます。何か、ちょっとした参考になれば幸いです。
朝型
Slackの自分の分報に時報を流しています。お仕事開始します & おわります。
業界全般の課題だと思っていますが、家事育児を担う立場だからこそ敢えて言います。大体の打合せは夜間帯にやる必要はないです。あるいは、開発プロセス上必要とされている会議と、コミュニケーションのための雑談と、用途を明確に分けるべきと思います。朝から働きはじめているメンバーが居るなら、敢えて17時以降は「会議」は避けていきましょう。雑談は夜間帯のほうが盛り上がったりするから、そのへんは自由にやったら良いと思っています！
結果
チーム内のことについては意識づいてきたかなあ。どうかなあ？
やらないことの宣言
18-21時は晩飯、お風呂、寝かしつけ、毎日あります。この時間帯の会議は出ません、と宣言したはずです。
よほど緊急でない限り...
結果
4回ほど結局、会議出た気がします。課題です。
雑談
Slackの分報で、なんとなく自分の思っていることが喋れている？
公共のchannel で呟こうが見てる人数変わらんし何なら検索されたらみんな見られるのに心理的安全性とやらが変わるの結構、人間なんて適当ですよね～。チャンネルの名付け次第というか、レビューって言わず修正にまつわる雑談会とか言った方が会議も絶対発言出ると思っている。
結果
なので、まだまだ「雑談」のチャンスを増やしていきたいなと思っています。 会議ではなく、雑談を。
レビュー方法
ソースコードレビューの「時間」を定例で取るのが難儀。
またすべてのソースに詳しくもないので、以下のようにしました。
Merge Request Approvals
Merge権限を持った者 != その修正ソースに最も精通している者
よって、Approveを使うことによってMerge判断を補う。
1以上のApproveを獲得していないものはMergeしないなどなど。
想定
Developer: その修正の開発担当者
Approver: その修正の評価者、実質最も修正に責任を持つ者。もちろんMergerが兼ねてもよし。つまりディスカッションした上で、Developer以外も誰かしらApproveを出せるところまで理解している状態をつくっておく。ノーチェックでマージすることはしないけど、責任の所在をここに。
Merger: Mergeするひと（主に私）
フロー
Developer: 規定のbranchでWIP or DraftでMR作成。
Developer、Approver、Merger: ディスカッションを完了。
Developer: 作成者がヨシと思ったらWIP外す。
Developer: Approveを仰ぐ <--- ★new
Approver: Approveする <--- ★new
Merger: Mergeする
参考：Github レビューでの Approve / Request Changes / Comment の使い方
結果
うまく行ったかなあ？比較的行ったと思うのだけど、引き続きチェックしていきたいと思います。
会議
質問しやすい雰囲気を常に考える
それでも「レビュー」の時の沈黙って嫌ですよね。
これは私の話術やファシリテーション力にもよるので、がんばります。
オンライン会議のときは「顔」を出す（よほど見せられないナリのとき以外）
上のと同様、うなずく、リアクション多めって、結構大事だと思っています。
会議の前に会議の内容を必ず予習する
これで会議の効率が変わると思っています。質問できない会議は、むしろ参加しなくて良い会議かもしれません。
会議の前に資料を共有する
これも。質問してもらうことをより期待できる会議になるかもしれません。
結果
以上、会議に関しては、チーム外にも波及できるのが理想。来月以降も継続して頑張ります。
目標管理を毎日意識づけてログにとる
ちょっと趣が変わります。1月ということもあり、目標をたてるタイミングでした。
目標は立てただけではなく、日々どれだけ意識して、そこに「草を生やす」ことを継続できるかだと思います。
楽しむ
これは社内のことには使いづらいけれど、こういうツールもあるよねという例：Pixela
どうしたら継続できるのか。継続してがんばります。
このリモートワーク状態のままあたらしい関係性をみんなと構築することのチャレンジ
これは最難関だと思っています。
ともかく、継続することで何かを発見したい。
結果
まだまだ、たったの１ヶ月です。
ペアを作ってお仕事
完全に一人に依存した業務を作らないようにする。
他所からの問合せを滞留させない
ペアで解決する。やり取りが滞ったら「相方」がフォローを入れて強制終了させるもあり。
これから短期的にTryしたいこと
やはりTODO管理が超課題。Slack上でTrelloしたいなとか。
これから長期的にTryしたいこと
安定基盤の保守
短いサイクルで次々とカイゼンを進め、リリースし続けられるチームになりたい、という意識の共有。
エアラインに例えるなら、保守対応として定時運航率を限りなく100%に近づけたい。問い合わせ対応やら不具合修正よりも、機能追加のほうが評価されやすい？そんなことはない。100%をチームとして維持できる状態にして見える化したい。「事故らなくて当たり前、時間通りで当たり前。更においしい食事を提供できて笑顔でこなせたら最高のエアライン」みたいなやつである。
チームメンバーにもむしろいつかこれを踏み台に卒業するあるいはむしろチームリーダーになってほしい。ここで経験したことをどんどん新しいチームに生かせたら理想だと思う。定時運航率を100%に限りなく近づける作業、いかに保守効率を上げるか、良いツールを作るか、テストとビルドを止めないか、あとはその基礎体力をつけるための圧倒的な学習も含め必須。問合せからお客様業務を理解し新機能に還元できる人材を輩出するチームでありたい。
ていうか前任者ー、がんばれよ新天地ー（涙）頑張らないといけないなあー！ 
そんなことを思い続けた1ヶ月でした。
おわりに
以上のようなことって本来自分の心の内々、あるいはせいぜい上司と話せばよくって、あえて開示するのは口幅ったいというか企業秘密をみせちゃうみたいな恥ずかしさがある。しかし部下の立場からすると上司や先輩が何考えてるかって興味津々ですね。こういうのもいいのかなと思って書いてみました。
以上今月の振り返り。面白がって頂けたら、さいわいです。