BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル ITとアーキテクチャ:裏返しの観点

ITとアーキテクチャ:裏返しの観点

原文(投稿日:2011/01/03)へのリンク

ソフトウェア業界は、無秩序で、コストは、どんどん高くなり、品質は低下している。クラウド コンピューティングによる約束は、いかなる重要な規模においても、今だに実現されていない。最近の Batler Groupのシンポジウム[“ビジネス プロセス マネージメントと Service Oriented Architecture”] におけるパネル ディスカッションでは、実際にコスト削減に成るのは、Public Cloudだけで、中から大規模ビジネスでは、ITコスト削減ソリューションと考えられる程、明確でない、と言われた。現在このようなキャッチ フレーズが業界にたくさんあるが、それで真の問題は解決されたのか?本当の問題は、何なのか?

業界は、昨今大量に雇われたスキルの足りない開発者による、生産性が低いと考えられている、ソフトウェア開発に、様々な方法論やツールを投入している。このことで長い学習曲線とバラバラの環境が生まれている。本当の問題点は、何か?システムは、単にビジネスがやらなければならないことを成し遂げるために、ビジネスを助けるツールではないだろう? すなわちシステムは、ツール以上のものなのか?我々は、ソフトウェア天国に達するために最適なツールと方法を選ぶだけでいいのか?なぜそのようなソフトウェア開発がこんなに難しそうに見えるのか?

30年以上経験のある二人のIT専門家であるBruce LaidlawMichael PoulinがITの過去と現在について、彼らの見解を比較している。進歩するために我々は、何をやっているかに、焦点を当てている。Bruceは、業界のすべての方法と技術を使ってきた。彼は、あらゆるレベルで働いてきており、数千ドルのプロジェクトから3億ドル超のプロジェクトまで、そして20億ドルを超え、更にそれを上回るような構想にも参加した。彼が経験したのは、小規模なビジネス、民間企業、国連の関係官庁、国家、州、地方の各レベル、そして全企業セクターである。Michael氏は、ほとんどが米国とヨーロッパにある、大きなソフトウェア開発会社といくつかの大手の金融機関のIT部門で働いていてきた。彼は、部門の枠を超えた企業レベルで、ビジネスと技術間の橋渡しに専念し、いくつかの国際標準団体の仕事に貢献している。彼のバックグラウンドとしては、多年に渡る数学アルゴリズムの開発、高度なソフトウェア設計とテスト、分散コンピューティング、サービス オリエンテーションと開発管理がある。

二人は、次のトピックスに関して彼らの経験を要約した。

  • ソフトウェア業界の状態
  • ビジネス ニーズ
  • ビジネスと技術を繋ぐアーキテクト
  • ITで、いかにものごとをやり遂げるか
  • 速く納品する道具としてのアーキテクチャ

彼らは、それぞれの見解から、業界として、ITを発展させるために何を知り、やらなければならないかを明らかにする、という目的で、これらを議論した。

ソフトウェア業界の状態

ソフトウェア業界をいかに動かすかを知るために、現在どこにいて、これまでどこにいたかを知る必要がある。

Bruce

よく設計され、よく作られたソフトウェアは、方法やツールにかかわらず、SW業界が始まった頃から、時間をかけて実装されてきました。ひどい作りのソフトウェアも同じ時間かけて、存在していますし、今日でも、開発が続いています。不幸にして、昔から今日まで、大抵のソフトウェア システムは、下手に設計され、下手に書かれた部類に入ります。正直に言えば、今日開発されているいくつかのソフトウェアも下手の分類に入ります。

客観的になるために、距離をおいて、質問しなければなりません。今日、30年前と比べて、企業は、買ったり、作ったりしたシステムを使って、うまくいっているのか?私は、総じて答えは、明らかにノーだ、と思います。私が今日見ている、ソフトウェア業界の特色を書くと、

  1. 高コスト: 数年前に数万ドルしていたプロジェクトが、今では数百万ドルかかります。今日のドルでさえ、それらのコストは、現在の費用の数分の一です。
  2. 低品質: ソフトウェア品質は、数年前より今のほうが、確かに良くありません。この状況を改善することを目的にした「高度な」テストや「方法論」があるにも関わらずです。
  3. 耐久性:ソフトウェア システムは、ほんの5,6年で置き換えられる、という神話がありますが、殆どの企業では、2,30年前のシステムを使っています。
  4. 技術: 業界には、30年前より技術は、ずっと進歩した、という話題や考え方があります。ハードウェアに関しては、疑う余地がありません。小さくなり、速くなりました。しかし、ソフトウェアに関しては、絶対に違います。事実、生産性は、一般に落ちているのがわかります。あるビジネスの革新的なアプローチによって、回避策を展開することで、この落ち込みを食い止めてはいるが、ソフトウェアは、今だにアートであり、色々違ってもツールは、所詮ツールでしかないのです。

Michael

この数十年で、ソフトウェアは、あらゆる分野で進歩しました。原子力発電施設から販売促進を促すソーシャル化した顧客フォーラムに至るまでです。例えば、30年前に裏庭の景観を計画するようなプログラムがあったでしょうか?私はそのようなものをたくさんは見ませんでした。その理由は、ソフトウェア技術の役割についての我々の意見では、造園のような重要でないことに、高価なコンピュータ リソースを書ける価値がないからです。今日では、ソフトウェアはどこにでもあり、余りに多くのことがやれるので、どんな例を持ってきても、充分には参考になりません。

