Posts for: #Team Building

4月1日の月曜日

23時頃に寝て4時に起きて6時に起きた。変な寝方した。私はわりと月曜日は好き。休み明けで元気だから、世の中的には逆かもしれないが。月曜日に加えて、今日は4月1日で新年度とあってさらに新鮮な気持ちになって晴れ晴れしい。

今日の運動は腹筋ローラー,腕立て,縄跳び(両足跳)をした。統計を 運動の記録 にまとめる。

go-ldap のコントリビュート

過去に私がコントリビュートした非同期検索の機能のなかで context によるキャンセルと channel の操作のところで効率のよい方法を提案してくれた方がいた。私が開発していて気付かなかったところをリファクタリングした。指摘されればその通りだと思う。開発していて non-blocking な select 文を書くことに気を取られているとその認識が漏れていたといった程度のリファクタリングになる。ちょうどいま go-ldap ライブラリを使うアプリケーションのデバッグをやっていて、特定のケースにおいてブロックしてしまう現象に遭遇していて、この context と channel の select 文の扱いが参考になった。issue をあげてくれた方に感謝。

アウトプットがない開発者への対応

お手伝い先でフルタイムの新規開発者が1ヶ月たっても機能開発の issue を1つも fix できていない。svelte で新規の一覧画面を作ってもらう、相対的に簡単な issue なのだけども1ヶ月かけてマージリクエストを出せるレベルにはなっていない。そして今日は休暇をとっている。普通の開発者の感覚として、どんな理由があろうと1ヶ月で issue を1つも fix できていない状況は異常だと思う。ほかメンバーだとそれぞれ16と8つの issue を fix している。もちろん開発者によってやっていることや取り組んでいることの複雑さが異なるため、単純に数が多ければよいというわけでもない。そして内容については私が課題管理を介して把握しているので他のメンバーの働き方になんの問題もない。どんな issue に取り組んでいても1週間に1つも fix できないという状況にはなっていない。1ヶ月かけて開発の issue を1つも fix できないというのがどれだけ異常な状況かはわかると思う。明日から出張で経営陣と進捗について話すときに大きな問題の1つとして共有して対策を検討する必要がある。

4次開発の仕掛り

2時半に寝て6時過ぎに起きた。

今日の運動は腕立て,スクワットをした。統計を 運動の記録 にまとめる。

定例会議

4次開発が始まって最初のマイルストーンを終えた。私はプロジェクトマネジメントの業務が残っていて、いくつか調整やドキュメント作成にも時間を割いた。プロジェクト初期からのメンバーは順調に新しい機能開発へ遷移できたように思える。この2人は放っておいても自律的に仮説を組み立てて業務を遂行できるだろう。そして、前の3次開発から参加した新規メンバーのサポートが、今回の開発フェーズにおける私のメイン業務になると考えている。いまのところ、まだプロジェクトや開発に貢献できる状態にはない。お手伝い先の経営陣にお願いして開発以外の業務はすべて剥がしてもらうようにした。これで言い訳ができない状況になったので開発に専念してほしい。

ハニカムさんと飲み会

先日 ハニカムさんの社長とランチ へ行ってきた。今回は社長と cto と一緒に飲みに行ってきた。18時半から始めて3軒はしごして23時半まで飲んできた。楽しかった。精霊の守り人 がおもしろいと教えてもらったのでまた時間のあるときに観てみる。

ざっくばらんにいろんな話しをして、同じ世代なので話しも共感しやすい。いくつかの話題があった中で教育の話しがもっとも盛り上がったように思う。みんな、よいおっさんなので後進を育てることに関心が向く。私もチームの若い子を指導しているのでその経験からの考え方を共有した。教育という分野は政治同様、誰でも一家言あって発散しやすい。飲み会のネタとしては鉄板に思える。縁があればハニカムさんとビジネスで協業する機会があるかもしれない。

提案の説得力

21時半から寝始めて何度か起きながら6時に起きた。昨日は雨降り、且つ移動疲れでしんどくてたくさん寝ることにした。

今日の運動はスクワット,散歩をした。統計を 運動の記録 にまとめる。

会議の準備

6時に起きてシャワーを浴びてから今日の打ち合わせの資料作り。ある程度は作ってあったものの、最終チェックしながら修正していく。9時前まで資料作りをしてオフィスへ出掛けた。

プロジェクトの進捗報告

出張したときの月例報告の14回目。前回の進捗報告はこちら

