【徹底比較!】CTO vs VPoE!両者の違いからそれぞれに求められる役割まで分かりやすく解説します!

会社の組織体系のトップに位置するのはCEOですが、技術部門のトップに位置する人のことをCTOと呼びます。更にこの技術部門の中を見て見ると、CTOを中心として、VPoEやVPoPなど様々な役職が有ります。本記事では、そんな開発の現場で良く混同されるCTOとVPoEの2つの役職をピックアップし、両者の違いから、それぞれに求められる能力などをご紹介します。

 

CTO

 

CTOとは?

 

 

CTOはChief Executive Officerの略で、日本語では最高技術責任者と訳します。その名の通り技術部門のトップとして会社の経営に参加し、 経営視点で技術部門を指揮する立場になります。

技術部門の方向性や開発方針の舵取りをする責任者という重大な役割を持っていますが、会社法によって設置を義務付けられたものではありません。そのためあくまで会社によって決められた役職ということになります。

情報技術の発展によりどこの会社でも技術部門を設立するようになり、CTOという名前が付けられることが一般的になりました。

 

VPoE

 

VPoEとは?

 

VPoEはVice President of Engineerの略で、日本語では技術部門のマネジメント責任者と訳されます。

VPoEはエンジニア組織が円滑に仕事をできる環境や、開発を行えるべく技術力を向上させるために採用や指導、環境改善などを行うことによってチームのマネジメントを行う役割を担っています。

主に欧米などでは以前からVPoEの役職は一般的でしたが、日本でもメルカリやSpeee、Gunosy など多くの会社でVPoEのポジションが設置されており、確実に浸透しつつあります。

CTOは聞いたことがあっても、 VPoEは初めて聞いたという方もいらっしゃるのではないでしょうか。

 

CTOとVPoEの違い

 

 

CTOは開発や技術方針の舵取り、VPoEは組織のマネジメントという説明をしましたが、その言葉通り両者にはエンジニア部門での責任者という共通点と課題解決と組織マネジメントという相違点があります

CTOもVPoEもエンジニア組織の責任者として、それぞれの役割を全うする責任を持ちますが、CTOは経営の視点に立ち、会社が今後仕事を継続・発展していくための技術的方向性や開発方針を導く必要があります。一方でVPoEはCTOが打ち出した方針に対してエンジニア組織の能力をアップさせるために新たな人材を入れたり、能力向上のために環境を改善したりなどのマネジメントを行う必要があります

 

CTOに求められる役割

 

経営面から見た技術的な意思決定

 

 

営利企業でも、日営利企業でも会社の利益を今以上に向上させるにはどのような施策が必要か?という課題に対して常に模索する必要があり、技術部門はそのための開発を続ける必要がります。

エンジニアが闇雲に新サービスを開発したり、システムを導入したりしても会社にとってそれがプラスになるかと言われると分かりませんし、技術は高くても会社がターゲットにしている顧客ニーズにはマッチしていない可能性があります。

そういった問題を回避するためにCTOは、会社としての方針や顧客ターゲットからニーズを汲み取り、エンジニア部門に対して目指すべき開発の道筋を示す必要があるのです。

 

VPoEに求められる役割

 

エンジニアチームのパフォーマンス向上

 

 

VPoEは会社としてエンジニア組織の能力を向上させるためにマネジメントを行う役割を持ちます。より端的に言うと使えるエンジニアチームの育成を行うことが命題となります。

基本的に会社の方針はCEOやCTO含め、会社の上層部が行う役員会議で決定づけられます。その中でCTOが指針した方針に対してVPoEは実現可能なレベルにエンジニアのチームビルディングを行います

そのための仕事は多岐に渡り、新たな人材を迎い入れるための採用や育成、働きやすい環境づくりなどチームを強化させるという目的の元あらゆる手段を利用します。

 

多部署との連携

 

 

VPoEは会社の営業や人事、法務などのトップとの連携を上手く図ることも大切な役割です。

お互いの現状や、希望を理解し合いそれを上手くチームに伝えることで循環する環境作りが出来ます。

それぞれのチームが日々仕事に追われてくると目の前の仕事に手一杯で他のことに手が回らなくなる状況が来ます。

そういった際に上手く指示を送れる立場として多部署と円滑な話し合いが出来るコミュニケーション能力が求められます

 

ゲームデザイナーを徹底解説!気になる年収から求められるスキル、プランナーとの違いまで幅広くご紹介します!

スマートフォンが発達して、より気軽にゲームを遊べるようになりゲーム市場は盛り上がりを見せています。そんなゲームを作成するときに必要な職種にゲームデザイナーという仕事があることをご存知ですか?今回はゲームデザイナーとはどんな仕事で、どんなスキルが必要なのかについて詳しく紹介していきます。

 

ゲームデザイナーとは

 

 

ゲームデザイナーとは、言葉通りゲームのデザインをするお仕事です。

大きく分けると以下2種類となります。

 

・CGデザイナー

ゲームにおけるステージやキャラクターを作るお仕事となります。アニメーションや背景グラフィック、デモムービーなど機能に合わせたデザインを心掛ける必要があります。

・UI/UXデザイナー

スムーズなゲーム「体験」を行ってもらうことを目的にデザインを行います。タイトル・メニュー画面の作成、ボタン・アイコンなどの最適化、フォントや文章などを中心にデザインしていきます。

 

以上が一般的に「ゲームデザイナー」と呼ばれて思い浮かぶものだと思います。ただ他にも挙げるとするならば、デザインとは元々「設計」や「意匠」という意味を持っているので、キャラクターなどのデザインだけにとらわれずゲーム作品全体の企画・構成を作っていく仕事でもあります。ゲームシステムや世界観など0からゲームを作っていきます。

