ryantsuji.dev

非エンジニアが本番にPRを出し、ハーネスが品質を担保する ── 改修フェーズの民主化（連載Part 5）

18 min read

目次

  1. 連載一覧
  2. いきなり1つのシーンから
  3. 比率の話ではない ── 「必要になったタイミングで、自分で直せる」が本題
  4. 実際にマージされた非エンジニアPR ── 直近3件
  5. 何ができて、何ができないか
  6. 線引きの原則: stackの追加は難しい / stackがあれば追加はできる
  7. エンジニアが残るのは「レールを敷く側」── stack立ち上げと、ハーネス自体の整備
  8. なぜ非エンジニアでも本番にPRが出せるのか
  9. ① cpgが「やりたいこと」から関連コードを引いてくれる
  10. ② Auto Reviewが品質を機械的に強制する
  11. ③ Self-Healingが事故ったときの後処理を持つ
  12. ④ Recurrence Preventionで罠が増えない
  13. その先 ── cortexの外へ、本番toCサービスへ
  14. コンテキストの問題はSPGでかなり解決できる
  15. しかし求められる品質水準が違う
  16. 解 ── AIに下準備を任せ、人間が最終確認を担う
  17. まとめ

みなさまこんにちは！エアークローゼットでCTOをしている辻です。

Part 1（総論）で、cortexのハーネス ── AIを本番で動かすための土台、Part 1-4で順に解説してきたcpg / Auto Review / Self-Healing / Recurrence Preventionの組み合わせ ── が組み上がってきた結果、エンジニアではないメンバー（事業サイドのマネージャー、PMOなど）も本番リポジトリにPRを出せるようになってきた話を書きました。Part 5はその続きで、そのハーネスが「誰が書くか」のレイヤーまで波及している話です。

「いやでも、品質をAIレビューに任せきって本当に大丈夫なのか」「結局エンジニアが事後にチェックしているんでしょう」と思う読者が多いはずなので、本記事はまず実例を1つ詳細に見せるところから始めます。

Part 5では、

  1. どんなPRが実際にマージされているか（直近3件の中身を具体に）
  2. 何ができて、何ができないか（既存stackの上に乗せる作業と、stackを立ち上げる仕事の境界線）
  3. なぜ非エンジニアでもこれが成立するのか（Part 1-4で積み上げてきた仕組みとの関係）
  4. その先 ── cortexを超えて本番toCサービスへ（Service Product Graph構想 + 品質水準の違い）

を実例ベースで整理します。詳細なtoCスケール側の実装話は別記事に切り出す予定なので、本記事では構想と方向感まで。

連載一覧

# テーマ キーシーン 記事
1 総論：cortexのハーネス PRが無人マージ / 障害が気づく前に治っている ai-harness-intro
2 Product Graph (cpg) コード・ドキュメント・DB・インフラを1グラフに統合 cortex-product-graph
3 AI PRレビュー webhook → AIレビュー → 自動修正 → squash merge cortex-auto-review
4 Self-Healing + Observability + 自動lint追加 アラート → AI調査 → 修正PR + 新規lint/型gate → 自動再デプロイで同じ書き方を機械的に弾く cortex-self-healing
5 ハーネスをtoCサービスに広げる 業務要件を把握している人が本番に直接PR / cortexの型をtoCサービスへ広げる構想 本記事 ←現在地
6 連載総括 根底にある思想（何を捨てて何を取ったか / なぜこの設計か）を中心に、失敗と学びも振り返る 準備中

いきなり1つのシーンから

社内ダッシュボードのWebアプリに +1,742行 / 41ファイル のPRが立ちます。タイトルは「PL dashboard ver.2」。内容は、複数部門のマネージャー / チームリーダーが自部門・自チームの案件をDiv / Teamスコープで閲覧できる機能の追加。共有型定義パッケージへのSSoT追加、APIサーバー側の新ルート + SQL（INNER JOIN + LEFT JOIN）、Webアプリ側の新ページ + 表示制御 + 個人設定（ニックネームを8bitピクセルフォントで表示する遊びも含む）── ひと通り入っています。

注目してほしいのは、これが「タイポ修正」でも「文字列の差し替え」でもない、ということ。entity / repository / APIルート / 画面 / フィルタ / 個人設定 ── 普通の機能追加で触る層は一通り触っています。スケール感としては1人のエンジニアが数日かけて書くサイズのPR。

