「今さら聞けないPaaSとは? IaaS、SaaS、DaaSとの違い」

教育課題としております日経SYSTEMSですが、10月号で纏めたい事項がありませんでしたので、日頃から整理したかったことを纏めて、紹介します。

「今さら聞けないPaaSとは? IaaS、SaaS、DaaSとの違い」

———————————————
PaaS ・・・ ”Platform as a Service”「パース」
———————————————
サービスとしてのプラットフォーム

開発に必要な
・ネットワークなどのインフラ
・OSなどのプラットフォーム
をインターネット上で使用できる。
⇒ 電気・水道などのインフラがそろった、ショッピングセンターのテナント

メリット:必要な環境がすでに揃っているので、プログラムを作ることに集中できる
デメリット:環境をカスタマイズするのは難しい

Google App Engine(Google Cloud Platform)
Microsoft Azure(マイクロソフト・アジュール)
Heroku(へロク)
IBM Bluemix

———————————————
IaaS ・・・ ”Infrastructure as a Service”「イァース」「アイアース」
———————————————
サービスとしてのインフラ

・仮想サーバ
・ハードディスク
・ファイアーウォール
などのインフラを提供
⇒ 土地だけを借りてお店を作る方法

メリット:アプリ・プラットフォームをかなり自由に開発できる
デメリット:開発には専門的なスキルが必要

Google Compute Engine
Amazon Elastic Compute Cloud
Xサーバーなどのレンタルサーバー

———————————————
SaaS ・・・ ”Software as a Service”「サース」
———————————————

⇒ 以前のお店が残した設備がある居抜き

メリット:全てのサービスがウェブ上で使えるので、開発のスキルや手間なく使える
デメリット:すでに用意してあるサービスなので、自由度は低い

Gmail、Yahoo!メール
Google Photo
無料ブログサービス

———————————————
DaaS ・・・ ”Desktop as a Service”
———————————————

パソコンのデスクトップ環境をクラウドでつくって、
インターネットを通じて利用するサービス

メリット:全てのサービスがウェブ上で使えるので、開発のスキルや手間なく使える
デメリット:すでに用意してあるサービスなので、自由度は低い

Microsoft Virtual Desktop
IBM Smart Business Desktop
Citrix XenDesktop

日経SYSTEMS 7月号より ~エンジニアのためのらくらくプレゼン術~ 「誰でも図解マスターになれる図形の意味と3つの関係性」

プレゼン資料は、システム構成図やフロー図に加え、概念的なことも図解できるようになると、資料の分かりやすさが高まる。
  ↓
プレゼン資料の図解で求められるのは「表現したい事柄から要素を抽出し、丸や四角形の図形で表し、位置や矢印で図形間の関係性を示す。」ということだけである。
  ↓
あらかじめ図形のパターンを用意し手置き、表現したい内容に沿ってパターンを選べば、素早く効果的な図が描ける。

■図形や矢印の特徴を押さえる
 何となく図形を選ぶのでなく、表現要素の概念と図形の特徴を合わせる。
   
 ・「組織」のように、実在し線引きできる概念は「四角形」
 ・「市場」のように、抽象的な概念は「楕円」
 ・「矢印」は、面積の大小で変化の大小を示す。
  「白抜き」はビフォー&アフター、黒塗りは因果や影響を与える関係

■関係性を位置で表現
 図形間の関係性の表現では、「相関」「流動」「構造」のパターンを利用
 すること。
  

 ①「相関」は「集合」「因果」「位置」に分けられる。
  ・「集合」は、抽象的な概念の関係性を表現する。
   
  ・「因果」は、線や矢印で論理的な原因を細分化し、要因を集約させる。
   「ロジックツリー」「フィッシュボーン(特製要因図)」など。
  ・「位置」は、縦と横の軸で区分したエリアに図形をマッピングして、
   図形同士の位置関係を表現。「マトリックス」ともいう。
   

 ②「流動」は「展開」「手順」「循環」に分けられる。
  ・「展開」は、成長や発展を表現する。
   良くなっていくことを表現するには、左下から右上へ。
  ・「手順」は、「フロー図」や「アプローチ図」と呼ばれ、左から右に
   時間が進んでいくイメージで図形を並べる。また「フローチャート」や
   「ガントチャート」のように期間をバーの長さで表現する方法もある。
  ・「循環」の典型はPDCAサイクル。正の循環は時計回りで安定感を、
   負の循環は反時計回りで不安定な印象を与える。
   

 ③「構造」は「階層」のみ
  ・「階層」は、ピラミッド型、組織図型、レイヤー型で表す。
   ピラミッドは上から下への広がりがあるもの、組織図は名の通り、
   レイヤー図はネットワーク構成のようなものに使用する。
   

