反対側からのアジャイル
この記事は「Agile Tech EXPO Advent Calendar 2020」の１２月１９日の記事として書きました。
書いたきっかけは「Agile Tech EXPO mini #2 - ノーコードでアジャイル/開発＆営業でチーム改善～」への参加です。その中で岡島さんの「ノーコードでアジャイルってどうなん？」という話を聞いて思ったことを書きたいと思います。
ノーコードでアジャイル
岡島さんのお話で紹介されたノーコードツールは最近Googleに買収され組み込まれた「AppSheet」です。デモではスプレットシートをデータソースに「買い物アプリ的なの」を作っていました。全くコードを書かずに設定をしていくだけでちゃんとアプリができました。たった数分です。たしかに早い。しかも自作するよりいろいろ便利な機能も・・。
こういったノーコードをうたった製品の案内には「アジャイル」との表現にあふれています。しかしながらそれは本当なのかと改めてアジャイルのプラクティスに当てはめたらどうなる。テスト自動化はどうなる、ペアプロはどうなる。・・・・とかアジャイル開発をバリバリやっている人達の常識からみて検証したという話をしていました。
結果はできることはできたけど・・・ちょっと違うという違和感。そこでアジャイルの原点へ戻ってみたら、もう少し新しい観点が・・・
コードを（あまり）書かない世界
実はわたくし、コードを（あまり）書かない世界（コミュニティ）の住人であります。Salesforceのコミュニティから始まり、そこからSaaSを使って業務改革をするGYOMU_Hackers_GuildなどのSaaS系のコミュニティから、AWSやAzureなどのクラウド系コミュニティ、そしてまたRPACommunityと、あまりコードを書かないノーコードや、ローコードの世界のコミュニティを中心に生息しています。
アジャイルのコミュニティに出没し始めたのは、元々運用のITILのコミュニティにも少～～～し参加していたこともあって、DevOpsとかの関係からアジャイルに興味が出て、アジャイルひよこクラブとかTokyoAgileCommunityに参加しだしたのが始まりでした。
そうこうしてSaaSを中心としたクラウドのコミュニティとアジャイルのコミュニティの両方に参加するようになって、あることに気が付きました。気が付いたのは２つ・・・・両方に参加している人は全くと言っていいほどいない事、そして双方で全くと言っていいほど「同じこと」を言っていたりする事です。
クラウドの世界の人たちが言うのは、「小さく早く始める」「失敗を恐れずにチャレンジする」「短いサイクルで見直して修正する」「まず実際に使ってみる」「現物で確認」「メンバーの成長」・・・・などなどアジャイルで使っている言葉は出てこないものの背後に流れる考え方は非常に近いものがとても多いのです。「・・・・あれ、この話どこかで聞いたような」と思っったら、それはアジャイルのコミュニティイベントで聞いた話だった・・・みたいな事がよくあります。当然、その逆もあります・・・・。
ノーコードの世界から
自分が受け持っている仕事のひとつにSalesforceのプロジェクトがあります。そのなかのひとつはすでに稼働しはじめて数年たっていますが、基本的に一週間サイクルでカイゼンのリリースを繰り返しています。ちなみにそこではアジャイルという言葉は一切使っていません。そこでやっているサイクルは、アイデアが出たら、まず作って、確かめて、修正して、決まったらリリースの手続きに進める。の繰り返しです。アイデアと確認は当然ビジネスサイドの人たちが行います。アイデアの前の現場への調査や調整も彼らが行います。実は作ってみて没になったアイデアもけっこうありますし、リリースしてからやめたものもあります。例えばレポートのアイデアだったら、条件だけ決めて列の項目とか並びとかはエンジニアに任せて、とにかく実物を作ってから確認する（使う・直す）というサイクルが中心です。
なぜこんな風になったかというと、やはり「作るコスト」が圧倒的に少なくなったことがあると思います。昔やっていたような設計書しっかり書いて、コードをバリバリ書く時代だったら、数週間で考えた事を数か月かけて作る・・・といったサイクルが当たり前だったと思います。それが今は、ちょっとしたものならテスト含めても数時間でできてしまうSaaSの登場によってその重みがまったく変わってしまいました。数週間かけて考えたものを１日くらいで作る・・・・大逆転になってしまいました。
そこで出てくる疑問は数週間かけるアイデアとか企画の不効率さです。・・・実はこれがアイデア出しからリリースまでのサイクルの中で一番無駄だという事に気が付いてしまったのです。このアイデアとか企画・・・ウォーターフォールでいう要件定義ですが、これが一番くせものです。考えるといっても所詮は「空想」でしかありません。現場の声と言っても「今の延長線上」でしかなく、それもうまく聞き取れているかはあてになりません。その現場の意見が本当の問題解決とはならないケースもままあります。そんな状況でぐるぐるぐるぐる時間をかけて考えたアイデアって時間をかけて苦労した割にはアテにならないことが多いというのが実感です。しかも「一発で決めなければ」や「失敗は許されない」というプレッシャーで余計なものがいっぱいついてきて膨れ上がります。・・・結果として過積載のグライダーみたいな要件定義が出来上がります・・・・結果は飛びだせない（リリースできない）か墜落（全く使用されない）というケースが体感的にも３割近くあったりします。しかも今は答えがわからないビジネス領域が確実に増えてきています。例えばどういう機能があれば営業活動の効率が上がるのか・・・完璧な答えを持っている人はいないはずです。・・・それならば、あまり細かく考えないで困りごとと仮説だけでまずは作ってみて、ダメだったら変えるとかやめたほうがよっぽどコストは低くなるわけです。・・・そんな試行錯誤をくりかえして自然と今の形に落ち着いています。
ノーコード（ローコード）とアジャイル
今はSaaS製品やノーコードのツール、そしてＲＰＡなどのそれっぽい製品やサービスが充実してきています。そんなにＵＩにこだわらない社内のＩＴ利用であれば、もはやこちらのほうが主流になってきています。これはアジャイルを必要とする領域が今以上に増えてきているという事です。そしてビジネスの世界はＶＵＣＡとか言わなくても急速に複雑で予測不能なものに変化してきています。ウォーターフォールが当たり前の経理的な領域でさえ、ビジネスとして高度なコントロールの実現を必要としたら、教科書的な答えはどこにも存在はしないのが現実です。自分で仮説を立てて確かめて、評価を繰り返す以外の道はないと思います。・・・・これってまさにアジャイルの得意とする領域ですよね。
これから近いうちにきっとお互い勢力拡大を続けているアジャイルの世界とノーコードの世界が混ざり合う時代が必ず来ると思っています。お互いのコミュニティに出る人ももっと増えてくると思います。そうなればお互いの相乗効果で、もっともっとビジネスが高速で変化する世界が実現できるのではないかといまから期待で胸アツだったりする２０２０年の暮れです。
この記事が気に入ったらサポートをしてみませんか？