IT社員3人組によるリレーブログ

某IT企業に勤める同期3人が、日常で思ったことを記録していきます (twitter: @go_mount_blog)

コンテナとは?Dockerは今や必須技術?

どうもkoheiです。

明日、いよいよHUNTER×HUNTERですね

 

ちょうど昨日までGoogleのCloudサービスを中心としたイベント「Google Cloud Next」が東京でも開催されてましたね。

今日は、そのイベントの中でも「セキュリティ」「DevOps」に並ぶ大きなトピックとして取り上げられていた「コンテナ」について書きたいと思います。

 

Google Nextの記事はこちらでもまとめられていましたので参考に

UNIQLOとの協業でもニュースになっていましたね。

ascii.jp

コンテナとは?

 簡単に言うと、アプリケーションなどの実行環境をパッケージングする技術です。

f:id:go-mount:20180921141933p:plain

サーバーの仮想化技術とよく比較されますが、サーバ仮想化は文字通りサーバのハードウェアをソフトウェアで再現している点などが違いとして挙げられます。

コンテナを使うと何がうれしいの?

 コンテナ技術を使うと下記のようなメリットが得られます。

 

メリット:

1. 環境ごとパッケージングされるので、別の環境へまる動かすのが容易

2. 環境の作り直しが容易

3. コードで環境や機能を記述するので、構成把握が容易。

 

難しい感じですが、以下のような問題を解決してくれます。

 

1. 開発環境でアプリ作ったけど、本番だと動かない・・・

 →コンテナ化して運べば環境差分ないので解決!

2. 新しい人が職場に来たので、その人用の開発環境をつくらなきゃ・・・OS入れて、アプリケーション入れて・・・で1日経過

 →コンテナ化して作っておけば数秒で完成

3. 今なんとなく使ってるサーバがあるが、先人が作っていろんなアプリも動いていて、中身のわかる人もいなくなって、もはや謎

 →コンテナの構成ファイル見れば、全部書いてあるよ!

 

さて、もちろんデメリットもあります。

 

デメリット:

1. セキュリティの担保。一つのコンテナで結局同じOSを利用している。

2. 運用監視。これまでのサーバとは異なる方式が必要。

3. statefulな環境(データを永続的に保持する)は不向き。

 

最近は上記のような欠点を補うため、様々なコンテナ管理ツールや、google, IBM, microsoftなどが提供しているコンテナ管理サービスも登場しています。

それはまた別の機会にまとめたいと思います。

 

Dockerの登場

f:id:go-mount:20180921163513p:plain

 さて、こうしたコンテナ技術ですが、最近はdocker社の作った2013年にオープンソースソフトウェアとして公開したDockerを使うのが中心です。

いまやweb業界では、会社がdockerを使っていなければ転職した方がいいと言われるほど必須技術と言われているそうです。

 

www.docker.com

 

実はコンテナ化技術自体は、linuxの機能を組み合わせることで実現できていました。

dockerの優れたところは、コンテナ技術をつかって、アプリケーションをどこにでも運び、どこでも動かせるようになった点にあります。

 

dockerを使ったコンテナ利用までの仕組みを下記の図にまとめてみました。

 

f:id:go-mount:20180921155248p:plain

 

まず、最初にコンテナとして実行させたいアプリケーションや動作環境をdockerfileに記載します。ここで記載された内容を基にコンテナが作られます。Dockerでは、コンテナはdocker imageという単位で扱われ、OS上のdocker engine上で実行されることで環境が構築されます。

このdocker imageはDocker Hubと呼ばれるクラウド上のレポジトリサービス(docker版のgithubですね)で共有し、imageファイルも利用することもできます。

https://hub.docker.com/

 

なぜコンテナがこんなに流行ってるのか?

 先ほどコンテナのメリットで書いた、環境移行が容易なことやコードでの構成管理はVagrant×VMwareなどの仮想サーバ技術でも実現できることは多いです。

しかし、「ユーザへのサービス提供を早める」という点でdockerに優位性がありました。

 

クラウド上でクリックするだけで、サーバ構築ができるようになりましたが

サーバ構築に数十秒~数分、サーバ上のアプリ構築にも数分~数時間かかります。

しかし、dockerならimageさえ作っておけば数秒で完了します。

このスピードの差が、dockerの支持を集めた最初のきっかけと言われています。

 

昔は、サーバ、物品調達が一番長くかかっていました。

昨今は仮想化、クラウド技術の発達により、サーバインフラはクリックするだけで整う時代になりました。

このような時代の変遷を経て、サービス提供にかかるまでに時間的な支配をしているプロセスは

サーバ調達→サーバ構築→アプリ開発へとシフトしていきます。

 

そこでアプリ開発を加速するために

様々なプログラミング言語や開発手法に対応した開発環境整備を高速化する

商用と開発との環境差分を埋める

などのニーズが高まり、結果Dockerというソフトウェアがいまや必須技術とまで言われるようになってきました。

まとめ

さて、ここまでコンテナ技術とDockerについて書いてきました。

今回は省略しましたが、Dockerコンテナの管理ツールであるKubernetesについても今後まとめたいと思います。

 