「ゲームデザイナー」と一口に言っても業務内容が多岐にわたることは覚えておいていいかもしれません。

 

ゲームデザイナーは売り上げに大きくかかわる仕事

 

 

ゲームデザイナーの仕事は非常に重要です。

なぜならどんなに企画のゲームであっても、全体のバランスや世界観が良くないとお面白いゲームを作ることができないからです。

 

暇つぶしにやるという単純なゲームも増えてきていますが、ハマるゲームというのは感情移入することができたり、非日常を経験することができるゲームです。

ゲーム全体のバランスが悪いとプレイしていて違和感が出てきて感情移入しにくいですし、世界観が陳腐だとのめりこむことができません。

ゲーム作成はゲームデザインナーから始まる仕事なので、設計の良し悪しで売れるか売れないかというのは大きく変わってくるのです。

 

ゲームプランナーとの違いは?

 

 

ゲームデザイナーの仕事を調べているとゲームプランナーという仕事をよく見かけます。

ゲームプランナーはゲームをプランニング(立案・企画)する仕事なので、ゲームを0から立案し企画を作っていく仕事なので企画から完成まで携わります。

つまり、ゲームの全体的な設計をプランニングしていくわけです

 

先ほど言った通りゲームデザイナーはゲームをデザイン(設計・意匠)する仕事でもあるので、ゲームの骨組みを設計してため当然企画立案にかかわっていきます。

しかし、ゲームデザイナーは基本的には「CGデザイナー」「UI/UXデザイナー」が主な業務となるので、被る部分はあったとしても、基本的には違うものと捉えて問題ないでしょう。

 

ゲームデザイナーの年収は?

 

 

そんなゲーム作りにおいて非常に重要なゲームデザインナーの仕事ですが、やはり目指すならどれくらい稼ぐことができるのかというのも気になりますよね。

 

転職会議が統計を取っているデータからは、ゲームプランナーの平均年収は378万円だと言われています。

世代別だと20代前半は平均323万円・20代後半は平均355万円・30代は平均426万円・40代以上は平均406万円となっています。

しかし、これはあくまで平均年収であってこれ以上稼いでる方もいれば稼げない方もいます。ゲームデザイナーはゲームの核を作る仕事なため売り上げに直結する仕事なので、評価が分かりやすいです。

参考:https://jobtalk.jp/salary_matome/jobs/129

 

【徹底比較!】フロントエンド vs バックエンド!両者の違いから必要なスキル、将来性まで分かりやすくご紹介します!

フロントエンドやバックエンドといった言葉は主にWebサイトの製作現場でよく使用されます。言葉を直訳すると分かるようにWebサイトの製作には大別すると前と後ろで大きく2つに分けることができます。本記事では、フロントエンドとバックエンドの違いから、必要なスキル、将来性などをまとめてご紹介します。

 

フロントエンドとバックエンドの違い

 

まずは両者の違いを説明

 

 

本記事を紹介する前に、フロントエンドとバックエンドの違いを最初に簡単に説明します。

フロントエンドはユーザーが見ているWebサイトの見た目の部分を製作するエンジニアで、バックエンドはそれをサポートする裏側の部分を担当するエンジニアのことを指します。

ユーザーがマウスやトラックパッドを利用してWebサイトを閲覧、動的なクリックができる設計を行うのがフロントエンドエンジニア仕事で、ログイン情報の入力や会員登録などを行える環境やそれらの情報を元にデータの保存や処理、呼び出しといった裏側の処理を行うのがバックエンドエンジニアの仕事です。

 

フロントエンド

 

フロントエンドとは?

 

 

前項でフロントエンドとは一般的にWebサイトの視覚的な部分を担当するエンジニアのことを指すと説明しました。

これは具体的にいうとクライアントが作成したいWebサイトのデザインを元に、HTMLやCSS、JavaScriptといった言語を使用してユーザーが視覚的にWebサイトを閲覧出来るよう状態にします。

また、スマートフォン、PC、タブレットなど様々なサイズの電子機器があるためそれぞれに合わせたサイズ設定(UI)や使いやすいデザイン性(UX)を求められることが多いです。

 

バックエンド

 

バックエンドとは?

 

 

バックエンドとは、一般的にWebサイトの目につかない裏側の部分を担当するエンジニアのことを指しています。

案件に応じてサーバーサイドやデータベースの要件定義や設計・開発、運用保守などをおこないます。そのため、会員情報登録やクレジットカード決済など個人情報のデータ管理など、ユーザー毎に別の見た目を形成する必要がある場合に特にバックエンドエンジニアが必要になってきます。

 

両者に必要な能力

 

フロントエンドエンジニアになるために必要な能力

 

 

フロントエンドエンジニアになるには、ウェブページを形作るHTML・見た目を良くするCSS・動的な要素を加えるJavaScriptの3つの言語知識が必要不可欠です。

基本的にはこれらの開発言語を知っていないと視覚的かつ現代的なWebサイトは製作することができないためこれらの知識は最低限必須になっています。

更に多くの場合で、これらの言語を使用した枠組み(フレームワーク)を合わせて利用しています。これは、よく使われる機能や見た目を枠組み化して簡単に実装できるようにしもので、CSSの見た目を良くするBootstrapがよく利用されています。

また、必須ではありませんがデザインに対する知識もある程度持ち合わせておいた方が良いでしょう。クライアントによってはデザイン案の一部をフロントエンドエンジニアに投げることもあります、そのような場合に自身である程度デザインできればより歓迎されるフロントエンジニアになるのではと思います。

 

バックエンドエンジニアになるために必要な能力

 

 

