スタイル・エッジLABO技術ブログ

士業集客支援/コンサルティングのスタイル・エッジグループ スタイル・エッジLABOのエンジニアによるブログです。

フレームワークについて

はじめに

はじめまして!スタイル・エッジLABOのYHです。
今年の4月に新卒として入社し、早いもので半年が過ぎました。
時間の流れの速さに震える日々を過ごしております…。

私は6月にプロジェクトに配属されてから現在まで、所謂「開発系」の業務に携わってきました。
LABOではPHPフレームワークを利用した開発を行っており、
9月まで配属されていたプロジェクト内ではFuelPHPを利用していました。
はじめこそ四苦八苦していたフレームワークを用いたコーディングも少しずつ慣れてきて、
FuelPHPと仲良くなれたかも!😊」と思っていた矢先、
10月から新たにジョインしたプロジェクトではLaravelの利用がスタート…!
まだまだ戦っている最中ではありますが、FuelPHPとLaravelの違いについて少しまとめてみました。

エンジニア歴半年ではありますが、初心者だからこそ気づいた違いもある(はず!)ということで、
温かい目でお読みください🙋‍♀️
f:id:styleedge_tech:20211118085117p:plain

0.フレームワークとは

違いを列挙する前に、そもそもフレームワークとは何かということについて整理してみます。
Wikipediaにはフレームワークについて以下の記載がありました。

ソフトウェアフレームワーク(英: software framework)とは、プログラミングにおいて、アプリケーションソフトウェア等の実装に必要となる一般的な機能や定型コードを、ライブラリとしてあらかじめ用意したものである。