ではでは

 

 

 

XaaSとは、PRaaSの流れへ

どうも、ITコンサルタントのShoheiです。

今日はXaaSについて少し理解を深めてみましょう。

SaaS/PaaS/IaaSのおさらい

以前、クラウドについて説明した記事で、SaaS/PaaS/IaaSについて説明しました。

これはクラウドに対する基本の分け方で、ユーザに何を意識してもらうか、逆に言うとユーザに何を意識しなくてもいいようにしてあげるかを示すものです。

SaaS(Software as a Service)を例にざっくり絵を描くと以下にようになります。

f:id:go-mount:20180917202151p:plain

SoftwareはもちろんなんらかのHW上で動いているわけですが、プロバイダから提供されているSoftware以下の部分は、意識しないでいいですよ、Software部分だけサービスとして提供しますよ、がSaaSの意味でした。

機能ベースでこの考え方を適用したXaaS

上記のSaaS/PaaS/IaaSは、XaaSのXにSoftware,Platform,Infrastructureを代入したものと理解していればいいのですが、

昨今、XにS,P,Iといった提供領域ではなく、特定の機能を代入したサービスとしてhのXaaSが登場しています。

例をあげていきましょう。全てカッコ内の機能クラウドで利用でき、それ以外の部分は意識しなくてよくなると思ってください。

  • Analytics as a Service (解析・統計を行うために必要な機能)
  • Logging as a Serivce(ログファイル収集するために必要な機能)
  • Ransomeware as a Service (悪質なランサムウェアを開発することなくお金を払えば使える機能 ※犯罪者がこの機能を利用してサイバー攻撃を仕掛けるイメージ)
  • Testing as a Service(検証に必要な機能)

厳密にはそれぞれ上記はSaaSやPaaSなど分類されたりするんですが、明示的にどの機能をクラウドとして提供するかを示すのに以下のようなXaaSと表されてるわけです。

これについて掘り下げるために少しだけ妄想を膨らませてみましょう

さて、少し妄想を膨らませるために非ITの例を出して考えてみましょう。

家政婦の中の、料理と掃除の機能を切り出した料理 as a Service, 掃除 as a Serviceについて考えてみましょうか。

  • 料理 as a Service
  • 掃除 as a Service

今までの例に従っていうと、家政婦部分を意識せず、料理してくれる機能と掃除をしてくれる機能だけ意識すればよいサービスになります。

f:id:go-mount:20180917204717p:plain

言葉を選ばずに言っているので、この例だと「 なんだと、人の部分を意識しないなんて人権侵害だ!奴隷じゃないんだぞ!」と言われてしまうかもしれないのですが、あえてこの例をあげたのは、理由があります。

ユーザから家政婦さんの存在が見えなくなったということは、逆に家政婦さんが存在しなくてもよくなったということです。ユーザから掃除の要望があがった際に、片付いた部屋を納品すればいいのであれば、例えばルンバにやらしちゃってもいいんです。

要するに、提供する機能の裏側でやっていることがユーザからほとんど見えなくなるわけなので、結果がユーザの期待するものになるなら、中の仕組みはどうやってもいい、ということです。

個人的にはこの仕組みがあるからこそ、以下のような流れが進むと思っています。

Professional as a Serviceへ

毛色が違うので、あえて上であげたXaaSの例に含めなかったのですが(クラウド上で提供されるソフトウェアのようなものではないため)、OaaS(Operation as a Service)という考え方をNTTが発表しています*1

これは、ITのOperationについてはサービスとして提供します、ユーザは中身を意識する必要がないよ、というもの。

今までは、Operationをお手伝いします、とプロバイダ側がいうと、どういう人の体制を組んで、どういう監視項目を仕込んで...と細かにお客さんと握っていたのですが、結果だけ提供するサービスとして扱うのであれば、その中身はユーザで意識する必要はありません。

まさに上記の料理や掃除の例と同様で、実際の中身が人間だろうが機械だろうが構わない、というものです。 ※NTTが自動化して結果だけ提供するサービスやってるように思えないけど

こういうのを、個人的にProfessional as a Service(PRaaSとでも呼ぼうか)と呼んでいて(これは著者の造語です)、

このように専門性の求められる機能や、プロにアウトソースしてしまった方が効率的な機能は、どんどんサービス化が進んでいき、人材を育てたりツールを作り込むのではなくのではなく、サービス利用で済ます、という時代がくるのではないかと推察しています。

まとめ

XaaSについて説明し、Professional as a Serviceと称した今後のサービスの流れに関する個人的推察を述べました。

IT系企業あるある10選!!

どうも、Keiです。

明日は3連休明け、地獄ですね。

 

ãæ¥æ¬ã®ããæ¹ã«ç´å¾ããããªããã¤ã人ãã¼ãæ¥æ¬ã®ããæ¹ã«ç´å¾ããããªããã¤ã人ãã¼ããï¼»ã¢ãã«ï¼Max_Ezakiï¼½ã®ããªã¼åçç´ æãæ¡å¤§ 

わたしは現在のIT企業に今月末で、ちょうど3年と6カ月勤務することになります。

 