バックエンドエンジニアになるための必須能力として、バックエンドの開発言語とミドルウェアの知識が必要になります

Java・C++といったコンパイラ言語、もしくはPHP、Ruby、Pythonといったインタプリタ言語を習得しておく必要が有ります。後者の方がプログラムの実行速度が速いため多くの企業が後者を採用しています。

それと同時によく利用される処理部分を枠組み化したフレームワークが開発言語にもあり、Ruby on Rails やCakePHPといった言語別のフレームワークも合わせて習得しておいた方が良いでしょう。

またハードウェアとフロントエンドエンジニアが製作したアプリケーションを繋ぐためにはミドルウェアという補完ソフトウェアを組み込む必要があり、その知識も必要です。例えばWebサイトの情報を送受信させるApacheやデータベースを管理するためのMySQLは多くのWebサイトで使用されるため習得しておくと歓迎されます。

 

大規模なWebアプリケーション開発になると、共同で作業を分割して行うことも増えてきます。そういった場合はバージョン管理ツールのGitHubを利用することが多いため、これも学んでおいた方が良いです。

 

SREに関して徹底解説!これまでのシステム運用との違いからDevOpsとの違いまで分かりやすく解説します。

近年なにかと話題になるSRE。Googleが提唱したエンジニアの役割であるSREは今までのシステム運用のやり方、そしてDevOpsとはどのような違いがあるのかについては、未だにわからない人も多いです。SREによってどのようなメリットを得られるのか、そしてどういうものなのかについて今回は解説していきます。

 

SREってそもそもどんなもの?

 

Googleが提唱したエンジニアの役割

 

 

なにかと最近話題になるSRE。言葉では聞いたことがあるものの、果たして自分たちには関係があるのか、そう考えていませんか。実はSREを知っておくことで、システム運用において生産性と信頼性を良くすることができるのです。

SREというのはGoogleが提唱したエンジニアの役割です。サイト、信頼性、エンジニアリングの3つの頭文字をとってSREと名付けられています。現在ではGoogle以外にも様々な企業で採用されていますが、それでもまだ実際に採用している企業は少ないです。

 

開発者にとって理想的な運用チーム

 

SREと従来のシステム運用やDevOpsとどう違うのか、という疑問を持つ人も多いはずです。SREと従来のシステム運用の違いは、開発担当が運用チームを依頼するかどうかです。SREの場合は、開発担当が自分たちの理想を実現するために、自分たちで運用チームを設計しようという思想から生まれています。

これにより開発者の理想通りに運用が行われ、作業効率はもちろん、信頼性や運用面において確実で柔軟なシステム運用が実現できます。SREがどのようなことをするか、そしてSREによってどんなメリットが生まれるのかについては後ほど解説します。

 

従来のシステム運用の仕組み

 

開発担当と運用担当は別物

 

ではそもそも今までのシステム運用とはどのような仕組みだったのか、ということについて説明していきます。基本的にはシステムを開発する開発担当と、開発されたシステムを安定的に稼働させるための運用担当というチームが存在します。

そして、それぞれのチームというのは独立しています。つまり開発担当はひたすら開発を、運用担当はひたすら安定的なシステムの稼働に努めていたということになります。これが従来のシステム運用の仕組みなのです。

 

開発担当と運用担当の食い違い

 

 

しかしこの従来のシステム運用というのは、最近になって徐々に減ってきています。一体なぜなのでしょうか。その理由は開発担当と運用担当が異なるチームの場合、どうしても新機能の導入などの部分で不都合が起こってしまうためです。現代のような速いスピードで動く社会において、従来のようなシステム運用では遅れを取ってしまいます。

システムというのは日々新しくなっています。開発担当は日々新しい社会の流れに対応すべく、機能などを追加したりしています。しかし運用担当はあくまで安定した稼働に重点を置いています。そのためもしも新しい機能を実装するとなると、場合によっては不具合などが発生してしまいます。そうなってしまうと運用担当の負担も大きくなるため、どうしても開発担当と運用担当の間に亀裂が生じてしまいます。

 

DevOpsって何?

 

開発担当と運用担当が連携してソフトウェアを作ること

 

 

開発担当と運用担当の間に亀裂が生じてしまっては、システムの進化は到底不可能になってしまいます。そこで登場した手法がDevOpsです。こちらは開発の時点で開発担当と運用担当が連携して開発をする手法です。これによりシステム運用などの部分において、大幅な生産性の向上をすることができました。

開発担当はシステム開発をする時点から安定した運用に重点を置いたシステム開発をすることが可能になり、そして運用担当も実際に運用させた上での改善点などを伝えることが容易になりました。結果的にどうなるのかというと、システム運用などの部分において柔軟性が生まれ、新機能の実装なども容易に行うことができるようになります。

 

生産性向上と穏やかな人間関係

 

 

DevOpsによるメリットは柔軟性が生まれるだけではありません。DevOpsは密接な連携を実現させるために、様々なツールを用いて自動化を取り入れます。自動化を取り入れることによって、従来のシステム開発よりも大幅に作業効率が向上します。

また、開発担当と運用担当が連携するには、コミュニケーションも重要になります。お互いを尊重し、そして支え合うことをしなければ開発が進みません。そのためDevOpsで開発をすることにより、穏やかな人間関係を構築した状態で作業を進めることができます。

 

【徹底比較!】仮想化 vs クラウド!両者の違いからこれからまで分かりやすく解説します!

皆さんはクラウドサービスを利用したことがありますか。世の中には多くのクラウドサービスがありますが、それらのサービスを実現するためには仮想化という手法が採用されています。本記事では、仮想化とクラウドの違いやそれぞれの特徴、実際にビジネスとして採用されている例などをまじえて分かりやすく説明します。

 

