いいねの数だけ仕事のこだわりを書く ～@OgiharaRyoさん編～

Ryo @OgiharaRyo

25. 報告は即時行う 週次定例ミーティング等が設定されていると「ミーティングの時に伝えれば良い」と思いがちだが、報告は早ければ早いほどいい。直後にミーティングであったとしても頭出しはしておく。

Ryo @OgiharaRyo

26. 人の立場を尊重する どんなに理不尽なことを言ってくる人でも、背景はその人も上司にせっつかれていたり、こちらから見えないプレースホルダーとの関係が緊迫していることもある。「相手にもいろいろあるんだろうな」という配慮を忘れない。

Ryo @OgiharaRyo

27. 細かいタスクから片付ける タスクの数はストレスの数。多少優先度の高い大きなタスクがあったとしても、優先度の低い細かいタスクを先に片付ける。メンタルが一番大事。タスク管理ツールの一覧性も大事。

Ryo @OgiharaRyo

28. 決裁権のある人を巻き込む 非効率の手戻りの多くは決裁権のない人と沢山話し合った挙句、決裁権のある人に弾かれた時に発生する。その人がどれだけ偉かろうと忙しかろうとプロジェクトには巻き込む。その必要性を正しく説明して説得する。

Ryo @OgiharaRyo

29. 理想論が先、現実が後 要件定義でもフィードバック受け入れでも、理想論は語ってもらう。自分も現実的に無理であろうと本来あるべき姿についての共有を行う。技術者でない人は自分の理想がどれだけ技術的に難しいのか想像ができないので、とりあえず何でも話してもらう。話しやすい雰囲気を作る。

Ryo @OgiharaRyo

ここから技術の話 30. 名前重要 設計以上に命名を優先する。名前に背くようなコードを書かなければ設計も自然になることは多い。しっくりこないまま実装を行わなければならない時は TODO コメントを入れる。一度妥協すると一生妥協するので妥協した記録を明確に残す。

Ryo @OgiharaRyo

31. Pull Request は細かく コードレビューで「うっ...」とならないぐらいが基準。大きな改修になる場合は、別ブランチを作ってそこに細かく Pull Request を出していく。大きな Pull Request は放置されやすく、レビューも雑になりやすい。

Ryo @OgiharaRyo

32. commit メッセージは日本語 日本人のみのプロジェクトであれば commit メッセージは日本語の方が良い。幸いにして日本語は多くの情報を短い文字列に詰め込むことができる。最速で理解できることが大事。英語を強制すると「Fix user model」みたいな雑な commit メッセージが出てきがち。

Ryo @OgiharaRyo