来月からは転職して別の会社に行くことが決まっているのですが、せっかく3年以上も長い間勤めたので、この3年間を振り返ってあるある形式でまとめてみたいと思います。

 

それではさっそく見ていきましょう!

 

  1. 意外とプログラミングができる人がいない
    大手IT企業のような上流工程を担当する会社だと、プログラミングなど実業務ができなくてもプロジェクトを進めることができるので、特に年が上の方だとプログラミングはできないことが多い。
    個人的には、プログラミングは自分の業務便利ツールみたいな用途でエンジニアは当然使うだろうと思っていたので以外だった。
    運用とか、サーバ構築系とかUNIX使う部署だとまた違うのかも知れないですけどね。

  2. 社内セキュリティと利便性がトレードオフ
    シンクライアント化によるデータの持ち出し防止や、ファイアウォールのURLフィルタリングによって社内のデータを外部から守ることについては他の企業より抜きんでているものの、その代償として欲しいときにデータを見れなかったり、アクセスしたいサイトが見れず、結局スマホで見たりしなきゃいけない。
    そのため、抜け穴を作っている人もいるという噂も・・・

  3. 証明書系の資料に手書きのサインとかハンコが必要
    サインとかハンコとか必要な書類が未だにけっこうあるんですよ。
    年が上の人だと、あきらめて「これ記入しなきゃねーめんどくさいねー」とか言っているけど、ぼくは未だにこの紙文化が嫌でしょうがない。証明書の写しを保存するのもダルい。
    こういうのを無くすのがIT企業である僕らの役目では・・・?

  4. 全員が1つの場所に集まる会議は減ってる
    リモートワークの影響で、働く場所に左右されず仕事ができるようになっているので、会議は電話+ウェブ経由で画面を共有するタイプが多くある。
    対面で会議を行って方が効率がいいからって、他のビルまで出張の予定を入れる人もいるが、できれば電話会議にして欲しいと切に思う。
    カスタマ向かいやプロジェクトのキックオフならまだしも、今やグローバルに相手側の拠点が当たり前に多様化している時代。
    この流れは、システムが追い付いていて非効率にならなければ非常に良いと思う。

  5. 飲み会が少ない
    半年ごとのキックオフや忘年会などシーズンの飲み会以外は基本ない。
    会社に入る前は"新橋のサラリーマンのおっさん"みたいなゴリゴリの先輩を想像していたけど、これはIT系限らないか・・・

  6. 飲むときは半端ない
    飲み会が少ないので、飲むときの量やみんなのテンションがすごい。
    以前、先輩が課長とレスバの末負けて、悔しさからか課長のはげ頭をおしぼりで拭いたそうだが、普通そんなことなります?
    飲み会じゃなくてもいいけど、ガス抜きって必要ですよね。

  7. 腰痛が気になる
    やはりデスクワークがメインになるため、一日中同じような姿勢でパソコンと向き合うこととなる。もしかしたら、生涯で家族より恋人よりパソコンと向き合う時間の方が多いんじゃないだろうか?
    ぼくはイスに姿勢が良くなるようなイス・オンザ・イスみたいなモノを乗せています。

  8. 合コンでの自己紹介がうさん臭くなる
    合コンでも何でも、「自分はIT系の仕事をしていて~」というとめちゃくちゃうさん臭くなりません?
    IT系って広すぎるだろ!詐欺師の常套文句か!っていつも思っちゃうのは僕だけでしょうか?
    誰か良い表現があったら教えて下さい。

  9. 休日にエスカレがあるとすごくブルーになる
    休日は仕事をしたくないのは当たり前だと思います。
    一方でIT系の宿命ですが、平日、休日関係なしのシステムトラブルやカスタマ対応のエスカレ電話はしょうがありません。
    課長やカスタマからの電話があったら最後、逃げられません。
    特に運用などの深夜にたたき起こされる人は枕元に業務用スマホを置いてるんだとか。
    日本のITは彼らのような聖人君主たちに支えられているのですね。

  10. 以外に泥臭い方式や運用方法をとっている
    学生時代は大企業のIT部門は、プロセスや会社の仕組みもしっかりしているんだろうな~と思っていましたが、実際入ってみると、このプロジェクトの技術は〇〇さんしか知らないとか、運用プロセスがきちんと決まっていなく、気づいた人が対応しているよ、とか整理されていないんだなぁと感じます。
    外からはその会社の製品やソフトなど、キレイにパッケージされたものだけを見ているので、勘違いしてしまうのですね。
    しっかり整理しなくてはいけませんが、ITも設計、構築、運用するのは人なので、泥臭い部分も存在しますよね。

 

さて、書いていていろいろとこの3年間を振り返ることができました。

現在、IT系企業に勤めている方も自分はこんな「あるある」があるよという場合は教えて下さい!

ではまた。

プログラミング言語Rって?tidyなデータ分析って?

どうも、koheiです。

スマブラでしずえさん戦!

 

さて、今日はデータサイエンス界隈でpythonに次いで使われているであろうプログラミング言語Rについて触れたいと思います。Rの成り立ちや、最近の流行りも含めて書いていきたいと思います。

  