(https://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF)

プログラミングにおける土台・雛形を用意してくれているのがフレームワークであり、
開発に必要な機能があらかじめ実装されているため工数を減らせるという利点があります。
フレームワークも各言語によって様々な種類があり、どのフレームワークにも得意・不得意な点があります。
何を実装したいか、どのように開発していきたいかによって選定する必要があり、
FuelPHPとLaravelはPHP言語のフレームワークの一種、ということになります。

実装するにあたってフレームワーク
「これがないとプログラミングは不可能!」 というものではありません。
フレームワークがなくてもプログラム自体は書くことはできますし、
独自機能による制限がない分、自由度は高くなると思います。
しかし、個人開発ではなくチームで開発するとなると、
各人が好きなように設計しコーディングしたものを製品として運用するのは
セキュリティ的にも脆弱性が高くなり、なにより保守できなくなってしまいます。
そこでフレームワークを用いて、同じ土台である程度の規約や設定に則ることで、
個々の経験やスキルの差をある程度吸収しつつ、一定の品質のプロダクト開発を実現するというのが
チーム開発においてフレームワークを導入する利点だと思います。

1.学習コスト

FuelPHPでコーディングをしているとき、一番困ったのが
「探しても知見が出てこない(探すのが困難)」ということでした。
調べが甘いのかな?と思い、検索ワードをあれやこれや変えてみても解決方法が見当たらず、
最終的には全然違うフレームワークでのコーディング方法が出てきて行き詰まることもしばしば😥
プロジェクト内外の先輩方にかなり助けてもらっていなんとか解決してきたのですが
コーディング初心者からすると情報がないという状況はかなり辛かったです…。
その点Laravelは公式ドキュメントが充実しており、非公式ですが日本語にも翻訳されています。
ユーザの個々の知見に頼らずとも公式ドキュメントに利用方法や解決策が詳細に記載されているので、
かなり助かっています。
また具体的な実装方法や、エラーの際の詳細な解決方法などといった
公式ドキュメントでカバーしきれない部分はユーザが投稿した情報をネットで多く手に入れることができます。
以上を踏まえて、Laravelの方がFuelPHPよりも学習コストが低く、
プログラミング初心者でも挑戦しやすいと感じました。
f:id:styleedge_tech:20211118085332p:plain

2.コーディングの柔軟性・拡張性

FuelPHPは「規約より設定」を重視して作られていることからも、かなり柔軟性の高いフレームワークです。
またcoreの拡張が容易だったりコーディング規約も比較的緩いことから、
ある程度は自由にコーディングすることができます。
(入社して少し経ったころ、先輩社員から
FuelPHPは生のPHPを書いている感覚と似ている」と教えていただきました。
当時は「そうですかね…?🤔」くらいの感想だったのですが、確かにLaravelと比較すると、
「独自の機能を持った生のPHP」という扱いができると思います。)

一方Laravelは、独自のメソッドが充実しており、開発時においてはそれらを活用することで
自前開発をする必要性を抑えることが出来ます。
フルスタックフレームワークとしての完成度が高いため、
初心者にとっては始めやすく、上級者にとっても開発時の煩雑さを減らせるので、
バランスの良いフレームワークなのではないかな?と思います。

3.フレームワーク独自機能の量

FuelPHPではフレームワークとしての機能にないため、自前で実装を行うことも時々あったのですが、
実装に時間がかかってしまう場面が多々あり、プログラミング初心者の私は
かなり悪戦苦闘しながら開発を進めていました。
(そのたびに先輩方に助けていただきました…!😳
この「自分の技術を互いに共有し合う」文化は、私がLABOで一番好きな特徴です✨)
その点、Laravelでは機能が充実しているため、実装自体がとても簡単です。

最近感動したのがページネーションの実装です。
ページネーション自体は、かみ砕くとそこまで難しいことはやっていない…ようなのですが、
データを分割したり、2ページ目に表示させるデータが何番目のデータになるのかだったり、
これは工数的にどのくらいかかるんだ…??と冷や汗をかいていました。
しかし、Laravelの優秀な機能のひとつにページネーション作成機能があるため、
ほとんどデータを操作することなく、ほんの少しの時間で実装が完了しました。
これは感動モノだったのですが、裏を返せば
「どのような処理が走っているかはわからないけれど、なんか動いた」 という状態であり、
私のような初心者プログラマが訳も分からずフレームワークの機能で実装していると、
バグが発生したときに対処できない可能性も出てきています。
実装に省略できた時間を処理内容を理解する時間に充てるなどして、
機能に頼りすぎないことも大切かな、と感じました。
f:id:styleedge_tech:20211118091338p:plain

最後に

FuelPHPとLaravelの違いについてまとめてみましたが、いかがだったでしょうか?
今回紹介した内容と私の観点を含めて、FuelPHPとLaravelについて以下の表にまとめてみました。 f:id:styleedge_tech:20211124140518p:plain
なんだかこう見ると「Laravel圧勝!?」という感じなのですが、
プログラミング学習という点においてLaravelは
メソッドが豊富な分処理の内容がブラックボックスになりがちという特徴があると思います。
私のようなプログラミング初心者の場合は、メソッドの内容をよく理解したうえで使用していくのが
今後の知見を増やすという意味でも大切だと感じました。

フレームワークを利用すると素早く簡潔に実装できるという利点があります。
また初心者でもコーディングしやすく、理解もしやすいため、技術力の向上も早くなると思います。

弊社ではプログラミング未経験でも、かなり本格的に実装を経験することができ、
また学びあう風土があるため、エンジニアとしてどんどん成長することできる環境です!

☆スタイル・エッジLABOでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください!
recruit.styleedge-labo.co.jp

OSI参照モデルとネットワークを構成する機器(ルータ、スイッチングハブ)

はじめに

はじめまして!スタイル・エッジLABOのYAです。 今年度新卒で入社しました!
僕は入社後のプロジェクト配属の時に、「ネットワークに関わってみたいです!」と希望を出したので、
現在は弊社や弊社のクライアントの方々のネットワークを構築・管理する役割を担っています。
基本的に希望が通る環境なので、自分の興味や関心のあるプロジェクトに所属できるのは
ありがたいなと思います😊
今回はそんな僕が普段設定・管理しているネットワークデバイスについて紹介していきます!
f:id:styleedge_tech:20211011135825p:plain

ネットワークデバイスとは?

ネットワークの中でのデータのやり取りをコントロールする機器たちのことです。
コントロールというのは、データをどこに向かって送るのか、逆に送らないようにするのか
などといった 通信におけるデータの流れを制御することです。

ネットワークでの通信のルール

このデータの流れを制御するには、各メーカーの各デバイスで共通したルールが必要です。
たとえばA社の製品とB社の製品が異なるルールでデータをやり取りしていたら、通信ができなくなります。
ちょうど人がお互いに知らない言語でコミュニケーションを取ろうとしてもうまくいかないようなものです。

そこで、通信のベースとなる共通のルールを定めるために、OSI参照モデルというものが生み出されました。
OSI参照モデルは、7つの階層構造で表されます。
そして、各階層のルールにしたがって通信を行うネットワークデバイスを定義します。
こうすることで、ネットワークデバイスたちはたとえ製品が異なったとしても、
各階層ごとの共通のルールにしたがって通信ができるようになります。
たとえば、A社、B社関わらず第3層を担当するデバイスは、第3層のルールに基づいて
データを送受信し、同様に第2層担当のデバイスは第2層のルールに基づいて
データを送受信するというように、各デバイスは各階層のルールにしたがってデータをやり取りします。
また、ルールを階層構造で表すことで一連の通信の中で各デバイスの役割分担ができるようになります。

ここからは各層のルールと代表的なネットワークデバイスとして
第2層を担当するスイッチングハブと第3層を担当するルータについて説明します!
1、4ー7層には申し訳ないですが、ここでは割愛させていただきます😌

      f:id:styleedge_tech:20211026135531p:plain

スイッチングハブ

第2層のネットワークデバイスです。
第2層では、ざっくり説明するとMACアドレスという情報をもとに、
同じネットワーク内の直接接続されている機器とデータをやり取りします。
MACアドレスとは、各機器に割り当てられる一意の番号のことで、
同じネットワーク内で「誰に」データを送るのかを表すための情報です。
スイッチングハブは、自分に接続されているPCなどの機器のMACアドレスを認識し、
そのMACアドレスの情報をもとに正しい送信先にデータを送り、
正しくない送信先にはデータを送らないようにして、データのやり取りを制御します。

〇ルータ

第3層のネットワークデバイスです。
第2層が同じネットワーク内の機器とのやり取りを行っていたのに対して、
第3層では、異なるネットワークにある機器との間でデータをやり取りします。
また、データをやり取りするための最適な経路を決定します。

ここで、話は少し逸れますが異なるネットワークとは何かについて説明します。
現在は世界中がネットワークに接続し、どこからでも動画の視聴やSNSでのやり取りが可能です。
このような世界規模のネットワークは、大きな1つのネットワークがあるのではなく、
実は小さな異なるネットワークが互いにつながることで構成されています。
日本の自宅から海外にいる友人にSNSでメッセージを送るとき、そのデータは自宅のネットワークを出発し、
SNSを管理するネットワークやその他の様々な小さな異なるネットワークを経由して、
友人の自宅のネットワークに到着します。

ルータはこのような異なるネットワークとのデータのやり取りをIPアドレスという情報をもとに行っています。
IPアドレスは、「どこの」ネットワークの「誰に」データを送るかを表すための情報です。
この情報をもとに、ルータは指定された異なるネットワークにデータを送信し、
さらにそのネットワーク内の別のルータが次の異なるネットワークにデータを送信することで、
次々にネットワークを経由してデータが正しい送信先に送られます。
f:id:styleedge_tech:20211011135943p:plain

最後に

今回はネットワークデバイスのうち特に代表的なスイッチングハブとルータについて紹介しました。
一言でネットワークや通信といっても、今回のようなデバイス間のものだけでなく、
クラウドサービスやシステム間でのネットワークや通信などもあり、非常に奥が深いです🤔
今後は、ネットワークに関する知識を武器にさまざまな分野に足を踏み込んでいきたいです!
このように自分の興味のある分野から派生して、興味・関心を広げていけるのは
エンジニアとしてとても楽しいですし、弊社にはそれを実現するための環境が備わっていると思います!


☆スタイル・エッジLABOでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください!
recruit.styleedge-labo.co.jp

社内でITのお困りごとなら「SIP」におまかせ✨

はじめまして! スタイル・エッジLABOのSMです。
今年の4月に新卒未経験で入社しました🙌

入社して半年が経ちましたが、日々新しい発見の連続で、沢山のことを学んでいます!

私は6月よりSIPに所属しているので、今回はSIPについてご紹介します🔍

▶そもそも「SIP」って?

過去記事の祝 🎉「CSIRT」&「SIP」の発足!!でも紹介しましたが、
SIP(シップ)とは社内IT支援室の略称で、
スタイル・エッジ・グループ全体から寄せられるIT関連の相談事への対応、
全クライアント事務所に対するIT各種サポートなどを全面的に担う組織です!

               

ではITサポート対応は具体的にどんな流れで行っているのでしょうか🔍

▶ITサポートの流れ

▷問い合わせをキャッチ

まずITサポートの問い合わせフォームから問い合わせが来ます📫
問い合わせ内容をSIPメンバーが確認し、SIPメンバーのうち誰が担当するかを決定します。
担当者が決まったら、担当者は問い合わせ者に直接連絡し、問い合わせ内容の詳細をヒアリングします👂

ヒアリング

          

ヒアリングは簡単そうに見えて、ITサポートにおいてはとても重要なフローです!
実際にお会いして状況を直接見ることができれば、どう解決すべきかわかりやすいものですが
各クライアント事務所からの問い合わせや、在宅ワークが増加していることにより
正しい状況をチャットで把握しなければなりません。

時には通話、画面共有などを駆使して状況を正確に把握します🔍

▷解決

状況が把握できたら、原因の切り分けを行います✂

例えば「PCがネットに繋がらなくなりました!」という問い合わせの場合、
PCは有線なのか無線なのか、他のPCも同様に繋がらないのか、などなど…
切り分けをすることで原因がどこにあるのかを突き止めます!

どうしても分からない場合は、他のSIPメンバーに相談することも。
試行錯誤して、解決まで導きます💪

▷今後の知見へ

解決した問い合わせは、全て内容を記録・共有し、今後の知見に役立てています📚

         

▶ITサポート事例

では実際に対応したITサポ-ト事例を紹介します!
あるクライアント事務所より「特定のモデムからPCが有線接続できません。」
との問い合わせをいただきました。
ヒアリングしたところ、「あるモデムに接続したPCだけネットワーク接続ができない」とのことでした。

しかし本当にPCに接続しているのはモデムなのでしょうか・・・?
モデムから直接PCを有線接続していることは考えにくく、もしかして「ハブ」のことを指しているのでは…
そう考え、ハブの写真をお送りし、「有線接続しているのはこちらの機器でしょうか?」と聞くと、
「それです!」とのこと!

また、同じルーターから繋いでいる他のハブに接続してネットワークが使用できるPCも
該当ハブに接続するとネットワークが使用できない、とのことなので
該当ハブを再起動していただいたのち、無事にネットワークに接続することができました✨

クライアント事務所の方からの問い合わせは、中々すぐに現地で対応することができないため
事象を一つ一つ確認することが大切ですね🔰

▶じゃあ、コードは書かないの?

確かに他システムを作っているメンバーに比べるとコードを書く機会は少ないですが
全く書かないというわけではありません💻

実は問い合わせをキャッチする仕組みにはGAS(Google Apps Script)が使われています✨

また、問い合わせ対応の抜け・漏れがないように、日毎の問い合わせまとめを確認したり
問い合わせ内容を記録する際に、問い合わせフォームに入力された内容から
必要箇所をピックアップして自動入力し、記録を短時間でできるようにしたり…
様々な場所でプログラムが動いています🔍

              

▶最後に

今後ともスタイル・エッジ・グループ全体、そして全クライアント事務所のIT周りをサポートしていきます!
そして、皆様のITリテラシーの向上を目指すこともSIPの役目です。

スタイル・エッジLABOでは、一緒に働く仲間を募集しています!
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください✨

recruit.styleedge-labo.co.jp

「Jitsi Meet」でビデオチャット環境構築~共有ドキュメント「Etherpad」導入手順

はじめに

この4月よりスタイル・エッジLABOに新卒入社したK2です!
社会人生活にもだいぶ慣れ、落ち着いてきた今日この頃ですが、
エンジニアとしても日々成長できるよう毎日楽しんで業務に取り組んでおります。

ところでみなさん、このご時世なのでリモートで作業することや、
対面での会議などはなくなりビデオ会議などが増えてきているのではないでしょうか? f:id:styleedge_tech:20210819100051j:plain

こういった背景から独自のビデオチャット環境を用意したい方向けに、 今回は
『Dockerと「Jitsi Meet」でビデオチャット環境を構築後、共有ドキュメントの「Etherpad」導入』
する手順をご紹介します!!

「Jitsi Meet」とは…

簡潔に説明すると、Jitsi Meetとは、オープンソースで開発された、
多人数同時ビデオ通話を可能にするWebRTCアプリケーションです。
アカウントを作成したりコンピューターにクライアントソフトをインストールしたりする必要はなく、
ウェブブラウザやスマートフォンから URL にアクセスするだけで、すぐにビデオ会議が利用できます。
ブラウザ以外にも、iOSAndroid 対応のアプリが公開されています。

また、Jitsi Meetの特徴的な機能として以下の様な機能が存在します。

  • 会議をYouTube Liveでストリーミングする
  • 会議中にYouTubeビデオを再生する
  • 複数人が同時に画面を共有することが可能
  • 通話時間に制限がない
  • Etherpadに基づく共有テキストドキュメントを利用可能

ビデオ会議ツールとして利用する場合はAWS等を用いてサーバーを用意することで利用可能です。
なお、この Jitsi Meet 用のサーバー環境は Docker に対応しています 。
そのため、自分のサーバー上にDocker Compose で起動する手順を今回はまとめました。

「Etherpad」とは

ウェブベースのオンラインエディタであり、オープンソースソフトウェアです。
複数人でテキストを同時に編集することが可能で、各々の編集した部分を対応する色で示すことも可能です。
また、チャット機能が存在するため、コミュニケーションを取りながらテキストを編集することも可能です。

Jitsi Meetでは設定を変更することでこちらのEtherpadを共有ドキュメントとして使用できます。
そのため今回Etherpadの導入までの手順を記載していきます!

想定する構築環境

下記は実際にローカルで動作した際の環境です。

Docker version 20.10.7
OS            Ubuntu20.04

上記の通りLinux上での構築を想定しているので、Windowsの方はWSLを利用して構築しましょう。
また、Dockerを用いて構築するので事前にDocker Engine と Docker Compose のインストールを
行っておきましょう。

環境構築手順1(Jitsi Meet立ち上げまで)

それでは早速環境構築していきましょう。 公式の構築手順はこちらをご覧ください。

1. ソースコード入手

まずはJitsi Meetのソースコードこちらから取得します。

ソースコードは作業用のディレクトリを作成し、保管することをお勧めします。

2. .env作成

cp env.example .env

.env内にはJitsi Meetの動作に必要な設定値などが含まれるため、
個人でカスタマイズする場合は環境変数を変更した際の影響範囲を理解しておきましょう。

3. .env内の各コンテナパスワードを設定

bash ./gen-passwords.sh

または

./gen-passwords.sh

.envにあるコンテナパスワードは設定されていないので、
あらかじめ用意されたシェルスクリプトを実行し設定します。

4. コンフィグディレクトリの作成

mkdir -p ~/.jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}