レビュー往復はこんな感じで進みます。

  1. PR open（+1,742 / 41 files）
  2. auto-review 1回目: Major指摘（権限スコープのfall-through ── 想定外のDivにデータが見えてしまう経路）+ Minor数件
  3. author修正push: scope fall-throughを塞ぐ + Minor対応
  4. auto-review 2回目: Nit残り、追加でeslint no-empty-functionを発見
  5. author修正push: lintも解消
  6. auto-review 3回目: まだ細部にCOMMENTED（まだAPPROVEしない）
  7. author修正push（iteration 2）: loading skeletonの強化 + 不要だったJSDoc修正のrevert
  8. auto-review 4回目: APPROVED → CI green + APPROVEが揃った瞬間にauto-merge → 本番反映

PR openからmergeまで レビュー往復4回 / 修正push 3回、その間に人間レビュアーは1人も介入していません。レビューは全部AI（auto-review bot）、修正はauthorがClaude Code経由で対応、最終的にAIがAPPROVEをsubmitしてauto-mergeスクリプトが拾ってmerge → デプロイ。テストはType SSoT 56/56・API 2,284/2,284・Web 1,113/1,113・oxlint 0 errorsの状態で本番反映しています。

特に2番目のレビューで返ってきた指摘 ── 「scopeのfall-through」── はやや専門的で、権限スコープに穴があってデータが想定外のDivに見えてしまうというセキュリティ寄りの問題でした。これを初回レビューで自動的に検出して、authorに修正を要求できているのが、ここで起きていることの本質に近い。非エンジニアがコードを書いても、AIレビューがMajor級の指摘を返して直させる ── この往復が回ってないと、ここまでのスケールのPRを非エンジニアに任せるのは無理筋です。

そして、このPRのauthorはエンジニアではない。事業サイドのメンバーがClaude Codeに「こういう画面を作りたい」と要件を渡して、cpg（Part 2）で関連コードを取得しながら、+1,742行の機能を実装した結果が、上の4往復です。

これが本記事の主旨につながります ── 業務要件を一番把握している人が、要件を整理してエンジニアに依頼するのではなく、自分でそのまま書く。品質はハーネスが担保するので、書く側に求められるのは「業務要件の理解」と「Claude Codeに投げて、レビュー指摘を受け止めて直す」までで足りる。+1,742行 / 41ファイルの規模でも、これが成立しているというのが上のシーンです。

比率の話ではない ── 「必要になったタイミングで、自分で直せる」が本題

最初に立場をはっきりさせておきます。本記事は「非エンジニアがコミット総量のX%を占めるようになった」というような比率の話ではありません。事業サイドのメンバーにとってコードを書くこと自体は本業ではないので、コミット量で測ると当然少ない数字になります。

論点はそこではなく、

必要になったタイミングで、必要な修正をエンジニアに依頼せずに自分でできる

という能力が成立しているかどうかです。これが成立すると、

といった業務側で発生する細かな要求が、エンジニアの優先順位待ち行列に詰まらず、その場で解決される。

従来の動線を思い出してみてください。業務側にちょっとした修正の必要が生じたとき、まず誰かが要件をテキストに起こして、エンジニアにSlackやチケットで依頼します。エンジニア側は他の本筋タスクの合間で見る必要があるので、優先順位の中で何日か待たされる。実装が始まっても要件の解釈が業務の認識とズレていて差し戻しが入り、レビューが入って、最終的に本番にデプロイされるまで、ちょっとした修正でも実時間で数日から1週間程度かかる、というのが普通でした。

これは業務理解とコードの間に翻訳レイヤーが挟まるから起きていることで、しかもエンジニアの本筋タスクが詰まっているほどこの遅延は長くなります。事業側の改善サイクルが、エンジニアのキュー長によって決まる構造になっていた、と言い換えてもいい。

本記事の本筋はここです。比率ではなく事業速度の話で、業務要件を把握している人が自分で書けるようになると、上の翻訳レイヤーと待ち行列が丸ごと消える。

業務要件 → 本番反映までの動線。翻訳レイヤーと待ち行列が消えることで、数日〜1週間 → 数時間に短縮される

以下、その能力が成立している実例を3件、具体に見ていきます。

実際にマージされた非エンジニアPR ── 直近3件

