ソフトウェアは世界を席巻しています。この力を取り入れるアプローチの一つがAs Codeです。
As Codeとはプログラムコードで表現し、処理もプログラムに任せるというパラダイムです。最も有名なのが、ITインフラに取り入れたIaC――Infrastructure as Codeでしょう。
IaCにより、ITサービスを支えるインフラ基盤部分の自動構築が可能となり、飛躍的な進歩をもたらしました。現代を支えるパラダイムの一つです。
As Codeにはビジネスを変える力があります。
今回は新しいAs Codeを提案します。その前に従来のAs Codeも振り返ります。 ※As Code自体の説明はしません。
ここからは新しい As Codeを提案していきます。
会議のファシリテーションをAs Codeにします。 略称はFACIaCとさせてください。
ファシリテーションとは、会議の進行管理と細かなフォローを指します。従来は、場の空気や参加者の様子を読みながら、ファシリテーターが行っていましたが、その必要がなくなります。
会議をどのように進め、参加者をどのように制御・フォローするかは全部コードにて書きます。実際のファシリテーションは、そのコードを解釈するプログラムが行います。
メリットは以下のとおりです。
エイリアスをAs Codeにします。 略称はAaCとさせてください。
エイリアスとは、ショートカットやシンボリックリンクを指します。
従来、エイリアスは人間が手作業でつくるか、あるいはスクリプトなどで一気につくるものでした。
As Codeにすれば、エイリアスをどうつくるかをコードで記述できます。より柔軟な設定や構造をもたせることができますし、作成・更新・削除も自在です。もちろん、IaCのように環境ごとに適用を分けることもできます。
IaCの一部と言えばそれまでですが、エイリアスは個人的なものです。
すでにDotfileやパッケージ管理といった技術はありますが、AaCもその範疇になります。環境構築、特にカスタマイズという世界に、新しい軸をもたらします。
手作業だったからこそ敬遠されていたエイリアスの利便性が、改めて見直されるでしょう。AaCを使えば、何百何千というエイリアスを仕込むことだって可能なのです。
ブックマークをAs Codeにします。 略称はBaCとさせてください。
ブックマークは元来個人的なものでしたが、組織内で共有できれば一種の情報共有として機能します。そうでなくとも、はてなブックマークはSNSとして知られていますし、Veinなどコミュニケーションツールとしての試みもあります。
https://www.slideshare.net/slideshow/veinpsychological-safety-and-introduction-of-vein/136959253
さて、BaCは、共同ブックマークを実現するために重宝します。
共同ブックマークの課題は整理とメンテナンスです。その辺の情報管理ツール、Wiki、共同編集ドキュメントなどでは太刀打ちできません。
組織内の多彩なニーズを吸収するためには、コードの表現力が必要です。ブックマークをコードで記述するというBaCのパラダイムに踏み込めば、この難題に対抗できると考えられます。
フォームをAs Codeにします。 略称はFOaCとさせてください。
フォームとは、ここでは何らかの処理を行う画面です。現代ではローコードやノーコードでつくるのが主流ですが、FOaCは次のパラダイムに進んでいます。
第一世代は融通は利きますが、高価ですし、つくるのにも時間がかかります。そもそもドメイン知識を知らない技術者では中々良いものに辿り着けませんし、ドメイン知識の伝達はハードです。
第二世代はドメイン知識伝達のハードルをなくし、非技術者でもつくれるなったものですが、GUIベースであることと、非技術者であることから、やはりつくるのには時間がかかります。また融通もあまり利きません。所詮はアプリであり、アプリの限界を越えられません。非技術者でも自分達でつくれるのは魅力的ですが、それだけです。
第三世代、FOaCは、その良いとこ取りができます。
IaC のようなレイヤー感で画面を記述するのです。画面の構成要素、つまりはフォームをどれだけ抽象化するかは、すでに第二世代の知見が貯まっています。
要は、第二世代でつくれるものを、As CodeでつくれるようにしたのがFOaCです。
第二世代の、GUIに縛られた制約を越えられますし、抽象化もされているので第一世代のように一からつくる手間もありません。また、プログラミング言語ほど難しくもないため、扱える人もそれなりに確保または育成できます。
見積もりをAs Codeにします。 略称はEaCとさせてください。
見積もりは従来Excelのような表計算ソフトウェアか、帳簿や会計のシステムを使っていましたが、どちらも古典的であり人間の能力にひどく依存しています。
As Codeにすれば人間への依存をなくし、処理をプログラムに任せきることができます。複雑な計算式や条件も、コードの表現力があれば実現できるでしょう。
実現のイメージとしてはオブジェクト指向が良いでしょう。人、サーバー、部品といったクラスを定義し、それらクラスをどのように使うか・関連付けるかをインスタンスとしてつくって（書いて）いきます。
クラスとしては予定、実績、その検証を行う能力をもたせれば見積もりはできます。もちろん、上述したとおり、もっと複雑な処理も表現できるはずです。
「それくらい別に普通につくればいいのでは」
と思われるかもしれません。実際、そのとおりで、慣れたプログラマであれば、As Codeの仕組みに頼らずともサクッと実装できてしまうでしょう。
しかし、見積もりをしたい人達に広く使ってもらうためには、やはりAs Codeのレベルで整備したいところです。
たとえば、元々コードを書いていた管理職が使えるくらいにできれば良いでしょう。現状はそのようなレベルの人材であっても、古典的なやり方に頼っています。
EaCには、この退屈で大変な現状を打破する力があると思います。