NASA Science 事例研究

訳者まえがき

この文章は2009年4月27日から5月1日にかけてKatie Cunninghamのブログに Part I, Part 2, Part 3 の３つの記事として掲載されたものをRetsuが日本語に訳したものです．2008年4月にNASA ScienceはPloneベースでサイトを作り直しました．その翌日にplone.orgでニュースとして掲載され，同年10月にWashington D.C.で行われたPlone Conferenceで発表されました．

NASA Science 事例研究

2008年のことですが，Pydannyと私はワシントンD.C.でのPlone Conference において，NASA Scienceについて発表しました．NASA Scienceというのは Space Mission Directorates（NASAの宇宙ミッション本部のこと.SMDと記す） の奉仕Webサイト（事業の成果を社会に還元するサイト）です．あなたが知らない かもしれないので言っておきますが，私たちはそのサイトをPloneで作りました． なぜ，そしてどうやって作ったのかをみんな知りたいようでした．私たちは 世界に向けてプレゼンテーションすることに決めました．そして間もなく その事例研究を書くように頼まれました． 敬愛するJohn Sahl氏はそれを辛抱強く待ち続けてくれた人です． これがそうです． 

第一部　なぜPloneか？

でも最初に，いくらか経過を！ 

SMDのWebサイトがその構造という点で最後に更新されたのは1999年に さかのぼります．その日のうちにそのサイトはそのデザインとコンテンツに おいて賞を得ましたが，そのサイトは大規模なオーバーホールが延び延びに なっていました． 

元々のサイトは90%がHTMLで，ところどころPerlスクリプトが 付け加えられていました．お互いに話をすることのないいくつかの小さな アプリケーションは別として，そのWebサイトの背後にデータベースは ありませんでした．そのサイトの元々の見栄えは，時間とともに何十という ミニサイトに取って代わられていきました．それらのミニサイトは完全に 新しい見栄えを持っていました．データはHTML内の深い所で更新されなけ ればなりませんでしたし，元々のツールなしにそれをしなければならない 哀れな人は神が救ってくれました（もちろん皮肉です．とても可哀想でした） 私はそれを何回かしなければならず，そしてそれらのことが生み出すHTML はきれいなものではありませんでした． 

コンテンツは本腰を入れて更新される必要がありましたし，その見栄えも 同様でした．フロントページの小さな黒人の男の子はどうだったの？ 彼はストック写真からの画像です．２００６年には彼は至あらゆる Webサイトで見かけることができました．ストック写真は弊害を もたらします．サイトの全体的なスタイルはみすぼらしく古くなって いました．サブサイトは利用者を困惑させました．それに検索は？ 自分たち自身によるサイトに固有の検索を使うのでではなく，Google を使うならば，問題があることはあなたも知っているでしょう． 

CMSを売り込む

私たちが最初に売り込まなければならなかったことは，もう一つHTMLの 怪物を作るのではなく．サイトのためにCMSを使うということです． 開発者はもちろんCMSが大好きでした．しかし私たちがそれを売り込む 方法は，顧客に彼らが何を得ることができるかを見せ，そして彼らが何を 失うかを考慮することでした．

• コンテンツを共有する：コンテンツはサイト間，ページ間，さらには アプリケーション間で共有することができます． 
• コンテンツの再利用：コンテンツは１つ以上の所で使うことができます．必要ならより的を絞ったミニサイトを作るのに使うことすらできます． 
• データと表示のより複雑な相互作用．たとえば自動的に更新される画像やデータのカッコいいレポート． 
• 集中管理されたテンプレートとCSSを使うなら，レイアウトと見栄えを変更するのがより簡単 

しかし，失うものは何だったのでしょう？ 

• 即座の更新．同じデザイナがいる限り，そのデザイナは彼らのソフトウェアを 通じて更新を走らせ，再度サイトを丸々アップロードすることができます． たとえソフトウェアツールがなくても，ひどいHTMLの中をさらにひどく 書き換えるだけのことでした．私たちにとっては苦痛でしたが，顧客にとって は少し待つだけのことでした．今ではある更新については即座に反映すること ができますが，それ以外のものは次のリリースを待たなければなりません． 
• 迅速な開発．顧客はある日カンプ（仕上がり見本）を見たら，次はサイトを 見ます！エクスポートの魔術です！今では顧客は私たちの開発サイクルの間 じっと座っ待たなければなりません． 
• 小さなチーム！デザイナを持つ以前は，非常勤のコンテンツ編集者が いただけでした．たったそれだけです！今では開発者のチームとデザイナを 一人か二人を擁しました． 