プログラミング言語R

R logo.svg

R言語ニュージーランドオークランド大学で作られたオープンソースフリーソフトウェアの言語です。

 

データ解析・統計プログラミングが簡単にできるように開発された言語です。

 

近年は、データ解析で使われるプログラミング言語としてpythonが非常に有名ですが、このR言語も肩を並べて利用されている言語です。

 

プログラミング別平均年収ランキングは、最近pythonに抜かれてしまいしたが、

まだ上位に食い込んでいます。

 

www.itmedia.co.jp

Rのメリット&デメリット

ざっくりとまとめると次のような点が挙げられます。

 

メリット

  • もともと学術/研究用途で作られたものなので、数学・統計処理が圧倒的に強い。
  • 「パッケージ」として、世界中の研究者が開発した最新の関数や数式を簡単に利用可能。
  • グラフや結果の描画のライブラリが豊富
  • pythonなどに比べて環境構築が比較的容易
  • スクリプト言語なので、トライ&エラーをしながら対話的なデータ解析ができる
  • 言語がシンプルで学習コストは低い

デメリット

  • システムに組み込んだりするのは不向き
  • 分散処理が必要になるような大規模データ処理は不向き

 

同じデータ解析に利用されるという点で、よくpythonと比較されますが

R→試行錯誤しながら探索的なデータ解析

python→ある程度データが見えた時点で、システム導入を見据えての開発

 

といった使い分けがよく言われています。

 

Rの環境について

下記のサイトからダウンロードしてすぐ使うことができます。

The Comprehensive R Archive Network

 

またRの統合開発環境としてはRstudioが有名です。

www.rstudio.com

 

こちらもフリーで利用することができます。

f:id:go-mount:20180914142930p:plain

(Rstudio公式サイトより)

画面左側がエディター/コンソールになっており、データに対する処理を記述し、結果をこちらで確認します。エディターは補完機能が付いているので非常に書きやすい形になっています。

また、右側は変数やオブジェクトの確認やプロジェクトと呼ばれるソースコードやファイルの管理機能、グラフの確認等も合わせて実行することができます。

 

R言語のパッケージ

世界中で様々なパッケージが近年はtidyverseと呼ばれるパッケージ群が主流で開発も盛んです。

 

tideverseはR界で神のように崇められているhadley wickhamが中心に開発していて、データ分析やそのデータの扱いをもっと「tidy」にしていこうというコンセプトで作られています。

 

www.tidyverse.org

 

「tidy」なデータや分析ってなんやねん、ってなるところですが

ざっくりいうと、ある一定のルールに従って、データを読み込み、統計処理や加工処理をしてもinput, outputも同じ一定の形式になるような処理をしながら分析をする

というプロセスになります。

 

細かいところはこちらのスライドが大変わかりやすいので貼っておきます。

speakerdeck.com

 

tidyverseに含まれるライブラリの中でも有名どころをかいつまんで説明します。

tidyr

f:id:go-mount:20180914150142p:plain

 さまざまなtidy型でないデータを、tidy型に変換してくれる関数が使えるライブラリです。

dplyr

f:id:go-mount:20180914150440p:plain

 

tidy型のデータを絞り込んだり、集計を簡単にできる関数が使えるライブラリです。pythonでいうpandasに近いですね。

ggplot2

f:id:go-mount:20180914150841p:plain

データの可視化を簡単に行うためのライブラリです。

Rの標準のライブラリもありますが、さらに複雑なグラフ描画が可能です。

 

そのほかtidyverseから少し離れますが、便利なパッケージ群

R markdown

f:id:go-mount:20180914151152p:plain

Rとmarkdownを組み合わせてjupyter notebookのような形を作ることができます。

分析結果の取りまとめたレポート作成に便利です。

Shiny

f:id:go-mount:20180914151324p:plain

 ただのレポートじゃ満足できない!という方向けに、webアプリケーションを作れるパッケージもあります。ユーザにwebページとして提供して、パラメータをwebUIで操作してもらいながら分析する。。。といった形を実現できます。shinydashboardと呼ばれる拡張機能も出ているそうです。

 

まとめ

さて、ここまでデータ分析で使われるR言語について書いてきました。

今回書いた内容について、下記の本で詳しく書かれているので参考にさせていただきました。

 

RユーザのためのRStudio[実践]入門−tidyverseによるモダンな分析フローの世界−

RユーザのためのRStudio[実践]入門−tidyverseによるモダンな分析フローの世界−

 

 

最近はpythonの勢いがすさまじくRの勢いが飲まれている感じですが、それでもまだまだデータ分析コンペティションのkaggleでもR言語は使われており、開発も進んでいます。

 

このあたりの開発は非常に盛んなので今後も情報を追っていきたいですね。

 

ではでは

本質理解とMECEアプローチ (ロジカルシンキング入門)

どうも、ITコンサルタントのShoheiです。

今日は、以前読んだ本と、つい最近読んだ本の中で、リンクさせると面白そうな考え方があったので、ご紹介します。

 

①「本質」を因数分解によって導き出す

