クラウドに学ぶビジネス設計

IT
文字数:11,475字 | 読了目安: 約15分 | 公開日:2019.08.12 | 更新日:2021.05.01

ここ数年、クラウドの普及が一気に加速してきました。一口にクラウドと言っても多様なサービスと活用法がありますが、AWSの魅力の一つにクラウド環境を活用した多様なサービスが挙げられます。サーバーのEC2から、ストレージのS3、コンテンツ配信のCloudFront、アプリケーションサーバー運用基盤のElastic Beanstalkなど、Webサービスを構築する上で必要なサービスが適切な機能単位に分離されて提供されています。

今回はクラウドの代名詞とも言えるAWSからクラウドの活用について考えてみましょう。AWSの設計思想には、ビジネスや社会インフラを考える上でも重要なヒントがあります。ITやクラウドのビジネスがどのように設計されているか知ることは、クラウドを活用するという意味でも既存ビジネスを再構築するという意味でも重要です。

データセンター・オンプレミスからクラウドへ

我が社では、クラウドのなかった時代からソフトウェアをサービスとして提供する ASP (Application Service Provider)のビジネスにチャレンジしてきました。いま風に言えば SaaS = Software as Serviceですね。2000年代前半はデータセンターのラックでサーバーを運用していたので、メンテナンスやトラブル対応のたび、山梨から東京のデータセンターまて、夜中に車を走らせたことが何度もあります。

それがいまやクラウドのおかげで、山梨のオフィスにいながら、クリック一つでサーバの起動・停止や増設・除去が出来て、バックアップも復元もリモートで完結します。なんと良い時代になったのでしょう。データセンター時代はデータセンターのスタッフにサーバーの電源OFF/ONを依頼して、リモートからコンソールで再接続するまでの起動を待つ数分間は本当にハラハラしたものです。

止まらない価値

ラック型サーバーのハードディスクやメモリは量販店にも在庫がないので、何かトラブルがあるとサービスを数日止めてしまうことになります。たいして売上のないサービスでもやはりASPとして提供している以上、止めるわけにはいきません。予備の部品を在庫で持っておいたり、メーカーに迅速に対応してもらうためのサーバー保守料、データセンターのラック代など、費用は出ていくわりに売上が上がらず辛いことになります。

我が社では2006年からASPのサービスを始めたもののマーケティングに苦戦して、売上が伸び悩んでいました。積極的に営業するにも、サーバーの増強などの設備投資も先行的に必要になるので、なかなか難しい判断をせまられます。2010年頃、もうやめようかと思っていた頃に 日本でもAWS が普及してきました。

共有か占有か

時間をさらに遡ると1990年代、Webサーバーの普及期には共有のレンタルサーバーを利用していた時期がありました。複数の利用者で一つのサーバーを共有していると性能面やセキュリティ面で何かと問題があり、徐々に専用サーバーに移行した経緯があります。Cobalt Raq や Xserve といったラック型専用サーバーを自社で保有して、データセンターで運用するようになっていたわけです。

そんな当時の経験から、仮想化されているとは言えハードウェアを共有するクラウドには懸念がありました。しかし、AWSはとてもうまく多様な問題を解決するサービスを提供してくれていたのです。

AWSのサービス設計

2010年頃、我が社では iOS / Android のアプリに力をいれ始めた時期でもありました。コンテンツ配信や Web サービス化に取り組む中で、多様な状況に合わせた AWS のサービスや機能が次々にリリースされていき、AWS への信頼感が増していきます。わかってるな~感がすごいあるのです。

弊社のWebサービスもAWSのおかげで、細々ながらもデータセンター時代から合わせて、14年間継続して運用してくることが出来ました。

AWSの設計はたいへん良く出来ていて、この考え方はビジネスから社会制度まで多様な分野に応用出来るものではないかと考えています。

疎結合

その一つが疎結合です。結合が疎ということですが、反対語として密結合を考えてみましょう。長い付き合いで阿吽の呼吸で仕事がうまくいくパートナーっていますよね。現場でのすりあわせのうまさなど、日本の製造業の強みでもあります。お互いに勝手知ったるで、場や設備や経験やコミュニティを共有し、暗黙知で密に繋がっているような状況が密結合です。

では疎結合はというと、機能や役割が分離されていて、外部からの利用方法が明確になっているイメージですね。プログラミングでいえば、カプセル化、フレームワーク、API なども疎結合の一環と言えます。

疎結合により、機能毎に入れ替えたり、組み合わせたり、問題を切り分けたりすることが行いやすくなります。AWSの基本設計には、冗長性、拡張性、可用性、安全性などがありますが、それらを実現する上で、疎結合が重要な概念を担っていると思います。