仮想化

 

仮想化とは

 

 

仮想化とは、物理的なリソースを複数に分割したり、それを統合したりして使用できるテクノロジーの事を指しています。

例えば一台の物理的なサーバーは安価なものでも高性能な物が多く、どんなに利用しても10~30%程度しか使わず残りの70%はアイドル状態で使用されていないケースが殆どです。

そういった場合に一台の物理的なサーバーを分割して複数の仮想サーバーを作成する事で、資源の無駄を省こうというものです。

 

仮想化の特徴

 

 

仮想化を行うことで、下に記載されている3つの利便性を実現することが出来ます。

 

・システムの無駄をなくす

仮想化についての冒頭部分でも説明しましたが、多くの物理サーバーはその性能の数十%しか使用していません。仮想化の発想が始まる前は一つのアプリケーションに対して一つの物理サーバーを用意することが一般的でしたが、サーバーの性能をフルに使っている企業は少なくシステムリソースの無駄を指摘されていました。

仮想化を行うことで残りのサーバー性能を分散し、別のサービスで利用することでシステムリソースを無駄なく使用することが可能になり、コストの削減にも繋がります。

 

・システムを自由に分割・統合出来る。

仮想化の大きな特徴として、システムリソースを複数に分けるだけでなく、統合することも可能になりました。これにより、複数の物理サーバーの一部を結合し、仮想のサーバーを作成することで拡張性を高めることが出来るようになります。

 

・リスクを分散することが出来る。

複数台のシステムを分割して仮想のサーバーを作ることでシステムのダウンリスクを低減させることが出来るようになります。

例えば一台のサーバーでアプリケーションを動かしていた場合にサーバーが何らかの故障や不具合でダウンしてしまうとサービス全体に影響が出てしまいます。しかし、10台のシステムを複合した仮想サーバーを使用している場合、一つのサーバーがダウンしてもその影響は10%程度と限定的になります。

 

仮想化の種類

 

 

仮想化について主にサーバーをメインに話をしてきましたが、サーバー以外にもストレージやネットワーク、アプリケーションといったリソースを仮想化する事もできます。ここではそれぞれの仮想化について簡単に説明します。

 

・サーバーの仮想化

サーバーの仮想化は、一台の物理サーバーを分割し複数の仮想サーバーを作成することができます。

 

・ストレージの仮想化

ストレージの仮想化は、一台の物理ストレージディスクを分割し複数の論理ディスクを作成することができます。

 

・ネットワークの仮想化

ネットワークの仮想化は、一つのネットワーク回線や機器を仮想化することで複数のネットワークを構築することができます。

 

・アプリケーションの仮想化

アプリケーション仮想化は一つのアプリケーションを仮想化することで複数のサーバーで使用することが出来ます。

 

クラウド

 

クラウドとは

 

クラウドはユーザーがストレージやソフトウェアを用意しなくても、インターネットに繋げるだけでサービスを必要な時に必要な分だけ利用することができるサービスです。

これによりユーザーは、サービスを動かしているコンピューターや接続方法などを意識しなくても簡単にサービスを利用することが出来るようになりました。

 

 

クラウドの特徴(メリット)

 

クラウドサービスを導入するメリットとして、以下の様な利便性を実現することができます。

 

・サーバーを用意する必要がない

クラウドが誕生するまでは、ユーザーがサービスのソフトウェアを購入し自分のサーバーにインストールして使用する必要がありましたが、クラウドサービスの場合は提供しているサービス元がサーバーを用意しており、ユーザーは自社でサーバーを用意しなくてもインターネットに接続するだけでサービスを利用できる様になりました。

 

・メンテナンスが不要

ソフトウェアのアップデートや不具合に対するメンテナンスなどは全てサービスの提供元が行ってくれるためユーザーは更新作業を行う必要がありません。

 

・どこでも利用できる

インターネットに接続する環境さえあればどこでもサービス使用することが出来るため、端末や場所を選ばずどこでも利用することが可能になります。

 

【徹底比較!】Sier vs SES!2つの違いはそもそも何?業界事情から将来性まで徹底解説!

企業などで扱うシステムというのは、ただ導入すれば良いというわけではありません。要件定義から始まり、開発が終わったとしてもその後の運用や保守も必要になります。その企業がシステムを導入する際に出てくる言葉が、SierとSESです。どちらも似たような業種ですが、今回はその両者の違いを様々な視点で解説します。

 

Sierとはどういう仕事?

 

複数のシステムをまとめる企業

 

 

企業の業務の効率化には、システムは必要不可欠です。しかし、企業がシステムのみを購入した場合、そのシステムを管理する人や何か異常が起きた際の保守のために、その分野に精通している人員を確保しなければいけません。そこで多くの企業がシステムを導入する際に利用する企業のことをSierといいます。

システムと言っても、単一で稼働するものばかりではありません。場合によっては複数のシステムを一つにまとめて運用することもあります。Sierというのはその複数のシステムを統合してシステムを開発したり、また運用や保守までを一括して請け負う企業です。

 

システム開発から保守まで一括で請け負う役割

 

Sierの良いところは、システム導入からその後の保守までを委託することができるところです。これにより企業は、システム導入のためにわざわざ余計な人員を確保する必要もありません。その分会社のコストも低く抑えることが可能になります。

システム開発から保守まで請け負うとなると、Sier側の仕事というのは多岐に渡ります。システムの要点定義から始まり、実際にシステムを開発したり複数のシステムを統合するなどして開発をすすめます。場合によっては運用保守も任されることもあります。

 

SESってどういうもの?

 