今回は3次開発を無事完了させたこと、昨日の 大きなふりかえり からみえることの、経営陣向けの私なりの見解や視点を報告していた。プロジェクトの状況について報告した後は、私の気付きや視点の共有、チームの新たな取り組みとしてテックブログを読む会の狙い、今後の予定などを共有した。少し前からメンバーの指導や育成についても経営陣へ向けて私の考えを述べるようになった。その1つとして運用と開発の兼任は不可能だと明確に提案した。その結果、新規メンバーのお手伝い先の組織体制や業務の分担なども大きく変更されて、新規メンバーがフルタイムで開発に参加できるようになった。私は組織を変更したり他業務を見直すことはできないため、これには経営陣の協力が不可欠となる。プロダクト開発はチーム開発をしながら適正な実績を示しつつあるので、私の意見も説得力をもって伝わるようになっていると推測する。そして、私自身も独り善がりや見当違いの施策に陥らないよう、月例のタイミングで私の気付きや考えを経営陣と共有するようにしている。どんな状況であっても、私の目的はプロダクト開発を成功させること、そのために必要なことは何でもやる。自身の保身も見栄もなにもないから自然体で共有している。そうしているうちに、私の雑談から組織も変えていくような話題へ発展したりもしている。

開発完了後の社内向け報告とデモ

いつも開発のイテレーションを完了したタイミングでお手伝い先の全社員向けに新機能の紹介やデモをしている。他チームと連携したり営業さんに向けにプロダクトの現状がどのようなものかを知ってもらうことをこのイベントの目的としている。どんな新機能があるのか、何が出来るのかを社内に伝えないと、チーム外の社員さんがお客さんと話すときに話題にもならない。多くのケースで質問がくるのは開発者からの技術的なものではあるけれど、コンサルや営業さんからお客さんの要件にあうかといった質問も歓迎している。今回は新たに作った一般ユーザー向けの画面の UI や機能などを紹介した。

よい開発文化をもつチーム

今回は寝台列車であまり寝付けなかったのか、fitbit に睡眠時間が記録されていなかった。おそらく2-3時間は寝たと思う。

今日の運動は合宿明けと移動疲れがあるのでお休みにした。統計を 運動の記録 にまとめる。

会議の準備

この3日間で私が主催の打ち合わせが5つある。主題だからそのすべてに私が資料を作らないといけない。もちろん先週から準備はしていたものの、完全ではなく、週末には城崎温泉でいっぱいいぱいになっていて余裕がない状態のまま出張になってしまった。打ち合わせの成否はそれまでにかけた準備時間に比例する。私の持論だ。最低限このぐらいの資料や段取りを組んでやらないといけないという私なりの基準がある。今回はぎりぎりまで資料を作ったり、打ち合わせ内容を練ったりして自身の基準すら満たすのにとてもしんどかった。

定例会議

いつものマイルストーン単位の定例会議。

特定の path 配下の web api にミドルウェアで認証や認可を適用している。こうしておけば認証しなければいけない web api の認証設定を実装し忘れるということが絶対に起きない。一方で未認証の web api もある。/auth/login/status/ping といったものだ。これらは未認証で呼び出せるのでトップレベルの path をわけたい。そうすると、既存のトップレベルに設定してある /api/xxx という名前が論理的におかしい。web api は他にもあるのに認証を要するものだけ api というトップレベルの path を付けるのは奇妙に思えてくる。

/api/ping

チームで話し合ったり、私が思いついた最終結論としては1文字の path を設けることにした。ミドルウェアを適用したいという目的なので path さえあればよい。認証を要することを表す単語をつけると path が長くなってそれはそれで違和感を感じるし、開発者はタイプ量が増えることを嫌う。そこで一文字にしようと提案した。

/p/ping

permit, private, protected の意図で p という文字を使う。

3次開発の大きなふりかえり

事前に資料を作っておいた 開発の大きなふりかえり。2時間を使ってふりかえりを行う。前回の大きなふりかえり を経て、今回も若手のメンバーが大きく成長してくれて、その成長度合いが課題管理システムの統計からみてとれた。私がプロダクト開発に参加してチームを組んで1.5年経った。初期からのメンバー2人はどちらも十分に課題管理をうまくできるようになった。その結果、チームがよい開発文化を形成するようになった。