5. コンテナの起動

docker-compose up -d

6. ブラウザアクセス

https://localhost:8443/

ここまでの手順が終わるとブラウザアクセス可能になっており、以下の画面が表示されていれば
Jitsi Meetを無事導入できています。

f:id:styleedge_tech:20210819125238p:plain

環境構築手順2(Etherpad導入まで)

Etherpadはデフォルトでは使用できないため、次の手順に従って実装します。

1. .envファイルを編集

.envファイルの92行目付近のコメントを外す。

ETHERPAD_URL_BASE=http://etherpad.meet.jitsi:9001

95行目付近のコメントを外し、以下の様に編集

ETHERPAD_PUBLIC_URL=https://localhost:8443/etherpad/p/

こちらのコメントを外す記載は公式ドキュメントにはなかったため、詰まりどころでした。
これまでの手順でのJitsi Meetと同様のオリジンにすることでクロスオリジンを回避する
ことができ、Etherpadを利用可能になります。

2. 共有ドキュメントを開くボタンの追加

~/.jitsi-meet-cfg/web/にcustom-config.jsを作成し以下内容を追記します。

config.toolbarButtons = [
    'microphone', 'camera', 'closedcaptions', 'desktop', 'embedmeeting', 'fullscreen',
    'fodeviceselection', 'hangup', 'profile', 'chat', 'recording', 'tileview',
    'settings', 'raisehand', 'etherpad', 'sharedvideo', 'livestreaming',
    'videoquality', 'filmstrip', 'invite', 'feedback', 'stats', 'shortcuts',
    'help', 'mute-everyone', 'mute-video-everyone', 'security'
 ];

