初めに

この記事は、株式会社ネオジニアで実際に運用されているワークルール（の一部）の紹介です。

会社概要

2012年創業、この記事の公開時点では10年目、社員数は 8名です。
受託開発がメインで、SES事業も少しやってます。自社サービスも開発中です。
開発環境は MacBook pro で、VirtualBox 上の CentOS にてDockerコンテナで実行環境を動かす方式がほとんどです。
主に Rails や .NET で提案することが多いです。インフラやスマホアプリもやってます。
GitHub, Redmine を組み合わせてプロジェクト管理しています。
スクラム開発をベースに日本の受託開発の商習慣にマッチするよう改変した開発プロセスを採用しています。
フルリモート出来る環境を構築済みです。今は Gather でバーチャルオフィスを運用しています。

なぜワークルールが必要か

リモートワークに移行したのは良いが、生産性が下がってしまっていた。

ワークルール制定前は、以下のような課題がありました。

リモートワークでは、メンバーの様子が見えないため進捗状況が雰囲気で把握できなくなり、これまでのプロジェクト管理方式ができなくなった。
PC画面や手元がみえないため、エディタやツールの操作を教えあったり、非効率なやり方を発見できなくなった。
画面が見えないため、相談の際にソースコードを読み上げられても理解できない。
結果的に、生産性が落ちてしまっていた。
コミュニケーションの減少、メンバーが協調して動くことが出来なくなっていた。

運用してみて

ワークルールは作っただけでは駄目で、毎日これが出来ているか自己評価する時間を設け、運用していく必要があります。
最初のうちはとまどいや、なかなか浸透しない部分もありましたが、だんだん慣れてきて、チームに広く浸透するようになると、各メンバーの行動が変化してくるのが実感できました。
実際に数ヶ月運用してみた後の、エンジニアからの感想を紹介します。

エンジニアからの感想

自分の行動を振り返ることが増えた
チームでキーワードなどの認識を統一できて、一体感が出た
コミュニケーションが増えた
誰かと一緒に作業するのが増えた。今までは皆が別々に仕事していて、自分から話しかけに行くことがほとんどなかった

効果

ワークルール制定後は、以下のような改善がありました。

リモートでのコミュニケーションのしにくさを全員で認識し、やり方を工夫した
メンバー自身が自立してタスク管理を行いはじめた
画面共有を先にしてから、確認や相談をするなど、手順が確立され効率が改善した
手戻りが減ってきた

公開にあたって

リモートワークでの課題に困っている企業は非常に多いと思います。
自社で上手く回り始めたワークルールを広く知ってもらい、少しでも皆さんのヒントになればという思いから、公開に踏み切ることにしました。
弊社ではスクラムに近い開発プロセスを採用しており、その辺の前提知識がないと理解できないような箇所もありますが、雰囲気だけでも伝われば十分かなと思います（その辺はまた機会があれば記事にしたいと思います）。
このワークルールはまだまだ未完成で、随時更新していっていますが、公開するのは4月時点の内容です。

ワークルール

版：v2 (2022 年 4 月 16 日)
自律して動く組織を目指すために。

行動指針

「自律して動く」

※自立ではなく自律。
自立：独り立ちしている状況。誰にも依存せず一人で仕事をこなす。
自律：自分の意志を持ち、自らをコントロールしながら、目的や意義を考えて行動に移せる状態。

当社では日本企業にありがちな従来型のガチガチの統制管理は行いません。それどころか、ほとんど指示も出ません。

今後は様々な変化に素早く柔軟に対応できる組織を目指すため、自分の意思を持ち、自ら考え、上司の指示を待たずに行動していくことが求められます（急激には変わらないので、少しずつの変化を目指す）。

組織の理念・目標を理解し、自分で考え判断し、責任を持って行動する。そのことによって、自分の価値観、自分の意思、自分らしさを仕事に反映することができます。

PC操作の効率化編

