2021-10-27

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

はじめに

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

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

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

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

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

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

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

　　　　　　

〇スイッチングハブ

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

〇ルータ

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

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

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

最後に

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

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

2021-09-29

社内で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

2021-08-31

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

ツール

はじめに

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

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

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

「Jitsi Meet」とは…

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

また、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を無事導入できています。

環境構築手順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/

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

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

最後に

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

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

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

2021-07-28

AWSについて

インフラ AWS

はじめに

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

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

「AWS」って…?

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

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

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

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

クラウド VS オンプレミス

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

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

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

サービス紹介

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

Amazon EC2
Amazon ELB

Amazon EC2(Amazon Elastic Compute Cloud)

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

Amazon ELB(Amazon Elastic Load Balancing)

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

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

最後に

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

弊社の風土として

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

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

2021-07-06

祝 🎉「CSIRT」＆「SIP」の発足！！

セキュリティエンジニアコミュニケーション

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

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

🎉CSIRTとは

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

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

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

🎉 SIPとは

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

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

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

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

🎉 弊社の風土

代表との月1面談

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

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

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

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

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

最後に

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

2021-06-01

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つのプロセス群にわかれています。立ち上げ、計画、実行、監視コントロール、終結というプロジェクトのプロセスごとにプロジェクトの管理方法や必要なドキュメントなどが定義されています。

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

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

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

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

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

目標

KPIなどの測定可能なプロジェクト目標や成功基準

ステークホルダー

プロジェクト憲章を認可するスポンサー名
プロジェクトマネージャー名
プロジェクト初期段階でアサインされたメンバーリスト

制約条件

初期段階の要求事項
納期
予算
プロジェクトの終了基準

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

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

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

ビジネスケースとは

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

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

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

上記をまとめれば

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

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

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

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

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

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

最後に

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

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

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

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

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

recruit.styleedge-labo.co.jp

2021-04-30

その業務、自動化してみない？　そう、RPAがあるじゃない。

ツール

はじめに

こんにちは、スタイル・エッジLABOのHHです。
私も気が付くとこの春から社会人2年目となりました。
インターン生として働いていた大学4年時に記事を執筆して以来、実に1年半の月日が流れました💦
弊社も新卒を迎え、先輩として接する機会も生まれてくると格好悪い背中を見せたくないと気が引き締まるものです(笑)

業務を自動化しよう

そんな久しぶりに執筆する記事ですが、今回はRPAについて書いてみます。
この業務、手動でやるにはちょっと面倒、でも自動化するプログラムを作成するほどでもないんだよなぁ。。 なんて思ったことはないでしょうか？

Google社が提供しているGASは比較的手軽にコードを書いて自動化できるため便利ですが、アプリをまたいだ操作を行うには力不足を感じてしまう場面も多いです。
それでは、RPAを活用してみてはどうでしょう？というお話を今回はしてみようと思います！

RPAとは

RPAとは、Robotic Process Automationの略で、様々な作業を自動化する技術の1つです。

弊社でも業務でRPAを活用し始め、私は現在RPAのシナリオを作成する業務に没頭中です。
そこで感じた、RPAってここがすごい！ということや、こういうところは気を付けなければ、といったことを思ったままに書いていこうと思います。

RPAのここがいいね👍

RPAのいい所としてぱっと思いつくのは以下の2点でしょうか？

アプリ間を横断した操作が行えること
デバイス間を横断した操作が行えること

2つとも似たような観点になってしまいましたね(笑)
それぞれ簡単にどういうことなのか書いてみます。

1. アプリ間を横断した操作が行えること

読んで字のごとくですが、ブラウザ操作やコマンドプロンプトの操作、チャットツールの操作やリモートデスクトップ接続の操作など、シナリオの組み合わせ方次第ではワンクリックで横断的な作業を行うことができます。

2. デバイス間を横断した操作が行えること

1.でも少し触れましたがリモートデスクトップ接続の活用によりPCをまたいだ操作も行えます。
RPAツールをインストールしているPCをそうでないPCにリモートデスクトップ接続を行い、適宜両デバイスでの操作を切り替えながらシナリオを組むことも可能です。

弊社では現在リモートワークが中心の業務スタイルとなっているため、自宅からRPAツールがインストールされているPCにリモート接続し、そのPCからさらに別PCにリモート接続を行いRPAの操作を行うなど、場所にとらわれずにRPAの活用ができています。
※自宅からVPNを利用し本社ネットワークに接続した状態でリモートデスクトップ接続し、セキュアな状態を担保しています。

RPAのここに注意

ここまでRPAのいい所を簡単に書いてきたので、万能な技術と感じた方もいらっしゃるかもしれません。
しかし、RPAは決して魔法のツールではありません。

複雑な判断を要する作業には向いていない
デバイスによっては同じシナリオでは正常に動作しなくなる可能性がある

など、気を付けるべきポイントがあります。

実務を行う上で、私も様々な試行錯誤を重ねているところです。
例えば、

リモート先PCの解像度や壁紙を一律にすることでデバイスごとの環境差異を極力なくす
RPAのシナリオ実行速度を上げるためにバッチファイルを併用する

といった工夫を行っています。

バッチファイルの実行管理やバッチではできない操作をRPAツールで行うなど、技術の特性を見極めシナリオを作成することが難しくも面白い点です。

最後に

技術を適切に活用し、目的を達成できてこそ素敵なエンジニアだと思いますので、業務の効率化に向け腕を磨いていきます。
1年半前の私と比べ、少しでも成長した姿をブログ越しに伝えられたら嬉しいです(笑)

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

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

recruit.styleedge-labo.co.jp