こんにちは。RSSのM.D.です。
空前のAIブームです！
レイスグループでもAI利活用に力を入れており、わたしたちRSSでも同様にAI利活用の可能性について多数の領域でチャレンジを続けています。
そのチャレンジの中でも今回は、Claude CodeやCodexといったAIエージェントを用いたアプリケーション開発、いわゆる「バイブコーディング」の活用事例について紹介します。とはいえ、当社の事業に関する前提条件やレイスグループ固有の知識が多いと紹介しづらいのは事実です。
そこで「社員の生産性を上げるWebアプリを、以前なら考えられないほどの早さで作ることができ、実際に生産性の向上が確認できた」という事例を取り上げることにします。社員の生産性の話であれば、読者においても参考になる部分が見つけやすいものと期待します。
本記事は三部構成です：
- 前編：アプリ開発の背景と、クイックに生産性向上につながった一連の流れ
- 中編：バイブコーディングを成功させるための考え方と開発の裏側
- 後編：AI時代のエンジニアの新たな役割とは
なお、このトピックにおいて最初にお伝えしておきたいことがあります。バイブコーディングについて「誰でもすぐにソフトウェアを作れる」と考える方もいますが、筆者としてはそう考えておりません。一般に言われるバイブコーディング評について違和感を覚えることもあります。その全てではありませんが、私の考えについて本記事を通じてお伝えできれば幸いです。
背景：ある社員が思ったとおりに時間を使えていなかった
きっかけとなったのは「ある若手社員に開発をお願いしているプロジェクトの進行があんまりよくない」ことでした。
以下に経緯を書いてみます：
- その若手社員にはもともと「問合せ対応」に類する主務があった
- その若手社員に「ソフトウェア開発経験を積ませたい」という思惑があった
- 同様の（開発経験を積ませたい）思惑がRSS内で少数あることから、それに適したソフトウェアプロジェクトを筆者の方で募って「マッチング」するということを以前からしていた
- そのマッチングの一環として、当該の若手社員の兼務の業務として、直接利用できる時間の半分以上をこちらに使う想定でアサインした
- 開発が進んだ様子がない週が頻発（ほぼ連発）するという状況になった
- 本人と話していても「なぜなのか」がパッとは良くわからない
- どう指導したらよいものか、主務・兼務の両上司（片方は私）が悩む展開になった
この経緯について、そもそも突っ込みを入れる箇所があります。「兼務での開発自体、一般に好ましい状況ではない」という指摘は妥当だと私も思います。原理的には「1つの開発業務に集中していただくのが最適」であるのは言うまでもありません。
しかし、他方で現実に発生するこのような状況にも組織として対応できる必要もあります。つまり「主務を維持してもらう必要がある一方で、それだけでは当人の経験が偏り続けてしまうというリスクに対処する」という現実の問題解決をしなければなりません。
兼務開発のリスクを意識しつつ、開発経験がプラスに働くように仕向ける必要があります。
一般的なアプリより踏み込んで用途特化した方がよさそう
一見すると、要するにこれは「タスク管理」の話、に見えます。そうまとめてしまえば、話は単純そうでもあります。タスク管理アプリ自体は世の中に溢れているのですから、何か使えないものか？
今回作成したアプリの発想の原点に関わる「タスク管理」と言えば、Google Calendarで記録を取る方法がまず思いつきます。実際、他の社員で成功裏にそうしている人もいます。当の筆者自身も、予定ややったことについて、メモ書き程度にGoogle Calendarで個別のカレンダーを作成して管理するということならあります。スケジュールの移動などのUIもその点で非常に使いやすいのはさすがです。
（今回の記事作成で行った「タスク管理」）
そもそも、その若手社員も自身でスプレッドシートベースの管理ツールは自作していました。日報の一環として「今日、主務にはこのくらいの時間を、兼務（開発）にはこのくらいの時間を使った」といった報告をしてくれていました。
しかし、上司（私を含めて）とのスムーズな意思疎通がなされる展開までに至らないという現実がありました。
朝・週の最初には兼務開発する予定だったはずなのに、ズルズルとその時間が消滅していきました。おまけにスプレッドシートでの管理あるあるで、集計ミスも発生します。把握する側としても、この管理手法は本人独自のものであり、共通化されているとは言えません。
「ズルズルとその時間が消滅していく」について、表面的には「自己管理」の問題と片付けたくなりますが、今回、個人的には「これは自己管理上の問題ではない」（原因はもう少しややこしいところにあるだろう）という直感が働きました。
「自己管理」でできる領域なら、可視化している時点でとっくに自分で直しているはずです。この手の浅い分析で問題を「本人起因」にすると、上司としては楽ですが、組織は決して良くならないという気持ちもあり、もう少し掘り下げることにしました。
とはいえ、結果として、何が真実か把握しづらい状況が続きます。
総じて、Google Calendarの方法、スプレッドシートの方法、さらに一般のタスク管理の方法は、今回、その社員に管理してほしいことや、暗黙に周囲が求めていることに対してはフィットしていないと思うようになっていきました。
「日次・週次で、予定していた業務ごとの作業時間、実際に各業務に割り当てられた作業時間を整理する」といったことが必要です。
四半期の中で例えば30%程度を今回の兼務開発に割り当てるとした場合、日次・週次・月次のいずれかにおいて投入する業務時間もそれに類する状態になると辻褄が合います。
主務・兼務の両上司の目線で実際にそういった業務指示になるわけですが、この予定・実績の管理にGoogle Calendarは噛み合いません。Google Calendarは全体的に「予定と実績をタイムリーに比較する、集計する」ためのソフトではありません。より具体的に言えば「今週は何時間、間接的な活動を予定していて、実際にはどうなったか」を今回の社員のケースではすぐに把握したかったのですが、これはカレンダーアプリが提供する機能ではありません。
一方、スプレッドシートはスプレッドシートで、「いつ頃、どういう活動をするつもりで、何を実際にしたか」という記録を、Google Calendarのようにドラッグ操作だけで軽快に管理することはできません。
「タスク管理」だと思って管理を試しても上手く行かないという現実を踏まえ、改めて今回の「要求」について考えてみます。すると、今回の要求は普通のタスク管理ではなく、「タスク管理」と「管理会計」の両方の目線を持った要求になっていることに気づきます。一方では、一定の時間配分で兼務開発を実施してもらいつつ、もう一方では、その社員の全体の勤務時間における活動割合の予実分析をしている、そんな塩梅です。
これは案外たちが悪い問題です。「本当は異なる２つの問題意識を同時に解決したい」という要望に対して、既存のアプリから適合しているものを探すのは難しいことが多いように思います。Google Calendarでもスプレッドシートでも、片方の要求をギリギリ解決するだけにとどまります。
達成したい目標が、一般的な世界の用途に照らして「混ざっている」、加えて社内固有の業務を意識する、となると、既存のアプリの拡張機能などで実現するのはかなりしんどそうです。
要求を整理して独自のタスク管理アプリを作ってみる
ちょうどその頃、筆者はAIを用いたアプリケーション開発をよく行っていました。アプリケーション開発とともに、問題提起やアプリを介した業務改善の提案を行なうような感じです。その中で同時に プロトタイプをスルスルッと作って、かつ、運用のイメージのつく仕組みも求めていました。
上の問題に出会った際にも、ある意味同じような脳みそでこう考えました： 「タスクの日次観測力を求める会社である割には、そういうことを支える仕組み自体が成熟していないな……」
その若手社員が苦しむことや、上司と「どーすればいいんですかね？」って顔を向き合わせて当惑し続けるのも本意ではありません。
そこで、「スルスルッ」と作ってみることにしました。その結果生まれたのが、今回紹介する日次目標管理のTaskelです。
作成したTaskelの簡単な紹介
当初はもっとシンプルな構成でしたが、現在は機能が増えています。ここでは、記述を簡潔にまとめ、最新スクリーンショットでアプリを紹介します
添付はメイン画面のスクリーンショットです。少しだけ画面について解説します。
- 3つのペインがあり、中央には「予定」と「実績」という2つのレーンがあります。左枠である「予定」は朝に書き、右枠である「実績」はその日に都度書いていきます。
- Google Calendarをお使いの方なら類似のインターフェースで、1日に予定を記載する部分が2レーンあるものを想像するのが手っ取り早いでしょう。特に予定通りに1日の作業を進行できた場合、「予定」の内容を「コピー」ボタンで「実績」にコピーしてマウスで伸び縮みさせれば良いので、二重で記録していても管理は大変にはなりづらいという工夫を入れています。
- 「自分が当初予定していた行動をしているか」をおおむね15分～30分の単位で確認するイメージとなるように、マウスによるドラッグ操作（移動や枠の拡大縮小）ができるようにもなっています。
- 勤務形態によっては休憩スケジュールが同じため、同じところに休憩予定が入るような支援機能もリクエストの後にすぐ実装しました。
- 予定と実績の双方でどのタイプの作業にどのくらい関わっていたかの割合が、中央ペインの下部で把握できます。
- スクリーンショットの事例では「直接活動」に対応する活動が予定より少なくなり、黄色の活動（ここでは詳細はモザイク掛けになっていますが）が予定とは別の事情で追加されたことがわかります。
- 全体的に社内で観測される日次・週次の業務観測サイクルに最適化された形で、モダンなWebアプリといえる程度に操作感についてチューニングを行っています。
- スクリーンショットで目につくボタン類は1つたりとも「ハリボテ」ではなく、全て完全に動作する状態で試験提供しました。
いわゆる SPA (Single Page Application) として使い勝手が良くなるように調整をしたアプリとなりました。
おまけ：Taskelの宣伝用画像
ついでに宣伝用のイメージもAIに作ってもらいました：
「タクシー広告にありそうな感じ」みたいに書いたら、後ろに3つもタクシーが描かれていて、しかもよく見るとタクシーの走っている車線がなんか変。なんともAIっぽいですね……。
可視化することで同じ視座で話を進められるようになった
詳しくは中編で述べますが、Taskelでははじめから社員が試用できるように、クラウドにデプロイ可能なように設計されています。私が動作確認をローカル環境でできたのとほとんど同じタイミングで、他の社員も自分の社内アカウントでログインして使うことができるようになります。
そこで、当の若手社員にこのアプリを使ってもらい、主務の上司とこのアプリ上で週次の様子をモニタリングすることにしました。
……すると、なんと記入をしはじめただけで、兼務業務の比率が改善しました。あくまで私の個人的な観測ですが、実際にこのアプリを使いはじめて次の週くらいから、兼務開発の作業量が当初の取り決めにかなり近い比率となり、実際にアウトプットもできるようになってきました。
それまで数週間「なんでだろう？」と当惑していたのと比べると天と地ほどの差（個人の感想）です。
- 日次で朝に予定を立ててもらい、日中各業務ごとに気づいた段階でGoogle Calendarに記録を取るような感覚でイベントを記録してもらう。
- 1日の終わり、週の終わりにアプリが集計した「予定」「実績」を確認してもらう。業務比率はアプリで自動的に集計されるので、入力の手間は最小になる。
- 上司サイドは同じアプリの対象社員の様子を随時見るなり週末に確認するなどして、問題があればどこに問題があるのかを把握する。
週次の「目標」と「実績」を見比べることができるようになったため「もともと想定していた主務・兼務の配分比率も週次で安定しているね」といった話ができるようになりました。
「記録しはじめた瞬間から正常化した」ように見えるのは一見、不可思議です。前述の通り、数週間も「なぜか兼務が進まない」状況だったわけですから、アプリ1つでこんなにも変わるのか、という印象。
真面目な人が真面目に導入すれば思い通りに結果が出る仕組みがなかった、というのが真因に感じられます。「自己の時間を管理せよ」と言われたら当然やろうと努力はしますが、良いツールがないままスプレッドシートで管理することそのものが非常に苦痛で効率も悪く、おまけに効果が薄い……なんてことを経験したこと、みなさんもないでしょうか。私はあります。今回はそういう事例だったのだと解釈しています。
新人研修で使ってみたいという話につながる
ここまでなら、単に「まぁまぁシニアの社員が自己満足でアプリを1つ作って、ユーザーも1人だけ」という範囲を出ません。これでも個人的には興味深い事例なんですけれども、しかし、ここからもう少しだけ話は進展します。
もともと「何らかの形で他の社員にも役に立つであろう」という仮説でアプリは開発していましたが、次の提案はちょっと想定と違うところからやってきます。
2026年入社の新卒生研修担当者の1人から「Taskelで26年新卒社員をモニタリングしてみたい」という話が舞い込んできました。言われてみて「なるほどそれは考えていなかったけど、筋が良いかも」とすぐ思い当たる提案。
当社では未経験者と経験者の両方が入社して一緒に研修を進めます。その際、各自の進行状況がかなりバラけることが多く、それを把握しておくことは価値があります。一方、その把握を社内で開発しているチケット管理システムで見ていたのですが、ものすごくピッタリしたツール、とはちょっと言いがたい感覚を個人的にも感じていました。チケットを起票すると、把握そのものにもいちいちコストがかかってしまうが現実です。
今回紹介しているTaskelでは、最初のユーザーに使ってもらう段階で、既に将来を見越して5人～10人くらいの部下管理に使う可能性はあるだろうなーとは考えており、メンバーの横並び比較の機能も実は並行して作って（実装指示をして）いました。
この「将来に向けた複数社員管理機能」が研修担当者の目に止まったわけです。以下に5名の予定を並べたときの中央ペイン部を示します。
上図では5名中3名は研修中、残り2名は研修をしていない社員をあえて並べてみました。1、 2、 4番目の社員が類似の作業を、3,、5番目の社員は異なる作業を実施していることはモザイク越しにもすぐに把握できると思います。また、社員ごとに計画通りに進行しているか否かもパッと見て多少は把握できるのではないかと思います。
各自の状況を詳細に掘り下げるのもスムーズにできます。今度は研修生1名のTaskel利用の実例を見てみましょう：
俯瞰するだけで、この社員のこの日の予定と実績が大きく異なることが分かります（モザイク越しだとそうでもないかも……）。そこで、具体的に各予定・実績の様子を見に行くと、研修の1つである「Google Cloud研修」の対面試験が大幅に前倒しで実行され、次の「セキュリティ」に学習が進んでいます。この社員は前倒しで研修を進められていることが漠然と察することができます。この予定と実績のズレは「前倒しで研修を進められているのでポジティブ」だと判定できます。もちろんこの逆のケースとして、「予定より進展が遅い」といったことも記録次第では把握可能になります（し、より心配すべきなのはこちらのケースです）。
私とその研修担当者の2人で「これ使いやすいなぁ！」と普通に感心する次第。横断での把握とともに、研修担当者の管理コストも下がることで生産性は着実に向上しました。
脱線：若干「監視ツール」めいているという批判もありそうなものだが……？
ちなみに、AIブームにあやかってこの記事もAIレビューを取り入れているのですが、「監視ツールと読み取られてしまうのでは」という指摘があり、あっとなりました。
外部読者（特にSNS）の目線では、「15〜30分単位で行動を確認」「上司が随時見ている」「新卒社員をモニタリング」という記述は「マイクロマネジメント・監視アプリ」というフレームで切り取られる余地があります。
実際、作っている際にも「このツールで記述粒度も含めてガチガチにルール化すると息苦しいことになるよなぁ……」とうっすら心配していなかったわけではありません。
RSSの実態として、フェアな説明は次のようになるのではないかと思います：このツール以前の問題として、レイスグループ全体が生産性向上・採算意識についてやや厳しい組織であり、若手教育でも実際に強調されています。その結果として、「もともと細かに計画を立てて振り返るカルチャーがある」のです。ただ、その計画と振り返りを活用する手段が限定的であった、そこにはこのTaskelが強烈にフィットした、ということ。
実際、記述の粒度については最初の「新人社員の開発」の事例も「新人研修」の事例でも、我々からTaskel向けに指導はしていません。上の5人のタスク管理でも、大きく枠を取っている社員と細かに書いている社員がいることが見て取れます。各自の管理に都合が良い範囲で粒度を指定してもらう、というのが元の設計思想とも噛み合っています。
改善を定量的に示すと？
定性的には分かるものの、では定量的にはどうか？
これは最重要なテーマでもあり、一方で筆者としてはちょっと解釈に苦しむテーマでもあります。どちらかというと「できないことができるようになった」ゼロイチの側面が強い。とはいえトライしてみましょう。
2つ事例を示したうちのはじめの兼務開発の事例について考えてみます。若手社員氏にも聞いてみたところ、まず直感で「生産性が上がった」のは間違いがないとのこと。
あとは定量的にどのくらい生産性が上がったかですが、おおまかには次のような部分は「ほぼ間違いなく時間の節約になっている」という結論に至りました：
- 日次については、10分くらいは節約している（もともとの日次の作業よりTaskelの方が安定的に短くなる）。また週次については、上司に報告する際にも同程度の10分かそれ以上節約できている。よって週の単位で言えば、少なく見積もっても優に1時間以上はこの集計と観測において節約できている。
- 四半期ごとに目標を立てる際、前四半期の実績を集計する際にアプリが集計機能を持っていることでやりやすくなった。これで数時間節約できている可能性が高い
細かい計算を置いておくと、これだけでも本人の業務時間において5%の生産性改善くらいは控えめに見てもありそうです。塵も積もれば山となる、とはいえ、「生産性が2倍」といった改善と比べると控えめ。
投入した時間に対する効果、「費用対効果」はどうでしょうか。
今回のアプリケーションはマウスでの直感的な操作など、Google Calendarに近いUIの操作を実現しています。これは結構作り込みがいるところ。
ですので、時間がかかったかと思いきや……
開発にかかったコストはいかほどか
まずは「カレンダー上の日数としてどのくらいかかったのか」を考えてみます。コミット履歴を追った結果、だいたい以下のような進行であったことが分かりました：
- Minimum Viable Productとしての初期バージョン完了にカレンダー日数で 3日
- 最初のユーザーに使ってもらう環境の完成までにカレンダー日数で14日
- 新人研修でフルに利用可能な状況までにカレンダー日数で27日
若干不正確（コミットタイミングで1～2日ズレている可能性もあります）であることは認めつつ、そうであってもやけに早いなと、開発した当の本人としては正直思います。
初期バージョンの時点で、前編でご紹介した「予定」「実績」の2レーンにわたるタスク管理UIや基本的なユーザー管理といった主要な機能は完成していました。特にGoogle Calendar風にインタラクティブに使用できるタスク管理機能がこのアプリのキモであることを考えると、それが3日かそこらで完成する、というのは通常ありえません。
……AIがなければ、そうですね……
タスク管理機能のデモだけでも、私自らが実装したら1ヶ月では終わらないでしょう。どちらかといえば私はWebフロントエンド開発を不得意としていまして（どちらかといえば「管理職」ですし、キャリア的にもバックエンド・SRE・データエンジニアの側の人間です）、適切なWeb APIを全て即座に選定できないように思います。探して試して自分の勘違いからなるデバッグをして……で、何日かかるやら。チップ状のタスクをドラッグして移動させ、またその下部分をつまんでタスクの所要時間を15分単位で増減させる、というだけでも調べなければ書けませんし、とりわけバグが発生して直りにくそうです。
「最初のユーザーに使ってもらうまで14日、営業日換算ならそれ未満」で、ファーストユーザーを獲得してその後の展開も良好というのは大変素晴らしいことです。細かいことを置いといて紹介するなら「社員の生産性を5%上げるアプリが2週間も経たずに爆誕」した事例として、バイブコーディングの価値をいかんなく発揮した事例と呼べると考えます。
さらに加えて、カレンダー日数以上に大事だと思われるのは、開発にかかった実際の作業量やエネルギーです。この期間にこのソフトウェアの開発に集中していた、わけではありません。もともと完全におまけの枠です。
他の仕事の片手間に実装指示を出しては使い勝手を検証、場合によってはクラウドにデプロイしては使ってもらいフィードバックを受け取る……というプロセスを繰り返しました（最初の3日よりも「新人研修でフルに利用可能な状況までにカレンダー日数で27日」の間がこのサイクル）。最初の「3日」こそ「指示→結果→再指示→……」の循環があまり途切れないようにしていましたので、その意味で「密度」はまぁまぁ高いバイブコーディングでしたが、14日・27日においては週をまたいでいますし、コミットを見る限りでも不活性の日があるようでした。
正式なソフトウェア開発プロジェクトということでもなく、厳密に開発ロードマップを決めたり、イテレーションを組んで体系的に開発と報告を繰り返すということ自体を一切していません。いわゆる「アジャイル」よりさらに「雑」です。
以上のような具合ですので「作業時間」を正確には把握できませんが……幸いこのTaskelスタイルでは私が行った日本語指示の9割以上は残っていますので、このテキストをベースに工数概算をしてみましょう。
大きい単位の作業指示とAIによる作業記録は、ほとんど全て記録としてgitリポジトリに残しています。この「主要な指示をなるべく記録に残しておく」という所作はあまり一般に流布しているものではなく、筆者の個人的好みでしかないのです（おすすめもしません）が、指示に費やした文字数の目安を今回紹介するのには多少役に立つでしょう：
- requirements/phaseN.md (phase1.mdなど) に開発フェーズごとの要求事項を記載している。現在Phase10までで436行13526文字
- 最初の3日を見るとおおむね300行10000字程度
- 上記のほか、個別の指示に対応する 1163行38486文字（AI生成がおそらく2割あるため、実際には8割程度は筆者が書いたもの）
「文字数多くない！？」と一瞬思われるかもしれません。具体的な例を以下に示すと、そうでもないことが分かります：
# レイアウトイメージに基づいた再設計の実施
`requirements/fundamentals.md` に「レイアウトイメージ」というセクションを追加し、
requirements/task_management.png も新たに追加しました。
現在の画面レイアウトにはやや根本的な修正を求める形になります。
一部DBモデルにもカラム追加が発生すると言ったことが考えられます。
`.ai/design.md` を見直して修正するとともに`.ai/todos.md` の作業済のものを `.ai/done.md`へ移動し、
改めて必要な作業を `.ai/todos.md` に記載してください。
レイアウトイメージにおいて不透明な点はこの段階で `.ai/tbd.md` を介して、もしくは直接指示者に確認してください。これが12行378文字となります。ファイルのパス指定などが含まれますので、「400字詰原稿用紙で……」といった感じの散文・小説の文字数と比べれば遥かに中身は薄く記述の負担は低くなる、とは申し上げて良いでしょう。
後は、記載者の日本語記述力とタイプ速度次第でして、正確な統計は取れません。
あくまで私の感覚ですが、実装してほしい事項を考えて落とし込むのに50時間かかったということはまずなく、これまでの全開発期間（2ヶ月）で10時間から20時間の範囲ではないかと思われます。どちらかといえばより長くかかるのは待ち時間でして、1時間考えて指示した開発フェーズの指示（requirements/phaseN.md）に対して、数時間待つということはよくありました。特に「最初の3日」は1回の指示は1時間クラスですが、待ち時間は3時間～5時間などということが珍しくはありませんでした。
ありとあらゆる概算が交じる中であえて主張するなら「20時間で毎月複数人の社員の生産性が5%上がり続ける」というのは、コスト対効果はそんなに悪くないのではないか……と思います。
日本語でほぼ完結する開発
このアプリケーションでは記憶の限り私自身がプログラムを直接記述したことがほとんど、いえ、全くありません。
…1回くらいはあったかもしれませんが、せいぜい設定ファイルの古いコメントを消すとかそういう軽微なもの。「プログラムの内部を追いかけてテストが直るように直接エディタでコードを修正にいった」といったことは一度もないと言えるかと思います。
代わりに行なったのは、「この表示はおかしいのでこうして」みたいな、言ってみればプロダクトマネージャーが開発者にわたす「開発チケット」のような指示が中心です。問題点や理想の状態を日本語で書くだけで、適切に修正される仕組みになっています。
1つ簡単な例を挙げます。以下の画面は、自分が閲覧権限を持つ他の社員を指定することで、その人の予定を確認するモードですが、「読み取りのみ」のインターフェースです：
ここで、画面上にはカレンダーアイコンが表示されていますが、これはバグです。このアイコンは本来、自分の予定を見ている際にGoogle Calendarの予定をTaskel内の「予定」に取り込むアイコンであって、第三者の予定において表示されているべきではありません。
これまでの開発であれば、このアイコンを表示させているHTMLテンプレートなりを自らIDEを用いるなどして確認しに行くところですが、AIエージェントを用いた開発においては代わりに指示をします：
※ ここで quick-impl-deploy はClaude Codeにおける「スキル」と呼ばれる仕組みを使っています。後に改めて説明しますが、ここでは「指示通りに修正してすぐにクラウド上で利用できるようにして」という指示をショートカットしていると理解していただければ十分です。
スキルを指定して、詳細を1文指示するだけで、修正・ユニットテストをはじめとした各種のテスト・AI自身によるレビュー・Google Cloud環境へのソフトウェアのデプロイが行われます。以下に作業が完了したあとのClaude Codeの応答を示します：
Churned for 14m 59s
この指示によってカレンダーアイコンは第三者の予定に対しては表示されなくなりました。
かかったのは15分です。「一瞬ではないが、自分がやるよりは圧倒的に早い」修正と言って間違いありません。これだけで関係する社員にはすぐに使ってもらえます。
ここでも分かるのですが、気づいて指示を出すのはせいぜい3分～5分ですが、15分の待ち時間が発生します。やはり指示の数倍程度はかかります。実際に自分で実装するなら集中して30分くらい拘束されるので、圧倒的に早いというのも同時に分かります。
全体的に「バイブコーディング」時代以前には考えられない速度と品質の両立が成し遂げられ、おまけに社内の生産性向上には明確にプラスに働いた事例であることは間違いないという水準まで来たTaskelですが、一方で、なんとなく気分で「夢のようなタスク管理アプリがほしい」と指示しただけでは生み出せないことも分かっています。
そこで中編では、このTaskelのバイブコーディングで具体的に筆者が何を考えてコンテクストを設計したか、について技術的な側面を紹介していきます。
レイスシステムソリューションズ株式会社のソフトウェア開発や、
採用に関するお問い合わせについては、下記のリンクにてお問い合わせください。