そうは言うものの、例えば、同類で比較するために、金融業界でモデリングしましょう。ソフトウェアにかかる管理オーバーヘッドのレベルは、劇的に増加し、コストに関しても同じです。ある人達は、これらは、あらゆるソフトウェア プログラムを扱うように、作られている、今日の構造上の/設計と管理インフラのせいにしています。しかし、このようなインフラのほとんどは、ソフトウェア製品の品質を向上する、と考えられています。この場合、我々は、なぜこの領域では、反対の状況を目にするのでしょうか?たくさんの異なる説明があると思います。それらの重要な部分を隠すふりはしません。気がついたいくつかの点を述べるだけです。

  1. 通常のソフトウェア プロジェクトの規模と複雑さが、並のソフトウェア 開発者のスキルを上回るようになってきた。例えば、人々は今だに、何年も前と同じ2つの考えで、ソフトウェア プロジェクトにアプローチしている。a)動くものを納品しなければならない b)最善のものを納品する。しかし「動くもの」と「最善のもの」は、余りの多くの場合、ビジネスが必要としているものではない。ITプロジェクトには、ビジネスがニーズとスキルのギャップを埋められる範囲で、アーキテクチャの仕事や分析の仕事において成功するような、もっと専門的な貢献が必要である。
  2. 単純化を主張する人達は、リソースの制約を理由に、ソリューションを単純化しすぎた。どのような更なる変更も原始的で、場当たりな、スパゲティ コードになってしまい、すべてが全てと結合し、後のプロジェクト コストが恐ろしく高くつくものに成る。
  3. 大量生産によって生まれたソフトウェア エンジニアは、プログラムを書くことはできる、すなわち、コーディングの仕方は知っているが、企業でのITの役割を全体的に見通すことができない。書くように頼まれたものがなぜ必要なのかについて理解していないのである
  4. プログラマの大量生産に関連して、彼らの仕事を生産/組み立てライン スタイルで組織化する試みがある。しかし、簡単なプログラミングでさえ、組み立てラインの作業よりずっと複雑な仕事であり、人々はこのアプローチに抵抗している。こう言うとITで人気のあるリーンの開発と管理手法に反しているように見えるが、これは、日本の生産工程からきている、というだけである。実際は、リーンをソフトウェアへ適用するために、当初のムダのない生産概念を大きく修正しており、それでもなお、このような原理を適用することの利益を証明する必要がある。
  5. ソフトウェア開発手法は、企業のニーズに合うものから個々のステークホルダーの興味を満足させるものへと変わってきている。多くの場合、アジャイル手法は、失望しているステークホルダーをなだめるために使われており、そのために、ビジネスがビジネス要求を願望で置き換えることを許している。
  6. コードを書くための最近のツールによって、ソフトウェア品質が少々下がってきている。良いツールは、結構コストがかかり、あなたが完全主義者でなければ、以前の障害を見せるだけで、CFOにそのコストをかけることを正当化できる。同時により安いツールは、もっと原始的で、プログラマーに単純なコードのみ書くことを奨励する。単純なコードがいつも正しいコードとは限らない(正しいコードは、いつも単純であるけれど)が、「動く何かを」納品するには、相応しい。すなわち、そのようなツールは、低品質な開発という考えを「標準的なアプローチ」として奨励するのである。
  7. 海外にアウトソーシングすることで、ソフトウェアの品質が落ち、10年前に戻ってしまった。海外へのアウトソーシングという疑わしい「経済学」で目がくらみ、ビジネスとITの意思決定者は、ITを未成熟な技術文化に追いやってしまった。彼らは、ビジネス価値と会社でのITの役割に、異なる理解をしている(ビジネス環境における文化的相違)。状況は、ゆっくりと改善しているが、国内の開発者は、海外からの納品物を「改善する」必要があり、すでにふくらんだアウトソーシングのコストを増やすことになる。
  8. 「今日ダメにしたものは、明日修正するつもりだ。」この後退性のプロジェクト管理哲学は、ある開発方法論において「理論的な」弁解を見出した。明日の変更については心配せず、言われた要求のみを実装するのだ、と主張する方法論である。ビジネスは、そのようなプロジェクトの「より低いコスト」に騙されることを許容しており、プロジェクトの結果の責任に対して高い(しばしばずっと高い)支払いをしなければならなかった。

自分の企業のビジネスを理解する

もし、あなたがどんなサイズのどんな組織のIT部門にいようとも、自分自身に定期的に問いかけるべき質問が2つある。「自分は何をやっているのか?」「なぜ、これをやっているのか?」 もしその答えが、「給料のためにやっている。金がもらえるならなんでもやるさ。」のようなものだったら、それはそれで悪くない、質問することもない。願いたいところであるが、必ずしも皆が熱血漢である必要もない。しかしもしあなたが雇用主のために働いているのなら、あなたの答えは、「私は、最もエレガントなソリューショを作りたいとか、最もきれいなコードを書きたい」と言うなら、議論する必要がある。このようなモチベーションは、しばしば無駄を生むからである。理想的なアプローチは、次のようなものである。「私は、ビジネスに意味のあるコードを書きたい、そしてこのコードを書き直ししなくとも、ビジネスが成長できるようにしたい。」 もしあなたのシステムを開発している人達があなたのビジネスを理解していなかったり、そうしようと努力しなかったら、あなたは、実装に失敗するか、あなたのビジネスは、作られたシステムでおかしくなる。

Bruce

誰が最もあなたのビジネスを理解しているか?

大抵の場合、ビジネスの全体的な役割とビジョンを最も良く理解している人は、上級マネージャーである。そのようなビジョンは、必ずしも組織のより低レベル層によっては、説明できない。より低レベルな層は、ビジネスのプロセスにはずっと馴染んでいて、いかにビジネスを組織すればそのビジョンをすぐに実現できるかを理解しているが、低レベル層は、なぜプロセスがそのようになっているのか、あるいは、いつそれを変えるべきかを必ずしも分かっていない。このことは、小さな工場より大きな会社でありがちなことであるが、ビジネスを理解しょうとすれば、これは、永久の課題である。

ある方法論では、始めにビジネス アナリストに「現在のシステム」を見させ、それがマニュアルなプロセスか、自動化されたものか、両方を組み合わせたものかを見る。実際に、ビジネス アナリストが現行システムを見て、あなたのビジネスについての情報を集めることができるのは、真実であるが、大にして、彼らが知るのは、あなたのビジネスが今日どう動いているかであり、どうあるべきかには、ほとんど関係していない。現行システムを描くこの活動は、新システムがどのようなものか分かり、移行計画が必要になるときには、意味のあるものになるが、要求を分析する目的では、大きな欠陥があり、大いなる時間と金の無駄となる。そして始めからプロジェクトを間違った方向に向かわせることになる。

誰が、ビジネスをこのように理解できるビジネス アナリストなのか? 彼らには、どのようなトレーニングが必要なのか?その仕事を効果的に実行できるには、どのようなスキルが彼らには要るのか?仕事がちゃんとできるためには、業界セクターの専門家である必要があるのか?

昔は、ITに配属された新人は、一連の段階的ステップを経験した。その例が、以下のようなものである。誰が、ビジネスをこのように理解できるビジネス アナリストなのか? 彼らには、どのようなトレーニングが必要なのか?

  1. ジュニア プログラマ
  2. プログラマ
  3. シニア プログラマ
  4. プログラマ アナリスト
  5. アナリスト プログラマ
  6. アナリスト
  7. ビジネス アナリスト

