IT全般」カテゴリーアーカイブ

日本の電子政府はなぜイマイチなのか

この記事は、 JPOUG Advent Calendar 2021 10日目の記事です。9日目は 明治そして大正昭和平成令和さんの記事SQL標準とPostgreSQL,MySQL,Oracle,etc…でした。

今回は技術のことは書きません。悪しからず…

デジタル庁が発足したが…

2021年9月1日に、内閣府の組織としてデジタル庁が発足した。

菅政権の目玉政策の一つであったが、当の菅首相は既に退陣し、初代デジタル大臣の平井氏もわずか1ヶ月で退任した。

デジタル庁発足の5ヶ月前に朝日新聞が実施した世論調査では、デジタル庁に「期待する」という人が44%、「期待しない人」が45%というかなり微妙な結果であった。

デジタル庁に「期待」44%、年代で差 朝日世論調査

個人的には、このような「ふわっと」した設問というのには違和感があるが、実際デジタル庁のホームページを見ると

デジタル庁

いきなり「データ戦略へのご意見をお寄せください(第2回)公開日 : 2021年12月3日」という文言が飛び込んできた。

「戦略」という組織にとっての最重要テーマに関して国民の意見を広く求めるというのは、今までのお役所にはない特徴なのかもしれない。

デジタル庁という役所が国民に一体何をしてくれるのか、国民として何を期待すべきなのか、考えてみたい。

各国のICT投資額推移

グラフは日本、米国、英国、仏国におけるICT投資額の推移(1980-2017年)である。

各国のICT投資額の推移比較(名目、1995年=100)

令和元年版総務省情報通信白書>ICT投資の状況から引用

赤線の日本は1995年以降ほとんど横ばいとなっていることがわかる。

この理由として「システムの維持管理費が高額化し、IT予算の9割以上になっている」という指摘もある。DXレポート ~ITシステム「2025年の崖」克服と … – 経済産業省

一方、米国と仏国は順調に右肩上がりとなっていることがわかり、対1995年比約3倍となっている。

1人当たり名目GDP推移

次は、上のグラフの国々+デンマーク、韓国、エストニアにおける1人当たり名目GDPの推移(1980-2020年)である。

1人当たり名目GDP(IMF統計、単位:USD)

Global Noteによりグラフ化

紫線の日本は1995年においてこの中で最も高い数字を誇る国であったが、2020年ではむしろ減少している。

しかし、日本を除く各国は1990年と比べて2020年は確実に右肩上がりに成長している。

米国の堅調な伸びはともかく、追加したデンマーク、韓国、エストニアの3国の伸びは著しい。(2021年で韓国は日本を抜いているという話もある。)

種明かしをすると、これら3カ国は次に述べる国連電子政府ランキング(2020年)の上位3国である。

これらのグラフから、我が国が『ICT投資が伸びないので1人当たり名目GDPが伸びない」のか、「1人当たり名目GDPが伸びないのでICT投資が伸びない」のかはまさに「鶏と卵の関係」でどちらが原因か、もしくは相関関係があるのかすら断定することはできない。

しかし、これらに相関関係があるのであれば、ICT投資を健全に増やすことができれば、1人当たりの名目GDPも堅調に成長するのではないかという期待感がある。

国連電子政府ランキングとは

国連が、加盟国すべてを対象とした調査により2年に一度発行しているランキングであり、政府がいかにして全ての者に対してアクセスと社会参加を提供させるためにICTを利用するか、という点に対して体型的な評価を提示しているものである。

国連電子政府ランキングは電子政府の成功条件として次の15の評価基準を設けている。

  1. 社会的有線開発事項との密接なリンク
  2. 効率性がよく社会的影響力があること
  3. 資金有用性が高いこと
  4. 十分な市民サービスを提供できる技術と文化
  5. 協調関係が発揮できること
  6. 法的枠組みの充実
  7. ICTインフラストラクチャーの充実
  8. 政治的リーダーシップと長期的ポリティカルコミットメント
  9. 国民・社会への公約
  10. 資本・技術インフラ発達に関する計画
  11. パートナーシップ
  12. モニタリングと評価
  13. 付加価値
  14. アクセスと技術
  15. プライバシーとセキュリティ

また、次の3つの指標を用いて定量化している。

  1. Web指数
  2. ICTインフラの整備状況
  3. 人的資本

3番目の人的資本について補足すると、成人識字率と、初等・中等・高等教育機関への相対的入学率の加重平均である。

2020年に発表された国連電子政府ランキングでは

1位:デンマーク(2018年 1位)
2位:韓国(同 3位)
3位:エストニア(同 16位)

となっており、エストニアの爆上げが注目される。

ちなみに我が国は

14位:日本 (同 10位)

である。

参考:電子政府世界ランキング指標の有効性と 潮流に関する考察

日本はデジタル敗戦国か?