PC操作を効率よく行うために設定変更や、ツールを導入するなどして工夫する。
TODO: 初回に設定すれば終わるような内容は、別資料にする。

キーリピート速度を最適化する

DELETEキーやカーソルキーなど、同じキーを押しっぱなしにして連続入力することは多い。その際のリピート速度を速めることで効率化につながる。
macOS では [システム環境設定]→[キーボード] を開き、[キーのリピート] を「速い」に設定する。[リピート入力認識までの時間] を「速い」に設定する。

キー入力のショートカットを覚える

自分がよく使うコマンドを中心に覚えること。macOSの場合は、例えば以下。

Ctrl+A 行頭
Ctrl+E 行末
Ctrl+D DELETE（Fn+BS）
日本語入力中 Ctrl+K カタカナ（F7）
日本語入力中 Ctrl+L 全角英数（F9）
日本語入力中 Ctrl+: 半角英数（F10）
日本語入力中 Ctrl+; 半角にする

ウインドウやタブの配置を工夫する

仮想デスクトップを活用し、サブディスプレイと組み合わせてウインドウの配置を固定化する。例えば、ブラウザはメインディスプレイの１、ターミナルはメインディスプレイの２、リモートデスクトップはメインディスプレイの３、Finderはサブディスプレイ、IDEは最大化してメインディスプレイに並べる、など。
毎日ほぼ同じアプリケーションを起動するため、配置場所を決めておいてそれぞれのアプリケーションの切り替えを素早く出来るようにする。
アプリの切り替えには、Command+TAB などのショートカットも活用する。

Clipyの導入

クリップボードの履歴をとることが出来るようになります。Windows向けには clibor があります。
ショートカットキーは option+Command+V などに設定すると、他のアプリとの競合がなくなって使いやすくなります。

社内標準アーカイバの導入

macOS では keka、Windows では 7zip を標準のアーカイバ（ファイル圧縮ツール）としています。（macOS標準のアーカイバには日本語ファイル名が化けるバグがあるため）

リモートワーク編

環境面での前提条件

安定した高速ネットワーク接続が利用可能なこと。
カメラ付きPCまたはタブレットで、オンライン会議室に接続可能なこと。
作業場所は、自宅内でなくとも構わないが、静かで作業に集中できる環境であること。
自宅で作業する場合は、家族・同居人に協力をお願いすること。作業場所を確保し、作業中は家に居ないものとして扱ってもらうなど。
必ず会社支給のPCで作業をすること。私用PCはオンライン会議に接続すること以外は使用を認めない。

クラウド事務所の概要

リモートワーク用に Gather をクラウド事務所として利用しています。業務開始時刻になったら、出社する代わりに Gather にログインし、会議に参加して下さい（会議が開催されていなければ開始して下さい）。
Gather はCPUリソースを消耗するため、専用のデバイスを用意することを推奨します。作業用PCとは別に、個人で所有しているPCやタブレットがあれば Gather用として使用して下さい。作業中もGatherの画面を常に表示しておけるようにし、チームメンバーからの呼びかけにいつでも応えられるようにしておいてください。
1日の業務に充てる時間帯を事前に決めて、計画的に行動してください。開始、休憩、終了時刻、それぞれコアタイム内であれば自由ですが、基本的には毎日同じリズムで生活できるよう、自分で効率的な時間配分を考え、時間割表として書き出してください。
自宅やコワーキングスペースなど作業場所はどこでも構いませんが、集中して業務に取り組むことが出来、安定したネットワークで十分な速度で通信できる環境が必須です。
自宅で作業する場合で家族がいる場合は、事前に業務と私生活の分離両立について考え話し合い、作業用のスペースを確保し、作業中はお互い干渉しないように、業務時間中は家にいないものとして扱ってもらう等、ルールを作って協力してもらうこと。

コミュニケーションの確保

