CACのAWS導入支援サービス「enterpriseCloud+」

開発・リリースフローの変化 後編

3. 開発フローに潜在する課題

もし議論されている手法が全て取り入れられた場合、どの様な結果になるかは「Beyond the 12 factor app」の第2章冒頭で記述されている。

実はこの文章、現実を皮肉った解説である。「虹とユニコーン」とは「あまりにも壮絶すぎて逆に畏敬の念を起こさせるような規模の大混乱に直面したときに使われる(悪い意味での)幸福感を表す皮肉」である。要約すると手段ばかりに囚われて、目的とその整理、構造の理解を怠るとこの様な状態に陥るということを指摘している。表現を変えるとリリースの方式や分類に使われる手法や手段ありきで議論を進めると、「虹とユニコーン」を存分に味わえることを示唆している。この状態はまさにグリーンフィールドが悪い意味でのブラウンフィールドになった状態とも表現できる。

この問題を回避するためには「API First」(参考記事：API-first software development for modern organizations | by Joyce Lin | Better Practices(https://medium.com/better-practices/api-first-software-development-for-modern-organizations-fdbfba9a66d3))の考え方を取り入れると良いと同書では解説している。参考記事では、欧米式のやり方を解説しているが日本に合わせて改めて本記事でまとめて見る。

図3−1

日本で思い描かれるウォーターフォール型ソフトウェア開発プロセスは図の2番目のものである。理想は一切のミスも漏れも無く設計から開発に流れる状態を想定しているが、現実はそうでは無く、詳細設計とドキュメントの記述テストは相互に補完し合いながらコーディングとリリースを繰り返すワークフロー形態を取る。欧米式では少し簡略化されているが、どちらにしろ、いずれかの工程でミスや遅延が発生した場合は後続のワークフローにそれが影響し、依存するチームを拘束しその発生頻度に応じてループを繰り返すという問題がある。また、作成したものの評価や測定はプロセスの後半で行われるため、変更を行う場合は規模に応じて相応のコストがかかる。

対してAPI Firstではデザイン、計画、モックの開発、テストから始める。従来型と違い開発を2つのフェーズに分け、技術者と非技術者の両方のチームメンバーがプロジェクトの現状やアプリケーションにアクセスできる状態(モック)を早期に開発し、先にフィードバックを得てから後続の開発を行っても問題ないと判断した状態に遷移してから、残りの開発を行うスタイルである。

今回紹介した記事はRestfulAPI開発の場合のAPI Firstの話であるが、サーバーレスアーキテクチャ全体を見渡した場合、同様の手法が有効なワークフロー・工程が何箇所もあるのに気が付けるかどうかが課題であるが、現実世界のプロジェクトにおいてはAPI Firstの作業工程を顧客が受け入れられるか否かもボトルネックとなってくる。そして、一見銀の弾丸のように見えるこの考え方も「The Law of Leaky Abstractions – Joel on Software(漏れた抽象化の法則)」の問題が常に付いてくることを忘れてはならない。何のためにAPIを利用して何のためにAPI Firstの考え方を使い、どの様なアプローチで要求をAPI Firstで実装しリリースするのかを十分に理解して実施・維持しない場合は「虹とユニコーン」が待っている。API Firstの考え方は作業工程の無駄が省略されるだけで、認知していない他の問題も存在していた場合それが顕著に現れてくる可能性があるのだ。

またサーバーレスアーキテクチャを取り入れる以前の問題も大事だ。現在進行形で漏れた抽象化問題が発生しているからこそ「漏れた抽象化の法則」で指摘されている「いったん抽象度が定義されれば、それは具体的であると思い込んでしまい、理論が破綻してしまっている」状態になっていることに気がつく必要がある。

漏れた抽象化の問題を事前に回避し、かつすでに起きているこの問題を解決する案はいくつかある。他にも方法はあるであるだろうが以下に例をあげる。

1. KJ法などを使い、抽象化された要素を分解し、再構成・再度抽象化を行うを複数回繰り返し、抽象化の漏れを減らす。メンバーの意識合わせを行う
2. 変わることの少ない絶対的な尺度を用い、抽象化された概念の再整理を行う
3. 0から概念を再構築する

1の手法は合意の形成、認知の共有、相互理解などのメリットがあるがメンバーが頻繁に入れ替わる際は効果が薄い。2の手法は唯物的な現実主義論だが、実際に実施しようとする場合は実行する側も説明を受ける側もそれ相応の前提知識が必要となり、実現性は薄い。3の方法は効果的だが現実世界では投資対効果が低い。しかも、IT技術ではなく領域としては認知科学の世界になってしまう。認知科学の専門家でも実現の難易度は高いであろう。実現が可能不可能であれば可能であろう。この話は認知の問題から来ているとも言えるからだ。どのような手法を採用するにしても時間・メンバー・コスト効果の問題が常に付随してくる。しかし、以下の問題を解決しなければ常に同じ結果が待っている。

1. 抽象化によって作業時間は短縮される、学ぶ時間は短縮されない
2. 抽象化された環境での問題解決は、されていない環境に比べて莫大な時間を要する

様々な設計プロセスの研究を行なっているデイビッド・C・ウィン博士はその論文（参考記事：https://www.researchgate.net/publication/299634192_Perspectives_on_iteration_in_design_and_development）の中で「プロセス改善を達成するための銀の弾丸のようなアプローチはまだ存在しない」と述べている。この問題の解決のアプローチについては様々な手法が考案され、博士の論文の中でもそれぞれについて調査がされているが、解は出ていない。

前置きが長くなったが問題を整理してみよう。開発工程と呼ばれるものは、図3−2で示す工程を体系的にまとめたものである。これに人(のアサイン)の要素と時間の要素、現代の技術を加えて要素を並び替えて効率的に進めようという考え方がAPI Firstと解釈できる。

図3−2

しかし、実際の要件は本来プロジェクトオーナーもしくは顧客が欲しかったものを細分化したものであり、図3−3で示す構造の右側の最適化が進めば進むほど、本来の要求との関連付けと管理が難しくなっていく。

図3−3

この構造の潜在的な問題点としては以下の通りだ。

1. 1.ビジネス的な外的要因で本来の要件は動的に変わる
2. 2.開発したシステムからのフィードバックで新しいアイデア、もっと良いやり方が見つかり要件が変わる
3. 3.技術要素とそれを持つ人的リソースの効率的なアサインの問題
4. 4.時間の問題
5. 5.システム自体から発生するコストの問題

CI/CDやマイクロサービスといった考え方・手法はこれらの問題のうち一部を効率的に解決する手法であって全体を俯瞰したものではない。特定の領域の課題・問題を以下の判断基準を元に効率的にやるための手法であって、必ずやらなければならないことに関しては変わっていない。

1. 1.コスト
2. 2.時間
3. 3.人のリソース

今回の記事の場合はサーバーレスアーキテクチャになるが、選択した技術や機能の組み合わせにより効果的に統合する手法や結果はケースバイケースになる。そしてアジャイル開発などの理論でも指摘されているがステークホルダも実際にこれらを実現する技術者もこれらのプロセスを通過・試行錯誤する過程や結果で成長し、考えや意見が変わるのだ。同時に利用する技術やツール、マネージドサービスも流動的に変化するため、万能薬的なものは存在しない。

コストや実際に目の前にいるメンバーのスキルを元に、本来の目的に対してどのような手法を一時的に使って解決を図り、その結果と過程を元に成長したメンバーと共に次はどのような手法を一時的に採用して、変化した本来の目的をその時その場で実現するかが命題で、手法や解釈の方に比重を置いては「虹とユニコーン」からは逃れられない。

よくある質問

全般について

• 全般

契約について

• 契約
• 更新
• 解約

料金/
支払いについて

• 料金
• 支払

サービスについて

• 開始
• 技術支援
• サポート
• eC+管理コンソール
• その他
• DBマイグレーション