顧客が失うものについて私たちはまったく開けっ広げで公にしていましたが，顧客は彼らが 失なおうとしているものよりも，得られるもののほうがはるかに上回ること が理解できました．顧客が疑問を持つと，私たちは古いサイトが行き着いた 混乱を指摘し返しました．古いサイトをアップグレードすることがどんなに 苦しいことだったか，それにそれをもう一度することは不可能であることを です． 

そのようにして，今やCMSを使うオーケーをもらいました．しかしどのCMS にしましょう？ 私たちの契約部門の係の区分はたくさんありました．.Net, ColdFusion, Java, それにNasa.gov CMSもありました． 

何が欠けていたか気付きましたか？ 

公式なPython係がありませんでした． 

私たちにはPythonを大好きな人たちがいました．そしてPythonをいくつもの プロジェクトで使っていました．ですが私たちは一緒にグループとして認識 されていませんでした．私たちは初めからPloneにしたがったのですが， それを引き渡す先のグループなしでPloneをどのようにそれを主張したのかって？ 最初に他の怪物たちを絶滅させるのです． 

HTML: そうです．純粋なHTMLとそれをアップロードすることでサイトを運営 したい人がまだいたのです． 

• 速い 
• 小さな作業場 
• 開発サイクル不要 

悪い点： 

• 検索機能なし！自分たち自身で作り手を加えなければならない． 
• データの動的グルーピングや関連づけがない．タグなし，レポートなし， 手作業で行われるべきではない「興味をひく他のもの」がない． 

Cold Fusion: 何人か熱狂的なColdFusion開発者がいました．なぜ彼らを 使わないのかって？ 

良い点： 

• 彼らはすでに組織内にいました！新たに雇う必要がありません！ 
• 彼らはCMSをゼロからやりたがっていました．それは常に何かを習う よりも簡単なことです．そうでしょ． 

悪い点： 

• CMSをゼロから書くことは，見かけに寄らず難しいことです．習うのに 難し過ぎないで，世の中のいくつかの標準に実際に準拠するCMSを作る ためには世界中からの人々のチームを必要とします． 
• その時に先導的だったColdFusion CMSはFarcry*であり，508**準拠 ではありませんでした．（訳注：Farcry*は自分が主役になって行う シューティングゲームのこと．表面的な機能は豊富だが基本的な構成 が貧弱, 508**は米国リハビリテーション法第508条のこと http://www.section508.gov/ ） 508準拠であること（障害を持つ人たちに対してのアクセシビリティ） は政府系サイトにとって必須なので，これには出て行ってもらいましょう． 
• まじめにApacheコンフィグレーションしないとみすぼらしいURL 
• SMDが欲しがり始めたものは，その時のColdFusionアプリケーションの 一群が提供するものよりも現代的なものでした． 

.Net: .Netはどうでしょうか？　どのみち.Net係がありました．なぜ彼ら を使わないのかって？ 

良い点： 

• スタッフがすでに手元にいた 
• .Net CMSであるSharepointがすでに存在し，NASAではそのための サポートがすでに他のサイトのサポートのために存在した． 

悪い点： 

• 私たちの.Net係は小さく，すでに仕事で負担がかかっていた． 
• 伝えられるところによれば，Sharepointはその内部に入るとPloneと 同じように複雑であり，もしそうでないならもっと複雑である． 
• 私の知っていたSharepointを扱うデザイナは，Sharepointのインタ フェースをカスタマイズしようとするのをひどく嫌った． 
• とどめを指したのは：.Net開発者はSharepointのスケーラビリティに ついて心配していたことだ． 

eTouch: NASA.govはCMSを使っている．なぜそれを使わないのか？ 

なるほど，実際にそれはすこしやっかいです． NASA.govが最初にデプロイしたとはいえ，SMDサイトのほうが最初に 開発を始めていました．NASA.govとeTouchが登場する頃には，私たち はほとんど開発をやり終えて，デザイン変更をしていました． 