今回は新たに入りかけた若いメンバーはうまく立ち上がらなかったという反省があるだけで、その他のことについては開発全般うまくいっているし、プロダクトの品質も上がっているし、バックログの課題もたくさん自分たちで見つけられるようになってきた。私からみてもこのチームは十分によい開発チームに育ったと思う。マネージャーとしての私にとっての次の課題は途中からチームに参加するメンバーをいかに早く開発に馴染んでもらうか、よい開発文化を形成するようになってもらうかという取り組みになる。

スライドのあちこちに次の文言を埋め込んである。

ふりかえりなくして成長 (改善) なし

初期から課題管理に取り組んでいる2人のメンバーはどちらも成長が著しいし、ふりかえりの効果を実際の業務で体感してもらえていると思う。私自身も初めてのマネージャー経験、初めての課題管理をプロジェクトマネジメントとして導入するという経験、それらの PoC としての答えは出たと思う。間違いなく、課題管理は開発プロジェクトをよりよくするものだし、適切に課題管理すればプロダクトの品質も高くなっていく。今回のふりかえりは課題管理をビジネスにすることへの確信につながった。

開発合宿ぷち前夜祭

1時に寝て6時に起きた。ここ数日2-3時に寝てしんどかったので数日ぶりに早く帰って寝た。最近は5時間眠れるようになってきた。健康大事。

今日の運動はレッグレイズ(椅子),腹筋ローラー,スクワットをした。統計を 運動の記録 にまとめる。

3次開発のふりかえり資料作り

昨日の続き 。一通り資料を作り終えてメンバーに共有した。QA テストのときに指導した ことに加え、3次開発をふりかえると新規メンバーがまた落ち込むかもしれない。しかし、経営者から開発に参加させてほしいと依頼されて、3ヶ月間なにもしなかったという事実を隠すことを私はしないし、あえてその背景を深堀りしないけれど、私のプロジェクトで次からこんなことを認めないという判断基準 (クライテリア) を設けて次の開発へ臨む。具体的にはフルタイムで時間を取れないのであれば開発に参加させないし、1ヶ月間を開発に取り組んで何も実績をあげられないときは開発から外す。今回は隔週で「来週からやります。」という言葉を3回ぐらい聞いて何もしなかったということが起きた。チームの規律を守るためにそんな人もいるとわかったのでその対策を講じる。

ぷち前夜祭

明日からの開発合宿に関東組が4人参加する。そのうち2人が前泊で神戸入りしたので軽く晩ご飯でもいくかと思っていたものの、いろいろ予定があわなくて、よしださんがうちのオフィスで別イベントのオンラインミーティングに参加するといった形になった。言うてもオンラインイベントなので mute にしながら会議室で軽く一緒に晩ご飯を食べた。阪急百貨店のデパ地下でお刺し身とお寿司とサラダ2種を買ってみた。18時前に行ったらお寿司とお刺し身は2割引だった。これで税込4,843円になる。このぐらいあれば2人で十分だった。オフィスの会議室も8人ぐらい入れる。数人規模の飲食イベントならすぐできそう。あとオフィスの冷蔵庫のスペースを奪ったままになっている缶ビールも3本消費できた。私はもう体重落とすことに専念しているので1人ではお酒を飲まないし、外へ出掛けてもなるべく飲み食いしないようにしている。体重を落とすゲームが楽しくなってきて、摂取カロリーよりも消費カロリーの方を大きくしていれば必ず痩せる。完全攻略に取り組んでいるような趣き。

昼も夜も課題管理の話ばかり

昨日はホテルへ戻って19時に寝て21時過ぎに起きて、23時頃に晩ご飯を食べて、1時に寝て6時半に起きた。

今日の運動は腕立て,スクワット,背筋,散歩をした。統計を 運動の記録 にまとめる。

プロジェクトの進捗報告

出張したときの月例報告の13回目。前回の進捗報告はこちら

開発はいま QA テスト期間であと2週間で今フェーズの開発を終える。今回は2週間遅延したけれど、あるメンバーにとってその分の成長も垣間見えたので中長期でみればこの遅延はよいものだったと思うといったことを上申した。優先度の高い要件は満たした上でメンバーの成長を実感したり、プロダクトの品質も上がってきている。私からみて十分に課題管理をうまくこなすチームになってきた。1年以上かかったけれど、よい開発文化をもつチームに成長したと思う。