一つ目は、初回の記事でご紹介した本の中にあった考え方です。

この本は、物事を"大人の学び方"で方法が記載されている本ですが、

その中で、物事の本質を因数分解の形で導き出すやり方/考え方が紹介されています。

「つまり一番大切なのはこういうこと」---自分が得た知識や経験を総動員して、最後にこの一言をひねり出す。これが「本質の理解」です。

因数分解の例を、著書にある例でいうと、以下のようなものがあります。

コンサルティング=仕組む力✖️仕掛ける力 (HRインスティテュート 野口吉昭さん)

上達の論理=まねる力✖️段取り力✖️コメント力 (明治大学だ教授 齋藤孝さん)

(中略)

プレゼンテーション=プレゼンス(誰が)✖️コンテンツ(何を)✖️デリバリー(どうやって伝えるか) 

これ読んだ時、"うーむ、確かに"、と思いました。

何かについて訪ねた時、わかっていない人ほどダラダラダラダラと、結局何が言いたいのかわからない説明をします。

職場にもそういう人がいてイライラします。

一方で本当に本質がわかっている人は、「あ、結局これはこういうことだよ」って端的に中核部分(本質)を答えます。さらに聞くとより深度の高い情報が出てきます。

 

因数分解にいたるプロセスや、因数分解時の注意点については、元の本に書いてあるので、ここでは書きませんが、本質を因数分解によって導き出すという考え方、かなりクールで面白いと思いました。

 

皆さんは自分の仕事や趣味について因数分解できますかね?

ITコンサルってなんだ?山登りってなんだ?歌を歌うことってなんだ?

なかなかちゃんと理解してないと難しいですね。

 

既出ですが、上述の事項が書かれている本を再度紹介しておきます。

プロの学び力

プロの学び力

 

 

 

②グルーピング ---MECEを活かした情報の整理

今度は別の本です。

タイトルの通り、キーワードとしてはMECEとグルーピングが出てくるので、超絶ざっくり説明しましょう。 (詳しく理解するには本読むのが最短です)

 

ロジカル・シンキング (Best solution)

ロジカル・シンキング (Best solution)

 

 

MECEとは

話の重複・漏れ・ずれをなくす技術です。

自部門に入ってくる情報を全体集合とすると、この全体集合は漏れも重なりもないどのような部分集合にわけられるだろうか、と考える。例えば、定期的に入ってくる情報と不定期の情報、一般に公開されている情報と非公開の情報、有料の情報と無料の情報、業界に関する情報とそうでない情報など大別する。

上述よりももっとざっくりな例でいうと、以下のような感じです。

例えば、新商品を売り出すターゲットを決めるのに、"日本にはどんな人間がいますか?"と質問をされたとします。

f:id:go-mount:20180912165909p:plain

MECEちゃんは思いつきで人々をあげていっています。

MECEくんは、人間という全体集合の中を、排他的かつ漏れなく分ける切り口(生物学的な意味では、男と女は被ってない、また人類には男と女しかいない)で、対象をわけています。これがMECEなアプローチです。

 

 

この問いに対する分け方で、他の例をあげると、以下のようなものがあげられます。

・都市部/地方 に住む人

・関東/関西/中国地方/... に住む人

・学生/Worker/学生をのぞく非Worker

 

この問いには使えませんが、以下もざっくりMECEな分け方です。

・質/量

・事実/判断

完全に排他的なものが望ましいですが、多少の重なりは許容することが多いです。完全にわけることが目的ではなく、あくまで論理的考察などの目的を達成するための手段としてのMECEなので。

 

グルーピング

さて次はグルーピング。

グルーピングとは、たくさんの情報が散らばっている時に、MECEな切り口を見つけて、その全体像をつかみやすいように、いくつかのグループに分けることだ。

 例えば、すでにある商品を買ってくれている人々のリストがあったとします。

ここにはどんな傾向があるんだろう、と分析する際に登場する手法です。

例を絵で描きましょう。

f:id:go-mount:20180912171819p:plain

絵の通りですが、MECEくんは顧客をMECEアプローチでグルーピングすることで、散らばった情報から傾向を抜き出しています。

MECEちゃんは、思いつきでリストを眺めて思ったことを言っています。切り口も、"イケメン"と"優しい"という、排他的ではない切り口ですね。

二つの本で言っていることの相関

アプローチや用途は違いますが、①②の本で述べられていることって、強くリンクしてくると僕は思っています。

仕事を理解することを例にとって説明しましょう。

 

仕事を始めると、無限に物/人/コトが現れます。

日々の細々した業務も、普段出会う人との関係性、ミッションも、全てが情報です。

そういった毛色の違う無限の情報を、ちゃんとグルーピングできて、重要なポイントを言葉で抜き出してくることが、上述の本質理解因数分解に繋がるのだと思います。

前の部署では自分はある程度その仕事の本質が理解できていたと自負していますが(3年いてまぁまぁ中堅扱いされていたのでね)、やっぱり本質理解してからは強い。何が重要か見えるし、やるべきことも見えてくる。

逆に本質を掴みきれていない今の仕事は、全てが新しく見えていて、情報がカテゴライズされずにやってくる印象で、体力があります。

 

