役割を横断する
フロントだけ見るんじゃなくて、バックエンドもできるようになろうね
エンジニアだけでなく、デザインもできるようになろうね
開発だけでなく、経営もできるようになろうね
というやつ
何を目指しているのか
根本的には、どうすれば組織全体が効率的に成長できるか、という一点になる
組織というのは、個人、チーム、部署、会社、市場、、みたいなやつ
これを実現するために、役割に閉じるのが良くない
自分事にするということ
理解するということ
メンバーの気持ち、メンバーのやっていることを
NARUTOの影分身の術みたいに、術を解いた時に同期されると良いんだけどな 結局、コミュニケーションになる
信頼関係
コミュニティの文化
適切な依頼ができない
これを依頼するのは大変かもなと無駄に忖度してしまう
実は10分で開発できるのに
課題に気付けない
専門分野によって課題を課題と感じれる場所が違うと思う
継続的に理解する
一度理解して終わり、ではだめ
仕組み化しないと情報の引力が働いて、気を抜くと偏る どこがボトルネックになっているかの判断
「この要件を満たす機能を作って」となっても、実はそもそもその要件を満たす必要がないかもしれない
閉じていると、根本的な課題に対する批判ができない
「その要件」や「機能を作ること」が前提となる批判しかできない
能動性
「上に聞かないと状況がわからない」となっていると遅い
コンテキストをどれだけ共有できるか
その眼の前のタスクをこなすにあたっての背景
本来の意図を掴めるかどうか
クライアントという役割も横断する
Aが機能や手順書を作って、Bがそれを遂行する、ってだけで割と情報が欠落する
Aが自分で遂行することで、遂行時の問題がありありと見えてくる
しかし、Aは遂行作業の全部をやる必要はない
9割型Bに依頼するが、詳細をAも理解しておくこと
コミュニケーションを密に取ること
フィードバックの質が違う
LLMに全部のコンテキストを突っ込みたいのと似てるmrsekut.icon
全体効率
属人性
専門分野の知見を別部署に適用する
ドキュメントで伝達できる部分とできない部分とある
割と全部情報を開示しているつもりだったが、まだ自分の直感で動き、共有されていない感覚もあったな
組織づくり
フロントのみやるではなく、
フロントもバックもデザインもできまっせ、という人を数人集めたチームの方が良い
その上で、フロントが得意な人はフロントをやれば良い
組織の構造の分けかたにもよる
残の話みたいな
全く同じことを何処かのページに書いてる気がするmrsekut.icon
人に依頼した場合、責任の所在がその人になったとして、
その人の怠りによって、自分がコストを被ることもある
1日前に言ってもらえれば余裕だったものが、5分前に言われることで対応が雑になるなど
早めに言うよ〜、をそのまま信頼するのではなく、自分が今できることを考え、早め早めに動いておく
意思決定
最終の意思決定をする人がいないと話が進まない
メンバーの多くが横断する気があり、かつ、意思決定者が少ないのが良いのかも？
意思決定する対象にもよるが
重要な部分の意思決定者が二人いると話がブレブレになることがある
能動的に動ける人が、サポート役にも回る、というのもチームとしてはかなり大事