こうした関係性のパターンを作成したものをストックしておき、いつでも使えるようにしておくとよい。

TypeScriptネットワークプログラミング

本書はもともと、TypeScriptを勉強するつもりで読み始めたが、TypeScriptの説明よりも、サーバ/クライアント形式のアプリ開発手法について重点が置かれている感じがした。
しかし、ネットワークアプリの開発にも興味があったのでそちらの方が勉強になった。

TypeScriptについてだが、いくつもあるaltJSの中でTypeScriptはJavaScriptの上位互換となっているため、部分的にTypeScriptの機能を使えることが特徴的である。
取り合えず使いたい機能だけを使っていくということで入りやすいと思えた。

ネットワークアプリの開発については、クライアント/サーバモデルの他、P2Pモデルの説明もあり、TypeScriptを使ったネットワークプログラミングについて、その基本的なところにポイントを絞って詳しく説明されていてわかりやすかった。

また、Node.jsの使い方についても説明があって、ネットワークアプリの入門書としても読みやすかった。

日経SYSTEMS 5月号より ~エンジニアのためのらくらくプレゼン術~ 「PCをいきなり使うのはダメ 倍速で資料を作る3つのコツ」

資料を作成する時、いきなりPCでプレゼンソフトを起動していないか?これは、時間を無駄にしている可能性がある。理由は、図形の色使いなど本質から外れたことに意識が向きやすく、時間を浪費しがちである。

構想をしっかり決めてからソフトを操作した方が効率よく資料を作成できる。また、資料も分かりやすくなる。

■作業の細分化

・「情報収集に30分」「仮説打診に30分」というように作業を細分化すると、隙間時間を有効活用できる。

■プレゼンのシナリオを下書きするストーリーボードを使用

・全体の大きな流れを考え、章分けする。
その後、各章の下にスライドの下書きを配置する。
ストリートボードは手書きが良い
プレゼンソフトで作ると細部に意識が傾きやすい。

■ストーリーの考え方:相手の状態を「不」で考える。

①「不信・不適」ステージ
「なぜ注目されるのか」「なぜ必要か」という重要性の訴求
②「不要・不急」ステージ
「なぜ今これを採用すべきか」という緊急性の訴求
③「不経済」ステージ
経済性を問われるので、他の技術や製品に対する優位性を示す。
④「不安」を払しょくするステージ
あなた自身や所属企業の実績・信頼性

■声に出して流れを確認する

・説明しにくいところは、流れに無理があったり、余計な情報が混ざっているから。
・手戻りが大きくならないように、ストーリートボードを作成した時点で話してみる
・事実の説明だけではなく、その解釈や結論まで一連の流れで話す
・できれば、資料なしで人に話してみる

日経SYSTEMS 4月号より ~実践 クラウドの正攻法~ 「SaaSからIaaSへ向け検討 移行可否は分岐で見極め」

今年度の教育課題として、日経SYSTEMSから気になった記事を纏めることにした。

日経SYSTEMS 4月号より
~実践 クラウドの正攻法~
「SaaSからIaaSへ向け検討 移行可否は分岐で見極め」

クラウドを試したら本格的稼働につなげる流れが定着しつつある。その中で問題なのは「オンプレミス環境で構築してきたIT資産をどうやってクラウドへ移行するか」だ。

■多様化するクラウドプラットフォーム

【IaaS】
・ゲストOSから上のレイヤーに当たるミドルウェアやアプリをオンプレで稼働していた状態のまま持っていける。
・既存システムの運用基盤を流用、また運用向けに開発したツールやPGMを再利用できるケースが多いので、運用管理者にとっても、クラウドを利用した運用業務を習得しやすい。

【CaaS】
・ITグループ全体で利用すべきコンポーネントを定義し、DevOpsやInfrastructure as Codeなどに基づいた仕組みと合わせて、従来の仮想サーバーより少ないリソースで、アプリを複数の環境に即時に配布する基盤として使われる。

