tabimobaさんのページ | デジタル改革アイデアボックス

あなたと創るデジタル社会

デジタル改革アイデアボックス


tabimobaさんのマイページ

ウェブサイト
ウェブサイトは未記入です。
自己紹介文
自己紹介は未記入です。

投稿したアイデア 2

官公庁や地方自治体が仕様書に「オープンソースCMSを禁止」する文言を禁止するべき

tabimobaさん

地方自治体のホームページ更改に係る入札案件において、「情報セキュリティの観点からオープンソースのCMSを禁止する」、あるいは明確な理由を記載せずにオープンソースのCMSを禁止(除外)している地方自治体が存在します。 オープンソースのCMSがセキュリティ上脆弱で、エンタープラ... » 詳しく

集合住宅におけるVDSLから光ファイバーへの移行推進

tabimobaさん

昨今はコロナ禍により、テレワークや教育(GIGAスクール構想)など、家庭のインターネット高速化が重要となっていますが、築年数の古い集合住宅においては、未だに通信速度が最大100Mbps(実測値はそれ以下)のVDSLであり、かつ光ファイバーへのマイグレーションが行えないという問題が生... » 詳しく

お気に入りアイデア 0

まだお気に入りがありません。

投稿したコメント 26

官公庁や地方自治体が仕様書に「オープンソースCMSを禁止」する文言を禁止するべき

オープンソースCMS禁止については、OSSコミュニティにおいても問題として考えられています。

以下は、Joruri,Zomeki開発元(サイトブリッジ)の代表の方が問題提起された内容です。参考までに、共有します。
https://m.facebook.com/groups/ossjapan/permalink/5227978890560925/

by tabimobaさん - 2021/04/17 04:00 問題を報告

> オープンソースを構築して運用するだけってのは割とありますよ。

公式サイト(lg.jpドメインで運用されるサイト)では見かけたことが無いですね。
一部署が業者に作成させたものを含めて「割とある」というのことであれば仰るとおりです。ただし、公式サイトとはポリシーが異なるため、分けて考える必要があります。

> ソフトウェアに関してはコミュニティ丸投げなので面倒見ません、バグがあったらコミュニティに投げるだけ、事故ってもソフトの欠陥なので、という奴ですね。

これは、プロプライエタリであっても同様です。導入はSIerが行いますが、ソフトウェアの瑕疵については開発元へサポートを依頼することとなります。違いは責任の所在が明確であるかどうかでしょうか。

オープンソースCMSは、製品によりけりかと思います。先に記載したシラサギやJoruri, Zomekiなどは自社開発、自社提供、日本国内開発の製品で、このような製品であればOSSであっても、サポートを締結することで、プロプライエタリと同様の恩恵が受けられます。もちろん、ソースコードの修正の要件も満たせます。

by tabimobaさん - 2021/04/17 03:57 問題を報告

#024

私自身は今は違いますが、昔は業界経験者でしたので、どうしても経験者目線で話をしてしまいます。ですので、それは実際には違うということには反応してしまうのです。

最初の議論が噛み合ってない感じでしたが、段々と共通認識は近づいてきたかなーと思ってます。

by tabimobaさん - 2021/04/17 02:22 問題を報告

#027

> 実際のところ、現状で OSS の実装やライセンスに影響されない何かを作るのはもうほとんど無理なのだけどね。

ええ、そうなんですよね。世の中のプロプラエタリなプロダクトも中身はOSSの塊ですし、JavaでWebアプリケーションを構築するなら今ならTomcatやSpringですし、エンタープライズCMSのテンプレートがVelocityベースというのもあるあるですし。オープンソースから逃れられない(オープンソースを避けることがナンセンスな)現実に気付いて欲しいものだなあと感じます。

by tabimobaさん - 2021/04/17 02:16 問題を報告

#027

そうです、RFPないしRFIのことです。自治体からは要求仕様書として公開されますので、「仕様書」と省略してます。