リモーワーク中は、コアタイム（11:00〜15:00）は基本的に専用のオンライン会議室 (Gather)に接続しておくこととする。
顧客との打ち合わせなど、状況によっては Google meet や Microsoft Teams のオンライン会議室も併用する。
作業用PCでオンライン会議に接続するとコミュニケーションとPC作業が両立できなくなる場合があるので、オンライン会議専用のPCまたはタブレットを用意することを推奨します。
なお、電話対応や他のミーティングに参加する場合など、やむを得ない状況では例外とし、切断してもよいものとする。

作業効率の確保

作業効率が低下することのないよう、留意すること。自分だけでなくチーム全体の効率を重視すること。
事務所に出勤して作業する場合に比べ、作業効率が低いと感じる場合はリモートワークではなく事務所に出勤して作業すること。
リモートワークでは業務遂行に支障があるとチームリーダーが判断した場合は、事務所への出勤を命じる場合がある。

コミュニケーション編

話し方

名前を呼ぶとき「○○さん」づけと敬語（丁寧語）を基本とする。（ただし、お互いに人間関係が構築出来ている場合は除く）。

理由: 呼び捨て、君づけ、あだ名で呼ぶ習慣は、無意識に上から目線の態度を取ることに繋がりやすい。
しかしながら、過剰な謙譲語、尊敬語はやりすぎなので使わない。

威圧的に感じる言い方、感情的な言い方をしない。人の話を遮らない。

理由: 威圧的な印象は議論に参加する気力自体を奪ってしまう

相手の話を聞く時に「目を見る」「うなずく」を徹底する

真剣に話を聞く姿勢を示すことで信頼関係を築くことができる

感謝は省略せず積極的に伝える

風通しの良い雰囲気をつくることができる
ヒートアップすることを抑えることができる

結論→理由の順で簡潔に伝える

何が言いたいのかをハッキリすることでやりとりが減る。

自分の言葉で言い換える

複雑な会話や指示があった時は、自分の理解した事を自分の言葉で言い換えて、理解が合っているかどうか確認する。

理由:「分かりました」だけでは、相手からすると複雑な話を本当に理解してくれたのか不安。
例えば「分かりました。確認ですけど、それって、かくかくしかじか、こういう事で合ってますか？」というように、自分の言葉で言い直して確認する。
相手の説明をそのまま復唱するのではなく、必ず自分が理解した内容を自分の言葉で言い直す。
そもそも、これが上手く出来ないということは、理解していないという事。
ただし、複雑度の低い内容であれば「わかりました」だけでOK。その線引きは難しいので慣れが必要。

チャットより対話

チャットや、SNS（GitHub含む）での議論禁止
4往復以上のチャットのやり取りになる場合は、直接話す or 通話で話す or MTGを設定する
チャット上での議論は非効率で感情的な衝突も起きやすいので絶対に避ける
リモートで対話する際は、口頭説明だけでなく、画面共有や、Googleクラウドなどで同じ資料をみるといった視認情報も共有する
GitHub には、経緯をまとめ、決定事項を記録として残す

リモートワーク時のコミュニケーション

リモートワークでは、通常とは異なるコミュニケーションの仕方が必要になってきます。これまでにやったことのない働き方にシフトしようとしています。リモート向けのコミュニケーションの仕方として、頭を切り替える必要があります。

返事をする
理由: 聞こえているのか、考えているのか、分からない。回線の調子が悪いときもある。
長い説明は、途中で「今の所わかりましたか？」と確認しながら進める
理由: 聞き手は、説明中に分からないことが出てきても、話を遮ったりしにくい。説明が終わってから「よく分かりませんでした」と言われる。なので、説明中に相手がついてきているか、配慮しながら進めること。

ホウレンソウ編

業務日報は終業時に

業務日報は、出来るだけ業務終了時に送信すること。

理由: マネージャは、報告を受けてから確認やコメントが必要なことがあると、返信します。業務日報が遅れると、確認が翌日になってしまう場合があり、プロジェクト進行に影響する場合があります。