疎結合の考え方は、ハードウェアであればモジュール化やユニット化であり、機能毎に分離することで、コストダウンや保守性を高めることにもつながります。

属人化と暗黙知

なぜ、疎結合を最初にお話したかというと、日本のビジネスの弱点がここにあると感じることが多いからです。

産業レベルでは、垂直統合から水平分業の時代になっても、系列で密結合されたサプライチェーン構造からなかなか脱却出来ていません。

産業レベルから個別企業、部門、工場、個人まで、機能や役割をうまく分離出来ず、曖昧なまま、暗黙知に頼っていることが多すぎるのです。

いわゆる村社会的、家族主義的でみなが阿吽の呼吸でつながっているので、あえて説明する必要がない。そんな状況が長く続いたことで、仕事を定義するとか説明すること自体が出来なくなっているのが日本社会の現状と言えるのではないでしょうか。

ホワイトカラーであれば、部長ー課長ー係長ー主任のようなヒエラルキーを昭和的な家父長制的に構成して、冗長な会議で情報を共有し、飲み会や社員旅行で一体感を醸成しながら、経験やノウハウを共有するようなビジネスの仕方では、現代のビジネスのスピードについていけるはずがありません。

製造業や飲食業などであれば、職人的な厳しい修行やひたすら反復させるような学習方法で教育していたのでは、いまどきの若者はついてこれませんし、変化が激しく非連続な進化を伴う現代のビジネス社会にも対応していけません。

良くも悪くも、仕事と組織と個人が未分化で、責任の所在も曖昧になりやすくなりますし、権限やら工程やら、いろいろなものが現代的な管理に馴染まない仕組みになってしまっています。

硬直した労働市場

また、良く言われていることですが、日本では人が先で仕事が後から着いていくと言われています。外資的なビジネスは逆に仕事の定義や職掌が先にあって、その仕事をする人を募集して契約するわけです。仕事が終われば雇用契約も終了となるので、職掌が専門化していき、専門職が成立しやすく流動性の高い労働市場と言えるでしょう。

一方、日本では正社員が機能を提供する雇用契約というよりも、身分制度のようになっていて、労働市場が硬直化しやすくなっています。

どちらにも一長一短があるわけですが、今は日本社会全体で仕事や雇用のあり方を再定義すべき時期です。

働き方改革と言うけれど

世の中では働き方改革が騒がれていますが、企業の方たちを見ていると、定時に帰るとか残業禁止みたいな部分ばかりが先行していて、かえって働きにくくなっていそうです。もっと、合理的に仕事をこなすことに集中し、効率化した結果、残業が減ったというなら良いのですが。

働き方改革の取り組みについて目標を設定して、前年度から何%残業時間を減らしましたとかいう管理のための管理仕事が増えてしまって、本業がおろそかになっていやしないかと心配にさえなります。話がだいぶそれてしまいましたが、目的と手段を取り違える傾向、表面的な事象にとらわれて背景や底流に流れる根本原因を見失う傾向は日本人の悪癖と言えます。

硬直化・固定化・官僚化

在宅勤務、サテライトオフィス、フレックスタイム出勤なども何度となく話題になりますが、世間を見ているとまったく普及している感じがしません。1年に1〜2回、満員電車の時間に行き当たってしまうことがあるのですが、「うわぁ、まだこんな状況が続いているのか」といつも思います。

わが社が八ヶ岳南麓に移住した1996年当時はまだまだネットを活用して田舎に移住するなんてやつは珍しかったこともあり、起業系や田舎暮らし系の雑誌がよく取材に来られました。その後は、徳島県神山町が IT 企業誘致に成功して有名なったり、ハワイで働く本多直之氏、多拠点で活躍される佐々木俊尚氏、四国に移住したイケダハヤト氏など、著名な方の事例もあり少しは普及したのかと思いますが、個別事例として点の域を出ておらず、なかなかトレンドと言えるほどの動きにはなっていません。

働き方改革とか言っている組織ほど、無駄な書類と稟議書と忖度と会議づけですし、ダイバーシティとかいっている組織ほど中高年の男性ばかりです。東京一極集中を是正して地方創生だの言っている役所もみ〜んな霞ヶ関にあるわけで、言行不一致も甚だしい限りです。

官僚的組織やサラリーマン的な思考に陥った人たちは、出来もしない目標をかかげ、数%改善することで時間を消費していきます。まぁ、それもこれも人生です。

適切な課題設定を

話をクラウドに戻すと、クラウドの導入においてもこの目的と手段を取り違える傾向に気をつけないといけません。従来はどこもかしこもクラウドNGでしたが、今後は、とにかくクラウドだ!みたいな傾向になることも注意しないといけません。