Etherpadの項目があるかどうかを確認しましょう。

3. コンテナの起動

docker-compose -f docker-compose.yml -f etherpad.yml up -d

etherpadを追加したため、etherpad.ymlファイルを指定します。

4. ブラウザアクセス

https://localhost:8443/

通話画面に入り、詳細アクションを選択した後に共有ドキュメントを開くボタンを押し、
以下の画面が表示されていれば無事導入できています。 f:id:styleedge_tech:20210819142838p:plain

Etherpad導入までの手順でした!

最後に

いかがでしたでしょうか。

Jitsi Meetはこの他にも様々な拡張機能を持つだけではなく、既存のソースコードを編集することで
自分好みのビデオ会議ツールにカスタマイズすることも可能です。
ビデオ会議ツールを選ぶのに悩んでいる方、自分だけのビデオ会議ツールを作成したい方等は
是非触れてみてはいかがでしょうか。

☆スタイル・エッジLABOでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください!
recruit.styleedge-labo.co.jp

AWSについて

はじめに

この4月よりスタイル・エッジLABOに新卒入社したMKです!
インプットがたくさんあり、毎日頭がいっぱいいっぱいです…
それでも親切な先輩たちの協力のもと楽しんで仕事しています😊

f:id:styleedge_tech:20210714164455j:plain