Redmineの工数入力も、出来るだけ就業時に行うよう習慣化しておくこと。

理由: 後から入力すると正確な時間がわからなくなる可能性があるため。

確認や相談は最速で

タスクごとの確認や相談事項などは、業務日報に書かない。その都度、最速で行うこと。
「あの件どうなった？」と聞かれてから報告するようでは遅い。

メールやチャットで、依頼や質問が来た際に、出来ればすぐに対応する。
手がはなせない時、または対応に時間を要する場合は「了解しました。午後には回答します」などと、とりあえず返事をする。
理由: 返事がないと、相手は「読んでくれているのか？」「意味が伝わらなかったのか？」「忙しいのか」とヤキモキしてストレスを感じます。
後で対応する場合は、リマインダーに登録するなどしてタスクを取りこぼさないよう工夫しましょう。

15分ザッソウルール

作業中に行き詰まり、15分経過しても解決できない（進めない）場合は、誰かに相談すること。

理由: 15分経過しても解決できないような課題は、それ以上続けても解決に至る可能性は低いです。
誰かに相談することで、説明したり質問されたりして状況が整理されていきます。起こっている問題、何が原因と考えているのか、試したことなどが整理されていきます。それだけで、今まで気づいていなかったことに気づき、解決に至る時もあります。
→「テディベア効果」と言われています。
相談にあたって、事前に状況を整理したり、うまく説明しようと考えたりしないこと。そもそも状況を整理できていないから行き詰まっているのである。変にまとめようとせず、雑なぐらいが丁度よい。とにかく相手と会話することで、質問を繰り返していけば自然と整理されていきます。
→雑な相談「ザッソウです」と宣言すればOK。相手が整理してくれます。
一人で考えていたときよりも視野が広がるため、思いも寄らなかった方向へ進む場合も多く、相談がより良い成果物につながります。
答えが見つからないときでも、総合的にちょうどよい落とし所を探ることができます。
「時間対効果」を考え、生産的に行動しましょう。
時報や繰り返しタイマーを活用して時間感覚を補いましょう。
理由: 集中しているとすぐに時間が過ぎます。例えば15分ごとに音がなるタイマーなどをセットし、時間の経過を認識しやすくしましょう。

相談前に画面共有

相談する場合は、口頭での説明だけではなく、作業中の画面を見せながら説明すること。

理由: 画面を見せればすぐに何をしているか（何が起こっているか）が伝わる。百聞は一見にしかず。
リモートワーク時は、画面共有か、画面のスクリーンショットをチャットに貼る。またはPRであげる、ファイルをzipで送る、エラーログを貼ったり、URLなど、同じものを閲覧可能なら何でも良い。
上級者であれば、画面を見るだけで説明不要ですぐに解決策が分かる場合もある。
ソースコードを読み上げない。人間なので、プログラムを読み聞かされてもすぐに理解できない。理解に大きなパワーを使う。普段
ソースコードは、聴覚ではなく視覚でしか認識したことがない。ソースコードは目で読むものである。
スクリーンショットは、最小限の範囲だけではなく。なるべく画面全体とする。
理由: 問題発生時は、無意識に視野が狭くなっているため。自分が見ている範囲の外側に答えがある時も多い。

開発編

リマインダーの活用

リマインダーアプリなどを活用し、自分のタスクを期限付きで登録しておき、自己管理すること。

月に1回しかないタスクなど、忘れがちなことを気づいたらアプリに登録する
実際に、繰り返しタスクを忘れてしまっていたことなどがあったら、すぐにアプリに登録し、次回は忘れないようにする
繰り返しタスクは、期限がきたら実行済みにせず、次の期限に再セットして繰り越して使う

二割共有

タスクに取り掛かる前に、内容や進め方についてのアウトラインを確認する。作業手順を書き出したり、物事の関係性をマインドマップで描画したり、タスク全体の工程を確認すること。
アウトラインが出来たら、着手する前に上長と共有しフィードバックをもらうこと。
アウトラインを書くまでもない、工程が明確なタスクの場合は、全行程の二割の進行度になったら共有する。

