高熟練作業に対する Gen AI の影響：ソフトウェア開発者との実験
(papers.ssrn.com)要約
- 研究概要
- この研究は、Microsoft、Accenture、そして匿名の Fortune 100 電子機器メーカーで実施された 3 つのランダム化比較実験を通じて、生成 AI がソフトウェア開発者の生産性に与える影響を評価したもの。
- 実験は各社の日常業務の一環として行われ、無作為に選ばれた開発者に GitHub Copilot という AI ベースのコーディング支援ツールが提供された。
- 合計 4,867 人のソフトウェア開発者を対象としたこの研究では、AI ツールを使用する開発者の完了タスク数が 26.08% 増加したことが確認された（標準誤差: 10.3%）。
- 特に、経験の浅い開発者ほど導入率と生産性向上が大きかった。
GN⁺の要約
- この研究は、生成 AI がソフトウェア開発者の生産性を大きく向上させうることを示している。
- 特に経験の浅い開発者に有用であり、AI ツールが学習曲線を緩和するのに役立つ可能性を示唆している。
- GitHub Copilot のような AI ツールは、ソフトウェア開発の効率を高めるうえで重要な役割を果たしうる。
- 類似機能を持つ他のプロジェクトとしては、TabNine や Kite などがある。
1件のコメント
Hacker News のコメント
IT人材の質が落ちている理由は、企業が人員削減のために1人にますます多くの役割を押し込んでいるからではないか、と時々思う。
以前は開発、運用、セキュリティがそれぞれ専任の役割だったが、DevOpsが生まれると、一部の企業はチーム統合ではなく、人員を2/3にしてもよいという意味に受け取り、DevSecOpsが生まれると、元の役割の1/3だけいればよく、開発者が運用とアプリケーションセキュリティまでやればいいと考えた。
shift-leftや統合運用モデルそのものを批判しているのではなく、経営陣が人員を減らしてコストを削ればボーナスを増やせると考えるとき、こうしたモデルが生む論理的帰結だという意味。
今や新人開発者は、信じられないほど複雑なn個のマイクロサービス環境に入り、既存コードベース、5本のCI/CDパイプライン、DBAの役割まで学びながら、安定したリリースサイクルにも合わせなければならない。
追いつくためにChatGPTを使うのが本当に驚くことなのかと思うし、IT企業がまともな事業戦略の代わりに「数字を上げる」ために人を減らすのをやめるまで、この状況は続くだろう。
MBAたちが見落としているのは、過剰な制約という現象だと思う。「開発者」という一般的な役割を「開発、運用、セキュリティ」に分けると、それぞれの役割をどうこなすべきかについて、ありとあらゆる細部が生まれる。再びDevSecOpsとして統合しても、その細部はそのまま残るので、1人が3倍効率よく働くのではなく、3倍の仕事を背負うことになる。
きちんと元に戻すには制約を緩め、その1人が仕事をどう進めるか判断できるようにすべきだ。
そこからの結論は、組織規模は小さくなれず、大きくなる一方だということ。従業員が増えるほど職務はより専門化し、彼らをなくすと、その機能は単に実行されなくなる。そのレベルの専門化では、残った従業員が職務記述書を少し変えて新しい責任を背負うのは難しいからだ。
結局、古い組織を捨て、新しく小さな組織としてやり直す必要があり、プライベートエクイティ／ベンチャーキャピタル／スタートアップのエコシステムが存在する理由もここにある。Gallの法則も同じ文脈だ: https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
一方で、最近生まれている新興スタートアップを見ると、本当に才能のある人がどんどん増えている。資金調達がより厳しい環境では、会社を始めるには本物の実力者がより必要で、そういう人たちがまた優秀な人を採るからだと思う。
今のテック業界は、スタートアップに関心のあったほぼ全員が技術的な問題をハックするのが好きで飛び込んでいた2004〜2008年ごろに、ずっと近い感じがする。
Cursorを使ってみた経験では、平凡なエンジニアができる仕事には非常に優れているが、それ以上の高度な作業にはひどく弱く、他人のコードを非常に速く理解する能力も必要になる。
おそらく、フロントエンドやWebアプリ開発に集中していない高度な技術エンジニアが、以前ほど多くのジュニアWeb開発者を雇わなくてもよくなるのだろう。Webページ用の基本的なHTML/CSSを素早く作るフレームワークやツールが登場して、ウェブマスターが消えたのと似ている。
「DevSecOps」人材が本来やるべき仕事の3倍をしているとして、彼らがさらに何をしているのかも見る必要がある。出張予約、経費精算と報告、勤務時間を事業区分ごとに分けて報告すること、休暇管理、会議管理、自作のグラフィックでプレゼン資料を作ること、外部ベンダー購買準備の80%までやっているかもしれない。
こうした仕事は職務記述書にはなく、実際の業務を妨げ、本業を遂行する能力を不均衡に削り取る。以前はこうした仕事ごとに専任の専門家がいて、はるかに安く10倍の効率で処理できた。
秘書、社内グラフィック部門、財務担当者のような専門家は財務諸表に表れていた。その役割をなくしても仕事が消えるわけではなく、セルフサービス型のオフィスソフトが「生産性」を改善するという名目の下、全員に細切れに分散されるだけだ。
その結果、全員が不均衡に遅くなるが、数字だけを見る人たちは廃止した役割の給与から節約できた金だけを見る。遅さは、ぼんやりした一般的な生産性低下の感覚、全員が経験する謎のコスト病としてしか現れない。
謎ではなく、生産性の向上はなく、むしろ損失が生じているのだと思う。ただし、明確で見えるコストを、分散され計算しにくいコストに変えるため、節約できていると錯覚しやすい。
見落としている中核的能力は、会社が属するビジネスを理解する力だ。そこそこの開発能力でも、事業目標への良い理解と組み合わされば、純粋な開発者の一部がAIに置き換えられる中でも、引き続き有効であり得る。
銀行系の会社で13年間、複雑性が大きく増し、ばかげた官僚主義も一緒に増えていくのを見てきた。今でも必要な作業はできるが、アクセス権がない。持つこともできない。
単純な作業が、今では正体不明のPuneチームと10段階の交渉をしなければならないものになり、彼らが実際にやるべきことがあると認識するまで、10回追いかけてエスカレーションしなければならない。
プロセスはばかげたものになり、何かを始めると2日かかるのか3か月かかるのか分からない。すべてのアプリは、新しいネットワーク作業、検証されていないUnixアップデート、あるいは必ず起こる無数の出来事の1つのせいで、継続的に保守しなければかなり早く壊れる。
結局、書類処理をする人たちと、本業も平均レベルの人たちがプロセスの奥深くに居座って勝ち、事業部は低品質なITを提供され、プロジェクトは遅れ、予算も超過する。これが「ひどいが我慢しなければならない悪」であるITというイメージをさらに固める。
もう気にするのはやめたし、仕事は人生のための手段で十分だ。私の焦点と達成感は、その「人生」の側にある。
何を測定するかが重要。この研究は Copilot の使用量だけを見ている
私は経験豊富なエンジニアだが、Copilot は私にとって役に立たないどころか邪魔になる。時間の大半は問題領域を理解し、自分が置かれている環境の制約と可能性を把握し、書くコードを考えることに使っている
実際にコードを打ち始めるときには、何を書くかはすでに分かっているので、「手助け」してくれる Copilot のオートコンプリートはただ気を散らすだけだ。私の作業フローをはるかに悪くする
逆に、実際のコーディング前の段階では AI が非常に有用だ。事前に考えておいた内容をもとに、よく作ったプロンプトだけでドラフトを得られることもあるし、その後に出てくる小さな想定外の問題に素早く答えを得るために LLM とペアを組むのはとても役に立つ
だからこのレポートとは異なり、熟練開発者が AI をうまく使えば、未熟な開発者よりも 大きな利益を得られることもあると思う
しかし Claude Sonnet 3.5 を Cursor や Continue.dev と一緒に使うと劇的に良くなる。コンテキストを明示的に制御でき、例えば 6〜7 個のファイルを選んで注入できるうえ、Claude の優れた能力も加わると、まったく別物になる
作業によっては簡単に 2〜5 倍速くなる。本来なら半日かかり得る作業を、1 時間以内にテスト付きの 100 行程度の本番投入可能なコードにできる
26 年の経験があり、2012 年から principal/staff/lead の役割を担ってきた立場で言っている。ただしシニア未満の経験では同じ向上は期待しない。実際には望む内容をかなり詳細に説明する必要があり、たいていは動く初期解を受け取ってから、6 回ほど磨き込み、理想的でよく分解された形にする必要があるからだ
例えば AWS 向けの IaC を書くときは、調べることが多い。AI に聞けば答えと例を非常に速く得られる。新しいサービスの IaC を学んでいる最中なら AWS のドキュメントを見るが、素早い答えや復習だけが必要なときは AI のほうがずっと速い
関数型パターンにより寄せ、モナドを設計し、入出力は境界でだけ行い、fluent programming を使うほど、効果は非常に大きい
ちなみにこれは Java での経験だ。Java を使って 3.5 年で、Java 8+ の機能に大きく依存している。ライブラリコードでジェネリクスを多用すると、LLM が一貫して正しい選択をする余地が大きくなる
より速く雑に作った設計では、こうした利点はそれほど得られない。Haskell、OCaml、F#、Scala のような本物の関数型プログラミングのユーザーの話をもっと聞きたい
ユニットテスト、特に テーブル駆動テストのボイラープレート作成には役に立ったが、有料サブスクリプションを維持するほどではなかった
慣れていない言語で作業するときや、生成されたコードが妥当かどうかを簡単に判断できる反復作業では非常に価値があった
逆に、自分がやりたいことが非常に明確で、標準的な実装に似ているが少し新しい作業のときには弱くなる。「reduce」や、より曖昧な手順でこうしたことがよく起きる
プラットフォームエンジニアとして Bash、Python、ブラウザ、素の JS、TS、Node、GitHub Actions、Jenkins Java ワークフロー、Docker など複数の領域を行き来しているが、領域を切り替えるときに頭を休ませ、ウォームアップするのには役立つ
この研究に、経験の浅い開発者がAIでコントリビュートしたあと、より経験豊富な開発者が処理しなければならなかった技術的負債が含まれているのか気になる。研究に出てきた企業の1社で、個人的にそういうことをたくさん経験したからだ
また、技術そのものにはあまり関心がないが、デリバリーには強い関心がある開発者ほど、AIにより大きな興味を示すのを実際に見た。PMはそういう人たちを好むが
こちらが依頼したのは5行程度の小さな変更とテストだった。ところが今や、新たな負債だけでなく、なぜ全面的に変わったのか誰も説明できないコード、その一部は変更するための変更にすぎないコード、そしてこのコードを保守する人たちから見てまったく見慣れないコードまで抱え込むことになる
こうしたツールを使う人のうち、シニアエンジニアでない場合にずっと見かける。結局そういうPRは却下してやり直すよう言うことになり、最初に得たと思っていた時間的メリットは消える
こうしたツールが役に立たないという意味ではないが、人々は出力が何なのか理解しないまま使っており、コードベースに及ぼす長期的な影響も理解していない
自分の魂の一部を失った日は、ある開発者にDBスキーマのフィードバックをしてもよいかと尋ね、彼がよいと言った数分後に「はい、自分はXにはあまり関心がありません」と言って打ち切ったときだった
関心がない？ その分野の専門家として、何を改善できるのか、どうすべきか、なぜそうすべきかを伝えているのに、関心がないとは
クラウドは失敗だった。いつでもscale up/outできるのだから、効率性や最適化を追求する必要はないという考えを人々に植え付けた。マイクロベンチマークの話をしているわけではなく、「このデータ構造の代わりにあのデータ構造を使ったほうがよいのでは」くらいの、ごく単純な話だ
社内でも使っているが、技術的負債はきちんと見積もられていない巨大な脅威だと思う
慣れていないAPIやパターンをコードに絨毯爆撃のように適用するには非常に有用だが、注意しないと膨大なコード重複と扱いにくいボイラープレートを生む
理由は大きく2つのバイアスにある。第一に、モデルの学習データがStackOverflow的なサンプルデータなので、コンテキストや制約を考慮しない。第二に、既存のコードベースを見てリファクタリングを提案するより、コピーして繰り返す傾向がある
1つ目は、最終的には自分の仕事をして、LLMが吐き出したものをレビューし編集すれば緩和できる
2つ目は、diffとコミット履歴が学習データに入らなければ緩和できないが、このデータセットは扱いもタグ付けもはるかに難しい。ある変更はリファクタリングのように良いものだが、別の変更は後続コミットで修正されるバグかもしれず、コミットメッセージは実質的に嘘なので明確な区別もない。誰も「バグ導入」とは書かない
さらにmerge、rebase、squashが履歴の意味を変えたり、削除したり、ノイズを加えたりして、すべてをいっそう曖昧にする
自分は技術が好きで、趣味でもソフトウェアを書くが、AIと一緒にやるほうが客観的にずっと楽しい。生産性がはるかに上がり、何より先延ばしがなくなる
行き詰まったり、仕事に取りかかりたくなかったりするときにAiderと会話を始めると、気づけばその日、AIなしではやらなかった作業が1つ終わっている
そのおかげで、以前なら数か月から数年かかっていた公開・非公開プロジェクトを、今では2週間ごとに出している。高速で経験豊富な開発者チームが隣に座っているコストが、1日最大でも数ドルだ
結論に飛びつく前に、論文をもう少し深く見る必要がある。研究自体も、結果の要約をもっと上手くできたはずだと思う
アブストラクトと結論では、結果として生産性が26.08%向上という単一の比率だけを示しているが、小数点以下が多すぎるように見える。少し踏み込むと、ジュニアは27〜39%、シニアは8〜13%という数値が出てくる
さらに深く見ると、経験年数だけでなく会社ごとの差も大きい。Microsoftでは、プルリクエスト以外にコミット、ビルド、ビルド成功率といった他の結果指標は統計的に有意ではないように見える。PRの増加もMicrosoftでは有意に見えるが、Accentureではそうではないようで、しかもそれすらジュニアに限られる可能性がある
アブストラクトと結論では要約が必要なのは分かるが、変数によって結果があまりに変わるので、単一の全体数値を要約として出すことに意味があるのか分からない。特に統計的有意性がかなりばらついて見えるからだ
AccentureはMicrosoftのような大規模組織と協業し、共同マーケティングを行う会社だ。約300人の開発者プールは全体サンプルをほとんど動かせず、AIワークフローをめぐるマーケティング／コンサルティング部門を作っているのだから、客観的だと仮定するのも難しい
3社目の匿名企業は実際にはランダム化比較試験ではなかったため、その結果をRCTとどう統合すべきかは言いにくい。また、大手テック企業の中には同様の実験を行い、有効性を知りたがったところが他にもあったはずなので、結果に含まれているもの以外にもデータがあると考えられる
なぜ、より大きなサンプル集合の中からこの会社たちを選んだのか。おそらくMicrosoftとAccentureには導入のインセンティブがあり、3社目はp-hackingで選ばれたからだろう
特にアブストラクトの「各個別実験にはノイズがあるが、3つの実験を合わせると」という文は、非常に悪い兆候だ。各社だけを見ると統計的に有意な結果はないが、この3集団を合わせると有意になる、という事実上の認めになっている。これは科学ではない
ジュニア開発者は、LLMが当てやすい作業をしているか、最初のドラフトがLGTMに見えるという理由で受け入れるミスをして、スループットが高く見える可能性がある
生成コードモデルを使うにもスキルが必要で、そのスキルは他人に仕事を委任し、複数の作成者による解法をひとつの凝集したシステムへ統合するときに必要なスキルと同じだ
私の直感にすぎないが、LLM支援コーディングは開発者として成長するうえで有害だと思う。生産性を一定の水準までは引き上げられるかもしれないが、その水準はシニアにとっては退屈な反復でも、ジュニアにとっては形成過程そのものだ
私の経験では、LLMは単純なボイラープレートコードだけに使われるのではなく、ジュニア開発者がまだ十分に理解していない、かなり一般的な作業に直面したときに呼び出される。実験し、学び、理解する過程の大部分がLLMに置き換えられ、本当のスキルは、動いているように見えるまでプロンプトを調整することになる
昨夜、初めてLinux RAIDを設定した。ものすごく難しい作業ではないが、mount、umount、fstab、blkid、mdadm、fdisk、lsblk、mkfsなど複数のツールが必要で、途中でガイドの正確な手順とは違う流れになることもあるため、チュートリアルやドキュメントだけを見るのは特に役立つわけではない
各ツールと各ステップについて何十もの質問をした。以前なら、ただコピー＆ペーストして祈っていただろう
2日前には、壊れたSSDからすべてのデータを復旧するのもChatGPTで学びながらやり遂げた。20%は間違っている可能性があっても、公開インターネットの平均よりはるかに良い「ガイド」がある状態で、まったく新しい技術に取り組めるのは本当に良かった
学ぶことが好きな人にとっては、インターネット上のゴミを延々と漁るのに比べて、七里の長靴のように感じる。もちろんインターネット上の他のすべてと同じく、AIの言うことも疑うべきだが、手間をものすごく減らしてくれる
私も同じ直感を持っていて、さらに言えば根拠のある強い意見と呼びたい。数年後に業界はその代償を払うことになると思う
「勘の良いジュニアソフトウェア開発者」の供給パイプラインは大きく枯れ、「AI依存のジュニアソフトウェア開発者」の洪水に置き換わるだろう。この2つのカテゴリの間には深い谷がある
当然、それは勘の良いミドル開発者、勘の良いシニア開発者の数にも連鎖的な影響を与える
一方で、自分が使うコードをすべて理解したい人は、LLMが出したもののうち分からない部分を調べる可能性が高い
少なくとも私はそう使っている。そしてこの仮説への反例を挙げるなら、LLMが私の知らなかった関数やライブラリのコンポーネントを使うことがあるので、新しい言語やツールキットを学ぶときに大いに時間を節約してくれる。私にとっては学習を遅らせるのではなく加速している
しかし、いずれにせよ成功する人たちにとっては、StackOverflowに質問を投げて、即座に、しかも非難されることなく答えを得られるようなものなので、本当に大きな贈り物だ
常に正しいわけではないだろうが、StackOverflowもそうだった。結局、いつものように個人次第だ
50年前には何かを作るには事実上必須だった機械語を、今の開発者のうちどれだけが書けるだろうか
LLMがまたひとつの抽象化の松葉杖から、堅牢な抽象化の柱へ変わりつつあるのかもしれない
この研究で最も興味深い点は、キャリア水準で分けたとき、在職期間が中央値より長い開発者では、「生産性」という出来の悪い代理指標に統計的に有意な増加が見られないことです。95%信頼区間はどの指標でもマイナス側に深く入り込むことがあり、ただわずかにプラス側へ傾いているだけです
自分の経験とも合っています。Copilotは退屈な作業の一部を減らし、より深い問いに頭を使えるようにしてくれる点では良いのですが、ジュニア開発者が言うような世界を変えるレベルではありません
また、しばしば微妙に間違っていて、経験の浅い開発者なら見落としそうな形です。私は生成されたものの大半でいったん止まって調整する必要があり、熟練度の低い開発者はその調整をどうすればよいか分からない可能性が高いです
数年使ってみて、今ではCopilotをいつ使い、いつ使わないべきかについてかなり勘がついてきたので、純効果はプラスだと思いますが、常にそうだったわけではありません
また、シニア開発者の「生産性」が下がったように見える理由の一部が、社内のジュニアの生産性向上によるものなのかも気になります。ジュニアがより多くのPRを作り、そこにミスが増えてレビュー時間が延びれば、シニアの生産性向上はそれに比例して小さくなり得ます
26%の生産性向上は、私の経験ともおおむね一致します。さらに見るべき軸は、新しい技術を扱っているのか、すでに慣れている技術を扱っているのかだと思います。AIは、私が学ぼうとしている言語やフレームワークではずっと役に立ちます
Bashで条件文を書くには正確にどんな引用符の呪文が必要なのか、といった補助的な言語の特異点や落とし穴を、私はよく覚えていません。そのため以前は、自動化のためのBashスクリプトはほとんど書かず、十分に頻繁に行う作業のときだけ労力をかけていました。jqでJSONを処理したり、AWKでパースしたりするのも同じでした
今ではLLMのおかげでBashスクリプトをずっと多く作るようになり、あまりに簡単になったのでプロセス文書化にもより頻繁に使っています。以前なら静的な手順書READMEだったものが、今ではユーザー入力を受け付ける対話型Bashスクリプト付きで提供されます
概して、シニアプログラマーがAIツールがなぜ機能しないのかを論じているのをよく見ます。ジュニアは先入観なくただ使います
役に立った場面は4つありました。第一に、QtやCSSのように自分が頻繁には使わないが、サンプルコンテンツが多いフレームワーク/言語についての質問
第二に、本来ならGoogle SearchやStackOverflowで探していたであろう非常に具体的な質問。たとえば「PythonでWindowsのCPUとRAM使用率を最も効率よく取得する方法」のような質問では、コピペするコードを直接作るというより、ライブラリや例を示してくれます
第三に、すでに書き方は知っているが少し時間を節約し、タイプミスを減らしてくれる定型コード。PyCharm用のCoPilotプラグインを使い、ファイルにコメントで意図を書くと、次の数行を補完してくれます。これも非常に短く具体的なときに結果が最も良いです。長くなるとCoPilotとのやり取りを繰り返しすぎる必要があり、もはや価値がなくなります
第四に、ドキュメントを素早く検索する方法
単体テストの作成に良いと言う人もいますが、私にはそうではありませんでした。少なくとも私が望む種類の単体テストではありませんでした
数値化するなら、生産性が5〜10%上がる程度だと思います。Notepadの代わりにPyCharmのような本格的なIDEを使うことや、CLIでgitコマンドを直接打つ代わりに優れたgitクライアントを使うことより、ずっと小さいです。つまり数ある生産性ツールの1つにすぎず、「革命的」とは言いません
巨大なRuby on Railsプロジェクトで約10日間Cursorを使ってみました。このスタックは13年以上使ってきました
GitHub Copilotがすでにもたらしていた生産性向上以上のものは得られませんでした。Copilotによる向上はおよそ25%程度だと見積もっています
しかし空のフォルダからNode.jsのような新規プロジェクトを初めて作る場合は、不気味なほど強力です。プロンプトだけで、OpenAPIスキーマからリクエストを処理し、swaggerでOpenAPIスキーマを提供するAPIを約5分で作れます
ただし新規プロジェクトをゼロから始めることは私にはまれなので、おそらくCopilotと標準のVSCodeに戻ると思います
人々がより多くのPRを作れるようにしてくれます。わあ、すごいですね。誰が気にするのでしょう
QAを通過する項目数は増えるのでしょうか。AI支援で作られたものは、QA後に見つかるバグが少ないのでしょうか。後から拡張や修正がしやすいのでしょうか、それとも硬直的で柔軟性のない設計なのでしょうか
開発者を品質不明のコードモンキーに変えるツールは、私が求めているものではありません。開発者が自分の作業にあるバグや設計上の欠陥を見つけるのを助けるツール、あるいはよく設計されたテストを書けるようにするツールが欲しいのです
PR数だけを数えても、有用なことは何も分かりません。むしろ単位時間あたりのコードが増えると平均品質は下がる、という私の直感を刺激します
Copilot: 「いいですよ、やっておきます！新しいコミットです！」
シニア開発者: 「なぜ？変更はアトミックです。経営陣が月間変更件数みたいな馬鹿げた指標をまた持ち出したら、丁寧に失せろと言っておきます」
これはおそらくGPT-3.5ベースのCopilotだった可能性が高いです
Microsoft: 2022年9月〜2023年5月3日
Accenture: 2023年7月〜2023年12月
匿名企業: 2023年10月〜?
Copilot ChatのGPT-4アップデートは2023年11月30日でした: https://github.blog/changelog/label/copilot/
私にとってAIはドキュメントを復活させてくれた。新しいフレームワークはドキュメントがあまりにも不足している。私にとって最後に良かったドキュメントはDOSの本だった。最近の開発者は、良いドキュメントがどんなものか見当もつかないのではないかと思う
それでもAIは毎回違う提案をすることがあるので、判断は依然として経験豊富な開発者がしなければならない。結局、AIはドキュメントとタイピングを置き換えるものだ
公開プロジェクトなら、ドキュメントはLLMの学習データの一部になっているため、ドキュメントが徹底して正確であることがはるかに重要になった。多くの開発者がそのシステムから答えを得ることになるからだ
非公開プロジェクトなら、ドキュメントをfine-tuningデータセットやRAGシステムに入れて同じ効果を得られる
何もドキュメント化されない理由を説明しているのかもしれない
だから実際には、開発者にコードをよりきちんとドキュメント化させる効果もある
必ずしも現代的なライブドキュメントである必要はなく、何でも構わない。昔の何がそれほど素晴らしく、私たちが何を失ってしまったのかを見て、その一部を自分のドキュメントに取り入れてみたい