ここまでTaskelそのものとその開発手法について解説してきました。
振り返って考えてみると、 ソフトウェア開発者として自然に捉えていた役割分担とは明らかに違う何かを考えているような気持ちがあります。
プロジェクト停止とその再起について、執筆時点では「はじまるかも」くらいの温度感であって、実際に使われるまでに距離があるということは前置きしつつも、ここであえて踏み込んで「停止してしまっていた取り組みがTaskel Frameworkによって再起した（あるいは再起する可能性が高まった）」という解釈をしてみましょう。
この解釈が成立した場合、個人的には2つの意味で指摘に値することがあると感じています。
まず1つ目。バイブコーディングでソフトウェア開発者ではない人ができない領域がはっきりと存在するし、それを無視しているとできそうに見えても完成しないということです。ただし、これについては本記事の当初から筆者が主張していることとほぼ同じ話ですので、ここではこれ以上強調しません。
ソフトウェア開発者である私からすれば、もう1つの方が重要なように思われます。
つまり、組織内のつまずきの石の類に引っかからないように、Taskel Frameworkのような適切な補助線をソフトウェア開発者が引くと、ソフトウェア開発者ではない人ができる領域はもっと広がる。そして、ソフトウェア開発者でないと対応できない領域はやはり着実に狭まっているということです。
この2つは矛盾しません。並べてみればそうと分かります：
- バイブコーディングでソフトウェア開発者ではない人ができない領域がはっきりと残り、それは無視できない。
- 適切な補助線をソフトウェア開発者が引くと、ソフトウェア開発者ではない人ができる領域はもっと広がる。
さらにここからもう一歩踏み込んで、暗喩的に次のことも発見に加えても全くおかしくないでしょう：
ソフトウェア開発者の新たな仕事に「（AI技術を使って）ソフトウェア開発者ではない人のできる領域を広げる」類のものがはっきり加わった
相対的に重要性が残るのは仕事のどの側面か
ここで「ソフトウェア開発者とそうでない人々の役割分担について変化があった」ということは、組織において大事なことです。その変化の後に、組織内の人にどのように振る舞ってもらうかが変わり、それが言ってみれば生産性の向上に直結するからです。
ただし、上の主張のあとに連続する後続の主張については、まだ世間的にはっきりしたものがない感覚もあります。実際、以下のどちらでも辻褄が合うのです：
- ソフトウェア開発者は自分自身で問題解決を率いつつも、それに加えて、補助ツールを介してソフトウェア開発者以外にダイレクトに問題解決させるという選択肢を持てるようになった。
- ソフトウェア開発者でなくても開発できる領域が確実に増えるよう、ソフトウェア開発者は補助ツールの開発によりエネルギーを割くべき、つまりソフトウェア開発者以外に奉仕すべきである。
実際のところ、後者のような表現に対しては、当の開発者の目線からすると心理的な抵抗や強い違和感を覚える方も少なくないでしょう。
しかし、ここで焦点を当てたいのは、そうした表現に対する感情的な摩擦ではありません。むしろ、これら2つの見方のどちらにも共通して横たわる、暗黙の「揺るがない事実」の方にこそ強い関心があります。
「ソフトウェア開発者ではない人がもともと抱えている業務フローの情報」の重要性は相対的に上がっている
中編で紹介した通り、目標は2つありました：
- 有用なWebアプリケーションを構想し、作りきる
- そのアプリケーションをできる限り簡単に「デプロイ」して安定化させる
Taskel Frameworkと呼称した座組は、目標のうち2つ目をフレームワークで解決する事例でした。そのフレームワークを使用する開発者が行わなければいけないのは、1つ目の目標だけに絞られることになります。
加えて「有用なWebアプリケーション」のハードルも上がり続けています。「Google Calendarやスプレッドシートで良いのにTaskelはなぜ要るのか」といった疑問は、選択肢が多い時代において「有用」に関して行なう議論としては十分本質的だと思います。それを乗り越えて使われないと「有用」とは主張できないでしょう。
遡って、前編の最初の方をここで振り返ってみます。ある若手社員が直面した課題に対して、私は次のような意識で問題の整理に挑んでいました：
「ただのタスク管理ソフトではこの問題は解決できないのではないか。もっと解像度の高い形で当該社員のペインに対応する要件があるのではないか」
当該社員が出会っている業務フローと、それに隣接する精密な問題理解がなければ、Taskelのような「特殊な」アプリは利用すらされないに決まっています。Google Calendarもしくはスプレッドシートで良いわけです。ソフトウェア技術を前提としつつも、どこまでも「問題となっている業務領域のペインは何か」をソフトウェア開発者は追いかける必要があります。
従来で言えば「プロダクトマネージャー」「UXデザイナー」といったロールモデルで表される領域に、ソフトウェア開発者がはじめから片足を突っ込む重要性・必要性を今まで以上に感じます。「プログラムを書く」というもっとも時間を食い潰す構成要素がなくなった代わりに、開発者の時間を何で埋めるかと言うと、それはもう開発者に隣接するありとあらゆるロールになっていくイメージです。
昨今の筆者の興味は、しきりに「業務・業務フローの理解をいかいかにスムーズにソフトウェアに流し込むか、そのためにどうAIに指示するか」にシフトしています。それを技術の言葉に置き換えることの価値が上がっているわけですし、それが1人の開発者の中でコンパクトに収まっているのがある意味「最強」の可能性が高い。昨今の流行りのキーワードで言えばFDE (Forward Deployed Engineer)のような動きが自然に求められるのかもしれません。
おわりに
当社内で実際に行われたバイブコーディングによるアプリ開発の紹介をしました。
LLMが端的に驚異的な生産性向上ツールであることと、同時にその生産性向上ツールでつまずかないバイブコーディングについて社内で取り組んだ内容を紹介しました。また「技術を知らなくてもソフトウェアを作れる」という市井の主張について、筆者が考えることは書き下せたものと信じます。
今回のTaskelの事例は有意義な取り組みと筆者も自負しているところですが、同時に 今回ご紹介した事例で検討したトピックは、レイスグループで必要とされる業務システム全体に対して「かなり小さい」 ということも、ここで強調しておくべきでしょう。本格的なプロマネ論を必要とするような規模の大きい取り組みにおいては、AIエージェント・バイブコーディングについて異なる用法・別種のチャレンジがあります。そちらについては、また別の機会にご紹介できれば幸いです。
もしこの記事の内容そのもの、もしくはそれを通じてRSSのソフトウェア開発について興味を持っていただけたなら幸いです。
これからもRSSのメンバーがブログを投稿していきますので、ぜひチェックしてください！
レイスシステムソリューションズ株式会社のソフトウェア開発や、
採用に関するお問い合わせについては、下記のリンクにてお問い合わせください。