理由: アウトラインをつくらずにはじめるとゴールまでの道のりが分からず、迷走する場合がある。
手戻りを減らすため、タスク着手後も二割程度の進行度で（つまり出来るだけ早いうちに）対応方針やゴールについての認識のズレがないことを上長と確認する。
その際、変にかっこつけず、自分のありのままの考えを伝えること。しっかりときれいに整理してから共有しようと考えていると、あっという間に時間が経ってしまいます。
整理された資料がなくても、口頭で伝える方が早い場合は、それでOK。
その後も、必要に応じてズレがないか認識合わせをしながら進める。

例えば、全体の骨組みだけコーディング（空っぽやコメントだらけの関数定義だけを一通り全体整備）して、PRする。その際タイトルに「[二割共有]」と入れておく。
なお、二割の基準が難しい場合もあるが、時間的に20%経過したときにも二割共有のタイミングになります。理想的には、時間的に20%よりも前に、二割程度の進行度になっているのがよい。

アウトライン作成の例：
（タスクによって共有すべき重要ポイントはケースバイケースなので、あくまでよくある例として捉えてください）

具体化：どんな手順で処理するかを考え、箇条書きにする。複雑なところは図にする。
雛形：ファイル構造、クラス構造、メソッドの構造、名称などを考え、実際に空っぽのファイル、クラス、メソッドを作ってみてPRを出す。コメントで、何をするか書いておく。
インタフェース設計：メソッド引数や、APIの受け渡しデータなど、他のモジュールとのインタフェースを考え、書き出す。

issueドリブン開発

プロジェクトの課題は全て GitHub issue （またはプロジェクトごとに指定された課題管理ツール）に登録して管理する。

新たな課題が見つかった場合は、抱え込まずに issue に登録する（登録すべき内容かどうか事前に誰かに相談してもよい）。
すべての課題をメンバー全員で共有することで、プロジェクト全体のゴールと進捗状況、問題点を簡単に共有できる。
課題の粒度が大きすぎる場合は、適宜タスクバラシを行うこと（後述）。

タスクの種類と優先順位
issue（タスク）には大きく分けて３種類あります。

設計実装
設計リーダーが全体の構想をした際に見えている大きな粒度のタスク。大まかにざっくりとした予定工数が設定されている。このレベルのタスクが後から増えていくことはありえない。
作業中に発生するもの（TODO, 技術的負債）
開発作業を進めていくと、途中で「ここやっぱり変更しないとまずい」「これもやった方がいいかも」「古いコードを書き直したいな」などと、バグではないが新たなタスクが発生します。
これらは、残りの工数見合いで対応するかどうか判断します。とりあえずissueで上げてください。対応しないとなるかもしれないが、取りこぼすよりはマシ。
バグ
基本的には対応すべきもの。ただし優先順位を付けて対応するため、重大度が低いものは対応見送りとなる可能性もあります。重大なものは、絶対やらなくてはならない。

タスクの性質によってライフサイクルが変わりますので、意識しておくこと。

タスクバラシ

実装タスクの粒度が大きい場合は、適宜タスクを細分化すること。GitHub ではチェックボックス記法を活用し、TODOリストのように詳細タスクを書き出して可視化すること。
細分化したタスクは、それぞれ工数見積りを行うこと。タスクの末尾に「2h」などと時間単位で工数を書いておくこと。
細分化する単位として最低限 4時間以内のタスクがリスト化されていること。4時間を超えるタスクは、更に細分化できるはず。
例：「商品選択画面の修正」というタスクがあったとします
このタスクに対して、UI設計書や仕様書を読んで、どんなことをすべきかイメージし、一つ一つ書き出して行きます。以下のような詳細タスクがアウトプットされます。