今フェーズの唯一のよくなかったところとして新規メンバーの受け入れに失敗した。2週間の遅延もそこに起因するものではある。受け入れに失敗した背景や私の所感、今後の対応についていくつかお手伝い先の経営陣とも話し合いをした。開発とは結局のところ、人の問題になってしまう。それはスキルや生産性の個人差が大き過ぎるから。人に向かい合ってその人の価値観や行動を変革して、よりよい開発文化を根付かせていくことがチーム開発には重要。それは一朝一夕ではできなくて、半年とか1年とかそのぐらいの時間がかかる。

お手伝い先の経営陣も私が取り組んでいる課題管理の価値を認めてくれつつあって、開発方法論の手法を学んだことがないというのが最も大きいところだろう。よい開発文化をもつ組織で働いたことがあれば自然に身に付くが、知らない人はまったく知らなくて徒手空拳で戦車と対峙しているようなものになる。課題管理でよい開発文化をつくるという私の PoC はほぼ検証できたと言っていいかもしれない。

筋肉食堂へ行ってみた

MIYASHITA PARK に RAYARD というショッピングモールとレストランが合体したような大きな複合施設が出来てた。昔はただの公園だったと思うのだけど、いつの間にか再開発されたらしい。水曜日の夜で外も寒いせいか、施設が大きくて広い割にお客さんはまばらで閑散とした雰囲気だった。それはそれで人混みがなくて私にとっては心地よくはあるけど、施設の真新しさに比べて寂しい感じはした。

RAYARD にある 筋肉食堂 でお仕事のお願いも兼ねて知人と晩ご飯を食べてきた。たまたま渋谷でどこかお店を探していて、いま筋トレしているからちょうどよいんじゃないかと思って店名からエイヤで決めた。接待でもあるので和牛フィレ肉ステーキコースを頼んでみた。ちょっと高めの価格帯だから接待にも使えるのかな?と期待しつつ行ったのだけど、高タンパク低脂肪なメニューがいくつか提供されて、料理自体はおいしかったし、ヘルシーなら言うこともないのだけど、コンセプト的に量は提供されないし、料理の品数も少なかったのでディナーという視点からこのコースのみでは物足りなさもあった。コース料理を食べ終えてからもう1軒行きましょうとそそくさと退出した。本当の意味でトレーニングやっている人たちがご褒美のような晩ご飯を食べにいくところかもしれない。

まん丸のボールみたいなハンバーグが私は一番おいしかった。中心はレアになっていてその食感も楽しめた。これは私の好み。メインの和牛フィレ肉ももちろんおいしかったのだけど、私はもともと牛肉ステーキをそれほど好きでもないのでハンバーグで十分満足できることにも気付いた。

うしとらスタンドで飲んできた

筋肉食堂は RAYARD の SOUTH エリアにあり、同じフロアの NORTH エリアに うしとらSTAND があった。会食前に付近散策で歩いていてたまたま発見した。別店舗のうしとらに何度か行ったことあるのでこんなところにもあるんだと懐かしく思うところもあって2軒目はここに決めた。筋肉食堂でヘルシーな料理を食べて、結局ここでポテサラと餃子とナッツといった、ややジャンクな食べものとクラフトビールを飲んでヘルシーな食事をおじゃんにした。しかし、接待という意味では気張らず、こういうところで飲み食いして雑談するというのもとてもよかった。さすがうしとらさんだ。

おいしいなりんご という名前の、柑橘系ビールがあまり飲んだことのない風味で、おいしかったというよりはモノ珍しかった。なんかいつもとは違うモノを飲んで非日常感を味わうことができて満足した。

勉強のやり方の基本

3時過ぎに寝て1度起きて7時半に起きた。また体調を崩さないか心配になってくる。

今日の筋トレは腹筋:15x2,腕立て:10x1,スクワット20x1をした。

業務での勉強のやり方の基本

隔週で水曜日はメンバーと1on1をしている。今日は年明けで最初の1on1になる。あるメンバーと勉強のやり方について話題になった。私が普段、業務で行っている勉強のやり方を紹介してみた。

  1. 業務の中で未知の内容やわからないことに遭遇する
  2. ツールやフレームワークを学ぶなら公式ドキュメントを一通り読む
  3. チュートリアルやサンプルコードを書くためにサンプルリポジトリを作る
  4. 実際にコードを書いて、動かしてみて、ドキュメントの内容を理解する
  5. 自分が理解した内容をテックブログに書く
  6. 対象への理解の解像度が上がってから業務に応用する