新人は技術的なスキルは持っているかもしれない、と考えられた。好きな言語は、de jourあるいはデータベース技術など。しかしそのスキルを効果的に適用する能力では、「ジュニア」だったろう。トレーニングによって、階段を登って、パターンを理解したり、ビジネスがどのように機能しているのかを理解できるようになった。一般的な帳簿はどのようなものか?在庫システムはどのようなものか?これらの2つのシステムは、どう関わり合うのか?このような良き指導者の下での成長によって、コンピュータ スキルは磨かれたが、ビジネスに対する眼識や知識も磨かれ成長した。ビジネス アナリストの段階に到達する頃までには、一般的なビジネスがどう稼動し、技術とシステムがいっしょになって、どうビジネスを動かすのかの両方を完全に理解するようになる。

しかし、ソフトウェアには、「良き古き時代」などなかった。昔も現在と同じような問題がたくさんあった。あらゆる会社がITスタッフにこのような成長プロセスを施せるほどの先見性あるいは忍耐を持っていたわけではない。普通の人間のあらゆる欠点が適切な人達が適切な職務に昇進する障害となった。

しかし、うまくいく時は、実に上手くいくものである。

今日、上記で確認された7つのレベルは、2つであり、しかも互いにレベルとして関連しあっていない。2つは異なる分野で、今日「開発者」間での違いはない、1年の経験であろうが、20年であろうが。同様に「ビジネス アナリスト」に関しては、そうなのか、そうでないのかで、経験は関係ない。このような事の欠点は、非常に未経験な人が非常に高額のプロジェクトからの成果をコントロールしていることである。

経験は、 有能なアーキテクトやアナリストに必要な要素であるけれども、充分でないのも真実です。ある人達は、1年の経験を20年繰り返しているような人もいる。(私の意見では、有能なアーキテクトは、プロジェクトの最初のフェーズでは、ビジネス アナリストの役割を担っているが、業界では、アーキテクチャ グループの外に「ビジネス アナリスト」を作っている。しかもアーキテクトによって得られる経験や深さを持ちあわせていない。この理由により、私は、「有能なビジネス アナリスト」を独立した地位としている。しかし、有能の意味するところは、本質的に同時にアーキテクトでもある、ということである。)

では、よいビジネス アナリストあるいは、アーキテクトを資格保証するのは何か? 次が私の意見である。

  • 業界で幅広く働いた経験がある
  • システムの作成や成功した実装において、「現場で、それをやってきた」経験がある
  • 概念レベルで考えることができ、違ったビジネスに関しても似ている点やパターンをすばやく理解できること
  • 学習能力が高く、短時間であなたのビジネスが何であるかを明確に説明できる。恐らくあなたのどのスタッフよりも良く説明できること。
  • あなたがあなたのビジネスがどのようなものか、何が必要かを説明すると、「理解する」こと

最後のポイントは、次のような質問を生む。誰が、あなたのビジネスが必要なものを知っているのか?顧客、ビジネスユーザー、それともオーナー、システム要求を最も明確に説明できるべきなのは、誰か?彼らは、システム アーキテクトやアナリストとして、訓練されただろうか?いいや。ビジネスがどのようなものか、そして、本来何をなすべきかの情報に関して、ビジネスユーザーが最も良く説明できる。いかに、ものごとが機能しているかに関して、彼らは意見を持っていることさえあるが、その意見は、指示ではなく、提案になるべきである。ビジネスユーザーのために、ビジネス要求を最高に「システム化」できるのは、ビジネス アナリスト/アーキテクトである(あるべきである)。

今日の多くの方法論がこの点で行き詰っていて、多くのシステムが結果として失敗している。私は、何度となく、システム スタッフが、顧客が要求を的確に説明しなかった、と不満を言うのを聞いてきた。皆さん、ごめんなさい。要求を掴むのは、顧客の仕事ではなく、あなたの仕事なのです、アナリストさん。アナリストは、ビジネスを聞くスキルを持っていなければならない。顧客との会話から、真の要求を掘り出すのである。堅実な分析とアナリストが「理解した」時の信頼関係がないなら、ビジネスが自ずとそのような見方をすることを強いるようになるだろう。不幸にして、以前よりも、このような危険な状況が増えている。頼んだことはやってもらえるが、必要なことがやってもらえない。

Michael

何年もの間、ビジネスの役割がITによって弱体化ないし無視されていた。IT関係者は、ビジネスのために何をどうやるべきか、自分たちのほうが良く知っている、と信じてきた。中央集権化されているITにおいてさえ、開発者は、プロジェクトすなわち彼らの同僚がやったことを後まで見なかった。あるソフトウェア開発手法は、何かを納入することにずっと焦点を当てるようになった。ビジネスと技術間の橋がほとんど壊れたときに、ITは、アジリティについて話し始めた。ビジネス側は、ほとんどアジリティのことは、理解していなかった。

私は、この10年以上、サービス指向ソリューションでずいぶん働いて、このことを知った。私は、SOAが魔法のように、俊敏性を提供すると言われたにもかかわらず、SOAイニシアチブで失敗した多くの会社を見てきた。私に分かっている、これらの失敗の大きな原因の1つは、ITがSOAを誤解したばかりでなく、ITは、サービス中心のソリューションを提供しているときに、プロセス中心のビジネスをやろうとしたことである。言い換えると、ITは、ビジネスがいかに動くべきかではなく、いかにビジネスが動いているかに反応したのである。

多くの業界では、ITは、ツール開発からビジネス ソリューション開発を含んだソリューション開発に変わってきた。しかし、正しいソリューションを生み出すために、ITは、正しいビジネス タスクすなわちビジネス ニーズを知らなければならない。低レベルの現場のビジネスチームと主に向かい合うと、ITは、ビジネスのこのレベルの問題(ほとんどの場合)に釘付けになってしまう。しかしこのレベルは、過去のビジネス要求を反映してはいない。真実は、低レベルな現場のビジネス プロセスは、機能のビジネス実現化以上のものではなく、時間と共に、これらのプロセスは、現在のニーズや戦略的な企業ゴール/目標から離れたものになる。

