ワークスロップ
AIの活用を否定するつもりは全くないのだが、何処に、何に、どうやって活用すればよいのかが見つけられていないのが現状。
仕事の効率化の観点から、システム開発のなかで何が無駄か、という問いに納品物の作成を挙げてみた。
システムが使えればよい、というお客様は多いのだが「要件定義書」「設計書」「試験仕様書・結果報告書」「操作マニュアル」などを納品物として指定してくるお客様もいる。
WFではなくアジャイルを標榜している為、どうしても「要件定義書」（要件定義はベンダー側がやるのか、という話もあるが）や「設計書」は後付けで、納品ギリギリで作成することになる。
また、「試験仕様書・結果報告書」も一通りの試験は納品物としてまとめるのだが、どうしても納品物としての試験には限界があり、納品後ユーザがシステムを利用し始めると障害は発生する。
また、「操作マニュアル」も作成し提出をしはするものの利用された形跡はなく、加えてユーザがマニュアルを見ようとする状況は困ったことが発生した場合であり、その解決策の殆どはマニュアルに記載できない。
そんな状況なので、かけた労力の割には価値を生み出していないので納品物の作成が無駄、といってみたのだ。
そうすると、AIによる開発エージェントなるツールを薦められた。開発したソースコードや過去の納品物（要件定義書や設計書）をAIに学習させて、要件定義書や設計書を自動生成させる、というシロモノである。
まだ商品説明も受けていないし検証もしていないので実用的かどうかは分からないが、ツールが実現しようとしている内容はちょっと違うかな、と感じている。
納品物としてのドキュメントは、その作成労力の割に価値を生み出していないので無駄だとは思うのだが、だからといってその無駄な作業をAIにやらせるというのは、当方の考えている解決策とは異なっている。
「要件定義書」「設計書」「試験仕様書・結果報告書」「マニュアル」という、ドキュメントがお客様にとっての必要性がどこまであるかはわからないが、システム開発をする側としては「要件定義」「設計」「試験」というタスクは必要不可欠であるし、運開後、ユーザが困っていることに対してフォローする方法が必要であることも間違いない。
特に「要件定義」「設計」「試験」の品質は技術者個人のスキルに依存する部分が多いので、なんらかの形で表出化し、共有し、組織としての品質向上に貢献させなければならない。また、ユーザへのアシストも他社商品との差別化につながるので、いろいろな方策をとらないといけないが、「マニュアル」はその方策の一つではあるものの最善の方法ではない。
要は、現状の納品物としてのドキュメントは労力の割に価値を生み出していないので無駄といえるが、だからといってその作業をなくすのではなく、価値あるものにしたいのだ。価値を生み出す労力は無駄ではない。
「要件定義」「設計」「試験」というタスクを実施すれば自動で「要件定義書」「設計書」「試験仕様書・結果報告書」というドキュメントが生成される。また「設計」をすれば「マニュアル」は自動で作成される、もしくは「マニュアル」を作成すれば「試験」も実施される。ユーザのフォローは「マニュアル」だけではない。サポートデスクなどでも実現される。そこで蓄積された困りごとは、改善設計へと行かされる。
これらにコーディングを含めた作業が有機的につながり、ドキュメントは自動で作成され、これが納品物として使える。この様な仕組みが究極の解決方法だと思うし、これらを実現するのにAIは有力なツールになる。
実際にどのようなものか、具体的なイメージが持てているわけではないが。
納品物がお客とベンダーの間の形式でよいのであれば、ワークスロップでよいので、簡単に実現できそうだ。でも納品物として作成するドキュメントを価値あるものにしたいのであれば、ここでもAIは強力なツールになるだろうが、その仕組みをつくる必要がある。
AIが生成するものを価値あるものにするには、その上のレイヤーでの仕組みが必要であるということ。これはAIと付き合うえでの根本的な課題なのではないだろうか。