PR 種別 規模 内容
#1688 再発防止（docs） +1 / 1 file merge-blocker botが誤検知する文字列をPRタイトルに使わないよう注記をdocs/gotchasに追記。自分が踏んだ罠をドキュメントに固定化するパターン
#1573 バグ修正（深い） +348 -177 / 7 files 週次KPIの月内累計実績が目標を不当超過する問題を修正。assignee_group_name集計がNULLのPMO/デザイナーチームをWIPに算入していた根本原因を、engineer-team-allowlist.tsで対称化することで解消。testも併せて追加
#1557 既存stackへの大型追加 +1,742 -227 / 41 files 冒頭シーンで取り上げたPLダッシュボードv2。API + UI + entity + repositoryまで一通り実装、ただしWebアプリ自体（stack）は既存で、その上に重ねた追加

この3件は、それぞれ違う 非エンジニア参加のパターン を示しています。

#1688 ── 再発防止ループへの参加

たった1行のドキュメント追記ですが、構造上は非常に重要な参加形態です。経緯はこうです。1つ前のPR（後で取り上げる#1573）のタイトルに「WIP集計」という業務語彙を含めたところ、リポジトリに入っているmerge-blocker botがそれをWIP（Work In Progress）と誤検知してマージをブロック。半日ほど開発が止まる事故になりました。

これに対するこのPRの動きは、「事故が起きた → 自分のPRだけ直してmerge」ではありません。authorは「同じ罠を他の人が踏まないように」と判断して、docs/gotchas（既知の落とし穴を集めたドキュメント）に「PRタイトルにWIP / do not merge等の文字列を含めないこと」という注記を加えました。

これはPart 4で書いた Recurrence Prevention（再発防止）のループそのものです。罠を踏んだ人が、その罠を全員のレールに固定化する。docs/gotchasはAIレビュアーも参照するので、次に同じ業務語彙でPRタイトルを書こうとした人がいたら、レビュアーが警告を出す ── という連鎖が作れる仕組みになっています。

たった1行の追記ですが、非エンジニアがRecurrence Preventionのループに自発的に参加している事実は、この記事の中で構造上最も重要かもしれません。

#1573 ── 深いroot cause修正

「数字がおかしい」という事業側の気づきから、データ整合性レベルの根本原因に降りていったPRです。表面的な現象は「週次KPIの月内累計実績（= 完了 + 週末WIP）が、月内累計目標を不当に超えていて、達成判定が誤って 101% を示す」。普通なら数字を合わせる係数を足してお茶を濁すか、表示側でクランプするかで済ませてしまいそうな話です。

ところがauthorは集計クエリまで掘っていって、根本原因を以下のように特定しました。WIP/完了側の集計がassignee_group_name = 'pi_pdg'でかかっていた一方、目標側はcapacity_by_team_monthテーブルを使っていて、デザイナー（pi_idt）やPMO（pi_pmot）などexpected_powerがNULLのチケットは目標側には計上されない。つまり、目標と実績で「どのチームを集計対象にするか」の定義が非対称になっていた、ということです。

修正は症状ではなく構造のほうに当てています。新しくengineer-team-allowlist.tsというファイルを切って、PDG_ENGINEER_TEAM_NAMES / ACE_ENGINEER_TEAM_NAMESを定数で固定し、目標側も実績側も同じallowlistで対称的にフィルタするように直しました。今後同じ非対称を組まないよう、型レベル（共通定数の参照）で縛るところまでやっています。

データ集計のNULL扱いと、目標 / 実績の対称性 ── これはエンジニアでも見落としやすい論点です。それを非エンジニアがroot causeまで降りて構造レベルで直しているのが、このPRの特徴です。

#1557 ── 既存stack上の大型機能実装

冒頭シーンで詳しく取り上げたPRです。+1,742行 / 41ファイル / entity / repository / API / UIまで揃った機能追加で、一般的な「改修」イメージよりはるかに強いスケール感です。

ただし重要なのは、Webアプリ自体（stack）は既に立っていること。新しいアプリを立ち上げるのではなく、既存の社内ダッシュボードに「PLダッシュボードv2」という新しい機能を1つ足している、という位置取りです。Pulumi / Cloud Run / Dockerfileに手を入れる必要は無く、新しい依存パッケージを追加する必要も無く、既存ディレクトリ構造の中で、新しいルートとページを追加して既存のrepository patternに乗せただけ。