逆にクラウドを活用している企業で情報漏えいがあったりすれば、すぐにクラウドはダメだ、とか言う話にもなってしまいます。本来、クラウドだろうとオンプレミスだろうと、適切な管理をしていなければどちらにもリスクがあることに変わりはありません。情報漏洩の大半は内部犯行者によるものであることも考えておく必要があります。

事象を俯瞰してみることなく、一義的に○○がダメだとか、□□が良いとか安易な判断は出来ません。すべてはバランスで、メリット・デメリットのトレードオフの関係にあります。

クラウドはIT活用の一環として

そういう意味では、モバイルファーストを打ち出している傾向も強すぎて、個人的にはモバイルにも偏重しすぎだと考えています。確かにコンシューマーはパソコンを使わなくなりますし、一部のベンチャー経営者などはスマホだけで仕事している人も増えています。

しかし、ビジネスの大部分は以前としてパソコンが必要ですし、使っています。特にわたしが重要と考えている分野、製造業や建設業ではCAD/CAM/CAE、クリエィティブ業界ではグラフィックソフトやDTPソフト、ビデオ編集/DTMなど、大画面のパソコンを利用しています。

どんな技術も普及期はメディアがあおるので、これからは○○だみたいな言い方がされますが、そこに振り回されてはいけません。クラウドもモバイルも適材適所で自社のビジネスでどう活用するかを考えていきましょう。

デジタルトランスフォーメーション= DX はすべての企業がIT企業になるという文脈で語られるものです。単にサーバをクラウドに移すというだけでは、企業競争力の源泉にはなりません。

クラウドはぜひ活用したい技術であると同時に、クラウドやITの考え方をビジネスに取り入れ、事業そのものを最適化することを考えないと、競争力強化にはつながらないでしょう。

多重化されたサービス

先に紹介した疎結合以外に、冗長性もクラウドのサービス設計において重要な概念の一つです。

企業においても、BCP =Buisiness continuity planning、事業継続計画の策定を求められる機会も増えています。日本酒メーカーの獺祭も西日本の豪雨で被害にあい、危うくサーバの水没でデータを喪失しかねなかった危機を経験して、クラウドの導入に踏み切ったそうです。AWSではなくOracle Cloud のようですが。

AWS では、全世界にデーターセンターが分散されていて、国毎に数カ所のリージョンと呼ばれる単位でサービスが構成されています。さらに、リージョン内にアベイラビリティゾーン(AZ)があり、物理的に分離されて構成されています。

また、アクセス数に応じてリソースを自動的に増強するような、スケーラビリティ(拡張性)を担保するための仕組み、Load Balancer や Auto Scaling なども用意されています。状態監視のHealth check 機能などもあり、異常があった場合の対応なども自動化できます。

古いビジネス、働かないおじさんを象徴する言葉に、「何かあったらどうするんだ!」というのがあります。「何かって何だ!」と言い返してやりたくなりますが、とにかく、自分の責任になりそうな新しいことは一切やらないような決裁者はどこにでもいます。

AWS は、何かあることを前提にシステムが設計されており、その仕組みと運用に感心させられることが多々あります。ストレージのS3などはそもそも冗長性を確保するように設計されていますし、サーバーのインスタンス、ディスクの EBS なども、要件に応じて冗長な構成にしたり、特定の状態を保存しておくスナップショットやイメージファイル化など、バックアップを保存して管理運用するための機能も豊富にあり、柔軟な運用が可能です。

システムにおける何らかのトラブルは、想定しすぎてもキリがありませんが、ある程度は具体的なトラブルを想定して、具体的な対策を講じておくことで、安心してビジネスを進めることが出来ることは確かです。

安全性とセキュリティ

クラウドNGの最も大きな理由がセキュリティでしょう。しかし、「セキュリティは大丈夫なのか」も、思考停止になりやすい言葉ですから気を付けないといけません。具体的に何を守る必要があるのか。費用対効果や利便性を考えながら整理していきましょう。

AWS には、アカウント管理の IAM(Identity and Access Management)、セキュリティグループとファイアウォール、ネットワークをプライベートに分離する VPC(Virtual Private Cloud)、操作ログを記録して監査にも対応可能な CloudTrail/ CloudWatch、ボリュームの暗号化、暗号化キーの管理など、セキュリティを確保するための具体的な機能が用意されています。