ビジネスにアジャイルであるためには、ITは、ビジネスがどこへ行こうとしているのか、将来どこに向かう計画なのかを知り、ソフトウェア開発を適切に調整しなければならない。ITがビジネス変化に適応するには、ビジネスのそれよりもずっと時間がかかる。コードには、隠れた、文書化されていない依存関係があり、関係の無いアプリケーションがプログラム ライブラリを多く共有しているからである。すなわち、一つの変更が、たくさんのものに影響し、ビジネス ユーザに再びリリースする前に、バランスを再度取って、安定化させなければならないのである。ということは、ITの人は、中から低レベルのビジネス運用部隊の人達よりも、ビジネスの世界における予期される変化についてもっと知っていなければならない、ということである。この10年間の経済的な混乱が生み出した状況では、ITは、ビジネスに精通したソフトウェア専門家を「育てる」ことはできなかった。ということは、ITは、もはや技術チームに、自然に吸収されたビジネス知識を頼ることができない、ということである。ITは、ビジネスの人達と働くことを任務とした専任スタッフ部門を持つ必要がある。この部門に、アーキテクトやビジネス/システム アナリストが属するのである。

すなわち、アーキテクトやビジネス/システム アナリストは、中間からシニアのビジネス担当と緊密に働き、一方で、ビジネスの意図や方向を学び、もう一方で、既存や新しい技術的能力の要点を説明しなければならない。この仕事は、個々のプロジェクトベースで行えるものではない。このような仕事は、フルタイムの一部としてやるか、プロジェクト横断のスコープで行われるべきものである。言い換えると、IT部門には、現在と将来のプロジェクトを跨ぐ、アーキテクトとビジネス/システム アナリストの組織を持たなければならない、ということである。アウトソーシングやレイオフが頻繁にある状況では、企業にとってのIT財産は、マネージャではなく、まさにアーキテクトとビジネス/システム アナリストなのである。ITでビジネス知識のあるものをクビにすることは、ITの脳みそを取ってしまうようなものである。そうなると能無しのITと仕事をしなければならなくなる。

この一連の論理に従って、もう一歩ビジネスに踏み込もう。明らかに、中から上のビジネスの人達には、問題があってもITの人達を助ける時間(あるいはその気)は、ない。この事実を理解すると、ビジネス側にビジネス アーキテクトの組織が要ることになる。経営層と一緒に戦術的、戦略的なビジネス タスクを実際に実装するビジネス アナリストと一緒になって、ビジネス アーキテクトは、ビジネス ニーズを認識し、ビジネス アーキテクチャを作り上げ、実装する必要のあるビジネス タスクを練るような、最高のビジネス計画を行うのである。ビジネス アーキテクトは、またITマネージャや技術アーキテクトとやりとりする。ビジネス側のビジネス アーキテクトとビジネス アナリストは、ビジネス要求の中心を作り上げる人達である。これらの要求は、最後は、ビジネス側とITに分かれる。

私や同僚の経験で何回かあった例では、ビジネス要求が異なった低レベルなビジネス プロセスの主観的なニーズから抽出され、それらのためだけのものだった。このようなビジネス要求は、あらゆるリソースを無駄にして、ITを「溺死させた」。この問題に関する、私の知っている唯一の軽減策は、ITに渡される計画の全ビジネス要求は、ビジネス 戦略と部門計画に照らしたビジネス妥当性のチェックをする必要がある。チェックするのは、ビジネス側のビジネス アーキテクトとビジネス アナリストである。私はこのアプローチを見たことがあり、これは非常に上手く行った。ITがビジネス要求のビジネス妥当性のチェックを主張すれば、ITに対する尊敬の念も出てくるのである。

現代の企業におけるアーキテクトの役割

この数年間、議論する前にセマンティックに同意することが一般的になってきた。そこでこの議論について、二人ともアーキテクチャ(ソフトウェア、ビジネス、技術、ハードウェアなどの)は、IEEE1471 標準に従って定義する(記述ではない)ことに同意した。IEEE1471 に追加できるのは、アーキテクチャを成す要素は、

  • 基本的で、自己充足で、一貫性がなければならない
  • 他から独立して存在できる(すなわち、他から派生したものではない)
  • 構造上の要素の中身を見せるべきで、外見ではない。

最後の表明は説明が要るだろう。特に、物事に対するいかなる見方にも、誰がそれを見ようとも、あるいは、どこから(視点がどうであれ)見ようとも、常に実際は、それは何なのかを誤解する、大変高いリスクを伴う。理由は、それは、主観的であり、モノの境界を良く知らないで、環境の一部をモノの一部と考えることがあるからである。反対に、モノの見方がモノが何であるかの実際の知識に基づいたものであれば、外部のステークホルダーのいかなる興味に対しても一貫した見方を生むことができる。

アーキテクチャの概念は比較的はっきりしているが、アーキテクトの役割については、同じようにはいかない。アーキテクトの特性が何であるかの業界標準の定義はない。2つの主な陣営の間には、はっきりとした違いがある。一方は、アーキテクトとは、スーパー技術者で現在の技術の一部ないし全部を非常によく理解している。そのようなアーキテクトは、.NETアーキテクトとか、JEEアーキテクトなどと呼ばれる。

他方の陣営の考えでは、アーキテクトは、それほど技術的ではなく、自動化とは関係の無い「システム科学」やその手法にもっと長けている。ここでの議論では、この後者の定義に従う。しかし、アーキテクトは、長年の経験から深い技術の専門性も持っている。「 それほど技術的ではない」と言ったのは、アーキテクトは、なぜ、どこで、いつを知っている人である。例えば、メッセージングがソリューションで使われなければならない、とする。それがベンダーが開発したメッセージングなのか自社で作ったものかは、アーキテクチャの観点からはどうでもいいことである(実装する人やマネージャにとっては、非常に重要であるが)。このようなアーキテクトは、最先端の技術専門家ではないが、ビジネスと技術の両世界の間を非常に良く意思疎通できる人である。この文脈においては、スーパー技術者は、アーキテクトではなく、ソフトウェアエンジニアとかテクニカル リードと呼ばれる。

Bruce

今日タイトルは、余りに簡単に変わるので、次のように言うのはちょっと気が進まないが、最高のビジネス アナリストは、システム アーキテクトであるが、経験とスキルによって技能を習得した人達が住む世界では、アーキテクトは、通常経験と洞察力を持ち合わせている。この場合、ビジネス アーキテクトの役割は、アーキテクチャがつくられる前に、アーキテクトによって演じられる。いずれの場合も、ビジネス分析をするリソースは、すでに挙げられている仕様を満足しなければならない。