【FaaS】
・実行する処理を登録しておき、サーバーをスケールアウト形式で起動、実行、停止する。これにより、季節で急激に変動するトランザクション量が増えるケースでも対応しやすい。
・トランザクション量のピークに合わせて高スペックのサーバーを用意しておく必要がない。

■SaaSからIaaSに向かって検討する

・クラウドの利用者側では、Saasから検討を始める方法に変化している。開発対象が少ない順にプラットフォームを検討し、最後にIaaSでしか動かないアプリのみIaaSに残す。

IaaSにより、ハードのコスト、保守要員の人件費を削減できる。しかし、ミドルウェアやアプリの領域は、オンプレと同じような保守が必要なので、コスト削減とはならない場合がある。

・オンプレとクラウドを併用するハイブリッドへの理解も進んできた。両社の長所が活かせる反面、両者を保守する必要があり、コスト増となる場合もある。

■非機能要件や稼働率も考慮

============================
★クラウド移行に向かない条件
・バッチ処理で、クラウドベンダーが提供していないCPU数やメモリー容量、高速なストレージを必要とする処理
・高可用性を実現するために、HWでクラスター構成を構築しているシステム
RAID構成を取っていて、HWと同等の性能が必要なストレージ
・ドライバーが物理サーバー上でしか動作しない、または仮想サーバーで動作保証されないAP
・特殊な装置の近くにあり、属地性、保全の観点から即時性を求められるシステム
・業務システムにおいて、99.95%以上の稼働率を求められるシステム
・障害発生や性能劣化発生時、エンドー・ツー・エンドで原因追及を即座に求められるシステム
・業務に必要とされるサービスレベルをクラウドベンダー側で保証できないシステム
============================

■クラウドの利点を享受するアーキテクチャー

目的はコストに限らず、アプリを含むシステム全体を柔軟に変えていき、ビジネス推進に貢献する狙いもある。キーワードは以下の3つ。

【リキッド】
アプリ機能をモジュール化し、各モジュールを軽量な機構によりAPI化連携する。その際、再生可能なコンポーネントやクラウドのサービスを積極的に活用する。

【インテリジェント】
システムの高度な自動化を実現し、ルーチンやタスクを削減し、効率化を図る。

【コネクテッド】
ビジネスパートナーや顧客を巻き込んだエコシステムを作り、IoTと接続し、アプリの相互接続性を向上させる。

■デジタルとレガシーの依存性を排除

オンプレからクラウドへは一気に移行せず、段階的に進めることが必要。「デジタルカップリング」という方法論が参考になり、12のステップからなる。
============================
★デジタルカップリング
・ドメイン定義
・インターフェース、(マイクロ)サービスの識別
・データコントラストの定義
・サービストとエンドポイントの定義
・ビジネスロジック疎結合化/移植
・イベントの定義
・同期/非同期フロー
・新アーキテクチャー定義
・新アーキテクチャーのPoC(概念検証)
・ファクトリー構築
・スケール
・組織再編とコミュニケーションの統合
============================

教育課題:日経業界地図2017 55~59

バイオ燃料。
稲わらからエタノールを取ることは知っていましたが、
タピオカ残さかから燃料を取るのは初めて知りました。
面白いです。サッポロビーールがタイで行っているそうです。

北九州にいるからか、エコに興味があります。
バイオ燃料がエコでできると、なおさらイイですね。
業界地図_55-

教育課題:日経業界地図2017 1~15

日本経済の様子を、業界別に示した「業界地図」。
この180に渡る分野の勢力状況を紹介する。

業界の動向、代表的な企業の名前を記憶する前に、分からないキーワードがいくつも。1カ月に立てた目標は、想像以上に時間を要することが分かったが、頑張る。

成果物として、業界シェアを纏めたものを紹介する。
業界地図_1-15

教育課題図書「最強の働き方」第四章

第四章 一流のリーダーシップ

◎誰に対しても丁寧に接する
 ◆タクシーで偉そうにしない
   順位で対応を変える人は大成しない。
 ◆謙虚に頭を下げるから稲穂が実る

◎信頼を大切にする
 ◆信頼を失うリスクにナーバスになる
   どれほど人に信頼されているかが、リーダーシップのサイズを決定する。
 ◆賢い嘘つきより、バカ正直が出世する。
   失敗した時の対応が透明で正直であってこそ、「信頼回復のリカバリー
   ショット」を打つことができる。
 ◆仕事相手の長期的利益を尊重する
   信頼と人を大切にし、相手の利益を尊重する姿勢が長期的信頼を築く。

