どうもばやしです。最近、発達の最近接領域という概念を知りました。
(以下の本を読んでたら出てきました)
おさなごころを科学する: 進化する幼児観 | 森口 佑介 |本 | 通販 | Amazon
これは端的に言うと「一人ではできないけど、他者(スキル上位者)の支援があればできるようなタスクをやる時に人は成長するよね」というものです。
引用元: 【図解付き】発達の最近接領域とは？ 教育者・学習者目線で考え直してみる│LearnTern（ラン・タン）
この概念を知り、私がチーム開発において何故みんながフルスタックにやることが良いと思っているかが一部説明できそうなので書いていきます。
フルスタックってなんなんだ
フルスタックエンジニアの定義は人によって様々だと思いますが、私の中では「ひとつの領域に固執せず色々幅広くやっていくエンジニア」くらいの意味合いです。 この記事での文脈としては「フロントエンドも触るし、サーバサイドも触るし、インフラも触ります。習熟度に関してはまちまちです」くらいの感覚で読んでいただけると幸いです。
チーム開発においてみんながフルスタックにやるとは
フロントのタスクはフロントエンドエンジニアしかやらないよ、とかサーバサイドはサーバサイドエンジニアしかやらないよ、とかではなく、みんながみんな色んな領域のタスクをやっていこうって意味です。これのメリットを以下のケースで説明していきます。
例えばフロントエンドエンジニアのAさん、サーバサイドエンジニアのBさんがいて、お仕事として以下の4つの仕事があるとします。
- 表示ロジックの微修正(フロント簡単タスク)
- フロントの横断的な状態管理のやり方の刷新(フロント難しいタスク)
- 登録ロジックの微修正(サーバサイド簡単タスク)
- テーブル分割(サーバサイド難しいタスク)
アウトプットを最大化させるタスク割当
領域毎にエンジニアが分かれており、アサインされるタスクが分かれる場合、表示ロジックの微修正とフロントの状態管理改修はAさん、登録ロジック微修正とテーブル分割はBさんがやることになります。
Aさんからすると表示ロジックの微修正は単純な作業で学びが少ないです。しかし状態管理の抜本的な改修はAさんからしても社内のスキル上位者に聞いたりググったり書籍を読んだりと学習を進めスキルを獲得しながら達成していくものです。同じくBさんも登録ロジックの微修正はつまらなく感じてしまいますが、影響範囲を調査しつつ、データモデリングもしつつ、性能のことも考えつつテーブルを分割するのは歯ごたえがあります。
つまりAさんもBさんも退屈で学びの少ない仕事と、取り組みがいがあり学習が進む仕事、両方をやることになります。
学習効果を最大化させるタスク割当
次にお互い得意分野はあれど、アサインされるタスクが領域毎に分かれていない場合を考えてみます。
ここで以下のようなタスクのアサインを考えてみます。
Aさんはサーバサイドは全然わからないので、登録ロジックの微修正を行うだけでも難しく誰かの手助けが必要です。そのためこのチケットをやることでサーバサイドの領域とはいえ学習は進みます。フロントエンドエンジニアとしてチャレンジングなタスクである状態管理のタスクはそのままAさんがやります。これも発達に適しています。同じくBさんはフロントエンド全然わからないので、表示ロジックの微修正も独力では難しいです。ただお互いがお互いの教師になれるのでサポートを受けつつタスクを完遂することができます。同じことをBさんの方でも行い学習の進むチケットを可能な限りアサインするやり方。領域を超えないことより、お互いの学習が進むチケットをシェアし合うことを優先するスタイルですね。
もちろん学習効果だけを考えて、アウトプットは犠牲にすることを是としているわけでありません。ただみんながフルスタックに取り組み事により、お互いが師になりそのときどきで学習が進むチケットをシェアし合うことができるので良い効果あるなぁと感じております。
異なる領域、ここで言うとフロントエンドエンジニアがサーバサイド学んで良いことあるんでしたっけ、という疑問に関しては、違う領域のスキルを得ることで自分の得意としている領域に良い影響ありそうとか、領域が偏った開発項目が並んだ(e.g. 今回のスプリントではフロントエンドの改修はめちゃめちゃあるけど、サーバサイドはほぼ無いよの)時にみんなで手助けしあえるとか、色々思っていることあるのですが、長くなるので省略します。
以上、ポエムでした。