このstackの上に乗せる範疇に収まっているからこそ、非エンジニアでも書ける。「改修」と呼んでいるのは、こういう位置取りに収まっていることを言いたいからです。次節で線引きをきれいに整理します。

補足: 本記事で「改修」と呼んでいるのは、一般的な「既存ロジックの細かい修正」よりかなり強い範囲を指します。新しいentity / 新しいendpoint / 新しいページの追加までこちらに含めていて、stackを立ち上げる作業との対比で線を引いています。

何ができて、何ができないか

線引きの原則: stackの追加は難しい / stackがあれば追加はできる

非エンジニア開発の境界線は「改修 vs 新規」よりも、「既存stackの上に乗せる作業か / 新規stackを立ち上げる作業か」で引いた方が実態に近い。

直前で見た3 PRは全部 既存stackの上に乗せる作業 に収まっています。stackそのものは既に自分が作ってあるものなので、その内側で動ける。逆に「アプリを0から立ち上げる」「インフラ定義（Dockerfile / IaC）から構築する」は今のところ非エンジニアが触っていない領域です。

別の言い方をすると、「家が建っている上での内装変更や部屋追加」は非エンジニア可、「家自体を建てる」はエンジニアです。家の構造（柱や梁の配置、配線、配管）が間違っていると後から取り返しがつかないのと同じで、stackの設計には事故の波及範囲が大きい判断が含まれていて、ここはまだAIに任せきれていません。

エンジニアが残るのは「レールを敷く側」── stack立ち上げと、ハーネス自体の整備

逆に言うと、レールを敷く側 ── stackを立ち上げる作業（新しいアプリを0から作る / 新規でCloud Run等をDockerfileから定義する / 新しいpipelineを1から組む）と、ハーネス自体を設計・拡張する作業 ── は今のところ非エンジニアが触っていない領域です。どちらも、そこには別領域の知識が要るから:

最後の「ハーネス自体の設計・拡張」は地味に重要な含意があって、非エンジニアが本番にPRを出せる状態を維持し続けるためには、誰かがハーネスを進化させ続けないといけない。Part 4で書いたRecurrence Preventionは罠ごとにlint / CI guardを増やす自動運動でしたが、ハーネスそのもののアーキテクチャ ── lensの構成 / 9 lensの判定基準 / Self-Healingのフロー設計 / cpgの構造 ── は別のメタ層で、ここはエンジニアの判断が要る。

具体例で言うと、いま9つあるAuto Review lens（[Graph] / [Architecture] / [Security] / [Test] / [Doc] / [Impact] / [Observability] / [AI-Antipattern] / [Recurrence]）の枠組み自体は、過去の事故と修正パターンを観察した結果として誰かが設計したものです。10個目のlensが必要になったとき ── 例えば「依存パッケージのアップグレード時のbreaking changeチェック」のような新軸が必要になったとき ── 既存のlensとの責務分担をどう切るか、判定の閾値をどう決めるか、というのはハーネス全体の構造を見ながらの判断になります。これがエンジニアの残された仕事の代表例です。

ハーネスが提供しているのは「逸脱しないレール」であって、レール自体を敷く仕事 ── インフラを立てる側も、レール（= ハーネス）そのものを設計する側も ── は別の仕事として残ります。レールを敷くのはエンジニア / レールの上を走るのは誰でもできる ── これが現状の境界線です。

境界線 ── 上層は非エンジニア領域、下層はハーネスとstackの整備 (エンジニア領域)

なぜ非エンジニアでも本番にPRが出せるのか

ここはPart 1-4で書いた要素がそのまま効いてくるので、復習として簡潔にまとめます。4つの仕組みが互いに強化し合うフライホイールになっているから、非エンジニアでも既存stackの上で安全に手を入れられる、というのが結論です。

① cpgが「やりたいこと」から関連コードを引いてくれる

Part 2 で書いたcortex-product-graph ── コードとドキュメントとDBスキーマとインフラ定義を1つのナレッジグラフに統合した知識基盤 ── がここで効きます。

非エンジニアが関数名やリポジトリ構造を知らなくても、自然言語で「ダッシュボードの指標カラムを増やしたい」とClaude Codeに投げれば、cpgがセマンティック検索で関連ノード（画面 / API / DB / docs）を1〜2ホップで取得します。技術用語を知らなくても入口に立てるのが大きい。