電子政府ランキングが14位に転落したこと、あるいはマイナンバーカードの普及率が未だに4割程度(2021年11月現在)であることなどから、「日本はデジタル敗戦国」という論調が最近目立ってきた。

そんな背景もあってのデジタル庁発足なのだろうが、Youtubeに面白い動画がアップされていた。

【デジタル敗戦】スマホ決済すらできない社員が出世する日本企業。夏野剛「政府じゃなくて民間が一番ダメ!」| FACT LOGICAL #9
【デジタル庁 vs 夏野剛・青野慶久】デジタル庁は本当に日本を変えられるか?| FACT LOGICAL #10

※1本目の動画の中で、夏野剛氏が「銀行口座はマイナンバーに紐づいている」と発言している箇所があるが、(現時点で)マイナンバーに紐づいているのは証券口座であって、銀行口座との紐付けは任意

デジタル庁チーフアーキテクトの話を聞いても電子政府のあるべき姿はイメージできなかった印象があるのだが、問題点についてはよく整理されていたので是非視聴されたい。

電子政府のあるべき姿

電子政府の理想形をイメージするためには、やはり電子政府ランキング上位国の事例に学ぶ必要があろう。

先進国事例の紹介

以下のリンクは非常によくまとまった記事であるので紹介したい。

デジタル庁発足にあたり、改めて世界の電子政府を考える

デンマーク

  • 1968年(!) CPR番号 – Wikipedia (日本のマイナンバーに相当)が導入され、市民にはCPR番号を記したカードが付与されている。
  • 生活におけるデジタル基盤。(生年月日、性別などの個人情報と行政、医療、教育、税務などに関する個人データが保管され、該当機関は必要に応じアクセス可)
  • 市民ポータルサイト「Borger.dk」:CPR番号でログインすると、国・地方公共団体すべての機関のネットワーク化されたすべてのシステムにアクセスでき、必要なサービスを利用できる。
  • 国民はCPR番号に紐づいた電子私書箱「e-boks」
  • インターネット口座「NemKonto」
  • これらに登録することは国民の義務であり、国や市によるお知らせはメールでe-boksに届き、給与の受け取りや納税はNemKontoを通じて行われる
  • CPR番号を用いてインターネットで個人認証を行うためのデジタル署名として NemID – Wikipedia がある。
  • 「ユーザファースト」のポリシーに基づく優れたUI/UX

韓国

  • ワンストップの市民ポータルサービス「政府24」
  • 政府24では、IDとパスワードを入力するだけで、住所変更や証明書発行など約3,000種類以上の行政手続きをオンラインで完結できる。
  • 政府24の国民によるサービス利用率は87.6%
  • 住民登録番号 – Wikipedia 生まれた時に全国民に割り当てられる個人番号、管理システムはポータルサービスの重要な基盤となっている。
  • 17歳になると役所で指紋登録を行い住民登録証の交付を受けることが義務づけられている。
  • 住民登録番号は、行政サービス以外にも医療や福祉、出入国管理、クレジットカード利用歴などの記録にも紐づいている。
  • 2001年制定の電子政府法では、行政業務・行政文書が原則電子化されており、税金の使い道や行政文書の開示をオンラインで公表することで、行政情報のオープン化が図られている。

エストニア