そんな私が紹介するのは… 「AWS」についてです!!! 私自身も知識が浅い部分はあるので、
今回は概要だけですが イメージだけでもしていただけたらうれしいです。

AWS」って…?

f:id:styleedge_tech:20210719093557p:plain AWSとは、Amazon Web Service の略で
Amazon が提供しているクラウドコンピューティングサービスの総称です。

クラウドコンピューティングとは…?

今日よく聞く言葉ですね🤔
一言でいうと、
インターネットを経由してサーバやストレージなどのサービスを利用できる形態です。
AWSは通販で有名な Amazon が、自社のノウハウを活かして提供しています。

クラウドコンピューティングのサービスが登場する前までのサーバの運用形態は
オンプレミスといいます。
これは、自社でサーバ機器などを設置して利用するというものです。

クラウド VS オンプレミス

ここで、クラウドとオンプレミスを比較した表を作成してみました! f:id:styleedge_tech:20210721143530j:plain 表からわかることは、以下のことですね。

  • クラウドは、構築期間やスケールの操作時間が短く、導入・運用ともにコスト面でも優位
  • オンプレミスは自由にカスタマイズできる

カスタマイズ性に関しては、一般的にはオンプレミスのほうが自由度は高いですが、
AWSは様々な提供サービスを組み合わせることでサーバ構築を行うので
自由度は高いと思われます!!