タイトル部分の切り替え
確認画面の送信ボタン名の変更
submit処理の修正
リースと購入の場合で表示する商品の切り替え
categories にカラムを追加するマイグレーションファイルの作成
追加したカラム用のActiveHash を作成
出来たら、実際に着手する前にリーダーに連絡すること。「#1234 タスクバラシしました」とチャットで送るだけでOK（#1234 の部分は issue や PR の番号）。

納期意識

タスクの期限、開発サイクルの期限、プロジェクト全体の期限をそれぞれ意識すること。

Redmineのチケットには予定工数が設定されているものがあるため、確認しておくこと（ただし設定されているのは標準工数であり、実際の工数は誰が担当するかで変わる）。
タスクに着手する前に工数見積を行い、どれぐらいの時間で出来そうか見通しを立てること。
期限が設定されていない場合は、見積工数が期限となるが、タスクの期限が明確に分からない場合は、リーダーに確認すること。
「何を」「いつまでに」を意識しながらタスクを進めること。
現在の進行度を自己管理し、納期に間に合わなさそうであれば早めに報告すること。「残業しよう」「対応方針を変更しよう」など、自分で勝手な判断をしない。

100%を目指さない

タスクを担当する際は、100%の完成度を目指さない。

50% 程度で一旦PRやレビューをしてもらい、軌道修正しながら、70%, 80% ぐらいまでもっていき、再レビュー。
残りの課題はもう後回しでよいから、先にマージや、他の優先度の高いタスクをやろう、となる場合があるため。
パレートの法則「80%の完成度には２割の時間でよくて、残りの20%を高めるために８割の時間がかかる」という言葉もあります。
80%で十分満足の行く状態であれば、かなりの時間節約につながります。
そもそも、現実世界に100%完璧というものは存在しない。100%を目指すのは自己満足でしかない

提案型で考える

課題に対する見解や対策を考え、「こうしたら良いのでは？」と提案するような活動を心がけましょう。
例えば、お客様に質問する場合には以下のようなことに留意しましょう。

相手に丸投げしない。
自分はこのように考えています、あっていますか？というように、自分の考えがちゃんと存在し、それが正解か、という聞き方をしてください。
業務について尋ねるのはOK、どう実装したらよいか尋ねるのはNG
どう実装するか考えるのがエンジニアの仕事。
何に困っているか（またはどういうシステムがほしいのか）をヒアリングし、「それならこうすればどうか」と提案するのが上流工程の仕事。下流工程でもこの考え方で仕事をするべき。
システムの内部仕様について尋ねるのはケースバイケース。調べて分かる範囲であれば、基本的には自分で調べる。ただし複雑度が高すぎたり納期が短かったりする場合は、「聞いたほうが早いと思ったので」と前置きして質問する。
しかしながら、そもそも聞かないと分からないことは聞くしかないので、早めに聞く。

下請けプロジェクトでは上流工程を担当したエンジニアに実装内容まで聞いてしまうエンジニアがいるが、それはNG。言われた事しか出来ないエンジニアになってしまう。

ここからは、開発者経験 2, 3 年以上の者へのルールです。

タスクのボリュームを増やさない

あるタスクを進めているうちに「これもやっといた方がいいな」と気づいたことがあったとしても、自己判断だけでやらない。

理由: タスク着手当初の「何を」「いつまでに」が変わってしまうため。
気づいたことは、TODOコメントなど残しておくか、対応が必要なことが明らかな場合は issue を立てておくこと。
チームで共有し、どのように対応するかリーダーの判断を仰ぐこと。
ただし数分程度の僅かな工数で対応可能な場合は、やってしまって良い。

標準化意識・社内標準へのコミット

当社ではOSSの開発プロセス、ワークフローをベースにしています。

