0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

4年目SEが「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」を読むPart1

Posted at

はじめに

初めまして。mirankoと申します。
X(Twitter)でバズっていた、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」について、官公庁向け業務アプリ開発4年目の私から読んでの感想などなどまとめていきたいと思います。
ページ数が多いため、何パートかに分けて投稿します。
本文の引用は最低限としますので、資料を読みつつ見て頂けるととても嬉しいです。

参照資料

「1 はじめに」セクション

・システム開発に対する知識、それを説明する力の高さ

一方でクラウドへの移行そのものが目的化されてしまい、必ずしもクラウドサービスの利用メリットを十分に享受できていないといった例も散見された。

この文を読んで、初っ端ですが私は衝撃を受けました。クラウドサービスのメリットを享受できていないことを情報として何件も持っており、それを課題として認識している点、それを分かりやすく簡潔に述べている点です。クラウド化自体、対障害性の向上などインフラ面が違うというだけの点での利点は勿論ありますが、資料で述べられている通りサーバを必ずしも用意する必要がない、インフラやセキュリティ管理をマネージドサービスに移管するなどの大幅なコスト・工数削減を実現できる利点も大きいです。そういったレベルの話を、国の文書でありながらここまで分かりやすく書いていることに感銘を受けました。システム開発に関する総合的な知識、サービスとして検討する知識が十分ある人の集まりなのでしょう。私もここまでの視点を持てるようになりたいです。

クラウドサービスのメリットについて旧新それぞれ説明

旧方針策定時にメリットとしていた可用性、柔軟性などの点と、それからサービスが拡張された現在のメリットをそれぞれ述べています。これがとても読みやすい。従量課金について週末は利用者が少なくコストを削減できるなど、具体例も交えた説明でものすごく説得力があります。
本番サービスの話だけでなく、テストや検証環境についてもかなり述べられていて、クライアントしてでなくデベロッパー目線まで包括した方針であると感じました。 今までは「必要経費」としてクライアント側からすると見えにくい検証環境などの費用が、クラウド化によって明確化していくのだろうと思います。同時に、クライアント側もここまでの観点をもってプロジェクトの精査を行う必要があるのでしょう。

「2 基本方針」セクション

クラウド・バイ・デフォルト原則は浸透できるか

クラウド上での構築を原則とする、聞こえはいいですが、中々難しいと考えています。その理由は個人情報、機密情報の管理です。先日のニュースでもありましたが、「この情報はここまで晒していい」「この情報はこの頻度で使うからこの置き方がいい」といった仕分けは、国のシステムのような複雑で、簡単に変えられないものだとより難しいです。なぜなら誰も答えを知らない 、からだと考えます。
(私の開発しているシステムでもたびたびあります…)
検討するにあたって、「昔から出している情報だけどどのくらい使われているか分からない」など、利用者側と開発者側ですり合わせる必要がある問題が膨大です。しかも、どれをすり合わせなければいけないかは開発する中でどんどん増えていくことでしょう。
クラウド化するにあたって、情報の扱い方を100%間違わないようにすることは切迫した課題だと思われます。

モダン技術の利用はどの規模で?

モダン技術、はどの規模で導入を検討するのか、と考えた時、まず考えられるのは新サービスや利用者の限られるサービスでしょうか。新しいサービスや利用者が少ないサービスでは、既存仕様・既存ソースに縛られることなく比較的柔軟に技術選定ができるはずです。ただ、サービスは往々にしてそれ単体で成り立つことは少なく、別のサービスと連携して真価を発揮します。そういった場合、別サービスとの連携インタフェースはモダン技術が使えるのか、別サービス側の古いフォーマットを踏襲しなくてはいけないのか、といった事象が発生するのではないかと考えました。
システムはいっせーので変わるものではないですから、こういった古い方に足をひっぱられ、それが技術負債となる問題は解決が一朝一夕ではいかなそうです。

「3 具体方針」セクション

SaaSの利用料が増大する場合が追記されている

想定していた利用量とコストの計画が実際と乖離していると、予想外にコストがかさむ恐れがあります。「特に利用料が高額なSaaS」って何なんでしょう?高い処理性能を持つプランやビッグデータ分析インスタンスなどでしょうか?何か事例がありそうです。

ベンダーロックインやめろ!

ベンダーロックイン、初めて読んだ単語でしたが、

ベンダーロックイン(英: vendor lock-in)とは、特定ベンダー(メーカー)の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象のこと。(Wikipediaより引用)

とのことです。なるほどこれは本当にやめてほしい。よくあるオープンソース製品の仕様に則っていないベンダ製品は新人目線だと本当に悪です。ネットに情報が全然ないし、妙な独自コマンドを使わないといけないし、かゆいところに手が届かないせいで無駄に独自実装が増えます。デベロッパは自社製品を使うことで「仕様を知っているのはウチだけ」状態にできるので、全部を自社製品で囲い込みます。そうすると変な独自仕様が増え、オープンソースの製品に変えるにしてもコストがかかるのでなかなか踏み切れず、レガシーな仕様が残り続ける悪循環です。
ベンダがSIなど担当する以上発生はするでしょうが、せめて仕様は有名オープンソースと揃えてほしいものです。

マルチクラウドやめろ!

これもすごく分かる。会社側の開発基準の都合で、「これを使えと言われたけど現場ではこれが必要」といったケースが発生し、結果別クラウドを立てて中継するといった無駄な作業が発生します。

技術的な合理性と経済的な合理性を持たないマルチクラウドは厳に避ける必要がある。

とありますが、親会社の都合など必ずしも最適でない理由で乱立するケースは少なくないと思います。
別クラウドどうしをつなぐサービス自体もお金がかかりますし、誰も幸せにならないのでやめたいですね。

おわりに

Part1はここまで。
ご意見ご感想等コメント頂けますと幸いです!

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?