<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
    <title>~&#x2F;notes - essay</title>
    <subtitle>Thoughts on technology, life, and everything in between.</subtitle>
    <link rel="self" type="application/atom+xml" href="https://rinx.fyi/category/essay/atom.xml"/>
    <link rel="alternate" type="text/html" href="https://rinx.fyi"/>
    <generator uri="https://www.getzola.org/">Zola</generator>
    <updated>2026-08-15T00:00:00+00:00</updated>
    <id>https://rinx.fyi/category/essay/atom.xml</id>
    <entry xml:lang="en">
        <title>仕事を依頼することの本質について</title>
        <published>2026-08-15T00:00:00+00:00</published>
        <updated>2026-08-15T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              rinx
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://rinx.fyi/posts/20260815-request-a-job/"/>
        <id>https://rinx.fyi/posts/20260815-request-a-job/</id>
        
        <content type="html" xml:base="https://rinx.fyi/posts/20260815-request-a-job/">&lt;h2 id=&quot;はじめに&quot;&gt;はじめに&lt;&#x2F;h2&gt;
&lt;p&gt;先日仕事をしているときに、数千行にわたる(おそらくはAI生成による)変更の含まれる Pull Request のレビュー依頼が、何の前触れもなしに突然飛んできた。
その Pull Request にはたった一行の Description が書かれていただけで、なぜこの変更が必要なのか、なぜ私にレビューを依頼したのか、なにを確認してほしいのかなどの情報は一切わからなかった。
後に Author に確認してみたところ、その変更をデプロイするため、単に形式上の Approve が欲しかっただけだったそうだ。&lt;&#x2F;p&gt;
&lt;p&gt;私個人としては、このレビュー依頼の仕方にとても違和感を感じた。
問題点としては次のような点が挙げられる。&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;数千行の変更をすべて確認しようとすれば非常に時間がかかる&lt;&#x2F;li&gt;
&lt;li&gt;変更の意図や背景、課題がわからない&lt;&#x2F;li&gt;
&lt;li&gt;レビューに何を期待しているのかがわからない&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;p&gt;総じて、レビュアーに対する配慮が欠けている依頼であると感じた。
(また、レビューに割ける時間もなかったので、この依頼についてはお断りした。)&lt;&#x2F;p&gt;
&lt;p&gt;この件をとおして、あらためて Pull Request のレビューとは何か、仕事における依頼とは何なのかについて考えてみた。&lt;&#x2F;p&gt;
&lt;h2 id=&quot;レビューを依頼すること&quot;&gt;レビューを依頼すること&lt;&#x2F;h2&gt;
&lt;p&gt;一般的にはレビューを依頼するとき、依頼者はレビュアーに対して何らかのフィードバックを期待し、最終的には Approval をもらうことを目指すことがほとんどだと思う。
書籍「Looks Good To Me」&lt;sup class=&quot;footnote-reference&quot;&gt;&lt;a href=&quot;#fn:1&quot;&gt;1&lt;&#x2F;a&gt;&lt;&#x2F;sup&gt;でも紹介されているように、 Pull Request に Approve するということは、レビュアーもその変更に責任を持つということだ。
単に形式的な Approve が欲しかっただけだとしても、変更に責任を持つことには変わりはない。&lt;&#x2F;p&gt;
&lt;p&gt;その意味で、レビューを依頼するということは、「レビュアーにもこの変更に責任を持ってもらう」ための依頼であると捉えることができる。&lt;&#x2F;p&gt;
&lt;p&gt;また、日頃忘れがちなことだが、「レビューをするのにも時間や労力はかかる」という点だ。
レビューを依頼する側の立場からすると、レビュー依頼には無償で応えてもらえると思いがち&lt;sup class=&quot;footnote-reference&quot;&gt;&lt;a href=&quot;#fn:2&quot;&gt;2&lt;&#x2F;a&gt;&lt;&#x2F;sup&gt;だが、レビュアーはその変更の背景や課題、意図や方針、そして実装について理解するために時間も労力も割かなければならない。ある意味ではレビュアーはコストをかけてまでその Pull Request に向き合っているのだ。&lt;&#x2F;p&gt;
&lt;p&gt;私自身、特にここ数年 Pull Request のレビューを多く担う立場となって、このことに気付かされた。&lt;&#x2F;p&gt;
&lt;p&gt;そのようなことを踏まえると、これも当たり前の話ではあるが、Pull Request の Author は、レビュアーがレビューしやすい状態をできる限り整えた上でレビューを依頼するべきだという話になる。&lt;&#x2F;p&gt;
&lt;p&gt;レビューするにあたって知っておくべき情報や、疑問が生じそうな箇所にあらかじめ答えるような Pull Request の Title &#x2F; Description を用意しておく。&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;何がどう変更されているか (概要)&lt;&#x2F;li&gt;
&lt;li&gt;なぜこの変更が必要なのか (背景・課題)&lt;&#x2F;li&gt;
&lt;li&gt;どういう意図の変更なのか (方針)&lt;&#x2F;li&gt;
&lt;li&gt;何を確認してほしいのか (レビューに対する期待)&lt;&#x2F;li&gt;
&lt;li&gt;etc...&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;p&gt;項目を挙げるとこんなところだが、個人的にはAI生成のあの冗長でわかりづらい文章も避けたほうが無難だと思う。
こういった部分は要点を絞って簡潔に伝えるようにしたほうが、読み手にとっては理解に割く労力が軽く済む。
これについては &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;newsletter.vickiboykis.com&#x2F;archive&#x2F;write-for-people&#x2F;&quot;&gt;Write for people - Normcore Tech&lt;&#x2F;a&gt; でも似たような課題感が共有されている。人間が理解しやすい、シンプルな表現が求められている。&lt;&#x2F;p&gt;
&lt;p&gt;その他には、これは私個人の心がけの話になるが、「この人の Pull Request ならまたレビューしてもいいな」と思われるためにはどうしたら良いかを考えている。たとえば、レビュー依頼をするとき、レビューによるフィードバックや Approve をもらったときには、必ず感謝の意を伝えるようにしている。時間や労力を割いてレビューしてもらっているのだから。&lt;&#x2F;p&gt;
&lt;h2 id=&quot;仕事を依頼すること&quot;&gt;仕事を依頼すること&lt;&#x2F;h2&gt;
&lt;p&gt;私たち SWE は Pull Request に限らず、普段仕事をしている上でほとんど必ずといっていいくらい、毎日他の人に仕事を依頼している。
Pull Request、 JIRA のチケット、 GitHub の Issue などの形式にパッケージングされた依頼は、意識しなければ自然に、その仕事を依頼される相手に対する敬意を忘れさせてしまう。あたかも Queue に Job を積めば、その裏で Worker が自動的にそれを処理してくれるかのように捉えがちだが、私たちはそれを実際に処理する人のコストや心理的な負荷を想像する必要がある。&lt;&#x2F;p&gt;
&lt;p&gt;自分の時間と労力を割いて向き合ってくれるのは「人間」であって、 Worker ではない。
AI の普及にともなって仕事のスピードが爆発的に変わってきた今だこらこそ、仕事を依頼する相手への敬意とプロフェッショナルとしての配慮を忘れてはならない。&lt;&#x2F;p&gt;
&lt;div class=&quot;footnote-definition&quot; id=&quot;fn:1&quot;&gt;&lt;sup class=&quot;footnote-definition-label&quot;&gt;1&lt;&#x2F;sup&gt;
&lt;p&gt;&lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;www.manning.com&#x2F;books&#x2F;looks-good-to-me&quot;&gt;Looks Good To Me - Adrienne Braganza&lt;&#x2F;a&gt;&lt;&#x2F;p&gt;
&lt;&#x2F;div&gt;
&lt;div class=&quot;footnote-definition&quot; id=&quot;fn:2&quot;&gt;&lt;sup class=&quot;footnote-definition-label&quot;&gt;2&lt;&#x2F;sup&gt;
&lt;p&gt;ここには「そもそも私が実装してやっているのだから、それに対してレビューするのは当然だろう」という心理が潜んでいるのかもしれない。&lt;&#x2F;p&gt;
&lt;&#x2F;div&gt;
</content>
        
    </entry>
</feed>