もう一つの理由は，政府系では，常にその資金がどこから来るのかという ことに関心を持っていなければなりません．私たちみんなが一つの幸福 であるかのように見えるかもしれませんが，あなたがもし人の蜜つぼから 取り始めたら，人はとてもとてもイライラします． 

Plone!

私たちは駆動技術をPloneに決めました．なぜかって？ 

• DC ZPUGの形でローカルリソースがありました．そこでは，私たちと 一緒に働くことに興味がある人々を見つけ，知恵を借り，私たちが選んだ プラットフォームの動向について少し聞くことができました． 
• 古参のCMSの一つであり，それは極めて安定しています． 
• 活発です．古参のCMSの一つでありましたが，それはその時でもまだ 疑いなく取り組みがなされていました． 
• 使うのが簡単なのがわかりました．インストールすると，それだけで， あらゆる種類のことができるようになりました． 
• 508準拠を得られました．これは私たちに多大なる時間を節約させて くれました． 
• Pythonで何か新しいことを本当にしたい，それも輝かしい新しいCMS で何かを本当にしたい開発者を熱くするその他の多数の理由がありました． 

顧客は買い込み，そして私たちはサイトを実際に作ることになりました． 

第二部　デザインと開発

さて，私たちは技術を選んだので，デザインについて取りかかる時です． 

アイデア！大騒ぎ！ 

大きなプロジェクトを引き受けることで面白いことの一つは，アイデアを まったく持たないグループを持つことになるか，あるいはアイデアが たくさんありすぎるグループを持つかのどちらかになることです． 私たちは後者のグループを持ちました．プロジェクトの最初から参加して いる者として，サイトの見栄えと印象について毎週新しいアイデアがある かのように感じ始めるようになりました．何十というカンプ（仕上がり見本） とワイヤーフレーム（ラフスケッチ）があり，それらすべてが，私たちが 好きなもの，私たちが嫌いなもの，あるいは，そう表現に困るような感覚 のものを持っていました． 

情報アーキテクチャー（IA） 

デザインはさておいて，私たちにはコンテンツについてのアイデアもあり ました．SMDはとてもたくさんの情報を持っていましたし，そのための サイトを作るためには，彼らが何をしたのかということについて理解しな ければなりませんでした．NASAについての面白いことの一つは，自分たち 自身に話すのはとても上手なのに，宇宙物理学者でない人を含んだその聴衆 のことを時々忘れてしまうことです．私たちは自分たちで無知な大衆の役割 を演じ，彼らの情報を平凡な利用者が理解できるような言い方で言い直し ました． 

私たちは大々的に情報アーキテクチャーに入り込みました． 

私たちが尋ねた最初の質問は，情報は通常どのようにして提示されたのか， そして新しくてカッコいいことを何かできないか？ということでした． 普通私たちは子供の頃に惑星：大きさ，位置，色，特徴なんかを教わりました． ですが，それらを何かで使いましたか？Jeopardyの優勝質問とか？ （Jeopardyは米国のTVクイズ番組．YoutubeでJeopardyで検索すれば 見れます） 

代わりに，ミッションと疑問の文脈でデータを提示することにしました． 私たちが何をしているか，それはなぜか？深宇宙の中をわざわざ調べる のはなぜか？綺麗な写真のためだけにそんなことをしているのか？土星を 調べるために人工衛星を送ったり，火星にRober探査機を送るのはなぜか？ 先鋭的な初期の情報アーキテクチャーの一つは伝統的な文脈を持たずに， そのサイトはまさにミッションと疑問を完璧なまでに基にしていました． 他の情報アーキテクチャーは疑問とミッションを持っていましたが， それでもその他のより伝統的なグループ化をしていました（私たちの 太陽系！星！私たちの惑星地球！）．最後の情報アーキテクチャーは SMDの内部組織構造を真似ていました（地球，太陽，惑星，宇宙）． 

ユーザビリティ（使い易さ） 

この時点で私たちはたくさんの疑問を抱えているのに，答えが少し しかないことに気付くことでしょう．ここでユーザビリティが登場します． 

私たちは情報アーキテクチャーとデザインにとても近づき過ぎることになり， ディベート，些細な微調整，委員会による不合理なデザインの時期， さらには，一目見て没にするには疲れ過ぎていたためにこっそりと 入り込んだひどいアイデアと遭遇せずには情報アーキテクチャーの 面倒を見ることはできませんでした． 私たちはユーザビリティのテストをすることに決めました． 