仕事じゃなくてもこの力は使えます。

よくいますよね、ぶわーーーーーっと無限に無秩序な話を聞いた後、「それってこういうことだよね」とまとめられる人。

これも一種のグルーピングと因数分解だと思います。

そういう人だと、人の悩みを抽出し解決する力も高いのだと思います。

どうやって身につけるかって? それは本を読んで学びましょう。

まとめ

本に書かれている本質理解の因数分解MECE/グルーピングに関して説明し、

それらの相関性に関する意見を述べました。

 

WALKING DEADあるある20選!!

どうも、Keiです。

今回はITブログはお休みで番外編をお送り致します。

 

 

夏。

 

 

そう、ホラーの季節ですよね?

皆さん、しっかりホラー体験していますか?

 

肝試し、戦慄迷宮、ホラー映画・・・などがありますね。

 

僕はというと、アマゾンプライム Videoで見ることができる米ドラマの「WALKING DEAD」シリーズにドハマりしています。

社会人なのに朝4時まで見てしまいました。

朝4時というのがリアルですよね・・・完全にハマってます。

 

ãã¦ã©ã¼ã­ã³ã°ã»ãããã(c)TWD productions LLC Courtesy of AMC/provided by FOX channel

 

WALKING DEADは、平和な町に突如ウォーカー(いわゆるゾンビ)が現れ、世界中にどんどんウォーカーの感染が広がっていく中、主人公(以下リック)が家族や先々で出会った仲間を守るために懸命に生きていくというストーリーです。バイオハザードのような派手なアクションというよりは、ゾンビが本当に現れたらどこに逃げれば生き延びれるか、人々はどう変化するか、などリアルな人間描写が魅力である作品です。

 

さて、そんな僕が今回は「WALKING DEAD」を見てあるあるだな~と思ったことを20個挙げて行きたいと思います。