業務をしながらこれを繰り返してプロダクト開発をしている。

私からみると、経験の浅い開発者は勉強せずに、インターネットでググった内容をそのまま業務に応用しようとする。そして、理解の解像度が低いために誤った設計や実装をしてしまう。それで手戻りが発生したり、品質が悪かったりする。何度も公式ドキュメントを読んだ方がよいと提唱しているものの、これがなかなか勉強しないといけない人には通じない。私も過去にそういう時期があったので意図が理解できないというのも理解できる。だからこそ、この話しは何度でもするし、いつかそのことを理解できるときがきたら役に立つことだと考えている。

メンバーから「公式ドキュメントを読んでも書いてあることが理解できない」というコメントをもらう。そう。理解できないから自分でコードを書いて、動かしてみて、その勉強をするんだよと教える。本当にそれだけのことなんだけど、それだけのことも理解できずに他人が書いた信頼できるかどうかわからない記事のコードを使う人が多い。本質的には技術の勉強を過小評価している。経験の浅い人は1-2時間読み書きしただけでモダンなフレームワークの抽象化や振る舞いを理解できるはずがない。私でもバックエンドならたいていのことは理解できるが、経験の浅いフロントエンドは怪しい。だから、分かるまでもっともっと勉強しないといけないという認識が必要だ。1-2時間で終えようではなく、勉強も含めて2-3日かけようと思うぐらいでちょうどよい。

さらに私はメンバーに「時間がかかってもよいからちゃんと理解して開発しなさい」と、これも何度も何度もメンバーに伝えている。それによってタスクが遅れても構わないとすら言っている。他社のプロダクト開発でそこまで言うと経営者からクレームがくる可能性はあるが、おそらくお手伝い先の経営者もいっときの開発の速度よりも、地に足の着いた開発者として成長してもらう方がずっと価値があると理解してもらっていると、私は考えている。だからこそ、メンバーにそう言って、みせかけだけで開発しないように伝えている。

今日話していて、ようやく自覚できるようになってきたんじゃないかと手応えを感じた。1年かかったけれど。私自身マネージャーとして未熟でもあるし、マネジメントがよくなかったところもあるし、伝え方もよくなかったのかもしれない。それでも繰り返し繰り返し、開発において大事な価値観はメンバーに伝えていこうと気持ちを新たにした。

災害義援金の推移

先日 石川県の災害義援金に寄付した ときにサイトにその日の残高を掲載していることに気付いた。関心をもったのでその記録を付けている。チェックを忘れたときは internet archive から分かる範囲で調べた。次のような感じに推移していて、そろそろ落ち着くのかもしれない。約60億円といったところ。他の団体や期間からの寄付もあるだろうけど、被害総額は約8,000億円らしいのでまだまだ全然足らない。

コワーキングのオンラインイベント

月例のカフーツさんのオンラインイベントに参加した。前回の所感はここ 。今回のテーマは「自治体とコワーキング」だった。私は行政を好ましく思っていない。行政と関わるお仕事もいくつかやってきた中で行政側の態度がよくなかったり、担当者も上から指示されたからやってますといったやっつけだったり、若い担当者は理解があっても決済権をもってなくて上司に没にされたり、一緒に働いていて楽しいようなお仕事に巡りあわなかったからだ。そして、目的意識からの違いから行政とのお仕事やプロジェクトが失敗とまで言わなくても、うまくいかないケースをいくつも見聞きしてきた。うまくいかないのに対して、うまくいったというのはほとんど聞いたことがないからまずうまくいかない。

それはともかく、行政と一緒になってコワーキングの事業をやろうとしている人たちもいるのでそれはそれでどんなことをやっているのかを聞いていた。今回は新しい参加者がいてその人の経歴ややっているコワーキングの行動なども聞けておもしろかった。街の人たちとどうやって仲良くなるかという話しで単純接触効果がもっとも効果が大きいのではないかと話されていた。なにもしなくてもそこにいて、徐々に人がくるようになって、人と会っているうちに仲良くなるといった話し。営業さんが取引先をまわるのもその戦略。

空き家バンク は住居向けしか対象としていなくて事業用にはなっていない。事業に使える空き家を探すのが難しい。空き家のマッチングシステムはあるようでないらしい。空き家がいっぱいあるのはわかっているので空き家をコワーキングスペースに改装して、町興しの拠点に使えばいいのではないかといった話しがあった。それはそうかもしれないが、私の感覚では、田舎にスペースは山ほどあるが人がいない。コワーキング的な新しい価値観で個々が自律して課題解決するような人を田舎でみつけるのはなかなか難しいと考えている。どちらかというと、一定の人口がいる地方都市や大きめの市が落とし所なのではないかと思う。