いくつかのデザインといくつかの情報アーキテクチャー，そして数十名 の協力的な犠牲者を選びました． テストは３つの部分から成りました： 

1. 機能デザインについての質問に答える 
2. でっち上げたサイトで課題を完了するように試みる 
3. 様々な特質についていくつかのデザインを評価する．たとえばフォントと 色の使い方や，専門性や信頼性の見栄えについて． 
4. カード並べ．同じような情報を仕分けし，それらにラベルを付ける． 

私たちは片側からしか見えないガラスの後ろ側の暗い小さな部屋で様子を 見ることになりました．体が引きつったり，少し蒸し暑かったりしましたが， それは素晴らしくて，とてもハッとさせられるようなありのままの体験でした． あなたが愛したもの，大切なデザインのお気に入りが情け容赦なくこき 下ろされるのを見ることになります．Webに革命をもたらすことになる あなたの壮大なアイデアが難色を示され，投げ捨てられるのを見る事に なります．つらいように思えますが，本当にそれは私たちをすっかり現実 の世界に引き戻してくれました．それはまた私たちの顧客にとっても そうでした．彼らはあるデザインのことで暗唱に乗り上げていましたが， 目からうろこが落ちたのです． 

カード並べも私たちに多くの事を明らかにしてくれました．一つには， 人は情報について変わった新しい整理法を望みませんでした． 彼らは惑星がグループ化され，太陽に関することがグループ化され， 地球に関することがグループ化されることを望みました．すべての 人が彼ら自身のほとんど同じ情報アーキテクチャーを見つけ出しました． （これはこの間のPlone Conferenceで私が繰り返したことです） 

この研究から，私たちは最も人気のあったデザインを採用することに しました．そしてSMDの内部組織構造を真似た情報アーキテクチャー で行くことにしました．しかしちょっと待ってください．そんなに悪い アイデアではないのでは？通常はYES，つまり悪いアイデアです． ですがSMDの内部組織構造はその科学を真似たものです：地球，惑星， 太陽，そして宇宙物理です．そのようなわけで，私たちは単純に 幸運なだけでした．このようにして，各部門はホームと呼べて彼らの 意思を働かせる場所を得，さらにそれでも利用者は自分で行き先を 見つけることができます． 

デザイナーを教育する 

これで私たちはデザインと技術を得ました！ これら二つのことを話し合わせるのに必要なことは，それをデザイナに 引き渡すことだけででした．そうではありませんか？ 

しかし，そうではありませんでした． 

私たちの係はPhotoshopの熟練者たちでほとんどが占められていました． 彼らはCSSの内部の仕組みについて少ししか知りませんでした．以前は 彼らは様々なAdobeやMacromedia製品を使ってサイトを作り，それを エクスポートし，そしてアップロードしました．この方式はPloneでは 使えません．CSSはHTMLやjavascriptと同じように手作業で仕上げ られなければなりません． 

いやはや，彼らは私たちを大好きに思ってくれたのでしょうか． 

私たちが結局最後にすることにしたのは，デザイナを開発者に変える ことでした．彼らは最初は抵抗し，Photoshopでのデザイン，エクスポート， アップロード，そして次のプロジェクトに移るというのサイクルをしていた ものでした．ツールで彼らをたたく代わりに，私たちが彼らに与えるものの 美しさを彼らに見せました． 

• バージョン管理．あなたが今まで作った画像のすべてがいつでもすぐに 手に入るとしたらどんなに素晴らしいことでしょうか？ 
• 彼らのマシンにサイトをロードしました．このようにすると，彼らは小さな 変更をしてそれをすぐに見る事ができました． 
• SVN update（サブバージョン）：彼らは私たちのマシンをアップデート することができました．それをするのにEメールは必要ありません． ただそれが更新されるのです． 
• 彼らにTALを教え，そして彼らができるカッコいい技法を見せました． たとえば，シマウマスタイル（リストの各行に交互に色が付くスタイル）や， 彼らが望むものを隠したり表示したりする技法です． 

私たちがしたことで最も重要なことの一つは，ビルという名前のCSSグル （教祖のような存在）を発見したことでした．彼はカンプを解釈翻訳し， 私たちの多くのアイデアをサイトにしてくれ，私たちのデザインを本当に 確実なものにしてくれました．私たちはビルが大好きです．私たちは彼の ために死体を隠すことさえしたでしょう．もし私たちが持ったようなデザイン グループをあなたが持つことになったら，できる限り早くグルを手に入れ て下さい． 

