バックエンド専門のEM｜Go × AWS × 組織改善 現場でGoを書きつつ、EMとして「強いチーム」を模索しています。 ｜技術探求： AWSの運用/Goの実践知 ｜組織改善： チームビルディング・育成・採用・プロダクト開発 ｜🚀 176人→500人目指して発信強化中！
Joined October 2022
- Tweets762
- Following220
- Followers202
- Likes3.9K
昔、学んだ技を無理に使ってコードを複雑にし、数ヶ月後の自分で大苦戦した。わずかなパフォーマンスと引き換えに保守性を溶かした苦い記憶。テクニックの証明じゃなく、誰が読んでも一発でわかる愚直なコードが一番強いと痛感した。
#エンジニア初心者
「リーダーが一番仕事をして作業を割り振る」状態に陥るとチームは回りません。私も昔は自分でやりすぎて疲弊しました。今は作業をメンバーに渡し、私は方向と判断に集中し、自分がボトルネックにならないよう意識しています。
#マネジメント #リーダーシップ
リーダーとは何をする人か——役割5つと、マネージャーとの違いを整理する
note.com/chujo/n/n6ae0c95858…
「なんかこの作業、面倒だな…」って手が止まる時、原因は大体タスクの粒度が大きすぎて何をするか不明なこと。昔の私もこれで毎日詰まってました。だから今は、作業を細かすぎるくらいに分解して書き出してから動くようにしてる。これマジで捗る。
ToDoリストが長い管理職ほど、仕事が終わらない。
あなたのリストに、こんな項目はないか。
・A社の件
・評価の件
・来期体制の件
2週間以上、消えずに残っている。
これは作業じゃない。
まだ決めていないことだ。
「A社の件」は、何をする項目か。
電話するのか。
資料を作るのか。
条件を決めるのか。
書いた本人にも決まっていない。
決まっていないものは、リストに置いても進まない。
そして人は終わらせやすい作業から手をつけるから
判断が必要な項目だけが、リストの底に沈殿していく。
ある管理職が40項目を分類した。
17項目が「次の動作が決まっていない」状態だった。
やったのは2つだけ。
①作業は「動詞で始まる次の動作」に書き換える
「A社の件」→「A社に回答期限を確認する電話をする」
②判断待ちは別リストに分け、週1回30分で決める
2週間で、残留項目は17から5になった。
リストの長さは、仕事量じゃない。
未判断の量だ。
note.com/kabu_nare/n/n6b78a9…
昔は「動けば正義」でコードを全部1つの関数やファイルに詰め込んでしまい、後から一切変更できない魔改造コードを量産していた。UNIXのパイプラインの思想に触れ、小さなモジュールを組み合わせていく感覚を掴んだ時は目から鱗だった。 #エンジニア初心者
「ミスが発生しました」「認識違いでした」と主語を消して責任逃れをするのは簡単だ。しかし優れたリーダーは、成功のときはチームを主語にし、失敗のときは「我々」として背負う。結果が良いときは君たち、悪いときは我々。主語の反転こそが心理的安全性の土台。
昔は「こんな操作する人いないだろ」と例外処理をサボっていた。でも本番環境では想定外が必ず起きる。システム開発において『ありえない』なんてことは、ありえない。だからこそ、どんな時も安全に倒すためのデフォルト値やエラー処理が絶対に必要になる。防衛力を高めよう。
#エンジニア初心者
「自分は論理的」と思い込んでいるメタ認知バグ型は、現場のマネジメントで最も苦戦する相手の一つです。こちらは事実やデータをベースに話しているのに、相手の脳内では「攻撃された」という感情が優先されてしまう。噛み合わなさを紐解く難しさを痛感します。
昔は「人によってコードの書き方が違う」のを許容してたけど長期的に見ると悪手だった。新しく入った人が「どれが正解？」と迷うし、微妙なコードをコピペして負債が広がる。例外的な書き方をする時は「なぜそう書いたか」をコメントに残す。これだけでチーム開発は劇的に変わる。
#エンジニア初心者
「仕事は論理、プライベートは感情」と分けて考えていた時期が私にもありました。でもマネジメントを経験して気づいたのは、仕事の中にも「論理より人に寄った問いかけ」が必要な場面が山ほどあること。結局、どれだけ正論を並べても人は感情でしか動かないんですよね。首がもげるほど共感します。
最近、開発に対する考え方を意識的に変えている。話題の新しいV字モデルにある「両肩」の重要性を痛感しているからだ。まずは機能を作るのではなく、仕様の段階でいかに顧客価値を創出できるか。AIに実装を任せられる今、エンジニアの主戦場は間違いなくここに移ってきている。
昔の自分に言いたい。「行数が少ない＝イケてるコード」ではないと。mapやfilterを繋げまくった芸術的なワンライナーは、半年後の自分やチームメンバーへの負債になる。少し野暮ったく見えても、一つ一つの処理の意図が明確で読みやすいコードを書くのがプロの仕事だ。
#エンジニア初心者
設計レビューで「なぜこれ？」と聞かれ答えに詰まる失敗を何度もした。原因は最初から1つの正解を作ろうとしたこと。今は必ず複数案を出して比較する。対立案があるからこそ本命の強みが言語化でき、1案だけの時には見えなかったリスクに気づける。差し戻しが劇的に減った。
これまでは「作るコストが高い」から徐々に進めるアジャイルが主流でした。しかしAIで爆速開発が可能になった今、一旦全部作ってから検証し、何度も作り直す「超高速ウォーターフォール」とも言える手法に新たな可能性を感じています。前提が変わると開発プロセスの常識も変わりますね。
昔は「デグレ防止」のためだけにテストを書いていた。でも本当の価値は「生きた仕様書」になること。その関数が何をするのか、どんな振る舞いを期待されているのか。第三者が読んで仕様が伝わるテストコードを書けるようになると、開発体験は劇的に変わる。
#エンジニア初心者
自分の取扱説明書を作ることの重要性に激しく共感しました。特に「スタンスがない人は全問記述式の試験、ある人はマークシート」という例えが秀逸です。私自身、頭の中に何となくルールはあるものの、言葉として残していないため、毎回ニュアンスの違う判断をしてしまっていると気付かされました。
これ非常に大事。会議の目的と時間は意識していましたが、「決める人」を冒頭で宣言する設計はできていませんでした。権限の所在が曖昧なままの議論は、ただの意見交換会になりがち。脱線しない会議を作るため、ファシリテーターの責任として決裁者の明示を徹底したい。
決まらない会議は、最初の30秒で決まっている
始まってすぐ、議題の説明に入る
そのまま話が広がって、時間切れになる
会議の最初の30秒で、3つだけ言う
1．今日決めること
「今日は、〇〇をA案かB案かで決めます」
2．決める人
「最後は、〇〇さんが決めます」
3．終わる時間
「〇時に終わります。決まらなければ、〇日までに〇〇さんが決めます」
この3つがあるだけで、会議はこう変わる
・話がそれたら「今日決めることに戻ります」と言える
・意見を出す人と、決める人が分かれる
・時間内に決まらなくても、決まらないまま終わらない
議題を説明する前に、決めることを言う
順番を入れ替えるだけで、会議は半分の時間で終わる
100名組織を束ねる管理職の現場から。
昔の自分に言いたい。DB設計でユーザー情報を何でも1つのテーブルに詰め込むのはやめろ、と。認証とプロフィールなど用途で分割するだけで拡張性が劇的に上がる。機能追加が身軽になるのはもちろん、負債になった機能をテーブルごとバッサリ捨てられるのが最大のメリット。
#エンジニア初心者
「必要な準備をしたら目の前に戻る」は至言。エンジニアは職業柄、事前にリスクを潰す癖がついているけど、それを対人関係や日々の不安にまで適用すると「言われてもない批判」を想像して疲弊する。過剰な予測機能を意図的にオフにして、今に集中する切り替えがマネジメントには必須ですね。