必要な期間や人数に応じてエンジニアを雇うサービス

 

Sierに似たような企業やサービスは、他にもSESというものが存在します。基本的にSierとSESは業務内容としては非常に似ていますが、SESはSierとは大きく異なる点が一つだけ存在します。それは、システム導入が主な目的ではなく、あくまでエンジニアを雇うという部分が主な目的となります。

なぜエンジニアを雇うことがメインになるのかというと、エンジニアを雇うことで、システムの開発や運用保守などの部分において柔軟に対応することができるためです。例えば一定の期間だけ開発のためにSESを利用し、その後の運用や保守などは自社の社員などに任せる、というようなことができるのは、SESだからこその強みです。必要な期間に必要な人数だけエンジニアを雇う、これがSESの主なスタイルです。

 

派遣と混同されがち

 

 

先程の説明を読むと、あることに気づくはずです。それは、ただ単にエンジニアを雇っているのであれば派遣と同じなのではないのか、ということです。確かにこの説明だけを読むと、派遣契約と似たようなスタイルです。実際にエンジニアのみを派遣するという部分では、通常の派遣会社と同じです。

しかし、あくまでSESというのは、派遣契約のようでそうではありません。これは後ほど説明しますが、指揮命令権がどちらにあるのかという部分が、派遣会社と異なります。基本的にSESの場合、クライアントとは派遣契約ではなく請負契約をするのが一般的です。派遣契約と請負契約の違いは、この指揮命令権がどちらにあるかです。

 

SierとSESの違い

 

SierとSES、業務内容は似ていますが企業が欲しているものによって異なっているということを説明しました。実はそれ以外にもSierとSESでは違いがあるのです。

 

報酬の対象となるもの

 

 

Sierの場合は、開発から運用保守まで一括して請け負っています。とはいえ、あくまで企業が欲しているものはシステムそのものです。つまりいくら開発から保守まで一括請負したとしても、実際にその報酬となるものは、開発などに携わった人ではなく、システムなどの成果物が報酬の対象となってきます。

一方でSESの場合は、一定の期間や人数に応じてエンジニアを雇うことをメインとしています。その間にシステムを開発したり運用や保守などを任せるなど、企業によって依頼することは様々です。システムそのものではなく、あくまでエンジニアを雇っているだけということになるため、SESの場合はエンジニアの勤務時間がそのまま報酬となるのです。

 

システム導入を依頼する企業の負担

 

SierとSESで提供するものが異なるということは、それだけシステムに関することを依頼するときの企業の負担も異なるということなのです。企業によっては、IT関連の部署が無いという会社もあれば、きちんとIT関連の部署がある会社もあります。また、同じIT関連の部署がある会社でも、あくまでシステムの運用や保守がメインとなるところもあれば、開発から運用保守まで万能にこなすことができる部署など、会社の部署の人員によっても異なります

企業が新しいシステムを導入する際、まずは自社の人員を元に検討します。そしてSierを使うかSESを利用するかを決めます。自社にIT関連の部署がない場合はSierを利用することで、余計な人員を確保することなく安定したシステムを手に入れることができ、SESについても自社のIT関連の部署の足りない部分をSESで補うということもできるのです。

 

SierとSESの業界事情を見てみよう

 

Sierで得られるチャンスは規模による?

 

Sierと言っても、依頼された会社の規模によってどのような規模のシステム開発を請け負っているかで、Sierそのものの規模も異なります。当然大きな会社のシステム開発などを請け負っている企業であれば、それだけ大きなシステム開発に携わることができるため、エンジニアなどを志望している人にとっては、きちんとした知識や実績などを身につけることができます。

企業にも大企業と中小企業があるように、Sierにも規模によって大小様々あります。中小Sierの場合は、独自のシステム開発案件を取る他にも、大規模なSierの請負をするということもあります。同じSierでも、会社の規模によっては得られるものも大きく異なるというのが現状です。

 

SES偽装請負問題

 

先程SESについての説明をした際、派遣に似ているようで実は全く違うということを説明しました。そしてその説明の中で、派遣と大きく異なるのは指揮命令権がどちらにあるのか、ということを説明しました。請負契約の場合、基本的に指揮命令権はクライアントではなく請負した事業主になります。今回のSESの場合は、指揮命令権はクライアントではなくエンジニアを送り込んだSES会社にあるということです。

しかし実際は多くのSES会社でこの部分を理解していない会社が多く、指揮命令権がクライアントにある状態が多いです。このような状態の場合、労働者派遣法においては偽装請負ということになり、法律上NGとなります。当然このことが発覚した場合、厳しい罰則を受けることとなります。

 

SierとSESの行く末やいかに

 

物事を捉える上でいい点だけでなく多面的に捉えることで、より客観的な判断が可能になります。

将来性についてもしっかり抑えておきましょう。

 

Webマスターってどんな職種?仕事内容からWebディレクターとの違いまで、徹底解説します!

Webマスターという職業をご存じでしょうか。名前だけだと具体的に何をする仕事なのかわかりにくいですよね。本記事では、Webマスターの仕事内容や必要なスキルを紹介します。また、Webマスターに似ている職業のWebディレクターと何が違うのかを実際の仕事内容や仕事の立ち位置を比較しながら解説していきます!

 

Webマスターとは?

 

 

Webマスターとは、Webサイトの運営と管理を行う職業です。ただし、実際にはWebマスターの仕事は明確に定まっておらず、会社の規模やサイトの種類によって変わります。

基本的には、サイトの情報更新、メンテナンス、コンテンツの編集、サイトの管理などが主な仕事です。

さらに、規模の大きいサイトになると、リニューアルや宣伝の際の販売業者とのマネジメントも仕事に含まれます。

 