> 例えば、元のコードのライセンスに注意して、ライセンスの許すオープンソースのコードを参考にプロプラエタリのコード起こせば良いのでは無いですかね。要はオープンソースにしろプロプラエタリにしろきちんと責任を持てるか否かなので。

そうですね、最終的には責任を持てるか否かであると思います。ですので、オープンソースCMS禁止というのは、ナンセンスであるなあと感じています。

何が何でも獲りたいということであれば、プロプラエタリなライセンスの製品も用意し、デュアルライセンスとするのも現状における回避策としてはたしかにありですね。

by tabimobaさん - 2021/04/17 02:11 問題を報告

#007
> 最低限作る実力があるのであれば、作ったものへの責任を追及もできますが、そうではなく「単に構築しただけ」であれば責任逃れしやすいですからね。(^ ^;;;;;


通常は「単に構築しただけ」ということはまずなく、構築に加え、その後のサーバやソフトウェアの保守もセットで契約が進められます。

by tabimobaさん - 2021/04/17 01:59 問題を報告

#022
> ただ、認定制度が形骸化してしまっているケースがないかは、きちんと実態を見て判断は必要かなとは思います。

ここはエンタープライズCMSでも同様の話かなと思います。それぞれのベンダーの制度等は把握しませんが、有資格者何名という感じで担保するケースもあれば、パートナーとしての参加費用を支払うだけのケースもあるかと思います。

by tabimobaさん - 2021/04/17 01:50 問題を報告

#021

> 禁止を禁止するのではなく、透明化してきちんと当事者などで議論して、どうするのがよいかを理解・共有したうえで、自然に「オープンソースCMSを禁止する必要はないよね」という流れができることが重要かと思います。

あるべき姿はそうかと思うのですが、仕様書でオープンソース禁止とされて議論のテーブルにも乗れない事業者は、どのように対応すれば良いでしょうか?ただ横で指を加えて見ているしか無いと思うのですが…。

by tabimobaさん - 2021/04/17 01:47 問題を報告

国産のSNSを

対Facebookであれば、mixiを育てていけば良いと思います。
対Lineは、SNSの要素を捨てて、知人同士のコミュニケーションに限定すれば、チャットワークを使う方法もあります。

by tabimobaさん - 2021/04/17 01:01 問題を報告

官公庁や地方自治体が仕様書に「オープンソースCMSを禁止」する文言を禁止するべき

#017
そうしますと、選定理由の透明化が必要ですね。

何回か申し上げていますが、私自身はオープンソースCMSが優れているとか、何が何でも採用しろということは一言も申し上げていません。

といいますか、オープンソースCMSだからというつまらない理由で排除しなくても、エンタープライズCMSを欲している自治体や組織では、エンタープライズCMSの方が優れていて採用されることはわかっています。なぜなら、オープンソースCMSでは機能要件を満たせないから。しかし、要件として「オープンソースCMS禁止」という合理的ではない、つまらない理由を掲げることや、そこで参入事業者を狭めるのはいかがなものかなと感じます。

ちなみに、オープンソースCMS=Wordpressのような小規模あるいはパーソナルユースのものを想像されているのではないかと思われますが、シラサギやJoruri,Zomekiなど、企業が自社開発し、オープンソースソフトウェアとして提供している自治体向けのエンタープライズグレードのオープンソースCMSも存在します。また、これらのCMSは開発元自身、あるいは製品を正しく理解した協力会社がSIを行っています。ですので、「「他人が作ったもの」をキッティングしてるだけですから、実力のほどが見れない危険性はぐんと上がります。」というのは必ずしも全てに当てはまるものではありません。

by tabimobaさん - 2021/04/17 00:15 問題を報告

#012

> アンフェアな状況をなくすには、「意識」を変える必要がありますので、「ただ禁止さえすればOK」ではなく、啓もう活動や、選定する側の意識改革がない限りは、不正の温床にしかならないということになります。
それを防ぐために厳格な監査を!とかそういう方向にそれていくと思います。

アンフェアな状況をなくすために、この問題を提起しています。
そもそも「オープンソースCMS禁止」と書かれれば、オープンソースCMSで事業を行っている企業は一切参入の余地がありません。

「オープンソースCMSを禁止」を要件とすることを厳格な監査で解決できるのあればそれに越したことはありませんが、なかなかむずかしいのではないでしょうか。

by tabimobaさん - 2021/04/17 00:04 問題を報告

#012

> 今の流れは、「女性は募集しないでください」ということを書かないようにすれば女性差別がなくなる、みたいな話と同様な議論にしかならないので、これ以上続けても意味がないと思いますよ。(^ ^;;

「「女性は募集しないでください」ということを書かないようにすれば女性差別がなくなる」というのは全く理解できないのですが、何に対する比喩でしょうか?

by tabimobaさん - 2021/04/16 23:59 問題を報告

#010

> 現状において「オープンソースCMSを禁止」する文言を要件に入れているような行政機関は、上位によるルールで「オープンソースCMSを禁止」する文言を要件に対して禁止されたところで、オープンソースではない CMS の提案を優先して採択するだけなのでは ?

それは別に良いかなと思います。

選定理由が明確であることと、アンフェアなものでなければ良いと思います。
(この機能が優れている、この機能が要件を満たしている等)

by tabimobaさん - 2021/04/16 23:55 問題を報告

#006

> 「オープンソースCMSを禁止」というのが合理的な理由に基づかない製品排除という理解が出来るのであれば、そもそも「オープンソースCMSを禁止」という要件を能動的に入れたりはしないですよね。

いいえ、入れることはあると思います。といいますか、あからさまに特定のベンダーの製品の採用を優位に働かせるために、敢えて「オープンソースCMSを禁止」とする要件を記載していると思われるものを数多く見かけます。(この時点で本命は決まっているのでしょう)

※仕様書を見ればどこの製品を採用しようと考えているのかは、記載されている要件よりなんとなく理解できるので、そのような仕様書を見るたびに、こんなつまらないことをせずに、別のところで勝負すれば良いのになぁ(そんなことしなくてもその製品で勝てるじゃないの)と溜息をつきながら思ってしまいます。

もちろん、担当者のスキル(その行政や自治体の能力)により、何となく安全側で考えて書いているケースも全くないわけではありませんが、そのようなケースは少ないように感じられます。

上に書いたようなケースで考えると、自治体や担当者の良心に任せるのは難しいかなと思いますので、明文化して禁止する必要があると考えます。

by tabimobaさん - 2021/04/16 23:32 問題を報告

#007

> 安全性に配慮せずに、危険なことを強制解禁しろというのは反対です(^ ^;;;

何を持って「安全性に配慮せずに、危険なことを強制解禁しろ」と判断されましたでしょうか。

おそらく、オープンソース=ソースが公開されている危険という誤った認識で考えておられるのではないでしょうか。

> 一方で「作る実力のない怪しいベンダー」による押し売りがまかり通る危険性があります

「作る実力のない怪しいベンダー」ということであれば、オープンソースでもエンタープライズCMSでも変わりません。結局のところ、作る側次第かと思います。

それから、オープンソースを利用するから低コストであるということも、間違った理解です。逆にTCOで考えればエンタープライズCMSを導入したほうが低コストである場合もあります。

ちなみに、私自身はオープンソースCMSを強制的に入れさせろとは一言も書いておらず、エンタープライズCMSとオープンソースCMSを不公平なく扱う必要があるよね(オープンソースCMSを禁止は不公平だよね)、ということを書いています。

by tabimobaさん - 2021/04/16 23:20 問題を報告

#003
オープンソースか否かに関係なくろくなベンダーや実装を選ぶ事が出来るようになるわけでないというのは、ケースバイケースであると思いますが、「オープンソースCMSを禁止」することを禁止にしなければ、合理的な理由に基づかない製品排除が解消されず、不公正な競争が続くことになります。

※このような状況下では、オープンソースCMSは検討や議論の段階においてテーブルにすら全く乗らない状態であるため、まずはオープンソースCMSを禁止させない状態とすることが必要と考えます。

様々な地方自治体が「オープンソースCMSを禁止」と記載していますが、自治体や担当者の良心に任せるのは難しい(組織としてそのような方々や行為を排除することは難しい、自浄効果は期待できない)と思いますので、本質はどうであれ、「オープンソースCMSを禁止」することは健全な競争を阻害する不公正な例として明文化のうえ、禁止する必要があると思っています。

by tabimobaさん - 2021/04/16 21:39 問題を報告

#002
はい、簡潔に申し上げればそのとおりです。
エンタープライズCMSもオープンソースCMSもどちらもOKにせよというのと、合理的ではない理由でオープンソースCMSを排除するな、ということです。

by tabimobaさん - 2021/04/16 20:41 問題を報告

アイディアに対する補足を記載しておきます。

官公庁や地方自治体のホームページは、セキュリティを考慮して静的配信(CMSから生成されたHTMLを更改サーバへアップロードし、ページを動的生成しない方式)がよく利用されていると思います。静的配信であれば、外部のサイト閲覧者はCDNあるいは静的配信先のWebサーバへアクセスしてサイトを閲覧することになります。

つまり、直接CMSへアクセスすることはなく、例えばCMSに脆弱性があっても、脆弱性は速やかに解決しなければならないとはいえ、サーバ・ネットワークのセキュリティが適切であれば、CMSサーバが外部からの脅威にさらされるリスクも少ないといえますので、CMSがオープンソースかどうか神経質に考える必要もありません。

以上も含めますと、官公庁や地方自治体におけるホームページ更改に係る「オープンソースCMSを禁止」するという文言記載は合理的な理由に基づくものとはいえないため、禁止すべきであると考えます。

by tabimobaさん - 2021/04/16 18:40 問題を報告

ナビダイヤルへの通話も無料にすべき

公的機関もナビダイヤルを窓口にしているケースがありますが、禁止していただきたいです。

例えば、東京都の自殺防止相談ダイヤルがナビダイヤルであったり、厚労省の労災相談ダイヤルがナビダイヤルです。これらの電話窓口どうしてナビダイヤルにする必要があるのでしょうか。

自殺防止相談ダイヤルへ発信する方は、切羽詰まって自殺寸前の方が最後の拠り所として掛けてくるかもしれませんが、彼らはクレーマーで煙たい存在ということなのでしょうか。

by tabimobaさん - 2021/01/22 20:39 問題を報告

日本企業運営のAWSのようなデジタルインフラが必要

必要なのは理解しているのですが、国内クラウド事業者のサービス継続性に問題があります。NTT系はすぐにサービスが終了するし、サービスの品質が優れているわけでも無いので、選択しにくいです。

国内でエンタープライズ用途で安心して使えるサービスはニフクラ、NECあたりになるかと思います。ただし、インスタンスなどの費用はAWSよりも高めです。また、同様のインフラを構築するとAWSよりも高くなるかと思います。

さくらインターネットは主に中小規模向けサービスです。実際に使ってみるといろいろと制限が厳しく、エンタープライズ利用は無謀なことがわかります(APIが連続実行に耐えられないなど)。また、上記同様同じインフラを構成するとAWSより高くなり、結局AWSで良いや、になります。

それから国内のクラウドサービスに共通することは、サービスの仕様やラインナップがAWSなどの海外勢と比べて貧弱なことです。

最近はDXがあちこちで叫ばれてますが、要となるこのようなクラウドサービス事業者を政府が積極的に支援し、国内企業が使いたくなるクラウドサービスとなるように育てていくことが必要では無いでしょうか(政府がユーザーになるというのもその一つかもしれませんが)

by tabimobaさん - 2021/01/15 22:32 問題を報告

「(仮称)Gov-Cloud」でのAWS利用を再検討すべき

AWSと、Azure、Google Cloudに分散して運用すれば良いと思います。

上記に国内クラウドサービスを含める場合は、サービスが仕様に適合しているかの確認とともに、10年以上にわたるサービス継続実績を要件としたうえで、事業者の選定を行うのが良いでしょう。また、上記メガクラウド間のプライベート接続対応も必要ですね。

それから、上記に加えてCDNも用意すれば、頭(ドメイン)はそのままで胴体(サービス)を柔軟に変えられるようになります。DDoS対策にも有効です。また、CDNはあえて海外サービスを使わず、国内サービスを利用すれば、本件のような懸念事項など、万一の際にも安心でしょう。

さらに、Kubernetesを活用すれば特定のサービスへのインフラ依存度も低くなり、他のサービスへシステムを移行しやすくなります。

by tabimobaさん - 2021/01/15 22:08 問題を報告

役所のメールでの問い合わせ

メールではなく、Webシステム化できると良いですね。例えば、申請状況はマイページで管理できる等。

また、WordやExcel等を利用せず、Webブラウザだけで申請が完結できる仕組みであれば、利用者に新たなコスト負担(Word,Excelの購入費用等)や特定の利用環境を強制すること(Windows+IE+Javaに制限等)がないため、利用者においてメリットになるであろうと思います。

Webシステム化し、かつ情報をデータベース化して構造化データとして扱えたほうが、コンピュータ上の処理も効率的に行なえます。また、フォーム化すれば、利用者も必要な情報を正しい場所に入力でき、かつ例外的な入力を排除できますので、利用者も迷う必要がありません。修正も部分的に行なえます。

担当者においては、データの検索や確認を短時間で行えるようになります。メールの場合は、情報を検索して不確実な情報の中から確実な情報を探す必要(問題)がありますが、データベース化すれば、データベースが正しく運用されていれば(データがきちんと整備されていれば)そのような問題もありません。

開発や運用コストは課題となりますが、利用者にとっても実務担当者にとってもメリットになることと思います。

by tabimobaさん - 2021/01/14 11:38 問題を報告

デジタル庁で官公庁向けノーコードアプリを作ってほしい

ノーコードを導入する場合、構築したシステムのメンテナンスが属人化しないように考慮する必要があります。

身近なもので例えるとExcelがありますが、関数やExcelマクロで、Excel上に簡易的なシステムを作成した「Excel職人」の社員の方が異動してしまった、あるいは退職してしまい、そのファイルを誰もメンテナンスできなくなってしまった、という問題はよく耳にする話ですし、検索エンジンで調べればぞろぞろと出てくる話です。

何が言いたいかといえば、ノーコードでも同じ問題が起こるということです。誰でもシステムが作れ、1名に任せっきり、引継ぎも十分に行われなければ、上記のような問題が起こる可能性が高いということです。

よって、
・開発は2〜3名で行う (1名で開発させない)
・関係者は全員同じスキル・同じ認識を有する
・意味のあるドキュメントをきちんと残す(仕様書、操作手順、差分情報等)
・差分管理を行う
・部署異動の際は引き継ぎの時間を必ず設ける
ということが、ノーコードを適切に運用する、かつ属人化を避けるために求められるでしょう。

by tabimobaさん - 2021/01/14 01:06 問題を報告

オープンソースのRPAツール

OSSのRPAツールはSikulixやOpenRPAというものがすでにありますので、それらを利用すれば良いと思います。

OpenRPAはUIPathに似たインターフェースのRPAツールで、有志の方によるローカライズも進められています(OpenRPAもUIPathも、Microsoft Workflow Foundationをベースとしたソフトウェアです)。

上記のようなツールをベースに、導入時のコンサルティング、利用方法等の研修・教育、自動化のためのスクリプト等の開発・提供、周辺ツールを中小企業に対して支援していくというのはありでしょう。ただし、このような内容は、民間に任せるべき内容かなと思います。(民業圧迫につながりかねない)

by tabimobaさん - 2021/01/14 00:35 問題を報告

官庁のシステムのオープンソース化

オープンソース化により、OSSコミュニティによりコンスタントに開発が行われ、機能改善やセキュリティ確保が行われる(手段)であれば賛成ですが、単にソースコードを公開するだけ(目的)であれば反対です。

まず、オープンソース化によって、コードが高水準化され、「常にエンジニアの監視に堪えうるソースコードをコミット」されるかといえば、そうならないでしょう。現実は、ぐちゃぐちゃでセキュリティホールだらけのコードも平気でコミットされるでしょう。

また、低コスト化については、成果物やコードなどの見えるものだけで「俺ならこの金額でできる」と思われるかもしれませんが、実際は成果物やコードが全てではありませんので、これらのみで低コストであるかを正しく判断することはできないでしょう。

それから、OSS化して開発を推進していく場合、コミュニティの形成やスポンサーの確保が必要になります。エンタープライズで利用されるOSSプロダクトは、企業や企業がスポンサーとなっているものがほとんどです。有償で開発された成果が並行してOSSになる(デュアルライセンスで運用される)ものもあります。もし、OSS=無償、個人が趣味で開発しているレベルのものとして考えておられる場合、この点は改めて頂く必要があります。

by tabimobaさん - 2021/01/14 00:16 問題を報告

ビッグテックのサーバーに依存してはいけない

国内のクラウドサービスは、数年でサービスが終了してしまうような、サービスの継続性に問題のあるサービスが多くあり、しばしば悩まされます。(昨年もとあるクラウドサービスが終了となり、とても悩まされました)

また、インスタンスタイプ廃止に伴う移行作業のようなものでも、海外のクラウドサービスであればインスタンスタイプの変更程度で済むものが、国内のクラウドサービスの場合は、全く異なるサービスへの移行作業レベルの対応を強いられる場合があり、非常に苦痛に感じることがあります。

以上は、ユーザーの立場から見てとても致命的な状況で、とてもでないけど安心して利用することができませんし、国内のクラウドサービスを積極的に使おうという向きにはならない(海外のメガクラウド勢を利用するという向きになる)と思います。

国内のクラウドサービス事業者の方は、安易にサービスを終了するのではなく、現在のサービスを生かし、長く育てていくことを考えていただきたいです。

by tabimobaさん - 2021/01/13 23:29 問題を報告

投票履歴 22

警察の違反金

高評価コメント 5

他のユーザからの評価(★の数)の平均が4以上のコメントを表示しています。

評価の平均値
5
コメント日時
コメントしたアイデア

公的機関もナビダイヤルを窓口にしているケースがありますが、禁止していただきたいです。

例えば、東京都の自殺防止相談ダイヤルがナビダイヤルであったり、厚労省の労災相談ダイヤルがナビダイヤルです。これらの電話窓口どうしてナビダイヤルにする必要があるのでしょうか。

自殺防止相談ダイヤルへ発信する方は、切羽詰まって自殺寸前の方が最後の拠り所として掛けてくるかもしれませんが、彼らはクレーマーで煙たい存在ということなのでしょうか。

評価の平均値
5
コメント日時
コメントしたアイデア

必要なのは理解しているのですが、国内クラウド事業者のサービス継続性に問題があります。NTT系はすぐにサービスが終了するし、サービスの品質が優れているわけでも無いので、選択しにくいです。

国内でエンタープライズ用途で安心して使えるサービスはニフクラ、NECあたりになるかと思います。ただし、インスタンスなどの費用はAWSよりも高めです。また、同様のインフラを構築するとAWSよりも高くなるかと思います。

さくらインターネットは主に中小規模向けサービスです。実際に使ってみるといろいろと制限が厳しく、エンタープライズ利用は無謀なことがわかります(APIが連続実行に耐えられないなど)。また、上記同様同じインフラを構成するとAWSより高くなり、結局AWSで良いや、になります。

それから国内のクラウドサービスに共通することは、サービスの仕様やラインナップがAWSなどの海外勢と比べて貧弱なことです。

最近はDXがあちこちで叫ばれてますが、要となるこのようなクラウドサービス事業者を政府が積極的に支援し、国内企業が使いたくなるクラウドサービスとなるように育てていくことが必要では無いでしょうか(政府がユーザーになるというのもその一つかもしれませんが)

評価の平均値
5
コメント日時
コメントしたアイデア

AWSと、Azure、Google Cloudに分散して運用すれば良いと思います。

上記に国内クラウドサービスを含める場合は、サービスが仕様に適合しているかの確認とともに、10年以上にわたるサービス継続実績を要件としたうえで、事業者の選定を行うのが良いでしょう。また、上記メガクラウド間のプライベート接続対応も必要ですね。

それから、上記に加えてCDNも用意すれば、頭(ドメイン)はそのままで胴体(サービス)を柔軟に変えられるようになります。DDoS対策にも有効です。また、CDNはあえて海外サービスを使わず、国内サービスを利用すれば、本件のような懸念事項など、万一の際にも安心でしょう。

さらに、Kubernetesを活用すれば特定のサービスへのインフラ依存度も低くなり、他のサービスへシステムを移行しやすくなります。

評価の平均値
5
コメント日時
コメントしたアイデア

メールではなく、Webシステム化できると良いですね。例えば、申請状況はマイページで管理できる等。

また、WordやExcel等を利用せず、Webブラウザだけで申請が完結できる仕組みであれば、利用者に新たなコスト負担(Word,Excelの購入費用等)や特定の利用環境を強制すること(Windows+IE+Javaに制限等)がないため、利用者においてメリットになるであろうと思います。

Webシステム化し、かつ情報をデータベース化して構造化データとして扱えたほうが、コンピュータ上の処理も効率的に行なえます。また、フォーム化すれば、利用者も必要な情報を正しい場所に入力でき、かつ例外的な入力を排除できますので、利用者も迷う必要がありません。修正も部分的に行なえます。

担当者においては、データの検索や確認を短時間で行えるようになります。メールの場合は、情報を検索して不確実な情報の中から確実な情報を探す必要(問題)がありますが、データベース化すれば、データベースが正しく運用されていれば(データがきちんと整備されていれば)そのような問題もありません。

開発や運用コストは課題となりますが、利用者にとっても実務担当者にとってもメリットになることと思います。

評価の平均値
5
コメント日時
コメントしたアイデア

国内のクラウドサービスは、数年でサービスが終了してしまうような、サービスの継続性に問題のあるサービスが多くあり、しばしば悩まされます。(昨年もとあるクラウドサービスが終了となり、とても悩まされました)

また、インスタンスタイプ廃止に伴う移行作業のようなものでも、海外のクラウドサービスであればインスタンスタイプの変更程度で済むものが、国内のクラウドサービスの場合は、全く異なるサービスへの移行作業レベルの対応を強いられる場合があり、非常に苦痛に感じることがあります。

以上は、ユーザーの立場から見てとても致命的な状況で、とてもでないけど安心して利用することができませんし、国内のクラウドサービスを積極的に使おうという向きにはならない(海外のメガクラウド勢を利用するという向きになる)と思います。

国内のクラウドサービス事業者の方は、安易にサービスを終了するのではなく、現在のサービスを生かし、長く育てていくことを考えていただきたいです。

ページの先頭へ