ビジネス要求が的確に記述されている場合、その要求を読んだビジネス側の誰にも、何が要求されているかは、明確である。要求は、設計のことについては、何も言っていない。しかし、要求は、設計上で考えるべき方向を物語る時がある。例えば、もし経営者側のビジョンが、顧客によるセルフサービス ポータルを目指しているなら、要求にそう書かれるのが適切である。しかし、顧客番号は、20桁の英数字で、そのブレークダウンした意味まで付いてきたら、それはビジネス要求ではない。それは、どのように顧客を追うべきかの誰かのアイデアなので、このようなことに経験のある人に任せるのが一番いい。

ビジネスニーズを満足するために、IT内で首尾一貫した戦略が必要であることを理解している企業は、ビジネス活動モデルとビジネス情報モデルからなるビジネス アーキテクチャに投資するだろう。これらのモデルは、自動化とは関係はなく、ビジネスが何をしなければならないか、そしてそれをするためにどのような情報が必要なのかに関するビジネスの本質を捉えるものである。もしこのようなモデルが存在すれば、全てのシステム プロジェクトは、全戦略の中で、確固たる基礎と地位を持つことになるだろう。

この種の戦略がなく、このようなモデルも無いので、どのシステム プロジェクトも時間と予算内で、できるだけのことをするように強いられる。企業のビジョンを持ったスタッフがいれば、このアプローチでもうまくいき、企業のビジネス アーキテクチャが増大していく。不幸にして、このようなことが起きるのは稀である。このような環境で望めるのは、ベストでも、システムや標準の冗長な部分が他のものと余り矛盾しないことや、バラバラなデータやプロセスを「修正する」ために、高くつくデータ統合プロセスの原因とならないことである。

結論として、ビジネス要求が最も理解されるのは、有能なビジネス アナリストとアーキテクトが企業内で緊密に働き、双方がビジネスのビジョンや方向を理解している時である。この協業によって、首尾一貫した、そして有益な要求文書が、ビジネスに役立つように書かれる。それは、現行のシステム プロジェクトばかりでなく、将来計画されるビジネス要求にも役立つのである。

Michael

アーキテクトの地位や役割に関する議論は、最近非常に熱くなってきている。ある企業マネージャたちは、ビジネス アナリストを超えるアーキテクトのプロジェクト上の役割をまだ、認めていない。同時に、企業アーキテクチャと関連するアーキテクトの機関がこれまでのビジネス領域を増々支配するようになってきた。

技術アーキテクトは、非常に人に依った、人間的なやりとりや関係の上に築かれているビジネス運営に、構造的な論法や形式的なロジックを持ち込んできた。このことは、あるビジネス活動には都合がいいが、全てにいいわけではない。自動化と形式化の機械的な応用は、確かに有形な価値連鎖の方法論には上手く行ったが、人間は機械ではない。価値ネットワークの無形で、意思疎通指向の価値を無視すると、ビジネスや技術的革新を実行するのが、ずっと難しくなり、遅くそしてずっと金のかかることになる。

しかし、ビジネス アーキテクトと緊密に仕事をすることは、ITアーキテクトばかりでなく、企業自身にも利益になることである。そのような協業は、ビジネスとITに境界があると、非常に生産的ではないので、新しい組織的な形が必要である。ビジネス アーキテクトと技術企業アーキテクトの両方が、全企業にわたる責任を持っている。ということは、仕事にあった組織的な形だけが、ビジネス アーキテクトと技術企業アーキテクトの両方が一緒に働く、本当に部門間協力しあえるチームである。このチームの権限は、平等あるいは、ビジネス部門とIT部門のそれぞれの権限より上で、企業レベルのプログラムやプロジェクトを監督する。

企業アーキテクトは、組織においてアーキテクチャに関わる部門の階層のトップであり、(ビジネスと技術の)全部門を通して、各開発プロジェクトまで降りていく。アーキテクトは、会社のビジネスと戦略計画に従って、組織の各レベルで何をなすべきかを定義する。一方、会社の経営層は、いかにアーキテクチャ上の決定やソリューションを実装すべきかに関わっている。この意味は、プロジェクトがプロジェクト マネージャによって設定されたら、関係するアーキテクトは、プロジェクトの目的と手段が適切に決められ、解釈されていることを検証する、ということである。

技術的ビジネス/システム アナリストは、要求の詳細と依存関係を見出し、文書化することで、BR(ビジネス要求)に貢献する。技術的ビジネス/システム アナリストは、「企業ビジョンを持ったスタッフ」ではなく、特定のプロジェクト ニーズに焦点を当てている。他のプロジェクトが何しているとか、(実装で)ダブっているのではないかとかは、普通、彼らのスコープを越えている。BRに依存しつつ、BRは、技術的ビジネス/システム アナリストのみによって集められる。ITは、間違った方向に成功しながら進んでいく、リスクが高い。重要な依存関係が 簡単にバイパスされてしまうことがあるからである。不幸にして、我々は、余りによくこのようなことを見てきた。

私が強く信じるのは、ITにより実装したり、サポートしたり、統合する意図を持った、あらゆるビジネス アイデア、提案、公式化されたニーズやタスクは、ITに持って行く前に、ビジネス内部で検証と妥当性の確認をしなければならない、ということである。ビジネス アーキテクトは、ビジネス内で、ビジネス アナリストと一緒に、技術への「入り口」で要求をコントロールするパイプラインを作らなければならない。技術アーキテクトは、BRをアーキテクチャ上のソリューションに変換して、技術的ビジネス/システム アナリストへ渡し、詳細を決めさせる。

パイプラインは、以下のような働きをする。

  1. ビジネス ニーズは、ビジネス要求者によって公式化される。
  2. ビジネス アーキテクトとアナリストは、ニーズをレビューし、戦略的ビジネス計画と会社の目標に照らし、課題を上げる。
  3. ビジネス アーキテクトとアナリストは、このニーズの実現による、周りのビジネス運営コンテキストへの影響とその逆について分析する。
  4. もし総合的に承認されたら、ニーズは、ITアーキテクトに渡され、このニーズに関するIT能力を考え、いくつかの高レベルなソリューショをビジネスに戻す。
  5. もしITソリューションが何らかしら(例えば、それをある程度最適化する)ビジネス ニーズに影響すれば、最終的な合意に達するには、行ったり来たりしてからである。
  6. 合意されたニーズは、コアなBRとして公式化され、ITに渡される。
  7. ITアーキテクトとシステム アナリストは、詳細を検討し、ITによる低レベルな設計と実装に必要なビジネス/技術要求を作り上げる。