サイトの目標を達成する役割

 

Webマスターは、運営しているWebサイトのかかげた目標の達成(会員登録、資料請求、商品の販売など)を目指します。

Webマスターはこのような目標を達成するために必要な仕事を滞りなく完遂する役割を課せられます。

 

サイトの目的や規模に応じて必要なスキルは異なる

 

先ほども説明したようにWebマスターには、明確な仕事内容というものはありません。そのため、必要なスキルや経験などもわからず、サイトの目的や規模に応じて企業の求める人材が異なります。

 

Webディレクターとは?

 

 

Webディレクターとは、Webサイトを作成するプロジェクトを監督する責任者のことを指し、クライアントからの要望に適したWebコンテンツを作成することが仕事となります。

Webディレクターの仕事は、スケジュールの管理、コンテンツの管理、プロジェクトメンバーの選定、クライアントの要望の聞き取りなど様々です。

 

プロジェクト全体の指揮をとる役割

 

WebディレクターはWebライター、Webプランナー、SEOエンジニア、Webデザイナーなどのプロジェクトメンバーをまとめ、意見を聞き、コンテンツの作成を滞りなく進めることが重要となります。

他にも、必要に応じてプロジェクトメンバーに対して、指導や指示を行うこともあります。

 

幅広いスキルが求められる

 

Webディレクターは、プロジェクトの進行、予算を管理するスキルを始め、コミュニケーションスキル、リーダーシップが求められます。

さらに、直接作成に関わりませんが、プロジェクトメンバーに指示を出すために最低限度のプログラミングやSEO、デザインの知識なども必要です。

 

Webマスターの具体的な仕事内容

 

 

WebマスターはWebサイト全体にかかわるため、仕事内容は多岐にわたります。以下が一例ですが、大まかな仕事内容です。

 

商品の仕入れと準備

 

・商品の仕入れと価格の設定

・仕入れ先ルートの交渉

・ラッピングや梱包の資材収集

・宅配業者との交渉

・代金回収、クレジット会社との交渉

・レンタルサーバーの選択

・マーケット調査

 

商品の販売促進・サイトの更新

 

・季節/目的に合わせた商品のキャンペーン計画

・商品.キャンペーンページ作成とアップロード

・掲示板やお問い合わせの対応

・SEO対策

・サイトにアクセスした顧客の動向分析

 

【徹底比較】転職理由 vs 志望動機!両者の違いから、履歴書への書き方や面接での話し方まで解説します。

転職理由と志望動機は、明らかに違うものであると認識することが重要です。転職理由と動機を混同していると、履歴書への書き方や面接における話し方にまで無意識に出てしまうのです。そこで今回は、混同しがちな転職理由と志望動機の違いを確認しながら、転職における履歴書の書き方や面接での話し方を解説します。

 

転職理由とは

 

 

転職理由とは、新しい職場や職種への転向を決めた理由です。例えば以下のような理由が考えられます。

 

・もっと高い給与を望みたい

・職場の人間関係に問題があった

・職場の体制に不満があった

・転勤をしたくない

・今の職種以上にやりたいことが見つかった

・基本的な技術を身につけたので、更に上流工程を経験したい

 

これらは全て、現職種や職場から離れて、自分の仕事に対する望みを叶えたい欲望で、転職する理由は基本的に、居場所やポジションを変える動機です。

転職を決意した理由には、ポジティブな内容が含まれないことも多いと思います。それは、今よりも良い条件を求めて転職を決意するのですから、当然ですね。

 

志望動機とは

 

志望動機と転職理由はリンクする部分がありますが、志望動機はこの企業なら思い描いた仕事ができると確信した理由です

例えば、転職する理由が「もっと高い給与を望みたい」や「職場の人間関係の問題」であったとしても、これらは転職先にその企業を選んだ動機にはなり得ません。

転職する理由となった原因を取り除くために別の企業を選ぶのですが、転職する理由をそのまま志望動機と捉えれば、それは“前の企業でなければどこでも良い”などといった考え方になってしまいます。

転職を決意したあとに、自分の望む条件に合った企業を探します。そして多くの企業の中から“その企業”を選んだ理由、“その企業でなければならない理由“こそ志望動機として明確にすべきことなのです。

 

転職理由と志望動機の明確な違いを意識する

 

転職理由と志望動機の明確な違いを意識すれば、前の会社でなければどこでも良いという気持ちを、志望動機にするという失敗を避けられます。

 

・転職理由:その他の企業を広く選ぶ決意をした理由

・志望動機:一つの企業に興味を持った明確な動機

 

より良い職に就くために視野を広げて企業をリサーチし、自分が求める条件を持った企業に興味を持つ流れですね。

 

履歴書への書き方

 

自分をプレゼンする

 

 

転職活動の中で、自分自身が望む企業を見つけたら、なぜその企業に注目したのかを書き出しましょう。

良いと感じた企業に対して志望動機を書くときには、あなたの経験はその企業で、どんなふうに役に立つのかをプレゼンする気持ちで書くことが大切です。

「前職が自分に合っていなかった」や「より高い給与を得たい」などの理由は、自身が転職したい理由にすぎず、その企業に興味を持っているとは言えません。

その企業で、自分が如何に実力を発揮し、企業の何に貢献できるのかを明確にするのが大切です。これはいわば、自分自身を売り込むプレゼンなのです。

 

経歴や経験は自分の武器と認識する

 

 

その企業でどのような働き方ができるか、その企業で何ができるかは、自分が培った自身の経歴や経験が武器となります。

全く違う分野へ転職する際にも、過去の経験で役に立つものが必ずあります。それら全ては志望動機に絡めることができます。