GitHubでのワークフローは、「Gitフロー」を採用しています。
Railsなどのフレームワークの使い方は、公式ドキュメントに記載されているような、標準的な使い方をします。
コーディング規約は世間一般で標準となっているコーディング規約を採用しています。
それら一般標準で規定されていないような実装方式などは、個別に標準化して進めること。
その都度バラバラな実装とならないよう、チームで課題と状況を共有し、最適な方式を標準化して定めること。
出来るだけプロジェクト固有でない、汎用性のある内容として標準化することを目指し、社内標準としてより上位の標準化として整備する（現状、社内の開発標準が未整備なため）

ライブラリアン

外部ライブラリを導入したい場合は、ライブラリアン（いない場合はリーダー）に相談すること。
その際、外部ライブラリが必要な理由、その選定理由、プロジェクトへの影響（調査済みであれば）、などを合わせて報告すること。

理由: タスクが完了してから「このライブラリを導入しました」と言われても、それが問題になる場合に大きな手戻りになるため。
外部ライブラリ以外にも、以下のようなケースでは相談すること。
標準の実装方式で対応できないため、特殊な実装方式を採用する場合
ミドルウェアやフレームワークの設定変更

DBA

DB設計に関係する内容は、DBA: Database Administrator（いない場合はリーダー）に相談すること。

理由: テーブル設計やデータフロー設計などは、将来ソフトウェアの規模が大きくなった時を想定して様々なことを考慮する必要があり、専門知識を必要とするため。
基本的にはDBAがテーブル設計を行うこと。
DB設計に基づいて、マイグレーションファイルなどを書く場合は、コードレビュー時に必ずDBAをレビュアーに含めること。

開発フェーズごとの考え方

初期構築や新機能実装時（0→1 を作るとき）と、肉付け（1→8 まで進める時）では、大事にするポイントが変わる。

初期構築時：

とにかく動くものを作って、早くマージしていく。
理由: 実際に動くものを早いうちに顧客に見てもらい、フィードバックをもらう。人間は、実際に触れて動くものを見て体験しないと、本当に重要なことに気づかない。
技術的負債よりもスピードを重視。負債を抱えることで、プロダクトの価値を高める。※これは経営者目線では当たり前の理論なのですが、一般的にエンジニアには理解されていない点です。例えば、銀行から借り入れ（負債）をしないと、新規ビジネスに投資できません。最初から素晴らしい構造のソフトウェアを目指しても、まずは利用者目線で価値のあるプロダクトでないと、ビジネスを成功させられません。また、作り上げてみないと最適な構造が判断できない、といった側面もあります。なので、基本的には初期構築がおわってから、負債を返していきます。
早いうちに要件の間違いや抜け漏れを洗い出し、後工程での手戻りを最小化する。
コードレビューでも、インデントや例外処理など、少しぐらいの命名ルール逸脱ぐらいなら目をつぶる。
状況によってはテストコードも省略OK。
完成度60%程度でもマージしていく。
気づいたことはTODOコメントで残しておけば良い。
とにかく早くレビューし、早くマージする。スピード重視。

肉付け時：

大きな要件のブレがなくなって、細かい部分を確認しながら、骨組みに対して肉付けしていく工程。
技術的負債を少しづつ返済しながら、実装を進めていく。
テストコードを整備し、CIを導入する。
オブジェクト指向による構造見直し、コードの可読性、リファクタリングなど、コードベースを整備する。
非機能要件（排他制御、セキュリティ、パフォーマンス、保守性など）についても考慮し始める。あ
ドキュメント整備、ユーティリティスクリプトなどにも着手する。

アーキテクチャの理解に努めているか

フレームワークやライブラリを使い始める前にそのアーキテクチャや設計理念を理解に努めているか。

例えば VueJSは仮想DOMを扱うが、これを理解せずに使っていると思い通りに制御できないケースが出てくる。
アーキテクチャを理解せずに進めると、結果的に遠回りする事になる。
開発スタートの前に、勉強会などを開催し、有識者が理念の説明を行うようにする。開発が始まってからも、理念に反するような実装が見つかり次第、意識の統一をはかる。（ザッソウを積極的に利用する。）
特に独自フレームワークの場合は、説明会を行うことは必須である