33. YAGNI (You ain't gonna need it) 「かもしれない」に備えない。今必要でないものを予め実装しないのは勿論、拡張性を考慮しておくことすら基本的にはしない。今、その瞬間に最適化する。

Ryo @OgiharaRyo

34. 既存のコードを信じない 母が肉を煮込む前に両端を切り落として捨てるので理由を尋ねてみると「祖母の知恵よ」と言われ、祖母に尋ねると「そうしないとお肉が当時のお鍋に入らなかったよ」と言われる笑い話がある。先人の設計が必ずしも今も正しいとは限らないので歴史的背景の把握を怠らない。

Ryo @OgiharaRyo

35. TDD の副産物に期待しない TDD によるテストの目的は開発を駆動するため以外にない。それによって生まれたテストコードがカバレッジを上げるのも、テストが自動化されるのも、ドキュメント化を助けるのも、全て開発駆動の副作用でしかない。副作用には一切を期待しない。

Ryo @OgiharaRyo

36. テストされなくても大丈夫なコメントを書く コードと違ってコメントの嘘はテストコードで検出できない。テストで誤りを検出できないものは可能な限りソースコードに仕込んではならない。コメントを書く時はコードの振る舞いや依存先に変更があっても極力嘘にならないような文章を心掛ける。

Ryo @OgiharaRyo

37. SSS を恐れない 作り直しで事故るのは膨大すぎるプロジェクトである場合や、作り直すのに必要なリソースや見積もり能力が足りなかった場合であって、個人的な経験では「作り直した方が早い」は大体正しい。世の中には本当に作り直した方が良い酷い遺産が沢山あることを忘れてはならない。

Ryo @OgiharaRyo

38. Metrics AbcSize は緩めない 割れ窓の最後の砦が AbcSize 制限。ここを緩めると終わりの始まり。どうしても緩めなければならない場所のみ disable コメントにて緩める。グローバルはどんな理由があっても緩めない。

Ryo @OgiharaRyo

39. 命名は郷に入りては郷に従え 後から参加したプロジェクトに命名規則がなかろうが、ローマ字命名が乱用されていようが、ありえない略語を使われていようが、それに従う。新たな命名を行ってしまうと結果としてそれが読み手の負担になることがある。

Ryo @OgiharaRyo

40. system spec はフラットに システムテストにおいては丁寧に構造化しすぎると逆にメンテナンス性が悪くなることが多い。異常系も正常系も全て同じ sceranio ブロックに並べると気持ち悪さは残るがあるべき操作をそのまま表現できるのでテストとしての品質は上がることがある。

Ryo @OgiharaRyo

ここから引きこもり編 41. 在宅勤務 自宅でできる仕事以外は選ばない。デスク、椅子、キーボード、食事、空調、服装、部屋の明るさ、といった生産性に関わる多くの要素の自由度を優先する。そもそも引きこもっていたい。

Ryo @OgiharaRyo

42. リモートワーカーなりの存在感 リモートワーカーだからこそプロダクトに深く関わり有益な発言をし存在感を出す。「在宅のあまり知らない人」なんて間違っても思われないこと。

Ryo @OgiharaRyo

43. ワンクリックテレビ会議の用意 リモートでも「ちょっと今話せますか？」に対応できるようにする。チャットルームの概要欄等にミーティング URL を常設しておき、カレンダーの予約や URL の発行等の手間を取らなくても一瞬で会話をスタートできるようにしておく。

Ryo @OgiharaRyo

44. 人間ではなくプロジェクトをマネジメントする リモートワーカーで構成されたプロジェクトにおいては進捗が滞っているか否かは各担当者が机に向かっているかや報告が上がってきているかではなく、リポジトリの状況や検証環境の状況やプロジェクト管理ツールの状況によって判断する。

Ryo @OgiharaRyo

45. ハードワークをしないさせない 全員がフルリモートフルフレックスの状態だと、良くも悪くも個人の気分や家庭の事情で、夜間や休日に仕事ができる。それは1つの自由ではあるが、累計労働時間は絶対に1日8時間以上とならないこと。ならせないこと。

Ryo @OgiharaRyo

46. 主体性のある人を採用する 詰まった時に質問ができない人や、完了しても完了報告をせずに指示を待つような人はフルリモート前提で採用しない。

Ryo @OgiharaRyo

47. 質問環境を整える 質問できる人、質問できる雰囲気、質問できる場所を整備する。「新人が困っていたら空いている人が助けてあげてね」とか、「新人さんは困ったら周りの人に相談してね」のような曖昧な教育を行わない。

Ryo @OgiharaRyo

48. 質問の場所をオープンにする 組織における教育は1:1で行わない。質問は皆がいるチャンネルにしてもらえば、他の人が答えられるかもしれないし、教育担当の説明の補足が受けられるかもしれない。また、教育担当が返事できていないことやしばらく質問が出ていないことがチームのメンバーに伝わる。

Ryo @OgiharaRyo

49. サボりに寛容である 仕事はサボればサボるほど良い。普段から「空いたらサボっていいよ」としておく。「空いたら別の作業を詰め込まれる」という環境では、完了報告を遅らせた方が得になってしまうので、成果が早く上がったことで不利益にならないようにする。