だらだらした大晦日

夜に アンダーニンジャ を読み始めて、途中で寝たりしながら気付いたら7時に起きた。それから起きないといけなかったんだけど、なんとなくのんびりしてお昼ぐらいまで過ごし、その後も軽く食べてから3時頃までだらだらしていた。

帰島

夕方ぐらいから車で実家に帰る。雨がぱらぱらしていたり、大晦日でもそこそこ交通量が多かった。途中の淡路 SA でお土産をいくつか買って1時間半ぐらいで実家に着いた。

WBC2023 ザ・ファイナル を見始めたら最後までみてしまった。私はニュースでしか知らなかったので当時のダイジェスト映像で試合を振り返ることもできてよかったと思う。とくにダルビッシュ選手の振る舞いや役割に共感できた。自分が選手として活躍するよりも、若い人たちがチームに馴染みやすいようチームビルディングに献身している姿勢がよかった。番組内のダルビッシュ選手の若い頃のエピソードを聞いているとそういう社交的な選手ではなかったようだ。それは2009年のWBCのイチロー氏の影響もあったのだと思える。私もいまマネージャーをやっていて、自分がその業務をできないわけではないが、若い人たちになにをどう教えたらよいかを考え込むことが多い。

テレビを見終えてから離れで机に向かって日記を書いている。私は家と作業場所を完全に分けるのが気持ちの切り替えにうまくいく。モチベーションや集中力を制御するために場を変えるというのを、昔はそれほど自覚的に行っておらず、いまほどうまく活用できていなかった気もする。いまはもっとうまく場を活用できるんじゃないかと思う。

モチベーションを揺らすもの

0時に寝て2時に起きて6時に起きて7時に起きた。まぁまぁ普通に眠れた。

定例会議

いよいよこのマイルストーンを終えると、あと1つで機能開発の終わりとなる。いくつかの要因があって開発の進捗は遅れ気味になっている。メンバーがどうこうというわけではなく、私がうまく段取りを組めていなかったり、自身がマネジメントの業務をちゃんとまわせていないところが開発スケジュールの遅延につながっている。いまの状況は私が失敗したあのときのあれや、このときのこれから全体の進捗へ影響を与えているなとわかるぐらいにはマネジメントの動きが読めるようになってきた気がしている。読めるんだったら対応しろよというのはわかっているものの、モチベーションが足りなくて成り行きに任せていて成るようになっていないなといったところ。私のモチベーションが足らないところも含め、今フェーズの開発にはマネジメントの反省材料がいくつかある。

真面目にやった人を不当に咎める

昔から私はわりとワーカホリックだったので興が乗るとずっとお仕事をしていることが多かった。若い頃はやったらやった分だけ成果が出て評価されて、それはそれで楽しかったものの、30代になるとできて当たり前、成果のレベルがよほど飛び抜けていない限りは評価されることはなくなった。仮に10段階で例えると、若い頃は3しかできないと思っていた人が8ぐらいやると評価されやすいし、30代では8やって当たり前だと思われているから10やっても12やっても大差ないとみなされる。もはやお金のためにお仕事をしているのではないため、評価されなくても気にはならないし、いまは自分で契約の判断ができるので嫌なら契約を終了して別のお仕事を探せばよいだけという割り切りもある。

そんな中、昔からずっと思っていることが1つあって、真面目にやっている人たちを適切に評価しない上司が多い。要はなにも言わなくてもちゃんとやってくれているから放置するといった傾向がある。そして、さぼっている人たちや成果を出せていない人たちをかばう傾向がある。それはパフォーマンスが低い人たちを悪く言うと、さらにモチベーションを下げて、もっと悪くなるから励ますという意図があるのだと思う。しかし、その対応が度を過ぎると、真面目にちゃんとやった人たちのモチベーションを吹き飛ばしてしまう。その典型的な言葉が「みんながんばった」になる。実際は数人のコアメンバーが業務の大半をやっているのに上司は個々人の差異をなくしたがる。チームの一体感とか、空気を悪くしたくないとか、ハレーションを防ぐとか、いろいろあるのだろう。私は一緒に働いている人なら誰でも気付けるレベルの、みんながんばってないのに、そういった問題を指摘することもなく、なぁなぁで済ませるのをいくつもみてきて、これは日本の会社や組織で共通する傾向があると思う。なにを危惧しているのかわからないが、問題の本質に触れようとしないことが度々起こる。気付いたら対応しないといけないから気付いてないことにしたいと言い換えてもよいかもしれない。そういう状況をみると「またか」と思って私のモチベーションが落ちる。誰だって働きたくない。