これは、どのような業界や企業にも適用できる、一般的なビジネス要求の作成プロセスである。私は、不適切に実装されたIT製品から生まれた潜在的に失われた収入は、どんなに市場リリースを急がされても、本当のビジネスニーズを定義するための努力と時間の大事さを強調している、のだと思う。

「良い」/「悪い」システムを作るためのプロセス

Bruce

「適切な人達」が見つかり、要求が上記のように開発されたとする。より良いシステムが作れると、保証されるだろうか?ハイであり、ノーである。

もし要求が上手く開発されたなら、よく開発されなかったより、ずっと高い確率で「良い」システムを作ることができる。なので、この点から状況は、良くなったように見える。不幸にして、まだ失敗するチャンスは、大きい。

Dr. Paul Dorseyの報告 は、プロジェクトが成功する理由のトップ3を以下のように強調している。

  1. トップ経営層からのサポート
  2. 充分な方法論
  3. 同様なプロジェクトを成功した人による信頼できる技術的リーダシップ

非常に面白いのは、どのような「プロセス」であるかは、関係ない。言い換えると、開発のスタイルは、どうでもいい。この経営者側のコミットの失敗は、いつ明らかになったか?

プロジェクトが始まると、経営者側は、昔から分析にほとんど忍耐を持っていない。「分析麻痺」という表現が使われ、分析のための時間は、「結果を出す」ことの犠牲になる。あたかも設計は、完全に時間の無駄であるかのように。私は、非常に優れた技術者チームと働いたことがあるが、結局彼らのプロジェクトは、失敗した。その理由は、単に彼らに、彼らの仕事をさせなかったからである。不幸にして、IT業界は、ジュニア スタッフを使って彼らの経験以上の仕事をうまくやらせた結果、このような状況を作ったのである。それに応じて、多くの手法が、単に分析をやらないで問題をうまくできる、と信じたのである。問題は、修正された!まあ、ある種のね。

この議論の最初の数パラグラフで、使われた手法がシステム プロジェクトが成功するかどうかの決定的要因ではない、といった。この概念に従って、 Extreme Programming, Agile, Rational Unified Processなどが自然にものごとを正しくやってくれるわけではない。これらの手法がやることは、すでに破綻したプロセスを適応させようとしてくれて、悪い状況から最高なものにしようとしてくれるのである。そして、称賛するのは、これらはある程度それをやるのである。不幸にして、もしビジネス要求が優秀な設計によって、上手く伝わらなかったら、開発者は、何を開発するのか?これらの手法は、開発者と共にビジネス側に、一緒に働いてシステムを作れば、要求が明らかになる、という希望を持たせる。もしビジネス人が企業とそのビジョンを例外的に理解しているなら、結構であるが、そうでなければ、良くないのである。システム全体がどうなるのかのビジョンがあるべきである。どの仕事よりも前に、全体のビジョンが完全に明らかにされなければならない、と言っているわけではない。そのビジョンの守護者(アーキテクト)が有能で、設計とともにどこへ向かうべきかを知っている限り、このビジョンは、徐々に成長していくのである。

問題は、ビジネスにとって「良い」あるいは「悪い」システムを作るのは、何かということである。これを判定するのは誰か?本当に白黒判定がつくものなのか?

実際には、どんなに下手に考えられたシステムでも、一般には、少なくとも何をする意図のものかの一部は、達成できる。最初に計画されたよりも、そこへ到達するのにもっと時間と金がかかるだろうが、ほとんどのシステムは、何らかの方法でそこに到達する。不幸にして、下手に考えられたシステムは、確実にビジネスが成長できる能力は殆ど無く、時間と共にニーズに合うようになることは、ない。

「良い」システムとは、ここではビジネス要求に合うシステムと定義され、ビジネスが時間と共に、機敏に変化できることを可能にし、そのユーザから見るとビジネスの真の実現者と思えるものである。

逆に、「悪い」システムは、ビジネスが今日する必要なものの一部ないし全てをある程度達成できるものとして、定義される。しかし、そのようなシステムは、明日のことができるような、ビジネスの変化する能力を邪魔するものである。

Michael

「良い」技術システムの私の解釈は、実行コンテキスト(ビジネスと技術)と結びついている。私が気がついたことは、繁栄している時代には、外部のビジネス環境で起きるビジネス変化は、停滞期に比べて、それほど頻繁でない、ということだ。これに関連して、ビジネスは、同じ技術システムに違った期待や要求をする。例えば、90年代の終り頃、米国では、システムのスケーラビリティとパフォーマンスが主な目標だった。今日のシステムでは、柔軟性/拡張性とセキュリティが一番優先度の高いものである。

今やビジネスの柔軟性が要求するのは、技術的ソリューションが充分に柔軟で、最小の投資で、ビジネス変更をシステム変更に組み込めることや最小の投資で周りのシステムの変更に組み込めること、そしてすべて合わせて、最小時間でやってくれることである(これがシステムの「柔軟性」の私の定義である)。これは、昔の「実利的な」プラクティスとは、際立った対比をなすものである。この昔の教えは、要件と言うものは、「石のごとく」決まったもので、修正や置き換えへの「手掛り」などなく、将来、文字通り変化などないかのようだった。

ビジネスニーズのITでの実装における自然なプロセスは、大抵破綻しており、それは、必ずしもITの過失ではない。ITは、多くの古いレガシー システムをいくつものパッチや「スパゲッティ」コードで作り、保守してきた。もしビジネスが速く、前進したければ、IT資産を修正して、柔軟性のあるものにしなければならない。これには、普通は用意していない、時間と投資がかかる。クラウド コンピューティングとアウトソーシングは、これには、殆ど役に立たない。古いレガシーシステムに会社の宝が存在しているからである。知識/論理とデータは、簡単にアウトソースできない。

Forrester Researchを引用すると、「あなたのビジネスの変化のスピードは、あなたの技術のスピードで決まる」ということである。なので、「良い」システムは、柔軟なシステムで今日役立ち、明日への拡張を許すものである。「アジャイル言語」で言えば、「良い」システムとは、日々の活動のビジネスニーズを満足し、ビジネス戦略計画に合うように、スムーズに変身するものである。