なるべくストーリーに関わるネタバレは少なくしていますが、ネタバレは絶対に嫌!という方はドラマを見てから帰ってきて下さい。

 

 

 

 

 

 

  1. ウォーカーがグロすぎる
    これは、第1シーズンの1話目から感じましたね。
    皮膚の質感だったり、内臓が出ちゃったり、ドラマとは思えないハリウッド映画レベルのグログロウォーカーが恐ろしい人数登場します。
    グロが苦手な方は最初は厳しいかもしれませんが、毎話1時間グロのオンパレードな訳ではなく、ポイントを押さえて登場するので大丈夫です。

  2. ウォーカーの頭柔らかすぎ
    ウォーカーは、基本的には銃やナイフで頭を刺して殺しますが、足で踏みつけても殺せます。このとき、まるで粘土をつぶしたようにウォーカーの頭が崩れるのですが、こんなにつぶれます?ってくらいつぶれます。
    特にウォーカーに転化(感染した後、ウォーカーになってしまうこと)した直後に柔らかくなるのは、転化に皮膚を腐らせる作用があるのですかね。

  3. 主人公が保安官で良かった
    このドラマでは、ウォーカーがたくさん登場するのですが、主人公リックがことごとく頭を正確に打ち抜いてくれます。
    銃のことはあまりわかりませんが、プロだとあんなにキレイにヒットするものなんですかね?

  4. 他の仲間の銃の上達度もハンパない
    これは緊張感のあるストーリーと重厚感のある映像で、最初は納得してたのですが、民間人だった主人公の仲間や家族も銃の扱いがプロ級になっていきます。
    がんがん、ヘッドショット決めていきます。やはり命がけだと違いますね。
    うますぎるだろ・・・

  5. いきなりウォーカー、ドーンみたいなのはない
    ぼく、ビビりなんでゾンビ映画でありがちな突然ゾンビが画面に入って驚かしてくるのが死ぬほど苦手なんですよね。
    WALKING DEADでは、ウォーカーの「ガサッ」って音がしてからウォーカーが登場みたいな安心安全な作りになっていますので、寿命が縮まる心配はありません。

  6. でもたまにある
    まあ、ゾンビ映画なのでしょうがないですよね。
    結局寿命は縮まります。

  7. やっぱり死亡フラグはけっこうある
    ゾンビやアクション映画につきものなのが死亡フラグですよね。
    逆に今度はどんな死亡フラグなんだ!?ってくらいの楽しみ方もありますよね。WALKING DEADでも死んでいく仲間達は「さよならは言わないよ」とか「絶対みんなでここを切り抜けるんだ!」など死亡フラグを順調に建築します。

  8. 死ぬ描写がないヤツ生きてる説
    これは少年ジャンプとかでもお得意ですが、ウォーカーから食べられる瞬間はカメラが上を向いたり、銃声だけ聞こえるパターンは死んでないことが多いですね。
    逆に、これで死んでいるとズシンと来ます・・・

  9. 夜見ると高確率で悪夢を見る
    僕はWALKING DEADを寝る前にお酒飲みながら見るのが好きなのですが、ほぼ毎回悪夢にうなされます。
    これも寿命を縮めてますね。

  10. 登場人物がお互いわりとシカトする
    WALKING DEADでは、リックを含めみんな残酷な決断を迫られることがあります。答えたくない質問もあります。
    そんな中で、お互い質問や言葉をかけるんだけど答えることができない宙ぶらりんな質問が増えてしまいます。しかし、これは答えられるんじゃないか?って質問もたまにある気がします。

  11. リックはカメラの左上を見つめる
    答えられない質問に対して、リックはアップからのカメラの左上をゆっくり見て、たいてい次のシーンに行きます。
    逆に、左上を見ながら話すパターンだとびっくりします。

  12. 日常音に敏感になる
    身の回りでスズメが動いたり、葉っぱが落ちる音など、ありえないんだけど「ウォーカーか!?」とビビッてしまう。
    ぼくがビビりなだけなんだけど。

  13. ハーシェルを見ると落ち着く
    ハーシェルはシーズン2からリックの仲間に加わった老人で、非常に人格者でリックや仲間が我を忘れたときに、みんなを落ち着かせてくれるぐう聖。
    ぼくも彼には何度も助けられました。

  14. 結局怖いのは人間
    賛否あるかもしれませんが、WALKING DEADでは、人類vsウォーカー以外にも人類vs人類が大半を占めてきます。
    ウォーカーから襲われ、食料や避難場所をいろんなグループが確保しなきゃいけない中で、それをめぐって争いや強奪が起きてしまうのです。
    これは、国によって性質も違うかと思うので是非バチェラーみたいに日本版WALKING DEADも作って欲しいですね。もちろん、低予算でなく。

  15. 見る側に予想させることが多い
    これは、面白いなーとおもったのですが、特に新しいシーズンの第1話目で前のシーズンのラストからリックや仲間の環境がいろいろと変わってたりするんですね。しかも、ドラマ中で特に理由も語られない。
    考えればわかることなのですが、後から見返すとわかることもあるので楽しいです。
    例えば、当然のように豚が飼育されていたりとか。

  16. ローリにストレスが溜まる
    ローリは、リックの妻で第1話でウォーカーの感染が発生したときはリックとはぐれてしまうのですが、その後無事合流します。
    しかし、その間にリックの親友のシェーンと体の関係を持ちます。リックが死んだと伝えられたからですが、切り替え早すぎるだろ!!
    しかも、この後もリックの感情をゆすぶったり、観客をイライラさせます。僕の悪夢の原因にも一役買ってること間違いないでしょう。

  17. ダリルが好きになる
    ダリルは、序盤でリックの仲間になりましたが、凶暴な性格を持つメルルという兄を持ちます。ダリル自身も最初は協調性に欠けるキャラで、チームに悪い空気をもたらした時期もありました。
    しかし、ダリルはだんだんと見違えるようにチームに貢献し、不愛想ながらチームになくてはならない存在となります。
    この「昔はヤンチャしてましたが、守るものができたので自分かわりますっす!」みたいな、ひたむきな姿勢が観客(てか僕)を彼に惹きつけるんですよねぇ。

  18. 自分も戦ってチームに貢献できるような気がしてくる
    子供や女性が活躍しているシーンを見ると、自分だって銃やナイフを使ってチームに貢献するんだって気持ちになりますよね。
    豚の世話でもいいんですよ。

  19. でもやっぱり無理。
    1話ずつ悪夢みるようなヤツに何ができるんだって話ですよね。

  20. 明るい話を聞きたくなる
    やっぱり、ずっとホラードラマを見ていると気が滅入ってしまいますね。
    「友達が結婚した」とか「7日連続晴れ」とかハッピーなニュースが欲しくなります。
    もちろん、WALKING DEADも暗い話だけでなく、その中でたくさんの小さな幸せがありますのでご安心を。

 

さて、いかがでしたでしょうか!

たまにはこんな回もいいですね!それではまた。

知らずに刑事罰を受けそうになった話

こんばんは、haseです。

 

先日新しく入ったプロジェクトでの事。

弊社から一部業務を発注しているグループ会社の社員の方にもっとこうして欲しいという指示を出そうとしたところ、上司からすごい勢いで怒られました。

なんぞ?と思って聞いてみると、「請負契約」だから、とのこと。

 

…え、だから何?

 

と、私と同じ感想を持ったあなた。

要注意です。怒られますよ(笑)

 

しかしこのケース、注意しないと実は笑い事では済みません。いわゆる後述の偽装請負となり、最悪の場合、刑事罰に発展する可能性もあるんです。

 

ちょっと指示しようとしただけでなぜそんなことになるのか。

そんなIT業界(だけではないですが)で陥りやすい「派遣」「出向」「請負」に関する勘違い・トラブルについて、今日はまとめていきたいと思います。

 

IT業界の社員事情

 現在、全労働者に占める派遣社員の割合は、2~3%で推移しています。しかしIT業界、というより弊社に限って言うと、体感的には半分は派遣社員の方なのではないかというレベルです。実際私が以前いたプロジェクトのチームでは、5名中3名が派遣社員の方でした。周りのプロジェクトを見回してもほぼ同じような事情のようです。(派遣社員の方は基本的に役職はつかないので、全体でみると割合は下がると思いますが、現場では相当数の派遣社員の方が活躍されています。)

 