私はよくやってくれている個人を、何度でも、よくやってくれていると明言して評する。がんばっていない人たちを咎めたりはしないが、がんばっていないのにがんばったとは絶対に言わない。状況によってはもっとがんばってほしいと言う。個人差があることを曖昧にしたりはしない。

新規メンバーを受け入れないという意思決定

19時過ぎに帰って晩ご飯食べて、21時から0時過ぎまでオフィスで作業して、また帰ってから一休みして出張準備して、5時前に出掛けた。1ヶ月ぶりの出張。

出張前の朝ご飯

三ノ宮駅のすぐ近くに24時間営業のなか卯がある。うまく眠れなくて時間があるときはここで朝ご飯を食べながら一息つくのがよいのではないかと考えた。今回の実際のタイムスケジュールが次になる。市営地下鉄の駅が5時30分ぐらいにならないと開かないため、あまり早く行ってもやることなくて手持ち無沙汰になる。その隙間時間を埋める場所としてなか卯がよいことに気付いた。

  • 4:56 家を出る
  • 5:10 なか卯に着く
  • 5:11 親子丼を注文する
  • 5:16 親子丼食べ終わる
  • 5:30 なか卯を出る
  • 5:35 市営地下鉄三宮駅のホームに着く
  • 5:41 市営地下鉄の始発に乗って新神戸駅へ

マイルストーン定例

隔週の火曜日は開発状況の共有や進捗確認、設計レビューなどを行う定例会議。先月の定例会議 でも確認していたが、新規メンバーの参加がうまく進捗していない。機能開発を3ヶ月と見積もっているうちの、2ヶ月が過ぎた。さすがにここから開発に参加して追いつくのは厳しいので、新規メンバーの今後の兼務状況に関係なく、今回の開発からは外すという意思決定をした。五月雨式に2回遅れたところで私の中では開発運営の構想から外すように徐々に調整してきていたし、2週間のイテレーションの節目でも既存メンバーにタスクを再割当てするようにもしていた。そのため、いまの開発に大きく影響を与えるわけではない。しかし、参加する可能性も残ってはいたのであからさまに除外することもできなかった。3回に渡って「いついつからやります」と言いながら、(兼務の業務が忙しいとしても) 何もやっていないことに、この開発やチームに責任をもつ私の立場としては印象が悪かった。なによりも業務として責任を果たしていない状況を問題であると当事者が自覚しているようにはみえないところにも懸念があった。よくない開発文化の実例の1つに思えた。

考えないという傷のある現場

2時に寝て7時半に起きた。昨日からよく寝た。また心機一転。

ldap エントリーの crud api

先週から ldap クライアントや そのプール を実装して結合テストも一通り書いていた。今日はそれらを使った crud な web api を一通り実装した。クライアント実装もテストもしっかり出来ているので後は時間の問題で1つずつ確認しながらコードを書いていくだけだった。こういう作業になると、まとまった時間があればすぐに終わる。他のメンバーのコードレビューをみたり、設計の話しをしたり、他に意識を取られてあまり自分の作業に集中できなかった。

言葉が通じないもどかしさ

先週「参考にして」と指示したものが「全コピー」で驚いてしまった。私がいくつか指摘したらすぐに削除し始めてさらに落胆した。自分の頭で考えて作業していないようにみえる。

開発というお仕事は自分で考えて、コードの1つ1つに明確な意図や根拠をもって書くものだ。もちろん、情報不足や設計に自信がもてなくて一時的に曖昧な実装にするときもあるけれど、それは懸念事項として把握しておくことで将来対応すればよい。基本的に追加するコードにはすべて意味がある。

他人が分からなくても自分が理解できているのなら、自分の考えを説明し、それが論理的であったり筋が通っていれば、私は自分の考えと違っていても構わない。説明できないコードを追加して、ツッコミを受けてなにも説明できない状況をみているのは本当に悲しい。

山田ズーニーさんの著書に書いてあった「考えないという傷」を思い出した。