サービス紹介

AWSは165種類以上のサービスを提供しています。 用途に応じた多種多様なサービスがあるのですが、
ここでは、私自身が調べたもの次の2つを紹介したいと思います!!

Amazon EC2(Amazon Elastic Compute Cloud)

用途に応じたスペックを自由に組み合わせて仮想サーバを作成・利用できるサービスです。
仮想サーバといえば、クラウドのほかにレンタルサーバというものがあります。 違いは、
クラウド → 借りた道具を使って自分でサーバを作る
レンタルサーバ → マシンや機能を借りる
といったイメージです。
「自分で作る」というと難しい…と思うかもしれませんが
EC2では、画面上からボタンをクリックするだけで簡単に作成することができます。
また、サーバマシンの組み合わせやOS・ソフトウェアの組み合わせなどが用意されているため
それを選択するだけでもサーバ構築ができるのです!

Amazon ELB(Amazon Elastic Load Balancing)

AWSが提供しているロードバランサーです。
ロードバランサーとは、サーバに集中するアクセスを、
複数のサーバやネットワークに振り分ける仕組みです。

サーバにアクセスが集中してしまうとサーバに接続できなくなり、
結果的にサイトが見えなくなるという状態になってしまいます。
そうなる状態を避けるため、ロードバランサーを活用しています。
f:id:styleedge_tech:20210719093627j:plain

最後に

今回は「クラウドコンピューティングとは?」の概要とAWSのサービス2つを紹介しました。
他のサービスも利用して、高速かつ安定したサービスを提供できるように
日々試行錯誤し、システムを運用しています!!

弊社の風土として

システム開発」と聞くとアプリケーションをイメージしがちですが
本格的にインフラ構築に関わることができます!

また、自身の興味に応じてプロジェクトを異動できるため
「インフラにも興味あるし、アプリケーション開発にも関わりたい…」という人にピッタリだと思います😉

☆スタイル・エッジLABOでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください!
recruit.styleedge-labo.co.jp

祝 🎉「CSIRT」&「SIP」の発足!!

f:id:styleedge_tech:20210621091401j:plain
3月よりスタイル・エッジ LABO に入社しましたWです。
私はエンジニア未経験で入社していることもあり、まだまだ不明なことばかりですが、
思いやりのある方々に囲まれ、エンジニアライフを楽しんでいます!

そんな私が今回お伝えしたいのは、
6月より発足された組織「CSIRT」と「SIP」についてです!

🎉CSIRTとは

f:id:styleedge_tech:20210621091502j:plain
CSIRT(シーサート)はComputer Security Incident Response Teamの略称で、
スタイル・エッジ・グループ全体に対してサイバーセキュリティ対策・推進を行う組織になります。

昨今のニュースでは、サイバー攻撃を始めとした情報セキュリティの事故をよく見かけるようになりました。
お客様からお預かりしている大切な情報をいかに安全に守るか、
グループ全体としても非常に重要なミッションになります。

