はじめに
Difyのプロジェクトに参画して学んだこととか思ったことをメモしてみる。
私は以前Difyの自動生成スキルを作った。
その後もOSS版へメタデータ付与した状態での一括挿入スクリプトを作ったり、どこでつまづくか、どこに自動化を挟めば早く進むかを感覚で理解していたつもりである。
そのため、Difyのアプリ案件が来た時、素早く構築して、品質向上のサイクルを高速に回すことで短期間で商用に耐えうるものが作れる……と思って意気込んでいた。
まあ、しかしそんな上手い話はあるわけがない。
自動化・高速化はプロジェクトを高速にするか？
自動化は素晴らしい。AIエージェントで素早く作るのは素晴らしい。
環境さえ堅牢であればワークフローなんてすぐ作れるし、複雑な要件もなんのその……と言いたいところだが、プロジェクトはそんな甘いものではない。
みんなそれぞれスキルも、わかっていることも違う。
私だけが早くとも、私ではできない領域がたくさんある。
今回の案件はまさにそれで、私だけが早く終えても他の人がそうであるわけがない。
個人が早くても、プロジェクト全体としては意味をなさなくなってしまう。
自分だけ早くても全体に波及しない
これは当たり前といえば当たり前の話ではある。
しかし、自分で自動化や高速化の仕組みを作っていると、どうしても「速く作れること」そのものに価値を見出しすぎてしまう。
だが実際には、プロジェクトで重要なのは自分の速度そのものではない。
全体が前に進めるかどうかである。
自分だけが素早く作れても、相手がその成果物を扱えない、前提を共有できていない、別工程で詰まる、となれば全体は止まる。
むしろ、自分だけ先に進みすぎることで、ズレや手戻りが見えづらくなることすらある。
個人の速さを価値にするには
では、速さは無意味なのかというと違うと思う。
そもそも、速さや自動化のいいところはなんだろう。
楽で頭を使わずに済む、それもいいところではある。
けれど、それ以上に、何かが起ころうともリカバリができるのがいいところだと思う。
たとえ手戻りが起ころうとも間に合う、やり直せる状況を作り出す。
これが一番大きい。
つまり、速さそのものに意味があるというより、速いからこそ余白ができる。
その余白があるから、後でズレが見つかっても戻せるし、相手に合わせて調整もできる。
そこに価値があるのだと思う。
やり直せる状況を作り出すには
自分だけが早い、その利点を活かすには、以下の二点を心がけた。
仕組みを整える
スキルや職種の違う方々でも、やり方が簡易で工程も少ない方法でやり取りできるように、初期に合意し、セットアップしておく。
自分だけができるやり方では意味がない。
なるべく誰でも乗れる形にしておくことが大事だった。
相手のつまづきそうな場面を予測し、自分のタスクを後回しにする
相手がツールの使い方でつまづきそうならマニュアルを書いておく。
設計でつまづきそうなら方針やサンプルを渡す。
そうやって相手のスピードを上げる仕組みを整えておき、手戻りリスクを減らす。
自分のタスクは、ある程度あとでいくらでもリカバリが効く。
だから、見通しが立つ限りは周囲のペインポイントを常に予測し、先手を講じることの方が重要だった。
結局のところ、自分が早いことをそのまま自分の作業消化に使うのではなく、全体が詰まらないように使う、ということなのだと思う。
結局どうだった？
全体の手戻りリスクを減らす方向に移すことで、自分も相手も等しくスケジュールの見通しを立てながら進めることができたように思う。
自分の拙い説明にも関わらず、チームの方がよく理解してくれたのもあって、スピーディーに動けたのにも助けられた。
というか、これが一番の勝因のように思う。
学んだこと
- 速さを自分だけのものにしないようにしよう。
- 積極的にプロジェクト = 他者に関わろう。
- 全体を考え、予測し、先手を取ろう。
自動化や高速化そのものはやはり強い。
しかし、それだけでプロジェクトが高速になるわけではない。
自分の速さを活かすなら、それを「自分だけが早く終わること」に使うのではなく、手戻りが起きてもリカバリできる状況を作ることに使うべきなのだと思った。