冒頭シーンの#1557を例にすると、authorは「PLダッシュボードv2で、PMO / チームリーダーが自部門・自チームの案件をDiv / Teamスコープで見られるようにしたい」という要件をClaude Codeに投げて、cpgが既存の/projectsルート、project-repository.ts、FilterHeaders.tsx、ProjectTable.tsxといった関連ノードを引いてきています。authorは「どのファイルを編集すべきか」を最初から知っている必要が無い。これが翻訳レイヤーを抜く土台になっています。

② Auto Reviewが品質を機械的に強制する

Part 3 で書いた9 lensの自動レビューが次の層です。

PRを出した後、[Graph] / [Architecture] / [Security] / [Test] / [Doc] / [Impact] / [Observability] / [AI-Antipattern] / [Recurrence]の9つの観点で漏れをREQUEST_CHANGESとして返す → authorが直す → APPROVEまでループします。初回PRで完璧である必要がないことが、非エンジニアが本番にPRを出せる前提を作っています。

冒頭シーンの4回のreview-fix iterationを思い出してください。1回目でscope fall-throughというMajor指摘、2回目でeslint no-empty-function、3回目はNit残り、4回目でようやくAPPROVE ── という流れは、人間レビュアーの代わりにAIが粘り強く指摘を返し続けている結果です。authorはこのループに沿って直していけばよく、最初からセキュリティ穴を埋めた完成形を書く必要は無い。

特に重要なのは[Security] lensです。冒頭シーンで検出された「権限スコープのfall-through」── 想定外のDivにデータが見えてしまう ── は、本番に出てから気付いたらインシデント級の問題です。これを初回レビューで自動的に検出して修正させているから、非エンジニアにPRを書かせても破綻しない。

③ Self-Healingが事故ったときの後処理を持つ

Part 4 で書いたSelf-Healingが3つ目の層です。

万が一productionで異常が出ても、AIがアラートを起点に原因調査 → 修正PR → 自動再デプロイで完結します。非エンジニアが踏んだ事故も人手を介さず復旧できるので、本番にPRを出す心理的ハードルが大きく下がる。

これは「非エンジニアでも書けるから安全だ」という主張ではなく、「書いた後に何か起きてもハーネスが拾う」という事後の安全網があることが、入口を広げられる前提になっている、という話です。失敗の可能性をゼロにする方向ではなく、失敗してもダメージを最小化する方向で設計してある。Part 4の3層構造（Observation → Repair → Strengthening）が、この事後安全網の中身です。

④ Recurrence Preventionで罠が増えない

最後に、Part 4の後半で書いたRecurrence Prevention（再発防止ループ）。

一度踏んだ罠は同じPRの中でlint / CI guardとして固定化されるので、次に同じパターンを書こうとしてもCIが弾く。冒頭シーンの#1688（bot誤検知パターンをgotchasに追記）のように、非エンジニア自身もこのループに参加します。

これが効いてくると、ハーネスのレールは時間とともに細かくなる。最初は「ここを通っちゃダメ」という大まかな線しか無かったところに、事故を踏むたびに「ここも、ここも、ここも」と細い線が追加されていって、結果として「迷い込みにくいレール」ができていく。非エンジニアにとっては、レールの密度が高いほど安全に走れる ── という構造になっています。

→ この4つは独立したパーツではなく、互いの出力が互いの入力になる設計です。Part 1のGuides + Sensorsのフライホイールの話そのまま。詳細はそれぞれの記事に書いてあるので深入りしませんが、非エンジニアが本番にPRを出せている現象は、この4輪が同時に回っているから初めて成立しています。1つでも欠けると、書く側に求められる前提知識が一気に増えて、すぐに崩れます。

その先 ── cortexの外へ、本番toCサービスへ

ここまでは「cortex内部」の話でした。cortexは社内AI基盤であって本番toCサービスそのものではありません。事業の中核を担う本番サービス側にも同じハーネスを持ち込めると、影響は社内ツール領域を大きく超えます。本記事は構想までしか書きませんが、何が同じで何が違うかだけ整理しておきます。

コンテキストの問題はSPGでかなり解決できる