◎部下を尊重する
 ◆部下に敬意を表する
   部下を尊重する企業文化は、組織力を強める上で、強烈なパワーを発揮する。
 ◆冠婚葬祭の対応で、人間関係が大きく変わる
   仕事のコマとしてでなく、人間として尊重していることを示そう。

◎部下に得をさせる
 ◆部下の市場価値を上げる
   部下の自己実現を助け、その市場価値を高めよう。
 ◆カネを払ってでも、部下に面白い仕事をさせる

◎部下を成長させる
 ◆日陰の仕事もきちんと評価する
 ◆ザルの上司にならない
   簡単にはごまかせないという緊張感が、部下を育てる。
 ◆成長させてくれた上司への忠誠心は強い
   会社を辞める時、誰が一緒についてくるか?部下と客を連れて辞められる
   かどうかで、勝負は決まる。

◎規範を背中で示す
 ◆上司の背中を見て、部下は育つ
   リーダーのコミットメントが部下のモチベーションの源泉
 ◆先陣を切って出陣しない大将には、誰もついていかない

<所感>
昔、別の会社に居た20代後半の頃、強烈な上司がいて、大きな影響を受けました。
それはたぶん私だけでなく多くの人がそうだったと思います。それは私の直属ではなく、ましてやよその部署の方でした。それを上司と呼ぶのは、自分を育ててくれたと思っているからです。

その人の優れたところを上げるとキリがありませんが、関心したのは、会社問わず、自分のプロジェクトに関わる人全て、その人の成長を考え、そのために労を惜しまない姿勢でした。ですから、こちらも真剣勝負です。個人の成長を促しつつ、大儀であるプロジェクトを完遂する、それはどれほど大変なことだろうと思います。

しかし強烈なカリスマゆえに、耐えられず辞めていく部下もいました。また、そのカリスマを軽く操るそのまた上もいたようです。長い会社生活の中で、いろんな人と巡り会い、いろんな上司も部下もいます。その中で「この人と一緒に仕事がしたい」という上司に巡り会うのは運だと思いますが、そう思われるのは、努力できることではないでしょうか。

教育課題図書「最強の働き方」第三章

第三章 一流の心構え

◎主体的に動く
 ◆上から降ってくる仕事は当然つまらない
   好きな仕事は、自分で探し、やったモノ勝ちである。
 ◆面白い仕事に自発的に取り組む
   受け身の姿勢では仕事の幅が狭まり、自分の強みを発揮できない。

◎先見の明をもつ
 ◆プロアクティブに動く
   将来起こりうる事象を想定し、長い時間で考えられる人は強い。
 ◆石橋を叩いて渡らず、叩き割る二流にならない
   ライバルより先に動けるアーリ-ムーバーが、慎重すぎる完全主義者を打ち負かす。

◎仕事の質にこだわる
 ◆お土産ひとつにも徹底的にこだわる
   仕事の細部にこだわる人が、勝負に勝つ。
 ◆哲学・美学のある仕事をする

◎危機感をもつ
 ◆自分の仕事を「より安く、より速くできるライバル」の存在を忘れない  
 ◆チャンスはいくらでもあると、油断しない
   賢いのに一流になれない人の特技は「油断」である。

◎期待を上回る
 ◆給料とポジション以上の仕事をする
   満足したビジネスパートナーや顧客の口コミで、仕事や責任が大きくなる。
 ◆会社にレガシーを残す
   会社を去ったあとに残るもので、あなたの真の価値が決まる。

<所感>
面白い、やりたい仕事に自発的に取り組むのは良いことだが、そうでない仕事を
やらねばならなくなった時、モチベーションを下げずに続けることも、相当な
力がいると思った。それには、組織ということを理解すること、そして、自分に
任せられた仕事の期待に応えようという気持ちを持つことだと思う。そしてそれを
乗り越え、仕事を全うした時、きっと自分には予想しない力がついてると信じる。
それはたぶん、好きな仕事を意欲的にすることでは得られない力のような気がする。

自分の仕事の哲学、そして美学。ITという明確な答えのあるデジタルな世界でも、
拘りを忘れない、自分らしい仕事を心がけることは必要と思う。