むしろ、これまでに得た知識や経験を活かし、満足できる仕事をしたい思いこそ、立派な志望動機となるのです。その企業をじっくりとリサーチし、自分自身の武器をどのように使いその企業で働くのかを考えてください。

ただし、これは自分自身を企業に捧げるという観点ではなく、その企業で自分が、納得のいく仕事ができることを証明する観点が含まれているのです

 

質問させる書き方

 

 

履歴書は、面接の場でも活用されます。そして、面接官が履歴書を見ながらあなたと対峙します。その時、面接官が知っていることは“履歴書の情報”だけですよね。面接の際には、履歴書に記載されている事項を中心に面接が進みます。

履歴書の志望動機に全てを詰め込んで書いていると、暗記したものを読むだけになってしまいますので、動機の記載は大まかな要点だけを記載しましょう。そうすれば、面接官もあなたに対して“もう少し知りたいこと”が出てきます

“あなたについて知りたい”と思わせることは、自分自身のプレゼンにとっては第一歩となります。

 

単体テストと結合テスト比較!技術的な違いからメリット・デメリットまで解説します。

システム開発で重要なのがテストです。システムの納品に至るまでには、ユーザーが望む機能が果たされていることや、エラーになってもシステムが止まらない作りになっているかを慎重にテストする必要があります。今回は、テストの中でも「単体テスト」と「結合テスト」について、技術的な違いやメリットとデメリットを交えてかいせつします。

 

単体テストとは

 

モジュールの動作テスト

 

 

ITシステムは、数々のプログラムの塊が集合することによって実現されています。ひとつひとつのモジュール(プログラムの部品)がしっかりと機能することで、システムとして成り立つのです。

自動車に例えるなら、ドアやタイヤなどの各パーツです。これらパーツのサイズや形が設計と違っていれば、組み立てても乗れない自動車になってしまいます。

システムも同じで、これらのモジュールひとつひとつに欠陥があれば、システムは動かない、あるいは誤動作を起こしてしまいます。

システムのモジュールに関しても、結合する前にモジュール単体でのテストを行います。ひとつひとつをしっかりとテストしておくことで、工程の手戻りを無くすことができるのです。

 

結合テストとは

 

モジュールを合わせた機能テスト

 

 

結合テストではモジュール単体でのテストをクリアしたモジュールと、その他外部モジュールを結合した状態でテストを行います。

自動車に例えると、本体やドア、タイヤといった部品をそれぞれ繫ぎ合わせ、設計通りにドアが開くのか、タイヤが連動して回るのか、それぞれに歪みがないかなどのテストです。

システムにおける結合テストも、モジュールを連携させた場合に、設計通り動くのか、あるいは想定外のオペレーションでのエラーでも、システムが止まることがないか(エラー処理や例外処理が入っているか)などをテストします。

結合テストを行うことで、ユーザーの業務に耐え得るシステムであることを確認します。

 

テストにも仕様書が必要

 

テストにも「テスト仕様書」が必要です。それは、テストパターンやその意味、テスト結果や原因までを記録していきます。

テストパターンでは、パターンに漏れがないように、全てのパターンを洗い出します。そして、パターンごとの結果も全て示しておく必要があります。

パターンについては、全てを網羅する必要があり、パターン漏れは許されません。ですので、ほとんどの場合マトリクスの表を作成します。

テスト仕様書は、ほとんどの場合作り手以外の人が読むことになります。他人が読み、実行することを意識して、読みやすく分かりやすいフォーマットと表現にしなければなりません。

テスト仕様書は、システムのテストが終了した後にも利用されるものです。何かしらの不具合が生じた時に、テスト仕様書を見ながら“問題のパターン”がテスト時点でどのような結果だったのか、また、どのようなアプローチでテストされたのかを確認し、根源を洗い出します。

単体テストや結合テストなどのテスト工程において、最も重要なモノがテスト仕様書なのです。

 

単体テストと結合テストの技術的な違い

 

単体テストではモジュールのプログラム把握が必要

 

 

単体テストで必要とされる技術は、その機能に特化した動作を把握していることと、動作するプログラムを熟知していることです。

単体テストでは、システムで使われる機能が細分化されたモジュールが完璧に機能していることを確認しなくてはなりません。

変数に入るべき値や、考え得る例外処理に至るまで、あらゆる角度からモジュールの機能をテストしますので、そのモジュールがどのように使われるのかを把握しておかなければなりません。

 

結合テストはモジュールを繋げた時の全体の把握が必要

 

 

単体テストを終えたモジュールを組み合わせた状態でテストを行います。この時必要な技術は、システムの全体的なデータの流れの把握です。

モジュール同士が繋がっているということは、システムに必要な機能は揃っているということで、ユーザーが行うオペレーションに近い動作で検証します。

モジュール単体では完璧に動くものでも、それらを結合すると不具合が起きる可能性があります。それはデータの受け渡しや、予期しないオペレーションによる例外処理などです。

また、結合テストでは、システムのセキュリティに及ぶまでを考慮してテストをする場合もあります。ですので、その業務に必要な技術の全てを把握しておくことも大切なのです。

 

単体テストを行うメリットとデメリット

 

メリット:ひとつのモジュールに特化して徹底したテストができる

 

 

単体テストを行う目的は、バグの無い完璧なモジュールを完成させるためです。そして単体テスト工程を行うことで、モジュールをしっかりとテストできるメリットがあります。単体テストが終わったモジュールの信頼性は高くなければなりません。

信頼性の高いモジュールを組み合わせることで、システムが機能するのです。結合テストにおいて、単体テストの信頼性はなくてはならないものなのです。

 

