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

Ryo @OgiharaRyo

50. コードレビューは即行う コードレビューは基本的に最優先で行う。コードレビューに限らず、滞ったら他の人の業務が止まるものを優先的に片付ける。

Ryo @OgiharaRyo

51. リモートワークの問題と組織の問題を切り分ける リモートワークによって何か問題が発生した時、リモートワークの特性上の問題であるのか、組織の問題であるのかを正しく見極める。基本的には後者であることがほとんどだが、前者の問題に捉えがちで誤った解決案に行きつきがち。

Ryo @OgiharaRyo

52. バックオフィスへの感謝を言葉で伝える リモートワーカーだらけの企業はバックオフィスの負担が大きい。何か郵送されてきた時や経費関連の手続きをする時など、しっかり言葉で感謝を伝えること。

Ryo @OgiharaRyo

53. リモートワークに生産性向上を期待しない 私は在宅の方が生産性が数倍高いが、そうでない人の方が多数であることを忘れない。リモートに切り替えた人の生産性が上がることに期待してはならないし、生産性目的でリモートワークを提案してはならない。

Ryo @OgiharaRyo

54. テレビ会議では相槌を打つ テレビ会議においては顔出しの有無に関わらず、喋っている人がテレビ会議ツールの画面を見ているかは分からない。自分が喋っている時に相槌がなければ不安になりやすいので、多少大袈裟でもリモート会議では相槌を心掛ける。

Ryo @OgiharaRyo

55. 体調不良の人に働かせない 在宅勤務では多少の体調不良ぐらいでは仕事ができてしまう。私の場合はそれも1つの自由であるが、他の人はそうではない可能性がある。普段から体調不良を気軽に訴えやすい雰囲気作りと、いつ突然人が欠けても大丈夫な体勢作りを心掛ける。

Ryo @OgiharaRyo

56. 自分が率先して休む 周りの人が普段から当たり前に休暇を取っていないと、新入社員や控えめな人は休むことを言い出し辛い。自分が率先して休むことでプロジェクト全体にカジュアルに休める雰囲気を作っておく。

Ryo @OgiharaRyo

57. 雑なテキストと厳格なテキストを使い分ける 普段は絵文字や語尾の「〜」や「！」等で雑でカジュアルなテキストを心掛ける。テキストから怒っていると不安になる人や、自分もそうしなければならないと思う人もいる。対して技術的な話をするときは曖昧さを排除するために厳格なテキストを書く。

Ryo @OgiharaRyo

58. 大事なことを先に伝える Yes or No で述べられることは先に述べる。質問するときは背景よりも先に聞きたいことを述べる。相手がテキストを読む時の脳内リソースを極力削らずに済むように配慮する。

Ryo @OgiharaRyo

59. 努力を評価しない 夜遅くまで頑張ったとか、沢山時間をかけたとか、そういった要素を評価しない。「頑張ってくれてありがとう」とか「大変だったね」とか一声かけることはあっても、その努力を周りの人が見習ったり、努力にモチベーションを感じたりしないようにする。あくまで成果を評価する。

Ryo @OgiharaRyo

リモートワーク編終わり。そろそろ思い浮かび辛くなってきたので、残りはテーマ無し。 60. 人を中継しない 自分で話した方が早いことを中継しない。伝言ゲームはどうしてもニュアンスが抜け落ちるし宿題が発生する。エンドユーザーでも社長でも「自分が直接話せますか？」と積極的に聞く。

Ryo @OgiharaRyo

61. ビジネスを理解する 自分が技術を分からない人に説明するのが難しいように、ビジネスサイドの人もビジネスが分からない人に説明するのは難しい。自分がプロダクトの舵を握って楽をするためにも、他のメンバーが楽をするためにもビジネス視点と技術視点両方を持って業務を行う。

Ryo @OgiharaRyo

62. ローカルマシンにデータを持ち続けない リモートリポジトリへの push は commit 毎に行い、ドキュメントは基本的にオンライン上のツールを使って管理する。いつ自分のローカルマシンが壊れても他の人がそのデータを参照できるように自分の作業は常にオンラインで公開しておく。

