Kiroを実案件で評価してみた③

Kiroによる弊社開発標準への適用（ドキュメント作成）

前回の記事でご紹介した、ドキュメント作成用のSteeringを活用して実際に作成されたドキュメントをご紹介します。

1) 画面設計書

実際のプロジェクトではExcel形式の設計書が多いですが、Kiroの操作できるファイル形式の制約を踏まえ、今回の検証ではHTML形式で画面設計書を作成しています。
Steeringに画面設計書の作成/更新手順を整理しKiroに参照させることで、機能追加のたびに画面設計書も自動で更新されるようになっています。
ここで重要なのは、設計書を後から手で修正するのではなく、開発タスクの一部としてKiroに実行させている点です。これにより、実際のプロジェクトで発生しがちな設計の更新漏れによる実装の乖離を防止しています。

以下は実際に作成された画面設計書の抜粋です。
画面レイアウトのイメージも含めてKiroにより作成しています。

2) API設計書

API設計書については、OpenAPI準拠のYAML形式で作成するようにKiroに指示しています。
各種設定値だけではなく、説明やリクエスト/レスポンスの例も含めることにより、人によるレビューや管理がしやすい内容としています。

3) テスト仕様書

テスト仕様書は、画面設計書と同様にSteeringに作成/更新手順を整理しKiroに参照させることでテストケースおよびテスト時に利用するテストデータの作成をしています。仕様が変更された際は、変更内容に対する追加のテストケースが作成されるようにしています。
また、一部のテストは自動テストをKiroで実施することで効率化を実現しています。

以下は実際に作成されたテストケースの抜粋です。

さらに、テスト実施後はレポートを出力するようにSteeringに記載しています。
これによりテスト結果がNGとなった項目を効率的に確認することができます。

ここまでの一連の流れ（設計書作成→テスト仕様書作成→実装→テスト実行）をすべてSpecsのTasksに含めることで、開発タスクの作業漏れを防止することができます。

検証を通じたKiroの評価

今回の検証を通じて得られた知見を基に、Kiroの有用性と課題を整理してご紹介します。

Kiroの有用性

前々回の記事では、Kiroによる工数削減効果についてご紹介しましたが、
検証を進める中で明らかになった工数面以外のKiroの導入による有用性をご紹介します。
前提として、Kiro特有の有用性だけでなくAI開発ツール全般の導入による有用性も含みます。

1) 学習・キャッチアップの高速化

Steeringに既存アプリケーションの仕様やリポジトリの構造等が整理されていれば、Kiroに対してアプリケーションの仕様等について問い合わせた際の回答の精度を高めることができます。
これにより、仕様や技術的な質問をチャットで効率的に行うことができ、従来の「ドキュメント検索→読解→理解」のプロセスを短縮できるため、プロジェクトへの新規参画メンバーの学習やキャッチアップにかかる時間を短縮することが可能になります。

2) 品質の均質化・向上

Steeringにプロジェクトや社内の開発標準を整理することで、新規参画者でも標準に則った成果物を作成することが可能になります。
また、Kiroはフレームワークやライブラリのベストプラクティスに則った実装や、「テストケース作成→テスト実行→コード修正」のサイクルを自動で繰り返し実施できる点から、品質の向上が狙えます。

3) 低コストで導入可能

Kiroの料金プランは4種類あり、お試しや学習用のFreeプランは無料で利用が可能です。また、本格的なシステム開発に導入する場合でも月額$20のProプランから開始することが可能です。(※記事投稿時点)
Proプランでは月当たり1,000クレジットが利用可能ですが、今回の検証で利用したクレジットは3ヵ月で約2,000クレジットのみです。
そのため、他のAI開発ツールに比べ低コストで本格的なシステム開発に導入することが可能です。

4) AWSとの統合

既にAWSを利用している場合は Kiroを利用する際にAWS IAM Identity CenterによるSSOが可能であり、AWSコンソール上でKiroを利用するユーザーを一元管理することが可能です。AWSの月額請求にKiroの利用料金をまとめることも可能です。
また、他のSaaS等のAI開発ツールを利用する場合、社内のガバナンス部門による利用承認にリードタイムを要することが想定されますが、Kiroの場合は既に承認されたAWS環境があればスムーズに利用を開始できると考えられます。