エストニア共和国 は旧ソ連から1991年に独立した、バルト海東岸に位置するバルト三国で一番北にある人口約130万人の小国である。

  • 行政サービスの99%が電子化されている。(例外として結婚・離婚に関する手続きは”意図的に”オンラインでできない仕組みになっている。)
  • 個人識別番号(Personal Identification Number)は誕生とともに割り振られる11桁の番号である。生まれた病院の職員等が住民登録ポータルから申請し、住民登録データベースに情報が登録される。
  • 15歳以上の国民は身分証明書となる電子カード「eIDカード」の保持が義務付けられている。
  • eIDカード一枚で、運転免許証、保険証、交通系ICカード、銀行カードの機能を包括している。
  • eIDカードの利用基盤となるのが、あらゆる機関のデータを連携するプラットフォーム「X-Road」である。
  • 1つの巨大なデータベースを構築するのではなく、「バラバラの小さなデータベースを繋ぐ」という逆転の発想から生まれた基盤がX-Roadであり、共通プロトコルで`様々なデータベースを疎結合により統合する仕組みである。
  • X-Roadには行政サービスだけでなく様々な民間サービスが接続され、引っ越しや出産などに伴う官民のあらゆるサービスがワンストップにオンラインで簡単に完結できるようになっている。
  • X-Roadを介したアクセスは厳正なアクセスログが保存され、個人識別番号に紐づく個人情報にいつ・誰が・何の目的でアクセスしたかを追跡することが可能となっている。

書籍「未来型国家エストニアの挑戦」から許可をえて抜粋

エストニア電子政府については次の記事も大変参考になる。

日本がエストニアから学ぶべき「行政DX」とは

日本とエストニアの違い

日本の「マイナンバー」とは

先に紹介したYoutube動画でも紹介されていたが、「マイナンバー(個人番号)」と「マイナンバーカード(個人番号カード)」は別物であることを理解する必要がある。

まずマイナンバーは、日本の住民票に住民ごとに記載される住民票コード(無作為に作成された10桁の数字+チェックデジット1桁から成る11桁の番号であり、住民基本台帳システム上で、日本の住民を一意に特定するために用いられる。)を基に、非公開の関数で返還された11桁数字にチェックデジット1桁を付加した12桁の番号である。これは日本に住民票がある全員に既に割り当てられている。

いわゆるマイナンバー法 第二条第8項では、「特定個人情報」は個人番号(マイナンバー)をその内容に含む個人情報であるとしているため、マイナンバーは「秘匿すべきもの」として扱われることになっている。

住民票コードは、住民票のある各市町村で管理されるため、出生の場合予め各市区町村に割り当てられた重複のない複数の番号(番号プール)から職員が取り出し住民票に記載することで決定される。

つまり、マイナンバーを決定するためには住民票(住民基本台帳システム)が必要となる。

次に、マイナンバーカードであるが、これは裏面にマイナンバー(コピーが取れないようなマスクが施されている)、表面に氏名、住所、顔写真が印刷されたプラスチック製のカードである。

カードの内蔵ICチップには公的個人認証情報(JPKI)が搭載されているが、カードをリーダーやスマホで読み取って公的個人認証ツールとして使う場合、マイナンバーそのものは利用しない。

秘匿すべき情報としてのマイナンバーをわざわざ印字した物理的なカードを持ち歩く必然性を筆者はどうしても理解することができない。(マイナンバーカードには紛失した際に届けてもらうための住所まで明記してある。もちろんこれも個人情報である。)

参照:マイナンバーカードの利用には、マイナンバー漏洩の可能性がついてくる (電子政府コンサルタント牟田学氏の「manaboo.com 電子政府ブログ」)

エストニアの「個人識別番号」とは

個人識別番号は以下のフォーマットによる11桁の番号が割り振られる。

  1. G:性別及び誕生した世紀。奇数は男性、偶数は女性 1-2(19世紀)、3-4(20世紀)、5-6(21世紀)
  2. YYMMDD:誕生年・月・日
  3. SSS:シリアル番号
  4. C:チェックデジット

個人識別番号は、個人情報保護法(Personal Data Protection Acts)により保護対象ではなく、国の財産であり公知のものとされている。個人識別番号は生涯変わることがない。

ちなみに、デンマークのCPR番号も韓国の住民登録番号もそれぞれエストニアと似た独自のフォーマット(ルール)により採番されるようになっており、日本のようにチェックデジット以外を無作為に生成される番号としていない。

なお、エストニアの「個人識別番号(国民ID)」と日本の「マイナンバー」の違いを詳細に解説した以下の記事が大変参考になる。

エストニアの「国民ID」と日本の「マイナンバー」 (同じく牟田氏のブログ)

エストニアにおける公的データベースとは

JPOUGの皆さんにとって「データベース」とは技術探求の対象であり、その能力をいかに引き出すかに関心があるのではと思うが、電子政府における公的データベースを考える場合、技術的側面だけでなく、法律・規則を含む政治的・社会的側面にも目を向ける必要がある。

下図は、エストニア国家情報システムのイメージであるが、その中核には法律で確立されたデータベースが存在し、それを支えるシステムと重要な利用者との接点が描かれている。

ここには、法律を作る「政治」の重要さが感じられる。

JEEADis勉強会資料から許可を得て抜粋

翻って、我が国はどうだろうか。

政治家のITリテラシーは低く、過去の遺産をいかに残すかだけかを考えているようにしか見えない。

2021年12月現在、18歳以下の子供への給付金の半分をクーポンで配るか否かで国会は大変混乱している。

しかし、昨年の全国民への特別定額給付金において政府は5月末までの支給を目標としていたにもかかわらず、結局夏頃までかかってしまったことを忘れてはいけない。

「10万円給付」支給済み世帯はわずか2.7% 関東の主要34市区を本紙が集計:東京新聞 2020/6/7

電子政府先進国では、国民の口座に対し国からの給付金が開始から2〜3日で勝手に振り込まれていたというような話も聞く。

日本人はもっと政治に厳しい眼を向けるべきではないか。

JEEADis勉強会資料から許可を得て抜粋

上図は、エストニアの公的データベースの中でも最も重要と言っていい「住民登録データベース」のガバナンスを解説したものである。

エストニアでは子供が生まれた産院の住民登録ポータルからの申請で住民登録が完結する。誕生後わずか10分で個人識別番号が割り振られるとの話もある。

一方、日本は出生届により子供は親の戸籍に入り日本国籍を得るのであるが、何らかの理由で親が出生届を出さない場合、その子は「無戸籍者」となる。これは本当に深刻な問題だ。

「わたしはここにいる」無戸籍の人々を支援【報道特集】

番組によると全国に1万人以上の「無戸籍者」がいるらしいと推定されている。

また、昨年の特別定額給付金の支給も基本的に世帯単位だったので、例えばDV家庭などでは様々なトラブルがあったと聞く。

行政と国民をつなげるにはやはり個人単位でなければならないのだ。

我が国の何が問題なのか

いろいろと書き連ねてきたが、日本の電子政府を阻む様々な要因はまた別の機会を設けて考えてみたいと思う。

以下は、ざっと思いつくまま並べてみたタイトルであるが、ブログで取り上げてみたいテーマである。

  • 公務員改革と業務改革(BPR)
  • マイナンバーと戸籍制度
  • クローズド・アーキテクチャとベンダー・ロックイン
  • 住民基本台帳はベースレジストリとなり得るか

しかし、日本の電子政府に求められていることは、以下の図に集約されているのではないかと思う。

「国民が政府を監視」

マイナンバーカードの普及率(強調しておきたいがこれは国連電子政府ランキングを上げる要因にはならないと思う)が4割にとどまっている理由として「政府が国民を監視」するためのツールとして感じている人が多いということは否定できない事実であろう。

エストニアの優れている点をいろいろ挙げてきたのだが、だからと言ってエストニア人は政府を信頼しているわけではない。

政権は時に交代し今までとは全く異なる主義主張をする政府になり得る。しかし、下図に掲げる「公平性」を担保するために、「追跡可能性」による「責任追求性」があり「透明性」を実現する仕組みがある。

この仕組みがあるので、エストニア国民は個人情報の管理を国家に委ねるのである。

JEEADis勉強会資料から許可を得て抜粋

私がエストニアを知ったきっかけとJEEADis(ジェアディス)

そもそも、私がエストニアの電子政府に関心を持ったのは、2019年3月にTBSラジオの「荻上チキSession-22」で「ハンコも書類もない!最先端電子政府を実現したエストニアの驚くべき実態とは?」という放送を聴いたのがきっかけだった。

その内容に大変な衝撃をうけ、ゲスト話者の小島健志氏が書いた

ブロックチェーン、AIで先を行くエストニアで見つけた つまらなくない未来 Kindle版

という本を早速買ってむさぼるように読んだ。

次に、読んだ本が

未来型国家エストニアの挑戦  電子政府がひらく世界 (NextPublishing) Kindle版

であり、さらにエストニア電子政府のことを知ることとなった。

そして、この本の著者である前田 陽二氏が代表理事をしておられる、

日本・エストニアEUデジタルソサエティ推進協議会(略称JEEADiS:Japan & Estonia/EU Association for Digital Society)  という社団法人の存在を知ることとなった。

すぐに個人賛助会員に申し込み、現在に至るわけである。

JEEADiSでは定期的に勉強会(現在はオンライン)があり、主に理事である電子政府コンサルタントである牟田 学氏が講師として非常に有益な学びの機会を提供している。

勉強会の内容は Youtube でも公開されているので、興味のある方は是非視聴していただければと考える。

偉そうに語る割には、私はエストニアには一度も行ったことはないのであるが(ちょうど30年前にノルウェーに1週間くらい行った経験はある)、エストニアのeレジデンシーを取得して、いつかはエストニアに行ってみたいと思う今日この頃である。

 

書籍紹介:『アポロ13』に学ぶITサービスマネジメント ~映画を観るだけでITILの実践方法がわかる! ~

書籍紹介:『アポロ13』に学ぶITサービスマネジメント ~映画を観るだけでITILの実践方法がわかる!

アポロ13号でなぜITILを学ぶのか?

アポロ13号の事故は1970年、一方ITIL:Information Technology Infrastructure Library1989年イギリスで初版が公開された。

従ってこれらには直接の関連性はなく、それは本書の中でも再三繰り返されている。
しかし、ITILがアメリカの成功体験を分析することで策定されたという逸話もあるので、「成功した失敗」と呼ばれるアポロ13号の教訓からITILの本質を学ぶという筆者の考えには共感できる。

目次

■第1部 ITサービスマネジメントとアポロ13
●第1章 ITサービスマネジメントとは
-ITサービスの価値を高めるために-
●第2章 『アポロ13』でITSMを学ぶ意義
-アポロ計画とビジネスストラテジの共通点-

■第2部 サービスストラテジ
●第3章 「ニール・アームストロングが月に降り立ちました」
-アポロ計画における戦略-
●第4章 「14号があればだが」
-アポロ計画における「顧客」とは-
●第5章 「月を歩くんだね」
-サービスという単位を考える-

■第3部 サービスオペレーション
●第6章 「ヒューストン、 センターエンジンが停止した」
-インシデント管理-
●第7章 「反応バルブを閉じろ、と伝えろ」
-サービスデスク-
●第8章 「自分の字が読めないんだ。思ったより疲れているみたいだな」
-問題管理-

■第4部 サービスデザイン
●第9章 「絶対に死なせません」
-サービスレベル管理-
●第10章 「チャーリー・デュークが風疹にかかっている」
-可用性管理-
●第11章 「問題は電力だ。電力がすべて」
-キャパシティ管理-
●第12章 「トラブルが発生した」
-ITサービス継続性管理-

■第5部 サービストランジション
●第13章 「なんとかして、この四角をこの筒にはめ込むんだ」
-構成管理-
●第14章 「この飛行計画は忘れよう」
-変更管理-
●第15章 「こちらヒューストン。打ち上げ準備完了です」
-リリース管理-

■第6部 継続的サービス改善
●第16章 アポロ計画は改善のかたまり
-継続的サービス改善-

読後感

「アポロ13号」というタイトルに惹き付けられて手にした本書だったが、予想以上に面白い本だった。

例えば、
●第4章-アポロ計画における「顧客」とは-では

  • 顧客:アメリカ大統領、政府役人
  • ITサービス・プロバイダ:NASAヒューストン管制センターと管制官
  • ユーザ:3名の宇宙飛行士、バックアップ宇宙飛行士
  • インシデント管理マネージャー:主席飛行管理官

のように、具体的な登場人物を映画「アポロ13」の場面から引用することで、ステークホルダーやその他ITILの重要なキーワードをわかりやすく説明している。

これは、各章で一貫しているスタイルなので、DVDを観ながら読み進めると非常に面白い。

実践には概念を現実に昇華させる方法が必要であり、この本の手法はとても参考になる。

なぜ日本ではITILが浸透しないのか?

IT業界に長く身を置いているのだが、ITILを始めて聞いた2004年ごろから現在までITILの考え方を取り入れて成功した例をあまり聞いた実感がない。単純に成功体験に接する機会に恵まれなかった結果なのかもしれないが、行った現場はことごとくITIL的でない状況だった。

ただし
「多くの会社でSLAとして作成された文書を実際に確認してみると、現状そのほとんどは単なる契約書であり、ITILで解説しているSLAとはまったく違っていて、愕然とします。しかし、すでにSLAがあることになっていますので、別途(本来の)SLAが策定されることはありません。SLAという名の契約書(実際には、法務部門のレビューまで受けて押印された、ただの契約書)が存在していますので、SLAを権威づけするような契約書が別途交わされることもありません(本当の意味でのSLAが存在しないのですから、当たり前と言えば当たり前なのですが…)。このような状況ですので、外部プロバイダとの間でUCを取り交わすようなことはあっても、プロバイダ内部でOLAを策定しようと考えるIT部門は、残念ながらもほぼ皆無です(筆者の知る限り、きちんとOLAを策定していたITサービス・プロバイダは1社だけでした)」(読書位置:1672)
とあるように、ITILを正しく実践できている会社がほとんどないというのが現実なのかもしれない。

構成管理データベース(CMDB)から始めよう。

データベースに深く関わっている立場から感じることは、ITILを実践できないのは中核となる構成管理データベース(CMDB)がないからだと思う。本の中から構成管理について述べられた部分を抜粋する。

「この構成管理、実はこれそのものは何の利益もユーザ満足ももたらしません。そのため、つい後回しに、ないがしろにされてしまいがちなプロセスです。しかし、構成管理は前述のとおり、構成管理データベースを常に最新の、正確な状態に保つことを目的としたプロセスです。構成管理データベースは、ほかの重要なプロセスがITサービスの提供に利益をもたらすことを確実にするために、とても重要な情報を提供します。したがって、構成管理は(地味なプロセスなんですが)非常に重要である、と言えるでしょう。」(読書位置:2693)

「構成管理の観点では、ストレージは単なるサーバーの属性の1つ(どのサーバーに何テラバイトの容量のストレージが割り当てられているか)に過ぎないかもしれません。また、物理的なサーバーの中に仮想サーバーが10台存在するなら、構成管理としては、その仮想サーバー10台もそれぞれ構成アイテムとして管理する必要があるでしょう。さらに、SLAや組織図などの文書は資産管理では扱いませんが、構成管理では非常に重要な構成アイテムとして管理対象に含めます。」(読書位置:2706)

「筆者がJAXAに勤めている人から話を伺ったところ、世界初のデータベース管理システムは、このアポロ計画で宇宙船に積み込む備品のリストを作るために作られたのだそうです。ヒューストンの管制センターで全体の管理をしていたコンピュータ・システムはIBM社のSystem/360でしたから、おそらくこの世界初のデータベース管理システムは、System/360上で稼働していたことでしょう。もっとも、IBM社初のリレーショナル・データベースである System R は1977年に初めて売れた、ということですので、この世界初のデータベース管理システムは、現代風のリレーショナル・データベースではなかったのかもしれません。」(読書位置:2731)

以前、某ITサービス・プロバイダに在籍していた時、構成管理データベースの重要性を実感していたにも関わらず日々の業務に追われ結局実現することができなかった。

構成管理データベースはオープンソースのツールが存在したりしているが、出来合いのツールに合せていくのではなく、現状どこにでもあるExcelベースで管理している構成情報をモデリングしCMDB構築のヒントを模索していこうと思う。

これが漠然とした今年のテーマである。

Amazon RDSをさわって考えた

やっと再開

新しい年になってもなかなかブログが捗らなかったが、今年から「ですます調」から「である調」に変えて再開することにした。

Amazon RDSを使ってみた

今までクラウドでデータベースを使うということに性能面でどうしても違和感を持っていたので、あまり積極的に関心を寄せなかったのだが、仕事の関係でPostgreSQL on RDSを使う機会があったので、個人的にも無料の範囲で試してみることにした。Amazon RDS

詳しい構築手順等は検索すればいろいろ見つかるので割愛するが、ゆっくり確認しながらでも30分程度でDBインスタンスが構築できてしまうのは驚異的である。

インスタンス作成中

RDSとOSS

当然のことながらRDSとOSSは相性がいい。ライセンス費用が発生しないからだ。一方商用製品であるOracleとMSSQLはライセンス費用を考慮する必要がある。

例えばOracle Enterprise EditionをRDSで使用する場合は、自前のライセンスを用意する必要がある。

バックアップ

RDSではバックアップウィンドウを指定するだけで勝手にバックアップを取得してくれる。万一バックアップからリカバリする場合は、今までのインスタンスとは別にインスタンスを作成しそちらにリカバリするなど多少運用を考える必要があるが、フルマネージドRDBサービスとしての重要な機能のうちの1つであるであることに間違いはない。

監視

AWSで提供されるCloudwatchによって、パフォーマンスデータの取得及び可視化(グラフ化)が可能である。

監視項目(メトリック)の数も充実している。

冗長構成

無料お試し版では使えないが、マルチAZ配置とすれば異なるアベイラビリティ・ゾーン間で「プライマリ」と「スタンバイ」レプリカの構成を自動的に構成・管理することができる。

「プライマリ」側に何らかの異常があった場合でも「スタンバイ」へ自動的に切り替えることで運用を継続することができる。

Oracleの世界で言うところのData Guardのような仕様で冗長性を担保する。

Oracle RACのサポートについて

将来サポートされるかどうかは不明だが、現在RDSではOracle RACはサポートされていない。

これは技術的なハードルというよりもむしろRDSの冗長性に対する考え方によるものなのかもしれない。

Oracle RACのようなActive-Active構成を実現するためには、複数ノードから同時アクセス可能なASMのような仕組みを実装必要があるが、「1つのインスタンスは1つのノードでしか動かさない」という割り切りをすれば、そのような仕組みは不要でありより一般的なファイルシステムを使用することができる。

また、Oracle RACにおいてはノード間通信であるキャッシュフュージョンが発生すると性能が劣化することはよく知られている。

だからノードを増やすスケールアウトで性能を担保するというのは実は難しく、マシンスペックを上げて対応するスケールアップで性能を担保する方が設計上は確実であるという考えにRDSは至ったのかもしれない。

どこまでユーザに変更を許すか

RDSはSSHによりOS領域にログインすることはできない仕様となっている。従ってユーザができることは限られており、逆にユーザの不適切なオペレーションによる環境破壊等を防止する仕組みであると考えても良いのかもしれない。

パラメータもマシンスペック(インスタンスクラス)に応じてチューニングされたものが自動的に設定されるため、ユーザは基本的にパラメータを変更する必要はない。

どうしてもデフォルトパラメータから変更したい場合は、パラメータグループを作成して反映させるようになっている。

考えてみれば、パラメータはデフォルトのまま運用するべきではないと言っていたのは昔の話で、例えばOracleではパラメータの自動チューニングが進化しているので、パラメータを変更してチューニングするという機会はどんどん減っている。

Amazon RDSは使えるか

クラウド環境に大切なデータを預けるのは如何なものか的な考え方は未だに根強いが、十分なコストメリットとセキュリティの妥当性を実感できればRDSのような環境を業務に活用するという流れは加速されるだろう。

私が漠然と持っていた性能面に関する懸念も杞憂に終わるのではないかとさえ思えるほど、RDSの内容と選択の多様性は充実している。

 

Oracle Linux 6.5 on Parallels Desktop for Mac OS

私の商売道具

私は仕事で2年前からMacBook Airを使っています。メモリとストレージを目一杯の8GB、512GBにそれぞれ増設し「Parallels Desktop for Mac OS(以下PD)」でWindows 7を共存させて使っています。スクリーンショット 2014-08-18 13.50.16

共有ネットワークモード

仕事で使うOracle環境はWindows側に構築しているのですが、Parallels Desktopのデフォルトのネットワーク環境は下図(PDマニュアルからの引用)のようになっており、Windows仮想マシンはMacOS側とネットワーク・アダプタを共有しているため(ネットワークについてはあまり詳しくないですが、ポートフォワーディングのような仕組みで実現していると思われます。)、MacOSから独立したサーバには見えていません。

共有ネットワークモード

 

すなわち、Windows側でリスナーを立ててもあくまでもWindows仮想マシンの中で閉じていますので、MacOS上のOracle Clientからの接続要求は受けられない仕組みです。

ブリッジイーサネット モード

仮想マシンを独自のIPを持ったスタンドアロン・コンピュータとして構成できないかということでいろいろ調べた結果、PDではブリッジイーサネット モードという構成が可能ということがわかりました。(PDマニュアルからの引用)

ブリッジイーサネット

これを使えば、仮想マシン上のリスナーで接続要求を受け付けられそうです。

Parallels Desktop上にOracle Linux 6.5をインストールする

この機能を見つけたので、前々からやりたかったOracle Linux 6.5 のインストールをやってみることにしました。(あくまでも検証環境ですので自己責任で行ってます。)

OL6.5上にOracle Databaseを構築して、MacOS上のOracle Client から接続するまでを目標とします。

インストーラのダウンロード

https://edelivery.oracle.com/ からOracle Linux 6.5のインストーラをダウンロードします。

ダウンロードページ

登録したアカウントでサインイン

メディアパック選択

Oracle Linux 6.5を選択

ダウンロード画面

V41362-01(.iso)をダウンロード!

仮想マシンの作成

新規作成の方法はいろいろありますが、仮想マシンリストの(+)ボタンをクリックしても追加できます。

新規仮想マシンの作成

新規仮想マシン

続行をクリック

空の仮想マシンを作成

PDではRedhat LinuxやCentOSのように正式にサポートされているディストリビューションであれば、DVDやイメージファイルを認識してインストールできますが、Oracle Linux は「その他のLinux」に分類されるため、まず空の仮想マシンを作成して後からOSをインストールする形になります。(実際はISOフィアルを認識させますが)

「ソースなしで続行する」にチェックを入れて続行をクリック

OSの選択

OSの選択ダイアログで、他のLinux>その他のLinuxカーネル2.6 を選択

名前と場所

名前は「Oracle Linux 6.5」に変更。「インストール前に構成をカスタマイズする」にチェックを入れて続行

ブリッジイーサネット

ここでブリッジイーサネット モードの構成にします。ハードウェアタブの「ネットワーク1」を選択。

種類を「共有ネットワーク」から「デフォルトのアダプタ」に変更、NICの種類は恐らくこの設定でよいはずです。

CDDVD

CD/DVD1を選択

接続先に先ほどダウンロードしたISOファイルの場所を指定します。

CPUメモリ

DBサーバなのでCUPを「2」、メモリを「2GB」に設定します。

クローズボタンをクリックして、続行をクリック

インストール開始

インストールスタート

一番上(Install or upgrade an existing system)が選択されていることを確認し(Enter)

diskfound2

Tabキーで「OK」から「Skip」にカーソルを移し(Enter)

start「Next」をクリック

言語

言語は「日本語」を選択

キーボード

キーボードは私の場合はUSキーボードを選択しました。

ストレージタイプ

ストレージタイプは「基本ストレージデバイス」を選択

デバイスの適用

ちょっと次に進むのをためらってしまうメッセージですが、あくまでも仮想マシンに割り当てられたディスク領域(PDは可変サイズのファイルが作成されます。)の適用ですので、「はい」を選択します。

ホスト名ネットワーク

ここでホスト名を指定します。(私の場合は「oraclelinux6.onefact.jp」としました。)

下の「ネットワークの設定」ボタンをクリックします。

ネットワーク定義

System eth0 を選択し、編集をクリック。

eth0

「自動接続する」にチェックを入れて適用をクリック

この後、タイムゾーンの設定とrootユーザのパスワード設定が続きます。

パーティションの作成

ストレージ構成

次にパーティション設定をディクスに書き込みます。私はデフォルト選択のままとしました。

パッケージ選択

次はサーバタイプによるパッケージの選択です。Database Serverという選択肢がありますが、これはMySQLサーバのことですので注意しましょう。

「今すぐカスタマイズ」ラジオボタンを選択して次に進みます。

デスクトップ

デスクトップ関連は「X Window System」「デスクトップ」「デスクトッププラットフォーム」「汎用デスクトップ」の4つを選択します。

アプリケーション

アプリケーションは「インターネットブラウザ」を選択します。

パッケージインストール中

インストールが始まります。上記の選択の場合パッケージ数は1047個になりました。

インストール完了

プログレスバーが進んでインストールが完了しました!右下の「再起動」ボタンをクリックしてリブートします。

インストール後作業

インストール後1

インストール後の設定を行います。進むをクリック。

ライセンス情報

ライセンス情報

ソフトウェア更新1

2

3

ユーザの作成

とりあえず全部「oracle」を入力します。

2

日付と時刻

Kdump

完了

oracleユーザでログインします。

端末

やっと完了です!図はターミナルを開いたところです。

次回はOracle Databaseのインストール・構築を行います。

書籍紹介:UMLモデリング入門

UMLモデリング入門UMLモデリングを本質から学ぼうと思って買ったのがこの本です。 UMLモデリング入門(児玉公信著、日経BP)

入門と言いながら全編大学の講義を聞いているような記述が並びますが、そもそも「情報システムとは?」「概念とは?」などの本質に直球勝負で切り込んでいくスタイルはじっくり読みこなしていくと必ず腑に落ちます。

下図は「1-2 情報システムライフサイクル」において、著者が考える情報システム構築プロセスを表したものですが、本書の目的はこの中の「要求設計」で業務のあり方を記述する「概念モデル」であると明確に言い切っています。

つまり施主(情報システムによって利益を受ける人)の漠然とした期待をまとめた原要求に対して、ITによって機能だけでなくビジネス・組織・仕事についても設計し「要求(つまり概念モデル)」を作り上げるという設計者およびアーキテクトの役割を解説する本だという認識を持って読めば自ずと理解が深まるのではないかと思います。(この図をみればアーキテクトとはどのような人なのかがわかるでしょう。)

また、筆者はこの図を使って、アジャイルな開発プロセスとは「設計者=施工者」であり要求設計と同時にソフトウェアの仕様ができることであり、結果として現場の生産性を上げるものであると説明しています。つまり設計することなしの「現場合わせ」の繰り返しはアジャイルではないという言葉は非常に説得力があります。

情報システムライフサイクル.001

単なるUMLモデリングの解説本ではなく、モデリングの本質に踏み込んだ良書です。

ITアーキテクト養成講座

ITアーキテクト養成講座
6月9,16,23,30日の計4日間、日経SYSTEMS主催の「ITアーキテクト養成講座」(場所:東京神田)に参加してきました。

本年(2014年)で5回目の人気講座だそうで、1月22日には システム設計の先導者 ITアーキテクトの教科書 というタイトルで書籍化もされています。講座の中で使用される図表等はほぼそのまま書籍にも使用されていますので、講座内容を事前に知るには書籍を一読すればよいと思います。(ちなみに講習参加者には2日目に書籍がプレゼントされました。)

講師の石田裕三氏は野村総合研究所でITアーキテクトとして活躍されていて、米カーネギーメロン大学で経営学、ソフトウェア工学を学ばれた経験もあるので、特に海外におけるIT事情の話は参考になりました。

参加者は約5名の6つのグループに分けられ、毎回シャッフルされます。(人数の関係で2回同じ人と同じグループになることもあります。)グループ単位でホワイトボードの前で課題を考え、その結果を全体で発表しあうスタイルで進めていきます。議論が進まなかったり発散しそうな状況になった場合は、講師やNRIのアシスタントの方々が適宜各グループを周り適切なアドバイスを与えてくれることもあります。

SIerのアプリケーション・エンジニア、インフラの運用担当者、ユーザ企業で業務要件を検討する人等、参加者のバックグラウンドは千差万別で、東京近辺だけでなく大阪や札幌等遠方からも多数参加しているのには驚きました。(もっともほとんどの人は講習費、交通費は会社持ちなので、私のように自腹で参加している人は接した限りでは見当たりませんでした。その点に関しては羨ましい限りです。)

グループ討議のよい点は、バックグラウンドが異なる人が集まると思いもかけないアイデアに出会えたり、違った視点から物事を観ることができることです。「自分はこのことについてあまり詳しくないんだけど、こういうことなんでしょうかね?」という意見に思わずなるほどと膝を打つようなことが多々有りました。

講座の内容は

  1. 要件定義
  2. 基本設計
  3. 詳細設計
  4. 実装
  5. テスト
  6. 保守

という一連のいわゆる開発(運用)のV字モデルにおいて、ITアーキテクトと呼ばれる人が何をすべきかということを体系的に学ぶことができるものです。

具体的にはPostgreSQLをベースにした高可用性システムの設計という感じで、特にインフラの経験が少ない人にはやや高度な内容に映ったようです。私もアプリケーション開発しか経験していなかった頃にこの講座を受けても消化不良になっていたかもしれません。

ただし、自分ができる領域をもっと広げて行きたいと考える”やる気”のある経験の浅いエンジニアにとってはよいきっかけになる講座だと感じました。

実際、私も昔少しかじったUMLをもう一度根本から勉強し直そうと思ったので、そういう意味でも投資した甲斐はあったと思います。