ITは、良いシステムを作るためだけに、次々にアジャイル手法を生み出す。アジャイル手法のほとんどは、ビジネスが今日とは違うように機能するはずがないし、将来もそうである、という仮定に基づいている。これらの手法は、たとえ企業にとって生産性を落とすようなものでも、ビジネスがいかに機能すべきか、ということには、敢えて挑戦しない。このことが、多くの「アジャイル実践者は、単純な設計を支持し、アーキテクチャや設計をはっきりと重要視することは、殆ど無いか全く無いという傾向に繋がっている。実際、ビジネス要求に従って、ソフトウェアを納品するのは、開発チームの責任である。このソフトウェアのビジネス価値は、チームの関心ごとではない。「もしビジネスがこれを要求したなら、彼らがソフトウェアが何をし、なぜそうするかを知っている」。

アジャイルチームがエラー処理メカニズム、拡張手段、通知/警告、補償ロジック、トランザクションの完全性、セキュリティ、運用安定性を後で、すなわち後の「タイムボックス」で追加することを約束することは、稀ではない。しかし、これら全ての技術的ことは、IT側の関心ごとである。これらは、サービス品質(QoS)の特性であり、ビジネスが技術から即望むことであり、次にではない。ビジネス論理は、単刀直入で、「もしソフトウェアが既に動いているなら(本当か?)、なぜもっと待って、「最終」リリースにもっと投資するのか?そうではなく、ITの連中は良く働くのだから、他の仕事をやらせろ。」これがまさに、アジャイルチームが自分自身のビジネスに対する落とし穴を堀り、その次に新しいものを「単純化する」ときに、「古い」問題を直すという猛烈な仕事をするハメになるのである。

新興のリーン方法論に戻ると、Taiichi Ohno氏によって公式化された本当に無駄のない生産工程原則をレビューすることは重要である。

  • 必要なものだけ作る
  • 何か悪いなら止める
  • 価値をもたらさないものは排除する

真に、これらの 原則は、非常に合理的で、最終結果が完全に定義でき、仕様化できる製造環境では、容易に解釈できるだろう。しかし、 Mary PoppendieckTom Poppendieckリーンプロジェクト管理手法の7原則を公式化したとき、いくつかの点で無駄のない生産工程から派生させている。

例えば、リーンチームがSOAサービスを作っているSOエコシステムでリーン手法がどのように機能するかを見てみよう。リーン原則「無駄を排除する」が非常に注目されるので、チームの最初の仕事がこれである。ついでながら、ソフトウェア開発でのムダとりは、生産工程のそれよりずっと大変である。ビジネス要求には、たくさん不確かなことがあり、アーキテクトのビジョンが必ずしもその中に反映されてはいないからである。なので、もし先行投資のアーキテクチャ設計がきらいだったり、無視すると、どのようにして、何が無駄で、何がそうでないかを正しく判断できるのだろうか?

SOAでは、どのようなサービスでもあらゆるユーザに使われるかもしれない。たとえ、最初に要求を出し、それがサービスを構築するのに使われても、その人がとっくにそのことを忘れたとしてもだ。SOAサービスは、未知のユーザ、あるいは、リーン用語では、顧客に役立つものでなければならない。各顧客は、サービスに固有の価値を見出すことができ、この価値は、開発チームが目指していたものとは大変違うかもしれない。生産工程の無駄の定義は、サービス指向開発には、上手く当てはまらない、という意味なのか?恐らく、先行の強力なアーキテクチャ設計なしでは、どのようなソフトウェア開発にも当てはまらないだろう。

他のリーン原則である「決定を遅らせる」は、概念的に「無駄を排除する」とは矛盾する。我々は、コミットメントを遅らせる、すなわち製品実装の完成を遅らせるかもしれない。仕事に影響するビジネス変化を予期しているからである。我々は変更を予期できても、どのようなものかはわからない。どうのように無駄を特定できるのか。その変化にとって、あるものは無駄かもしれないし、別のものは非常に役立つフィーチャかもしれない。私は、サービス指向の公式「変更に備える設計」は、遅らせたコミットメントよりずっと機能すると考えている。

他の2つの原則「一貫性を作り込む」「全体を見る」は、「チームに権限を与える」に疑問を投じるかもしれない。リーンチームは、特定のタスクにフォーカスすることになっているので、「全体」を見るのは難しい。さらに、プロジェクトの範囲外のITの他の要素との一貫性を保つように作るのは、もっと難しい。これらの両原則は、チームを跨ぐアーキテクト部門に属することで、開発チームではない。無駄を定義できる立場にいるのは、アーキテクトである。

最後に「チームに権限を与える」(逆は、経営層に権威を与える)の原則は、ITリーン手法に追加されたもので、元々の原則「悪い物は、止める」が排除されたことに注目することは、おもしろいことである。この意味は、開発と運用には「晴れの日」しか予期していない、ことなのか?止める原則なしでは、権限のあるチームとリーンプロジェクト マネージャは、後退する仕組みを持たないことになり、無駄を含んで何でもかんでも配布し続けるのである。こうして、2つの選択肢から1つの結論が出てくるかもしれない。ITリーン手法は、尚もその土台が未成熟、あるいは間違った手法である、ということである。

もっとうまくやれるか?

Bruce

さて、この議論で我々が言っているのは、

  • 手法は、成功の決定的要因ではない
  • ビジネスには、ビジネス アーキテクチャが必要
  • ビジネスは、ニーズを特定し、アーキテクト/アナリストは、要求のシステム化を特定すべきである
  • 経営層は、手法を認め、それを一貫してサポートする必要がある
  • 良いシステムの尺度は、ビジネスを実現する能力で測られる

いかにそこに到達するか? IT業界は、これまでも常に厳しい状況であり、いつも最高の人達を見つけることはできないし、経験の少ない、あるいは余り有能ではない人を使わざるをえなかった。このような現実で、良いシステムを作れる希望はあるのか?あると、私は信じる。

もし良く説明されている良いビジネス アーキテクチャがあれば、要求を前進させるしっかりした土台があることになる。もしそのようなビジネス アーキテクチャの上に確固たるアプリケーション アーキテクチャが作られれば、プロジェクトの仕様を、コントロールされた、斬新的な方法で実現することができる。

