>@pook_tdr32: 属人性は低い方が良いと今は思っている派なんだけど、高い方が良いメリットって何かあるのかな…。

> 特定の人に依存した作業があるとその人は休みにくくなるし、周りもこの人がいなくなったら大変になることが目に見えてて精神的に辛い気がするからあまりメリットを感じない…。

>@a_suenami: これは以前誰かが言っていたことが心に残っていて、属人性は確かに低い方がよいが、属"技能"性はそうではないっていうのが一番しっくりくる。

>「誰にでもできるようにする」という言葉の「誰にでも」は正しくは「同じくらいのスキルを持っている人にだったら誰にでも」であって、スキルレベルや得意領域の異なる人にまで展開しようとするとだいたいどこかに歪みを生む。

>その業務にどの程度のスキルが必要なのかを考慮せずに安易に自動化したりルール化したりすると、結局その自動化メカニズムや制度のメンテナンスのほうが属人化するっていう現代のイソップ童話みたいな話どこの現場にもあるでしょ

>@naoya_ito: 組織もチームもプロジェクトもサイズが小さい時はそこにある情報を全部把握できるけどある程度の規模を超えると全部把握できなくなるので、成長の過程で把握できてない状況を受け容れる必要がある。ここのマインドチェンジをチーム全体で行うのが難しいというか、そういうことに自覚的になるのが難しい

>@naoya_ito: 自分たちが以前のように状況を掴めなくなったことに不安を覚えて、なにかやり方が悪いんじゃないかと自分たちに原因を求めるのを当たり前だと思ってるところ、いや、把握できない前提に切り替える規模でしょ、と開き直ることがいつできるか

>@sugimoto_kei: ひとの数が増えるほど、コミュニケーションや管理のコストが増える。大きな組織をどうマネージしょうかと考える前に、組織を小さく保てないかと考えた方がよい場合が多い。特に開発においては、多くの素晴らしいプロダクトが小さなチームによって開発されていることを忘れてはいけない。

>@sonatard: 何か課題があったときにプロセスで解決しようすることはとても多い

>しかしプロセスは最低ラインを超えない人を最低ラインに押し上げるもので、ラインを超えている人にとっては足枷になる

>足枷が増えすぎた結果が大企業的な軽快さがない開発プロセス

>@sonatard: 本当の課題は、最低ラインを超えない人が成長していないことかもしれない

>その場合の理想的な解決策は、プロセスの整備ではなく成長方法を考えること

>@sonatard: チームでコードの方針を統一する方法として、以下の2つがある

>1.「レール」を固定する方法

>2. 「基本指針の理解」の統一

>前者はみんなが同じコードを書けるが冗長なコードが多少は増える

>後者は最小のコードを目指せるが、人のスキルに多少依存する

>@sonatard: 例えば

>Reduxですべての状態をStoreに持てば、どこに状態を持つかの指針はぶれない。

>一方でReactの基本指針としては状態のスコープは最低限にする方向性なので、必要であればLifting State Upするという指針だけで、あとはエンジニアに任せることもできる。

>@sonatard: 自分としては後者の方が好きで、エンジニアによってブレるかもしれないけど、そこはエンジニアの成長に期待したいし、その成長を支援できる組織にしたい

>@uhyo_: 設計方針というのは前提条件が変わるたびに再計算しなければならないから、Reactで例えるとuseStateではなくuseMemoだよ（？）

>@koushisa: フロントエンド関係なく、レイヤ作るとしたらアーキテクチャ特性と入出力の明確化や重要で、それをどうやってテストで担保するかやルールの周知といったことをビジネス要求と対話し続けつつ軌道修正する気概が必要

>@koushisa: 目的として「変なコードを書けないように」、「統一感」や「書く場所に迷いをなくす」などが含まれている場合は要注意で、ソフトウェアは必ず進化する(予測も難しい)という前提条件をわすれている

>@sonatard: その技術が運用コストを下げるかどうかは

>日常的な開発負荷 と 異常系の検出コストの比重で考える必要があると思う

>どちらか片方だけが、良いからすべてよしとはならない

>@sonatard: 日常的な開発負荷が下がるが、異常系の検出コストが極端に上がるなら、それは良くない

>逆に、日常的な開発負荷がかなり上がるが、異常系はレアケースでそもそも検出コストは対して下がらないなら、それも良くない