ちなみに、わが社がクラウドの導入に踏み切った大きな理由がセキュリティでした。当時、データセンターにファイアウォールやプライベートネットワークを構成するには、ルータやファイアウォールのアプライアンス製品を導入する必要があり、多数の機器と工数と費用が必要でした。しかし、AWS では管理画面から IP アドレスとポートの組み合わせで簡単にアクセス制限できます。

Policy(方針)を定義して、Role(役割)を IAM ユーザーやサービスリソースに割り当てることが出来るなど、細やかな制御も出来るようになっています。多様な設定の状態管理が複雑になり、管理手間にはなりますが、それはオンプレミスでも同じことと言えます。

また、こうしたセキュリティを誰が管理するのかによって、適切な解も変わってきます。社内に情報システム部門を持てる大企業から、中小零細で情シスが一人あるいは兼務をしている企業まで、業種や社員全体のITスキルレベルとの兼ね合いもあり、画一的な解は存在しません。

自らも変わる

社内ネットワークなど、よりインフラに近いリソースについては、パソコンやネットワーク機器といったハードウェアを納入している企業やネットワーク回線を提供している NTT や KDDI 、および、それらの関連会社に管理をまかせる方が良いかもしれません。ただ、インフラ寄りの事業者はどうしても運用が保守的になりやすく、新しい取り組みが遅れたり、そもそも導入出来なくなる傾向もあります。

情報システム部門が保守的になりすぎると、現場からは不満の声があがりますし、競争力の強化にもつながりません。実際、セキュリティを金科玉条にして、現場に負担を強いているところも少なくないようです。

また、情シスやIT部門がアカウント管理をする中で、社内に余計な力学を発生させないことも重要です。一般的に情報システムやIT部門は若手が担当するケースが多いでしょう。経営陣や管理職はもちろん、現場のベテラン社員などと比較しても、年齢の若い社員が多くなります。

そうすると、どうしても微妙な力関係が発生してしまいます。明らかに年長者や現場が強い場合は IT 側の若い担当者が疲弊していきますし、そうでない場合は対立構図も生まれやすく、社内政治に悪用されることになります。

新しい時代のビジネス文化を築く

クラウドの導入など、新しい取り組みをする上で、社内の協力は欠かせません。既存の社内文化も含め、人材教育の方法、外部から支援を受ける場合の会社の選定など、多様なマトリクスを解いていくことになります。

そして、自らが変わることも必要です。従来のやり方に固執していては、衰退は避けられません。クラウドの活用を機会に、ビジネスのあり方そのものを根幹から見直すことが新しい道を切り開くことにつながります。

日々の業務に追われる中、クラウドやITを導入するなどの新たな取り組みにはエネルギーがいりますが、少しベクトルを変えて、新たな場とコミュニティを作ることが出来れば、組織の文化として自律的に動いていく可能性があります。

自律性に必要なのは、明快な方向性とビジョン、コミュニティと情報共有の場、雰囲気と文化です。組織やメンバーがオープンでフラットであることが重要です。

従来的な権威志向、権力の乱用、雇用形態による差別、情報の非対称性、といった要素を意識的に排除する必要があります。合理性とともに、ビジョンやゴールに情熱を持ってコミット出来る文化が必要です。

おおげさかもしれませんが、日本が超高齢化社会と人材不足で負の連鎖に陥らないためには、IT の活用と人材教育が欠かせません。ぜひ、あなたの会社から、あなたの部署から、あなたから、良い文化が醸成されるように願っております。

参考書籍

AWSは、通販会社であるAmazonが年末のクリスマス商戦時にサーバーが落ちて商機を逸した経験から生まれたサービスです。アメリカのクリスマス商戦はすさまじく、ECサイトであるアマゾンのアクセスは10倍近くにもなるそうです。この時期に合わせてサーバーを増強すれば、閑散期にはリソースが無駄になってしまいます。この需要を補完し、平準化する目的でAWSが生まれました。

アマゾンの革新性は多岐に渡りますが、その中でも物流・ロジスティクスは大きな要素です。本書の著者はアマゾンでロジスティクスを担当していた方で、いかにしてアマゾンが巨大な物流網を構築したか、そのベースとなる考え方を知ることが出来ます。

読書全般に言えることですが特にこの手の書を読むときは、単にAmazonすげー、ベゾスすげーとならないようにしたいものです。逆に、著者のアラを探すような評論家モードで読むのも時間の無駄です。わたしは、自分が著者の立場だったらどうするか、出来るだけ、没入して考えるようにしています。今回の記事で紹介したAWSの設計思想を含め、Amazonが急成長している背景を知り、自らのビジネスに応用出来ることはないか、考えながら読んでみることをお勧めします。

デスバイアマゾン

アマゾン 世界最先端 最高の戦略 成毛眞

タイトルとURLをコピーしました