それで，開発者たちは何をしていたのか？ 

最初の頃の私たちの考え方は，サイト内で持つことになるであろうアイテムの すべての種類について別々のコンテンツタイプを持つというものでした． その結果，結局次の図のようなあるとんでもないUMLになってしまいました． 

私たちはスラッシュドットされた時の処理をどうするかについて悩ましい 多大な時間を過ごしたりもしました，私たちの顧客（そしてある請負の人たち） はFarkやSomething Awfulとして知られるローミングDOS攻撃を知りません でした． 

私たちみんなにとってそれはてんてこ舞いの時期でした．開発の１年，揺れ 動く要件，私たちが確定できないスケジュールはいくつもの気違いじみた 週末と重度のすり減った精神をもたらしました．私たちはそのサイトのため に新しい赤ちゃんのための準備よりもより多くの準備をしました． （そういえば，サイト開発と私の２回目の妊娠は並行した出来事でした）． ですが，とうとう「ある日」にNASA Science 1.0はデプロイし，そして チームはまさに疲れ果てた開発者とデザイナの肉の山塊と化していました． 

私たちが得たものについてのいくつ細かいこと： 

•  4 Zopeインスタンス 
•  1 ZEOインスタンス 
•  Varnish 
•  Apache 
•  LDAP 
•  とてもたくさんのプロダクトの部分コード 
•  全体で使われた少数のプロダクト 
•  一つの怪物的なカスタムプロダクト 

私たちは今やメンテナンスモードにあります． 

第三部　学んだ教訓 

今ではサイトがデプロイされ，私たちはくつろぎながら，長く大変な 過程で学んだことを見渡す機会を得ました． 

要件！ 

要件のことに関しては，早いうちに要件をかき集めてください． 私たちはそうしませんでした．書類の束に目を通すのをひどく毛嫌い する顧客のからみがあったり，創造的プロセスが狂ってしまったという 理由のからみもありました．もし早い時期に要件を集めていたとしたら， 私たちはプロジェクトの期間を１年削ぎ落としたであろうと私は確信します． それどころか，私たちは一度も要件を紙に書きませんでした．紙切れや 会議議事録のようにその言外に要件を意味するような形で存在するまま にしておきました．私たちが不必要にはるばる遠くはなれてしまわない ようにするような，要件を管理する人はいませんでした． 

さらに，要件にはもう一つ注意しなければならないことがあります． 何度もあることですが，開発者は曖昧さに遭遇すると，それをはっきりと 声に出して話す代わりに，彼／彼女はどんどん前に進もうとします． これは混乱を生むことにしかなりません．今では要件について少しでも 戸惑うならば，すぐに声を上げて, そして回答を得るまでうるさくわめき立てるというルールがあります． もし頭の中に本当の要件を持つ人があなたのために使う時間がないという 理由であなたが回答を得られなければ，その要件は情け容赦なく別の リリースに押し出されます． 

審査 

あなたの人々のスキルについて審査する必要があります．人はレジュメに 関して容赦なく嘘をつき，このことは私たちに多くの時間を負担させます． 私が学んだことの一つは，レジュメにCSSとJavascriptを知っていると 書いてあるという理由だけで，それでその人が実際に構築することができたり， あるいはゼロから作り上げたりすることができるということを意味しないと いうことです． 

これは彼らを悪い人と見なすのではありません．私たちはみな折々にそれを します．話題について一過性の知識を持っていることと，それについて深く 理解していることの間には雲泥の差がありますが，はっきりした何かが常に あるわけではありません． 

これは次の教訓につながります． 

トレーニングは価値ある投資 

カンファレンス，ブートキャンプ，講習．組織内の誰かを行かせることです． それはすべてそれだけの価値があります．私たちの開発者はトレーニングを 受けました．そしてそれは私たちに天と地の違いを生み出しました． もしチームのすべての人に同じ量のトレーニングを受けさせていたら， リリーススケジュールを数ヶ月短くすることができたでしょう． 

コミュニティを使う 

