前々回の投稿、「「SaaSの死」の時代、IT人材が持つべき能力とは？ その１ ～SaaSは滅びるのか？～」では、Claude Cowork、Claude Codeの衝撃的なパワーについて触れ、「SaaSは本当に滅びていくのか？」という話をしました。本当にSaaSが滅びていくのかは未来になってみないとわかりませんが、アプリ開発の概念が大きく変わっていくことは間違いないと感じています。
Claude Cowork、Claude Codeを使い始めて2か月半になりました。この間で主に実施したことは以下です。
何個かアプリ開発を進めている中で、「適切にアプリ開発を進めるための条件」が見えてきています。本投稿ではその中の一つである「設計力」について考えてみたいと思います。
アプリを開発する前に、実現したいことをどのようなシステムの構造で組み立てるかを考える必要があります。例えば、一般的には以下のような判断基準がありますよね。
上記は「例えば」の話ですが、このような各要素を考慮し、ユーザーがツールを利用するシーンなども頭に置きながら、適切なシステムの構造を考える必要があります。
上記で触れた当社システムでは、勤怠・工数入力ツールはデスクトップアプリとして開発しました。勤怠・工数は全ユーザーが毎日のように入力するものです。この利便性が低いと入力しない人が多くなり、勤怠・工数入力ツールとしての意味が薄くなってしまいます。そのため、操作性を重視してデスクトップアプリとして実装しました。また、現状の表示の度、または入力する度にリアルタイムにサーバーへアクセスする仕組みでは、操作性が落ちますし、オフラインの状態で入力ができないなどの課題も生じます。そのため、PC内にローカルDBを持って情報をある程度キャッシュし、定期的にサーバーと同期する形にしました。
ある程度はClaude Coworkが会話の中で導いてくれますが、このような会話をClaude Coworkと対等に行うことができないと、言われるがままに設計が進められ、結果として最適でないアプリができる可能性も十分ありますので、注意が必要です。
Claude Coworkとの会話の中で、ある程度Claude Coworkが導いてくれて、一応アプリは開発できると思います。業務のニーズをしっかり押さえ、それを要件として伝えられれば、機能的にも正しく動作するアプリができると思います。しかし、「非機能」の部分が不十分なアプリができてしまいます。
例えば、最重要なのがセキュリティです。セキュリティのリスクとして「外部の第三者からの攻撃」、「内部の従業員による故意・過失の漏洩」など、いろいろあります。どのような形で悪意のある第三者からの接続を拒否するのか？などはしっかり考えなければいけません。また、「一般社員なのに経営面の機密情報を参照できてしまった」などもあってはいけません。セキュリティリスクが増大している昨今、この検討は必須です。
また、パフォーマンス、可用性など、他にも非機能の側面で考慮すべきポイントはいくつもあります。AzureやAWSのPaaSを基盤として使うとして、コストも鑑みつつ最適なグレードのサービスを選択し、最適な構成に仕立て上げる必要があります。この辺りをおろそかにすると、いろいろな意味で脆弱なシステムになってしまうため、網羅的・構造的に検討する必要があります。
例を挙げるともっともっとありますが、現状Claude Coworkと開発を進めている限りでは、率先してこの辺りを考慮して導いてくれるということはありません。私から「この側面の検討をすべきでは？」と相談すると、「いいポイントですね。重要なことなので考えましょう。」として進めてくれますが、今のところはこちらから言わないとダメ、という感触です。
Claude Cowork、Claude Codeを使って開発を行う場合、このような設計力を持った人をプロジェクトのメンバーに含めることを、強くお勧めします。