タスクを依頼する

技術的に自分の方が詳しい場合

ドメイン的に自分のほうが詳しい場合

のような軸はありそう

技術的に自分のほうが詳しい場合

というか、対象者が、その技術に慣れていない場合のアプローチをどうするか

これもいくつかの軸がありそう

例えばフロントエンドに限定すると、ハードルは色々ある

TypeScriptという言語自体の知識

ReactやNext.js周辺の知識

その他、関連する諸々のライブラリの知識

もっと汎用的な、型を効果的に用いた設計の知識

moduleの作り方の知識

UIの知識

etc.

徐々に知識を増やすようにする

一気に100個の知識を覚えてね、というのは無理な話で、

毎回、2~3個の新しい知識に触れる、という具合になるようにタスクを振る

少しずつコントロールできる範囲を広げる

独立したPackageを振る

Packageに閉じてれば何をやっても良いを使う

実装速度が影響しないので、対象者がボトルネックになることを回避できる

最初は小さめのPackageを振ると良い

仮に実装が微妙でも、影響範囲が極小なので問題ない

(当然レビューはする)

円環アーキテクチャの表層を振る

ViewとかRepositoryとかを振る

影響範囲が小さい

実装が微妙でも問題が起こりづらい、実装速度が遅くとも問題が起こりづらい

詳しい人が、中心部分を作る

トップダウンに概観を掴むために

ボトムアップにタスクを振りすぎると、全体的に何をやっているのか見えづらくなる

工夫できるとすれば

コードレビューをして軽く目を通してもらう

コードは読まなくてもディレクトリ構成だけ読んだり、型だけ読んだりするのでも意味はある

ドキュメントを読む

進捗の会話する

同じPackage内の表層を振る

独立したPackageでない部分を振る場合に、表層を振ることで、内部も見つつ実装することになる

こうやって見ると、

実装上の依存関係と、タスク(の振り方)の依存関係には密接に関連があるmrsekut.icon

実装上の依存の方向や、結合性等を意識することで、効果的にタスクを振ることができるmrsekut.icon

Packageに閉じてれば何をやっても良いの抽象化をした感じかmrsekut.icon

そうやって考えると、コンウェイの法則のような「法則」が出てくるのは納得感がある

3人のチームで業務を進める時に、

mrsekut.iconが、実装&ドメインについてそこそこ詳しく

Aが、ドメインは同等、実装ツールが慣れていない(他のツールでは経験豊富)

Bが、ドメインはやや薄い(途中参加のため)、実装は強い

という感じだった

Aには、徐々に知識を増やすようにタスクを振るようにした

最初はReactで帳票を作る箇所を依頼した

どういう内容を出力するか？というドメイン知識は必要だが、

技術的にはReact (react-pdf)の基本が分かればできる

Nextがどうのとか、global stateがどうのとか、通信がどうの、みたいな知識がいらない

Bには、一部のドメイン知識、強めの技術力が必要な箇所を振った

例えば、横断的に永続化周りを見てもらうなど

永続化は、円環アーキテクチャの外側なので、全体のドメイン知識が必須というわけでもなく、実装速度が他の箇所への影響が小さい

もちろん、一部のドメイン知識は必要