これからも増え続けるであろうサイバー攻撃からお客様の大切な情報を守るため、
更にはスタイル・エッジ・グループ全体のセキュリティを守るため、
サイバーセキュリティに備える専門の組織として発足されました。

🎉 SIPとは

f:id:styleedge_tech:20210628135144j:plain SIP(シップ)は社内IT支援室の略称で、
スタイル・エッジ・グループ全体から寄せられるIT関連の相談事への対応、
全クライアント事務所に対するIT各種サポートなどを全面的に担う組織になります。

スタイル・エッジ・グループの事業拡大に伴い社員数も増え、
IT関連の困りごと・要望も増加傾向にあります。
そういった、スタイル・エッジ・グループ全体のITに関する困りごとを
リーダーシップ(SIP)をとって解決していく組織として発足されました。

私も6月から開発業務とSIP業務とを兼任しています。
そして、私がSIPを兼任することになった経緯に「LABOらしい」風土があると思っています。

ですので、突然ですが弊社の風土についてちょっと話をします↓

🎉 弊社の風土

代表との月1面談

弊社には毎月1回代表との1対1の面談が設けられており、
業務のフィードバックををもらえたり、自分の今後の思いをぶつけたりすることができます。
代表は各メンバーのこれからに対して真摯に向き合ってくれます。

SIP発足に関しては、私の面談の際話題にあがりました。
私は未経験からエンジニアに転職していることもあり、
「IT周りの知識をもっと吸収したいという思い」と、
「困っている人の力になり、それを日々実感したい」という思いからSIPに立候補しました。
するとトントン拍子で話が進み、2週間後にはSIPの一員になっていました。
私は違う業種から転職しているため、 この「決定のスピード」と「やってみたい!という思いを尊重する風土」に驚きました!

エンジニアをやっていると、やりたいことや学びたいことは刻々と変わっていくと思います。

  • とにかくコードを書きたい。
  • 違う言語も触ってみたい。
  • ネットワークについて学びたい。
  • サーバーの知識を身につけたい。
  • チームを牽引するリーダーの経験をしたい。

弊社には自分のやりたいことを声に出すことが尊重される風土があります。

最後に

少しまとまりが悪くなってしまいましたが、
どうか、今後のスタイル・エッジ LABOの成長(と私の成長?)を見守っていてください!
もしくは、これからのスタイル・エッジLABOを一緒に作っていきませんか?

☆スタイル・エッジLABOでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください!
recruit.styleedge-labo.co.jp

PMBOKについて

こんにちわ、スタイル・エッジLABOのOです。

最近はプロジェクト運用について、もっと効率よく出来ないかな?もっといい方法はないかな? と考える日々です。

そんな中、最近読んだPMBOKについて書いていきたいと思います。

PMBOKとは?

PMBOK Guide、正式名称はProject Management Body Of Knowledge Guideです。 プロジェクトマネジメントの知識を体系化したもの、と本には記載されていました。

そもそもプロジェクトとはなんでしょうか?

PMBOKでは以下のように定義されています。

独自のプロダクト、サービス、所産を創造するために実施する、有期性のある業務
決定している納期に合わせて顧客の要望に合う製品やサービスを提供する業務の事

つまり、期限内に誰かの要望を満たす何かを作ったり、サービスを提供することということですね。

このようにプロジェクトとは何か?という定義から、プロジェクトを進めていく上で必要な ドキュメントなど多くの事を定義しています。

今日は10の知識エリアの一つ、プロジェクト統合マネジメントについて少し触れていきたいと思います。 まず10の知識エリアとはプロジェクトマネージャーが注意を払うべき、管理上の10の領域のことです。 プロジェクト運用するにあたってのポイントを大きく10に分けたイメージです。

以下は10の知識エリアの概要をまとめたものとなります。

知識エリア名 概要
1.プロジェクト統合マネジメント プロジェクトやエリアをどのように進めるかを定義する知識エリア
2.プロジェクト・スコープ・マネジメント プロジェクトやフェーズにおける作業範囲や、成果物の設定に関して定義する知識エリア
3.プロジェクト・スケジュール・マネジメント 納期管理に関する知識エリア
4.プロジェクト・コスト・マネジメント プロジェクトで承認された予算に関する知識エリア
5.プロジェクト品質マネジメント 生成される成果物やプロジェクトの品質に関する知識エリア
6.プロジェクト資源マネジメント メンバーなどの人的資源や、物的資源などの管理に関する知識エリア
7.プロジェクト・コミュニケーション・マネジメント 会議予定を設定し、適切にコミュニケーション内容や方法を管理する知識エリア
8.プロジェクト・リスク・マネジメント プロジェクトにおけるリスクの特定・分析・対応方法、対応策の実行、リスク監視に関する知識エリア
9.プロジェクト調達マネジメント 契約終結やベンダーの管理に関する知識エリア
10.プロジェクト・ステークホルダー・マネジメント ステークホルダーの関与度の定義や管理に関する知識エリア

