ソフトウェアを開発していく上で、設計書やシーケンス図などにもよく使われるOffice。
特に『Excel』は、表計算やマクロだけでなくお絵描きもしやすいツールで、グリッドに合わせて等間隔に図形配置できたりオブジェクトでシーケンス図やモジュール構成図が作れたり、あとWBSやEVMSなど予実管理や進捗管理にも使え、本当にマルチで使えて便利ですよね。
ことあるごとにExcelばかり使い、逆にExcelの呪縛から逃れられなくなっている『Excel中毒』になってしまっている自分に気付かされる時もあります。
ただ、ご存知の方も多いと思いますが、海外ではあまりExcelって使われていないようで、Officeももちろん活用はされますが、GoogleスプレッドシートやAtlassian、HTMLホストドキュメントなど、そもそも、こういった設計に関する資料の類をアーカイブファイルとして使わない文化も多く、マルチな使い方ができるExcelをガンガン使っているのは、特に日本企業が多い、とも言われているようです。
OA化や自動化、仕組化によってこのExcelから脱却していく時代に入っていますが、日本企業においては、設計書や構成図などのお絵描きやAPI仕様書、シーケンス図など書きやすく、結局Excelは根強く残っていくのではともいわれています。
ですが、昨今において生成AIが登場、便利だ便利だと言われて多用していたこのExcelが、日本企業の生成AIの利活用におけるハードルを上げてしまっているという、新たな事実も浮き彫りになってきている模様です。
というのも、クラウド型生成AIやエッジ、オンプレ型生成AI、いずれもプロンプト駆動やエージェント駆動、どんな駆動方式であっても、大規模学習モデルに最終的にいきわたるのは結局『テキスト言語』であって、ExcelやWordなどバイナリ形式のファイルを直接AIは読めず、一度マークアップ言語や、表の場合はreStructuredText、HTMLやUML、XMLやJSON、CSVなど、テキスト変換できる『構造化言語形式』に一度変換しないとAIモデルが解釈できない問題があり、このインパクトをもろに受けてしまっているのが現状のようです。
※補足）
Microsoft GraphとOffice Nativeに統合されたMicrosoft Copilot/M365 Copilotは、Officeファイルが直接読める唯一の生成AIサービスですが、ソフトウェア設計や技術面の工程作業支援の利活用に特化しているわけではありません。
インストラクション駆動だけでなく、もちろんファインチューニングやトレーニングによるモデルの学習、AIが参照するナレッジベースも同様、Excelだと直接学習できず、Vision(マルチモーダルの画像認識)で絵にしつつそれでもぼやける中身の精度を上げる努力が必要で、AIと付き合っていく、という上でも、Excel文化は早期に脱却していく必要があるのかもしれません。
皆様それぞれのソフトウェアの開発現場においても、長い歴史を経て膨大なExcelやWordで作られた歴代含むOfficeの設計書や仕様書が山積みになっていると思いますが、例えばマークダウン形式にしてMkDocsやSphinxで体系だったHTMLのウェブホスト構成にするなど、時代に合わせた文書の在り方へ変革していくことが、生成AI啓蒙期に入ってきた今だからこそ、求められる時代になってきているのではないかとも感じています。
日々作成されている設計書や仕様書の未来を考え、ことあるごとにExcel、Excel、ではなく、時代に逆行しているなら少しずつでも先を見据え、時代に合った形式へ、変えていきたいですね。
ぜひ、一度皆様のプロジェクトでも、振り返ってみて頂ければと思います。