もし充分なアーキテクチャのプラクティスやガイドラインが組織化され、そして、上級マネージャー層によってサポートされた企業ビジョンが表明されていれば、プロジェクトチームの経験やスキルにそれほど頼らなくとも、それなりにうまくいく。それは、単に彼らが働いているフレームワークがすでにしっかりと定義されているからである。これは、完璧なアプローチではないが、それが、我々が直面している現実である。

何年もの時間をかけずに、そのような「必要な」ものを提供することは可能なのか?

もしビジネスをモデル化するのに、適切な人々を見つけられれば、かなり速くモデル化できるだろう。ビジネス(政府、製造、軍事など)によらず、二人のモデラーのチームが活動と情報のモデルを獲得するために、一緒に働けば、かなり早くこれらのモデルはできあがる。中から大の環境では、6ヶ月のプロジェクトで、このニーズに対応するのに充分である。

それ以上にアプリケーション アーキテクチャが変わるようであればもう2,3ヶ月必要になるだろう。それは、上級マネージャーのビジョンと方向に依存する。必要な期間は、主観的だが、組織の文化と組織がどの程度レガシー アプリケーションに依存しているかに非常に依存する。

上記で議論されたことを認識すれば、開発プロジェクトはもっと良くなり、首尾一貫したものになる。しかし、これには別の側面もある。ビジネスを何十年にもわたる下手な実装や冗長なシステムから開放することができるのである。

これまで話してきたアプリケーション アーキテクチャは、現在企業内で使われているアプリケーションの全てとこれらのアプリケーションがどのようにビジネスの真のニーズを助けたかあるいは妨げたかの評価も含まれている。これらのシステムを見る時、もっとビジネス要求に焦点を当てると、機能やデータに基づいた統一化の機会がめぐってくる。ポートフォリオにあるアプリケーションの数を減らすことは、運用コストを減らすだけでなく、もっと信頼性のあるそして、タイムリーなデータにより、著しい利益とビジネス変化の課題を満足するように、ずっと敏感な開発環境を提供することになる。

Michael

このトピックに対する私の答えは、「ハイ、ITは、もっと上手くやれるが単独では、できない」だ。ITは、ビジネスを巻き込む必要がある

  1. 技術ソリューションに関して下される全ての決定
  2. ビジネス戦略に向けた能力レビュー
  3. 協働開発と保守の資金調達
  4. 作られた技術システムの評価

このような関わりによって、ビジネスに彼らのニーズと好みに対する責任を持たせるようにしなければならない。

技術アーキテクトが実装するいくつかの代替ソリューションを提案する時、顧客とステークホルダーは、最も安いが前向きではないソリューションを選んだら、この決定に対する責任は、彼らが負うのであり、ITではないことを知らなければならない。私はこれまで開発に最も安いソリューションが、保守で非常に高くついたケースを非常に多く見てきた。どのように2つのバランスを取ったらいいのか?それは易しい。ビジネスとITは、技術ソリューションの所有コストを目標にしなければならない。プロジェクト/開発コストだけを目標にするのは、絶対に例外的な場合にならなければならない。

ITが技術的能力をレビューすると、技術的プラットフォームが古くて、陳腐化してはいないが、ベンダーがもうサポートしていないことが分かる場合はままある。そのようなプラットフォームがビジネスの戦略的ゴールや目標に適切に貢献できるだろうか?答えは恐らくノーである。ITは、はっきりと、使っているシステムは、戦略的なビジネスニーズをサポートしていないことを言わなければならない。このことを既存のソリューションの「所有コスト」で示すのである。すなわちその保守コストにIT予算の殆どは食われて、戦略的開発にはほとんど回らないことを示すのである。

新しいソリューション、製品あるいは、システムが開発されているとき、将来のビジネス 顧客によってレビューされなけばならない。伝統的なユーザー受け入れテストは、通常、ビジネス機能よりも深くチェックすることはない。対照的に、ビジネスレビューは、例外的あるいは、非標準的なビジネス状況の全てで、IT製品に挑戦する必要がある。例えば、スケーラビリティは、専用のテストシステムではなく、実際の環境で証明されなけばならない。もしシステムがレビューを通れば、実際のユーザにも受け入れられる。もしパスしなければ、あるビジネス要求は、洗練する必要のある可能性がある。いかなる場合でも、ITとビジネスが一緒に、ビジネスの期待を再設定し、改善方向を特定する必要がある。製品のバグ報告で喧嘩するのではなく、協業的かつ積極的なやり方で一緒に働くのである。

どうやってITは、ビジネスをもっと巻き込めるのか?恐らく、私が始めて言う訳ではないが、a) ビジネスにおけるビジネス アーキテクトの考えを支持し、推進する b) ビジネスと技術アーキテクトを混ぜた組織にして、ビジネスと技術に跨いだ企業アーキテクトの考えを支持し、推進する c) 同じビジネス ドメインで働いているビジネスと技術チーム間のビジネス アナリストの定期的な交換をする d) ITでダイレクター レベルの地位を作って、ビジネス経営層と直接仕事をするようにさせ、ITを意図したすべてのビジネス要求のパイプラインとして、ビジネス管理層と直接仕事をするようにさせる。 e) 責任を持ったプロジェクト横断の分析グループを作り、低から中レベルの運用プロセスを分析させ、技術的能力に基づいた最適化のための提案をさせる、すなわちITを積極的に先を読めるようなものにする。

私は、潜在的なIT改善の側面が、技術統制にある、と考えている。私が本当に意味している技術統制とは、全アーキテクチャ、開発、データ/情報そして管理の統制領域のことである。この統制は、何が何で、どの技術が開発やテストに使えるか、ということばかりではない。開発、開発およびテスト用のツールと方法論、既存のそして、「進行中の」システム、製品、ソリューションに関わるプロジェクト管理手法やコラボレーションに対する、アーキテクチャ上や設計上のコントロールについてのことである。統制ポリシーは、全てのビジネス開発におけるITの関与を明確にし、ITとビジネス間のSLAで定義された、ソリューション所有権の目標と責任に取り組まなければならない。統制は、管理者層が代行するわけにはいかない。統制は、何が、どのようになされるべきかを言い、一方管理層は、統制ポリシーに権限を与える。もし統制ポリシーがIT管理者層によって維持されるなら、全てのIT機能を単一の権限ある統制の立場から、舵をとることができるため、ビジネスにも俊敏性をもたらすチャンスが生まれる。

この記事に星をつける

おすすめ度
スタイル

BT