デメリット:コストがかかる

 

 

テストというイメージから、誰でもできてすぐに終わるという意識を持っている人が少なくありません。

しかし、単体テストでは、しっかりとシステムを把握しておかなければなりませんし、そもそも単体テストは非常にコストがかかるのです。

テスト仕様書やテストケースの作成でも工数がかかりますし、実際の単体テスト中にバグが見つかれば、その調査と改修を行わなければならないからです。

単体テストを見積もる際には、コーディングよりも大きなコストがかかることを意識しておかなければなりません。

 

結合テストを行うメリットとデメリット

 

メリット:品質が高まる

 

 

単体テストで信頼性のあるモジュールを結合しテストを行います。単体テストをクリアしたモジュールも、結合テストの段階で機能的な不具合や仕様バグが見つかることも少なくないのです。

結合テストで出た不具合は、最悪の場合モジュールの改修という手戻りを起こしますが、結合テストでモジュールバグや仕様バグといった致命的な不具合を洗い出すことが大切なのです。結合テスト経たシステムは、より品質を高めたシステムとなります。

 

【徹底比較!】UI vs UX!両者の違いから関係性まで、具体的な事例とともにご紹介します!

PCが普及したことにより、UIという用語は一般的になりました。そして近年ではUXという用語を合わせて頻繁に聞くようになりましたね。技術の進化とともに、ユーザーと仕組みを繋ぐUIは、より魅力的なデザインが求められています。そこで今回は、UIとUXの違いを確認しながら、その関係性や具体的な事例を紹介します。

 

UIとUXの違い

 

UIはユーザーと仕組みを繋ぐ

 

 

 UIはUser Interface(ユーザーインターフェース)の略称で、コンピューターや技術などとユーザーを繋ぐポジションを担います。特にPCやスマートフォン、公共のシステムなどを含むコンピューター操作の窓口です。

UIは、そのシステムの機能をユーザーが思い通りに利用するために、メニューに沿った画面遷移や、実行するためのボタンなどを設置します。

UIに一番重要な機能は、システムを使って目的を果たすために、できる限り分かりやすく、そして使いやすく設計することです。

 

UXはユーザーの体験

 

 

UXはUser Experience(ユーザーエクスペリエンス)の略称で、技術やモノを利用したユーザーの”印象に残る体験“を表します。モノを利用した時に”これが欲しかった“と思わせるデザインやUIなど、リピートしたい体験を提供するのがUXです。

一度使ったら離れられない使い心地や、また利用したくなるUIデザインは、ユーザーの喜びや、その時の状況にマッチしたものです。

安全面を考慮して利用すべきモノには、デザインやUIでユーザーを安全な利用方法へ導きます。これもまた、UXデザインによって実現されるのです。

 

UIとUXの関係性

 

UIUXで洗練される

 

 

UIとUXは、その目的とデザイン性から、非常に密な関係性を持っています。UXをデザインする上で、それを表現する舞台がUIになるからです。

ユーザーにモノを使った体験を提供するために、UXデザインを行います。それは、見た目であったり感触であったり、あらゆる感覚でオペレーションを体験してもらわなければなりません。そのためには、UIの在り方からデザインする必要がありますので、UXデザインはUIの設計にまで影響を及ぼします

また、UXはユーザーの状況や期待値を考慮してデザインされ、それがモノのUIとして可視化されますので、製品の普及にとっても重要な役割を果たすのです。

 

UIの具体的な事例

 

CUICharacter User Interface

 

 

CUIは、文字列を使ってコンピューターを利用するためのUIです。全てをキーボードだけで操作し、命令コマンドだけでプロセスを実行します。

映画やドラマなどで、IT技術者のスペシャリストやハッカーが、黒い画面に向かってものすごいスピードでコマンドをタイピングするシーンを見かけますが、その画面がCUIです。

現在のようにGUIが普及する前は、一般的なUIとして、ユーザーとコンピューターを繋いでいましたが、現在は主にサーバーエンジニアやネットワークエンジニアが、サーバーやネットワーク機器を操作する時に利用されています。

 

GUIGraphic User Interface

 

 

WindowsやmacOSを代表するOSは、全てGUIによって作られています。

私たちユーザーは、目的の処理をアイコンやファイル名を“クリック”や“タッチ”する事で、直感的に操作し、その結果を視覚的に判断しています。

ひとつひとつのコマンドやプロセスが、全て画で表現されているので、それらを直感的に道具として利用することができます。また、GUIというUIが、タッチパネル操作というUXを実現しているのです。

 

スマートフォンアプリのUI

 

 

スマートフォンでは、必ずアプリをインストールして、アプリを起動してからその機能を利用します。その時、私たちユーザーがタップする画面がUIです。アプリが提供するサービスに、アプリの画面を通して繋がります。

スマートフォンアプリのUIは、PCモニタよりもはるかに小さいスペースに、分かりやすい配置をする必要があります

機能が多いアプリでは、ボタンの配置や画面遷移などといった細かな動作ひとつが分かりにくいだけでも、ユーザーは離れてしまいますよね。このようなことを避けるための設計にもUXデザインが重宝されます。

 

UXの具体的な事例

 

クイックホイール

 

 

クイックホイールは、AppleのiPodに搭載されたUIであり、UXです。このクイックホイール は当時、ユーザーに新しい体験を提供した技術のひとつです。

ホイールの上を指でなぞるだけで音量の調整をおこなったり、そこにあるマークを押すと曲送りなどができ、音楽プレーヤーのUIにおける新しい体験でした。

また、クイックホイールをなぞる動作に合わせた“音”に惹かれるユーザーも多く、感覚をUXデザインしたと言っても過言ではありません。