ITという業界は、基本的に正社員だけでは回らない場合がほとんどです。システム構築ではプロジェクトベースでの受注が多い関係上、リソースの変動が激しく、派遣社員の方や外部発注に頼るケースがほとんどです。また運用業務についても、業務委託するケースが多く見られます。

IT業界においてはそれだけ派遣や請負というケースに触れる機会が日常的にあることになります。

 

契約形態の違い

上記でも少し触れましたが、正社員以外の方にお仕事を依頼する場合、IT業界では「派遣」「出向」「請負」のケースがほとんどです。

まずは大まかな違いをまとめると、下記表のようになります。

 

契約形態 雇用元 指揮命令関係  就業場所
派遣 派遣会社 派遣先 派遣先
出向 出向元 出向先  出向元と異なる
請負 派遣会社or請負業者 派遣会社or請負業者  雇用元と異なる場合もある

 

派遣・出向

https://res.cloudinary.com/bizhint/image/upload/f_auto/oldimages/000/002/411/content/c7afa24407e76a2cbd5d6b3b7dc1a873cb2d3136.jpg

https://res.cloudinary.com/bizhint/image/upload/f_auto/oldimages/000/002/411/content/c7afa24407e76a2cbd5d6b3b7dc1a873cb2d3136.jpg

 

まずは派遣・出向についてです。

ここから先は発注側=派遣・出向・請負として労働力・成果物の提供を依頼する側、受注側=派遣会社など労働力・成果物を提供する側として話を進めます。

 

上記は派遣契約の図になりますが、発注側として注意すべきポイントは「指揮命令関係があるかどうか」です。

その点において、派遣・出向には大きな違いはありません。雇用元は受注側となり、受注側は発注側に対して「労働力」を提供します。 

 

提供されるのは労働力のため、契約によって業務内容に制限はあるものの、その「労働力」をどう使うかについては、発注側が決めることができます。つまり、業務に関して口出ししても問題はない、というより管理する必要があります。そして残業をさせた場合も、契約に従って残業代が発注側より支払われます。

 

請負

次に請負の場合です。

https://res.cloudinary.com/bizhint/image/upload/f_auto/oldimages/000/002/407/content/df23a96b7e1123bf0a9b38584423da3bc77fc64c.jpg

https://res.cloudinary.com/bizhint/image/upload/f_auto/oldimages/000/002/407/content/df23a96b7e1123bf0a9b38584423da3bc77fc64c.jpg

 

 請負の場合にもっとも異なる点は、発注側に指揮命令をする権限がないということです。つまり、請負契約をしている方に対して、私のように指示を出してしまうと違法になります。

 

なぜそうなるのか。

それは、請負において受注側が発注側に提供するものは「成果物」だからです。「労働力」ではありません。

発注側は、提供を依頼した成果物の作成過程について口を出すことはできません。それはあくまで受注側の責任にて行われます。そのため受注側の労働者がいくら残業をしようが、発注側は残業代は出しません。

 

例えば…

makotoロボットというものをhase株式会社(発注側)が作りたいとします。

 

これを派遣で実現しようとした場合、hase株式会社は派遣会社Arisa(受注側)に対して、Satoさんをください!という依頼を行います。基本的にはhase株式会社で一緒にロボットを作り、一緒に頑張った時間だけ対価を支払います。

https://cdn-ak.f.st-hatena.com/images/fotolife/W/WorldWorldWorld/20170406/20170406231945.png

https://cdn-ak.f.st-hatena.com/images/fotolife/W/WorldWorldWorld/20170406/20170406231945.png

 

 

一方請負となると、hase株式会社は派遣会社Arisaに対して、ロボットの腕を40,000円で作ってください!という依頼をします。ですので、Satoさんがどれだけ頑張って腕を作ったかにかかわらず、40,000円を支払います。

https://cdn-ak.f.st-hatena.com/images/fotolife/W/WorldWorldWorld/20170406/20170406232042.png

https://cdn-ak.f.st-hatena.com/images/fotolife/W/WorldWorldWorld/20170406/20170406232042.png

 

偽装請負

ここで、派遣か請負かというのは、契約ではなく実態で判断されます。

つまり、請負契約にもかかわらず発注側が作業指示をしている場合、「偽装請負」として刑事罰の対象となる可能性があります。

 

では、なぜ偽装請負をしてしまうのか。

それは、請負契約としてしまえば残業代を支払う必要がなく、かつ労働災害や業務指導、必要な設備の準備などの請負労働者に対する責任を回避することができるからです。

 

これは現代の奴隷と言っても過言ではなく、IT業界の闇の一部を担っていると言っていいでしょう。

 

最後に

IT業界にはこの偽装請負というものがはびこっているとよく耳にします。

意図して偽装請負をしている場合は早く労働局に見つかることを願うばかりですが、もし私のように意図せずこのケースに該当してしまっている場合は、怒られる前にぜひ契約内容の見直しを。

 

私のような人間が生まれないことを願っております。

ではでは。