cortexがうまく回っている最大の要因は cpg ── コード・docs・DBスキーマ・インフラを1グラフに統合した知識基盤 ── にあります。AIが「何を見て・何を考えるべきか」の入口をcpgが提供しているから、Auto Review / Self-Healing / Recurrence Preventionの精度が成立する。

そのcpgの発想を既存サービス向けに工夫して構築したものがService Product Graph（SPG）です。ひと言で言えば「サービス側40+リポジトリ横断のナレッジグラフ」── 本番toC側はリポジトリがそもそも40以上に分かれている（フロント / バックエンド / バッチ / 管理画面 etc.）ので、それらを横断するグラフとして作っています。

cortexの場合はリポジトリ1つの中にコードもdocsもインフラ定義も全部入っているので、cpgを作る難易度は比較的低かった。これに対して本番toCは、業務ドメインごとに別リポジトリに分かれていて、しかも各リポジトリの言語やフレームワークもまちまちです。同じ「ユーザー」概念を扱うコードがフロントとバックエンドで別の表現になっていて、それぞれが別チームのメンテ下にある ── という現実とどう折り合うか、というのがSPG側の固有の難しさです。

ここは詳細な構築方法や活用例を別記事で展開する予定なので、本記事では割愛します。要点だけ言うと、SPGが入れば、コンテキスト解決の問題はcortexと同じレベルで対処できる見通しがついている、ということです。

しかし求められる品質水準が違う

cortexとtoCの最大の差は、許容できる事故の重さです。

cortexの場合、最悪「社内ユーザーが30分使えない」程度の影響に収まりますが、toCサービスの障害はそのまま売上に直結し、ユーザー体験を毀損し、SNSにスクリーンショットが流れます。「気づく前に直っている」ことを売り物にできるcortexのSelf-Healingモデルは、toC側ではそのままは持ち込めません。

つまりcortexのauto-mergeループはそのままではtoCに持ち込めない。Part 1で紹介したFowlerのGuides / Sensorsの枠で言えば、Sensorsの側にもう一段「人間」を入れることが要求されます。

解 ── AIに下準備を任せ、人間が最終確認を担う

ではどう設計するかというと、cortexでAIに任せていた部分をそのまま手放すのではなく、人間最終確認の前段までをAIが整える形にシフトします:

結果として、人間が見るのは「もう一通り検証が済んでいるPRのsign-off」だけになります。cortex内部のhuman-on-the-loopはそのままに、toC側だけ最後の輪っかを少し小さくして人間を残す、というイメージです。

「人間がsign-offするなら結局エンジニア時間は減らないのでは」と思われるかもしれませんが、重要なのはサイクル全体の時間配分です。従来エンジニアが時間を使っていたのは「実装 + テスト書き + テスト環境準備 + 自己レビュー + 他者レビュー対応」の全部で、sign-offはそのうちのごく一部にすぎません。AIが前段の大半を担うことで、エンジニアが投じる時間は「最後のsign-offに判断を集中させる」形に圧縮される。書く側（= 業務要件を把握している人）も別に増えるので、トータルの処理可能量は確実に増えます。

加えて、sign-offに専念できるとき、エンジニアの判断は実装の細部ではなく**「この変更を本番に出してよいか」というメタな観点に向かいます。これは従来「実装が忙しくて判断に時間が割けない」状況とは質が違って、エンジニアの仕事の中身が実装作業者から品質ゲートキーパー**にシフトする、と言い換えてもいい。

このあたりは構想段階で、詳細は別記事に切り出す予定です。本記事では「cpg → spg / cortexの品質基準 → toCの品質基準 / auto-merge → AI下準備 + 人間sign-off」という形に変形して持ち込む、という方向感までを書きました。

cortexの型をtoCサービスに変形して持ち込む ── cpg → SPG / auto-merge → AI下準備+人間sign-off / Self-Healing自動 → 人間最終判断の3点が変わる

まとめ

次回 Part 6 は連載全体の総括です。中心はそもそもどういう思想でこれをやっているのか ── 何を捨てて何を取ったか、なぜこういう設計を選んでいるのか、という土台の話。あわせて、ここまでの記事では「うまく回っている結果」を中心に書いてきたので、その裏で踏んできた失敗・つまずきも振り返って、思想と実装のあいだのギャップも整理したい。自分自身の振り返りでもあり、同じようなことを始めようとしている人にとっての参考にもなれば、と考えています。

comments (0)

まだコメントはありません。