10の知識エリアは、ここからさらに5つのプロセス群にわかれています。 立ち上げ、計画、実行、監視コントロール終結というプロジェクトのプロセスごとにプロジェクトの管理方法や必要なドキュメントなどが定義されています。

f:id:styleedge_tech:20210531192500p:plain
10の知識エリア

この10の知識エリアの一つ、プロジェクト統合マネジメントについて少し触れていきたいと思います。

プロジェクト統合マネジメントとは

10の知識エリアの統合的な役割を持ち、プロジェクトやフェーズの進め方・管理や終結の方法を定義している知識エリアです。

例えば上記表の立ち上げプロセス時に必要とされる「プロジェクト憲章」も詳細な定義がされています。 まずプロジェクト憲章とは「プロジェクトの存在を正式に認可するために必要な文書」とあります。

プロジェクト憲章にはプロジェクトの目標や制約条件、ステークホルダーなどを記載するよう定義されています。

目標
  • KPIなどの測定可能なプロジェクト目標や成功基準
ステークホルダー
  • プロジェクト憲章を認可するスポンサー名
  • プロジェクトマネージャー名
  • プロジェクト初期段階でアサインされたメンバーリスト
制約条件
  • 初期段階の要求事項
  • 納期
  • 予算
  • プロジェクトの終了基準

また、そのプロジェクト憲章を作成する上で必要な文書も定義されています。

プロジェクト憲章作成のイメージ
プロジェクト憲章作成のイメージ

ビジネス文書と組織のプロセス資産が必要とあります。 組織のプロセス資産とは過去に実施されたプロジェクトの情報や、これから開始されるプロジェクトで利用できそうな内部資源の事です。

ビジネス文書についての説明は以下の通りです。

ビジネスケースとは

  • プロジェクトの実現可能性の有無や、工数をかけてプロジェクトを始めるべきかを検証するための評価指標となる文書

ベネフィットマネジメント計画書とは

  • 期待されるベネフィット(成果物)
  • ベネフィットの発生時期
  • ベネフィットの評価方法
  • ベネフィットを確認する人 が記載されている文書

上記をまとめれば

プロジェクト自体のやるべき価値があるか検討し、その成果がいつどのように発生し、評価できるかを見定めた上でプロジェクト憲章を作成しましょう

上記のプロセスを踏む事で無駄なプロジェクトを進めずにすみ、何らかのベネフィットを生み出せるということですね。

このように様々な文書の定義やプロジェクトの進め方などが記載されていますが、PMBOKはあくまで定義、全てを実施する事も推奨していません。

実際に全て実施していければいいでしょうが、現実のプロジェクトでは難しく感じます。

これをかみ砕いてどう現実のプロジェクトに落とし込んでいくか?というところが大事なんだろうな、というのが感想です。

今後、試していこうと思います。


最後に

PMBOKの触りだけ紹介しましたが、いかがでしたでしょうか。

プロジェクトマネジメントはやればやるほど、難しい分野だと感じます。
プロダクトに対する責任、大量のドキュメントとの闘い、メンバーの管理、スケジュールとの闘い、そして決断を常に迫られます。 なので、どうやったら楽になるかを考える日々です!(笑

プロジェクトマネジメントの中で、ドキュメント管理は悩みの種の一つです。
これといった正解が決められているわけでもなく、時間がかかるとわかっていても作らなくてはいけない物です。
仕様書の書き方や設計書の書き方を紹介している書籍もあり、フォーマットが準備されている会社もありますが、全てが最初から用意されていることはほぼなく、結局何かを参考にその場で作っていく事の方が多かったです。
そういった経験から必要なドキュメントは何なのか、どういったフォーマットなら便利に使えるかを考える上の知識としてPMBOKを活用していければと思います。


スタイル・エッジLABOでは、一緒に働く仲間を募集しています

  もし興味を持っていただけましたら、ぜひ採用サイト↓も覗いてみてください。

recruit.styleedge-labo.co.jp