5) 開発範囲の拡大

従来のAIによる開発が得意とする0→1の新規開発だけでなく、既存アプリを理解した上での追加開発にも対応できることを今回の検証で確認しました。
さらに、アプリケーション開発以外にもIaCコードの作成、OS/ミドルウェアセットアップのスクリプト作成、運用手順書作成等のインフラ関連の開発タスクにもKiroの仕様駆動開発を適用することが可能です。

課題

Kiroの有用性をご紹介しましたが、実際のプロジェクトで利用する際には考慮すべき課題がいくつかあります。それらの内容と対応策をご紹介します。
前提として、Kiro特有の課題というよりはAIを活用した開発全般に当てはまる課題がほとんどになります。

1)：Kiroと人の役割分担が曖昧では生産性が上がらない

実際のプロジェクトでの要件定義等の上位工程で仕様が固まっていない状態でKiroに実装を任せてしまうと、出来上がったものが想定と乖離してしまい手戻りが発生してかえって工数がかかってしまいます。
一方で、Kiroの活用を局所的にしてしまうと仕様駆動開発の強みを活かすことができません。
どこを人が実施し、どこをKiroに任せるのかの役割分担を事前に整理しておくことが望ましいと考えています。
これは実際のプロジェクトでチーム/メンバー毎の役割分担を事前に定めておくことが重要であることと同様です。

2)：複数人での並行開発が困難

Kiro(IDE)は個人の端末にインストールして利用するツールであるため、Specsをメンバー間で共有していたとしても、同じ機能を複数人で並行開発した場合に差分や競合が発生する可能性があります。
SteeringやSpecsをしっかりと整備することで、ある程度制御することは可能と考えていますが、そもそもKiroの特性に合わせて複数人での並行開発を実施しないことが望ましいと考えています。
例えば、従来の開発プロジェクトではフロントエンド担当とバックエンド担当で分かれて実装をすることがよくありますが、Kiroを利用する際はそのような分担をせず、実装する機能の要件をまとめてKiroに連携して1つのSpecsの中で全て実施することで「1人の開発者+Kiro」の体制で実装が可能になります。

3)：AIによる作成物のレビュー負荷

Kiroは実装やドキュメントの作成を高速で可能な反面、一度に大量の作成物が生成されるためレビュー担当者が全体を把握しづらく1つ1つ確認するのには負荷がかかります。
そのため、AIによる作成物を前提としたレビュー観点を整理し、レビュー対象に優先度を付けることが重要であると考えています。

4)：デザイン要件は文面では伝わりづらい

実装する画面イメージをプロンプトの文面のみでKiroに指示すると認識のずれが発生しやすく、想定と異なる画面が作成される傾向があります。
対応策として、Kiroは画像をインプットとすることができるため、画面のイメージ図をプロンプトと合わせてインプットすることでイメージに近い画面の実装が可能になります。

また、課題ではありませんが開発生産性を向上させるために意識するべきポイントもご紹介します。
まず、Kiroの技術的制約の考慮です。例として、検証実施時点ではKiroはExcelファイルを扱えない仕様であったため、各種ドキュメントは社内の標準とは異なるHTMLやMarkdown形式で作成しました。このように仕様に合わせてドキュメントの標準化等を行うことでKiroを最大限活用して開発生産性のさらなる向上が狙えます。

次に、適切なコンテキストウィンドウ管理が挙げられます。コンテキストウィンドウとはAIモデルが一度に処理・記憶できるテキスト量の上限です。アプリケーションのコード全体を常にKiroに参照させてしまうとコンテキストウィンドウが不足してしまい推論を継続できなくなってしまいます。そのため、チャットで参照する範囲を明示的に指示することやSteeringを活用することでコンテキストの消費を抑制し、効率的なAI開発が可能になります。

まとめ

検証を通じた、Kiroによる生産性向上の評価結果をご紹介しました。
今回の検証ではKiroの活用によりシステム開発プロジェクトにて57%の工数削減を実現しました。
Kiroの特徴であるSpecsによる仕様駆動開発はエンタープライズシステム開発に大きな有用性がある一方で、課題として検討すべきポイントも見つかりました。
さらなる生産性向上に向けて改善を重ねながら今後も取り組んでまいります。