Ryo @OgiharaRyo

63. 検証のフットワークは軽く ソフトウェアに問題が発生した時、考えすぎるよりもまず再現させる。手元に環境を構築したり、最小のプロジェクトを作ってみたり、テストコードを書いてみたり、といった手間を惜しまない。

Ryo @OgiharaRyo

64. ロジハラを恐れない エンジニアは結構ロジハラ扱いされやすい職種で、ビジネス的な理想やビジョンを技術的実現性やデータによる正論で突き返すことが日常だが、それが我々の専門性でもあるので、伝え方の配慮はすれど正論で勝負することからは逃げてはならない。

Ryo @OgiharaRyo

65. 小さな頼まれごとはすぐに取り掛かる すぐに済むことだからこそ、自分の作業のキリの良いところまで待たずに頼まれた瞬間に取り掛かる。自分都合よりも基本的に他人の信頼と評価を優先する。結果的に自分の評価が上がって発言力や権限が増して自分都合の仕事がやりやすくなる。

Ryo @OgiharaRyo

66. 他人へのお願いに「ついでに」はない 「XXX やるんだったら、ついでに YYY もやっておいて」のような頼み方はしない。人には人の計画と想定がある。頼んだことが「ついで」かどうかは分からない。他人の時間を奪うこと、計画を狂わせることに対して「ついでに」のような軽薄な言葉を使わない。

Ryo @OgiharaRyo

67. 気軽にメンションしない 人へ通知を送るということは、その人の集中力を奪うことなので、特別な理由がない場合はメンションしない。特に here, channel, everyone は信頼を損ねるので使わない。「この人から通知ということは重要なことだな」と思われた方が良い。

Ryo @OgiharaRyo

68. 会議に遅刻しない オフラインオンラインに関わらず、会議には必ず時間前に参加する。人の時間を奪うことは信頼を大きく落とす。テレビ会議であっても遅くとも2分前には入室する。１秒でも遅れる可能性がある場合はその旨を連絡する。

Ryo @OgiharaRyo

69. 離脱する人の仕事を信用しない 退職が決まった人や、プロジェクトの離脱が決まった人は、仕事の手を抜きやすく責任からも逃れやすい。引き継ぎ業務の主導も離脱予定者に任せない。引き継ぎの責任は離脱予定者ではなくチームで持つ。

Ryo @OgiharaRyo

70. フル稼働しないさせない 1日の労働時間の見積もりは多くても4時間程度にする。1日8時間フルに使わないといけないようなスケジューリングはしない。割り込みは発生する。想定外の問題も発生する。そもそも人は8時間も集中して働けない。月の計画も休暇を考慮して20日もフルで見積もりをしない。

Ryo @OgiharaRyo

71. 仕事の成果を常にオープンにする 常にプロダクトや検証環境に新機能をリリースして動きを見せる。すぐに成果が見せられないような大きな仕事に取り掛かる場合は途中経過を共有する。「あの人、今何やってるんだっけ」と思われたら終わり。

Ryo @OgiharaRyo

72. 時給の仕事は請けない 仕事の成果はプロダクトメンバーが知っていれば良い、あるいはプロダクトが予定まで完成していれば良い。それが許される仕事しか請けない。何時間働いたか、どんな仕事に何時間使ったか、といった報告や資料作成に時間を使わない。

Ryo @OgiharaRyo

73. 人に進捗を聞かない 必ず日の終わりに push させる、数日にまたがるタスクは細分化する等、聞かなくても見えるようなマネジメントを行う。進捗を聞かないと進捗が分からないような仕事の仕方をする人とはできる限り働かない。

Ryo @OgiharaRyo

74. 一緒に働く人を選ぶ 対人はストレス。約束を守らない人、レスポンスが遅い人、無断で仕事をする人等とは仕事をしない。万が一することになったとしても「私はこの人と仕事をするのが辛い」という旨を上の人に伝える。それが叶わない場合は自分がプロジェクトから抜ける。メンタルが一番大事。