これを学ぶには時間がかかりましたが，今では私たちは過激な信奉者です： コミュニティを愛することを学んでください．厄介な問題を抱えるたびに， 外の世界にはそれをすでに解決したあなたより賢くて才能に溢れた誰かがいます．まったく彼らは非常時の万能粘着テープよりもずっと良い何か実際の記述や 仕様をコミュニティに出しているかもしれません． 

IrCに加わろう．あなたの地域のユーザーグループに入り込もう．何かの メーリングリストに参加し，Twitterに加わろう．コミュニティを使うこと を学び，そしてできる時にはお返しをしよう． 

グルを得る 

私たちの思いがけない最大の幸運はCSSグルであるビルを発見したことだ． それは純粋に掘り出し物を見つける才能だった．新しいやつが仕事を始めて， 私は彼の机の上にカッコいい小さな像があるのに気付いた．私は雑談するのに 立ち寄り，ビデオゲームや他のギークなものへ私たちの興味を語り合い始めた． その時，私は彼のデザイン本の山の中にCSSの本があるのに気がついた． 

「CSSするの？」 

 私たちはそれについて話し始め，そして数分のうちに，彼は私のおおざっぱな CSSの知識の側を勢い良く通過した．彼はCSSの美点を褒め讃え，そして 私にいくつかのカッコいい技法を見せてくれた．私はそこを中座し，それから すぐに私のプロジェクトマネージャの所に走った．私たちが彼を素早く 手に入れることを要求するために． 

あなたのグルたちを見つけ，そして彼らを厚遇してください．彼らが魅力ある 仕事を得るようにしてください．彼らが働く必要があることを彼らがするよう にしてください．彼らが忙しくて仕事に没頭するように魅力的な仕事が彼らに あるようにしてください．あなたのグループに彼らを引き留められることは 何でもしてください． 

3rdパーティプロダクト：買い手危険負担 

私たちが最初に始めた時，私たちはPloneプロダクトを通じて仕事の80%を することができるような印象がありました．ああ，何て馬鹿だったのか， 世間知らずの日々だったのか．．． 

実際には，サードパーティプロダクトは注意深く入念に精査されなければ なりません．ときどき，それらは十分に良く働きますが，一旦使い始めると， 私たちはそのコードが不可解で独自性に満ちていることに気がつきました． もし顧客がほんのわずかな変更を頼んでいたとしたら，その厄介な問題に ハマるのは誰かを見極めるために，私たちはその変更要求チケット付きの 厄介な問題と戯れていたことでしょう． 

ときどき，私たちは必要としているものを中に入ってつかみ取ってきました． CSS技法，あるテンプレートのこぎれいさ，あるいはPythonコードの断片 などです． 

IrCでのプライベートチャンネルを通じて，Alexandar LimiはPydannyに 言いました：「Plone開発者のスキルの一つの尺度は，他人が行ったものを 評価する能力である」と．私たちは今ではそれを肝に命じて，サイトに持ち 込みたいどんなプロダクトを調べるのにも私たちの専門家たちを集めています． 

テストされていないコードは壊れたコード 

プロジェクトにはいつも人が入ったり出たりしています．いずれのコードの 山にも属さずに，絶対に呼ばれることのない機能を持つということは， 人に来るように懇願し，彼らを迎えに行き，そして彼らを使おうとすることです． （つまり大変な努力がいるということ） 

それにNASA Scienceは巨大です．そのいくつかの部分はコンテンツ編集者や 開発者やデザイナによって頻繁に見られる場所ではありません．ですが， リリースの間に何度もそれを見る訪問者がいることに，あなたは最後の１ドル を賭ける事ことができます．（つまり利用者が見るところなのに，作る人間がチェックしきれないような場所があるということ） 

すべてのコードはテストを持たなければなりません．使われないコードは取り 除かれなければなりません．それをするのに時間を取らないということは， 結局はそれまでずっと節約してきた時間とお金よりも多くの時間をかけること になります． 

状況 

今日のところは，満足した顧客がいて，ぎっしり詰まった開発とリリースの スケジュールがあって，幸福そうな開発者がいて，NASAでのもう一つの オープンソースプロジェクトがあります．このNASA Scienceプロジェクト はそのサイトの誕生に大混乱の経過をたどったかもしれませんが，その後は， 私たちに賛辞が山ほど与えられただけでなく，オープンソースソリューション への要請がより多くなりました．

完