2020年1月22日水曜日

今からでも間に合うWeb2.0時代の企業内ブラウザ選択


◯Webの未来予測の振り返り

Web2.0という言葉の発祥から15年が経とうとしています。
2007年 Radar Networks社の創業者の予測では、2010年からはWeb3.0時代で、2020年より先はWeb4.0の時代になるだろうと言われていました。
しかし現実は、Web3.0にさえ到達できていません。

Google, Facebook, Twitter などのサービス1つ1つに、個人の代替であるアカウントを持たなければならなかったのが、Web3.0ではサービスによってアカウントがコントロールされるのではなく、完全にプライバシーが保護された個人情報を個人がコントロールしてシームレスに各サービスを横断できるようになると予測されていました。
日本国内に限られている住基ネットさえままならない現状を見るにゴールへの道のりは果てしなく遠く感じます。
キャッシュレスの時代とも言われる昨今ですが、各サービスごとにカードやICが必要なのは現実世界もWeb2.0と変わらないと言えます。

シームレスにサービスを横断する助力としては弊社にもGluegent Gateがありますが、Web3.0ではそういった認証ゲートウェイとも違っています。Webのインターフェースやネットワークインフラ自体に普遍的に備えられた形です。

そういったわけで私達はまだしばらくWeb2.0の今の世の中でよりよい仕事をしていかなければならなそうです。

◯Web2.0時代のブラウザの進化と衰退

Web2.0の世界では、多様なサービスを実現するために、そのフロントエンドであるWebブラウザが大きな進歩を遂げてきました。OSのGUIシステムに肉迫してくるほどで、Chromebookの登場などはその最たる例と言えます。
Web上のものを操作できるだけでなくユーザーの設定の選択によって、様々な操作ができるようになりました。ローカルファイルアクセス、カメラ、マイク、位置情報、通知、オフラインコンテンツ、最近はBluetoothやUSBデバイス操作までも、Webブラウザ経由で行えるようになりました。
むしろネイティブアプリケーションを選択せざるを得ないケースを探すほうが難しくなってきています。Officeソフトも凝ったものでなければ、Microsoft Office OnlineやGoogleドキュメント/スプレッドシート/スライドで事足りる様になり、ファイルの共有も添付やダウンロードなどせずともWebブラウザ上で扱えるようになるクラウドストレージでの運用も普通となっています。

そういった背景から今の現実は、Web2.0がようやく浸透し成熟した時代と言えそうです。

しかし古くからある社内システムの運用を余儀なくされ、よりよいアプリケーションやサービスを社内システムに取り入れることが困難な企業も少なくありません。
中には数十年も前のWeb社内利用ルールをそのまま運用していたりというケースがあります。
例えばWebブラウザはNetscape Navigatorしか使ってはいけない…というような古すぎるルールなどはさすがに無いかと思いますが、Internet Explorer(以下、IE)しか使ってはいけないというルールを未だに設けている企業があることをまれに耳にします。

WebブラウザとWebアプリは、より色々なことが行えるように利便性を追求する広げる方向と、プライバシーやセキュリティ確保のための精密性や制限を与える方向の、両軸の更新で進歩しています。
中には数年前まで使えていたブラウザ機能がセキュリティ確保のために廃止となって、Webアプリは新しい仕組みに追随するよう変更されることも少なくありません。またWebアプリ自体がより良くなるために新しいブラウザ機能を取り入れていくことも多いでしょう。それによりどんどんIEと乖離が進みます。

WebサイトやWebアプリが、なんとかIEと最新ブラウザの両方で動作するよう頑張っていても、レガシーコードのために余計にjavascriptでCPUを使ったり、通信データが増えたりする、ファットなものになっていきます。
本来であれば、新しい機能を増やしたり安定性やパフォーマンス向上のアップデートを進められるはずが、IE対応という地道な設計や努力のために遅くなります。

IEは今以上進歩せず細々とセキュリティパッチを続けるだけです。レガシーシステムの面倒をみるだけのものになっています。MicrosoftもIEの開発を止め、Edgeへ舵を切っています。

そして、Windows以外のプラットフォームでも動作する新しいEdgeの開発に以前から注力していましたが、ようやく先日の2020年1月15日にリリースを果たしました。
Chromium ベースの新しい Microsoft Edge をダウンロードする

◯Edgeの出現が示唆するもの

これまでのEdgeはIEのレンダリングエンジンであるTridentを改良したEdgeHTMLで構成されていましたが、新しいEdgeではChromeブラウザのベースメントであるChromiumを採用して再開発されました。当然Chromeとの互換性も高くChromeのブラウザ拡張がEdgeでそのまま使えるほどです。
弊社の共有アドレス帳Gluegent Flow Status View等もEdgeで動作して驚いたのを覚えています。

筆者はβ版の頃から数ヶ月使っていましたが大きな問題もなく十分に使えています。
また、ChromeがGoogleアカウントごとのユーザー管理を行えるように、新しいEdgeではMicrosoftアカウントごとのユーザー管理が容易であることも魅力です。
IEからの系譜と継承を完全に断ち切り、Edgeは完全に生まれ変わったといえます。
Visual Studio Codeもそうでしたが、とうとう自社開発なんて小さなプライドをかなぐり捨ててMicrosoftが本気を出してきた、と私はワクワクしています。

海外ではWindows Updateで提供が開始されていますが、日本だけ令和2年4月からとなっています。その理由は確定申告のe-Taxシステムが新しいEdgeで動作するのか不安視されているためで、確定申告で混乱が起きないように配慮されたという事情があるそうです。

さてこれでOSに標準バンドルされるWebブラウザが新しいEdgeとなれば、同等のChromeを敢えてダウンロードする必要性が極端に低くなります。
新しいEdgeに対応したこれまでのEdge拡張に加えて、豊富なChrome拡張もまるごと使えるようになったEdge。Office365を使っている企業や、G Suiteを使っていない人が今後Chromeを選ぶでしょうか。
新しいEdgeの出現は、相手の懐に入って取って成り代わるというMicrosoftのこの大胆な戦略が功を奏して将来ブラウザシェアを大きく塗り替えるスタートとなるのかもしれません。

◯未来への選択

社員がPC/スマートフォンを使い、簡便な操作で効率良く仕事が終われるように、時代に合わせてWebの利用ルールは見直されるべきものです。

いずれくるIEの終焉。それまで使い続けることに意味を見い出すことは難しいでしょう。
ActiveXコンポーネントを使わざるを得ないIE専用Webアプリしか、会社でWebブラウザは開かないということでもない限り、IE専用Webアプリ以外のすべてを今からChromeやFirefoxやEdgeでの利用に移行しても、やりすぎということはないでしょう。

社内Web環境の改善に向けて次に舵を切るのは…、あなたの番かもしれません。


(クラウド開発部 Kato)

 

2020年1月15日水曜日

タスク一覧の各メニューにはどういう情報が表示されるかご存知ですか?

Gluegent Flowをご導入いただいているお客様からよくいただくお問い合わせで「タスク一覧のそれぞれのメニューに表示されるデータの種類がよくわからない」「自分が作成したタスクデータが意図したメニューに表示されない」といったタスク一覧のご質問があります。
今回は、タスク一覧にはどういうデータが表示されるかをご紹介しましょう。

◯タスク一覧とは

Gluegent Flowをご利用いただいているすべてお客様が必ず目にする画面が「タスク一覧」です。この画面からタスクデータを処理し、自分の申請したデータを参照しているかと思います。この画面には「タスク」「申請済み」「処理済みタスク」「来そうなタスク」「参照可能」「下書き」の6つのボタンが表示され、それぞれをクリックすると、それぞれの画面にタスクデータが表示されます。
管理者様はエンドユーザーから「自分が作成したタスクデータがない」や「さっきまで表示されていたデータが表示されなくなった」といったお問い合わせ・ご質問を受けているのではないでしょうか。
では、それぞれのメニューについて詳しくご紹介していきましょう。

◯タスク

「タスク」には自分が処理すべきタスクが表示されます。経路の担当者に自分もしくは自分が所属するグループが設定されているものが表示されます。
また、自分が作成したものの、先の経路で差し戻しをされたり、やり直しをしたものもここに表示されます。
個人
経路の担当者に自分が直接設定されているものが表示されます。
グループ
経路の担当者に自分が所属するグループが設定されているものが表示されます。
すべて
個人とグループに表示されているものが併せて表示されます。

◯申請済み

自分が作成(申請)したタスクが表示されます。
終了していない申請データ
途中の経路で止まっているなどにより、終了扱いになっていないデータが表示されます。
終了した申請データ
最後の経路で処理されたり、確認経路まで進んだことにより、終了扱いになっているデータが表示されます。
すべて
終了していない申請データ・終了した申請データに表示されているものが併せて表示されます。

◯処理済みタスク

自分または自分が所属するグループのメンバーが処理を実行したタスクが表示されます。
よく間違われますが、自分が申請したタスクはここには表示されません。自分が申請したものは「申請済み」に表示されます。
※ただし、やり直しや差し戻し後に再申請した場合はここに表示されます。
個人
経路の担当者に自分が直接設定されており、自分が処理したものが表示されます。
担当者に自分以外のユーザーも設定されており、自分以外のユーザーが処理したものもこちらに表示されます。
グループ
経路の担当者に自分が所属するグループが設定されており、自分を含む誰かが処理したものが表示されます。
すべて
個人とグループに表示されているものが併せて表示されます。

◯来そうなタスク

経路に自分・自分が所属するグループが担当者となっているものがあるが、その経路まで進んでいないものが表示されます。
たとえば、申請→承認→決裁のうち決裁経路に自分が設定されているが、現在は承認経路まで進んだものが表示されます。
承認経路で却下されることもあるのでここに表示されていたとしても必ず来るとは限りません。
個人
経路の担当者に自分が直接設定されているものが表示されます。
グループ
経路の担当者に自分が所属するグループが設定されているものが表示されます。
すべて
個人とグループに表示されているものが併せて表示されます。

◯参照可能

自動処理や管理者により参照権限が付与されたものが表示されます。
自動処理での参照権限の付与は「参照許可設定の追加自動処理」にて行います。管理者による参照権限の付与は「タスクデータ一覧」にて行います。
個人
自分が直接参照権限を付与されているものが表示されます。
グループ
自分が所属するグループに参照権限を付与されているものが表示されます。
すべて
個人とグループに表示されているものが併せて表示されます。

◯下書き

タスクの画面下部の「下書き保存」をクリックされたタスクが表示されます。
「作成」でタスクを新規作成し、申請を行わず「下書き保存」をクリックしたものはこちらにのみ表示されます。
「タスク」で表示されたタスクで、処理を行わず「下書き保存」をクリックしたものはこちらと「タスク」に表示されます。

いかがでしたでしょうか。それぞれのメニューに表示されるデータの種類がおわかりいただけましたでしょうか。管理者の方はもし誰かに聞かれたときはこの記事をご紹介いただくと、時短になると思います。ぜひご活用ください。
もし「この機能の使い方がよくわからない」「いつも聞かれるので記事にしてほしい」というご意見がございましたらお寄せください。
(SUTO)

 

2020年1月9日木曜日

年始のご挨拶

あけましておめでとうございます。
昨年は御代替わりして、令和最初の○○という話題が多かったように思います。
今年に入っても青山学院が完全優勝した箱根駅伝も令和最初の箱根駅伝と言われたように4月末までは令和最初の○○は続きそうです。


2019年の総括

さて、クラウドシーンに注目すると昨年はビジネスチャットの話題が花盛りだったように感じます。
そのUI/UXからエンタープライズSNSと呼ばれていた時代はメールとの兼ね合いから、なかなか普及には至りませんでしたが、メールと電話の中間コミュニケーション(あるいは良いとこどり)という立ち位置が意識されるようになってからは部門導入はもちろん、全社導入する企業も増えてきたように感じます。

まだまだ課題は少なくないですが、いわゆるテレワークをするメンバーが増えてきていることもあり、今年もビジネスチャットの動向には目が離せません。

また、クラウドサービスを複数利用するのが当たり前という世界になってきているのも特筆すべきことでしょうか。
必然的にパスワード管理をどうしたら良いかが話題となり、多要素認証を検討するのが普通のことになってきています。
二段階認証なのか、証明書認証なのか、FIDOなのか、いろいろな手段はありますが、いかに安全にクラウドを利用していくかはもはや常識的な課題となってきています。
常識的という意味では社内システムを含めた複数サービスのシングルサインオンという要件も俎上に上がるのが普通のことになってきています。
ただ、これらの課題に関しては特別な技術・運用検討が必要なわけではなく、ソリューションが定石化してきているのも昨年あたりからの流れでしょうか。

これから5Gの時代に入り、クラウドサービスも現在の形から大きく変化していくと思われます。
その変化の時代の真っただ中にいるワクワク感を感じつつ、弊社としては全ての働く人々に安心と快適をもたらすためのクラウドサービスを提供し続けて参りますので、今後ともよろしくお願いいたします。

   Gluegent Gate

2019年12月25日水曜日

ビジネスチャット導入しただけで、仕事がうまく回ると思ってませんか? (3)

前回までの記事で、長らくビジネスコミュニケーションの定番だった「メール」の次世代を担うツールとして登場してきた「ビジネスチャット」について、その構造的なメリットと、実際に現場に投入した場合の不具合について見てみました。今回は、そのような状況を踏まえた上で、どのように活用するのが良いのか考えてみます。


ビジネスチャットを有効に活用するための秘訣

前回の記事では、うまくいかないことに着目しました。では、ビジネスチャットは、意識が高く、特定の職種の人たちだけにしか、その効力を発揮しないのでしょうか。本稿では、様々な工夫を実践し、利用者の気持ちを変えることで、問題点を克服出来、ビジネスを一歩前に進めることに着目します。以下に、ビジネスチャットの導入を成功させる秘訣を上げてみたいと思います。

一つ目は、「クイックレスポンス」です。何をおいても、スピードが最も大事です。チャットは短文による頻繁なやりとりを前提としています。細かな情報を投げられたら、それに対して細かく、出来るだけ早く返答を返すことで、次の情報を引き出します。それが第一です。返答できる時間がない場合には、絵文字一つでも、賛成or反対の二文字だけでもOKです。それがないと、話が進まず、チャットの魅力半減です。何らかの反応がないと、読んでないのか、異論がないのかすら分かりません。「この人は読んでたら必ず何かしらアクションしてくれる」ということが分かると、レスがなければ「読めてないんだな」というのが分かります。「内容によって都合が良い時だけリアクションする」ような対応は、相手に対して余計な判断の幅を与えることになり、シンプルで高速なコミュニケーションを阻害します。また、スレッドが伸びていて、議論が追えてないとか、返答を書けない場合でも、それを伝えておくことで、一旦やり取りをおいておいて他の事ができます。チャットは高速な返答をある程度期待するので、返答がない時間が長引けば、発信者は待ち状態のままでストレスを感じます。他のこともできません。何にしても、まずは会話をしている状態をつくるために、「クイックレスポンス」が最重要です。

二つ目は、「積極的な意思表明」です。「名指しされていないから、見てるだけにしよう」とか、「特に反対もないから、コメントも書かない」という姿勢では、発信者が自分の意見にフィードバックを得られず、議論が進みません。反対も賛成もなければ、話が深まりません。チャットは、会話を模したオンラインサービスと言えます。対面であれば「頷く」「相槌をうつ」という動作が伝わりますが、チャットでは、そうはいきません。積極的に反応することで、相手の次の言葉を引き出すことが、議論を活発にさせます。

三つ目は、「コミュニケーションツールの公式化」です。組織として公式なコミュニケーションツールとして、定めることで、多くの人が参加します。「慣れないから使わない」とか「ログインが面倒」とか「普段使う環境から遠いんだよね」という言い訳を許してはいけません。少なくとも、可能な時にはオンラインでいることで、「クイックレスポンス」も可能になります。トップダウンで、組織全体にこれを使うということを明確に示す必要があります。

四つ目は、「ストレスなく使える環境の整備」です。「ログインが面倒」であるとか、「開くまでに手間がかかる」というのは、利用者のストレスになり、利用率を下げます。可能な限り、チャットを利用するまでの敷居を下げなければいけません。モバイル端末で使えることや、通常利用するサービスとのシングルサインオンの有効化により、利用者が使うまでのステップを出来るだけ少なく、意識することなく利用できる環境を整備する必要があります。

五つ目は、「価値が有る情報を集める」ということです。見ない人が多いのは、そこに価値がないからとも言えます。価値がある情報が集まり、そこに参加していなければ仕事が立ち行かない状態になれば、かならず人は集まります。集まることで、より有用な情報が集まり、活発な議論が進みます。

六つ目は、「育てる努力」です。メールは、個別のやり取りの延長ですが、チャットは、「チャットルーム」といった特定の話題を扱うスペースがあります。上の「価値が有る情報を集める」にも通じますが、チャットの議論の進み方や、読んでない人の巻き込み方など、ツールをよりよく利用するためには、メディアとして育てる努力が必要であることを認識し、実行しなければなりません。「チャット導入したけど、誰も使わない」とか「一部の人が雑談するだけのツールになってる」というのは、使われ方を観察して、持っていきたい方向に育てる努力をしていないためであるとも言えます。導入したら即全員が有効につかえて、効果も抜群というものではありません。ユーザがその有用性を認識し、お互いに育てる努力をすることで、より価値がある情報があつまり、高速なコミュニケーションが実現でき、結果としてビジネスの活性化につながります。

ビジネスチャットを賢く使いましょう

チャット自体は、コンシューマでも広く使われていましたし、特定のコミュニティでは、もっと古くから使われていました。IT業界にある程度の年数いた方であれば、IRCやICQなどを使っていた方もいるでしょうし、現在ではプライベートでSNSのチャットを使っている方も多いでしょう。しかし、チャットが一般のビジネスの場でも注目され、実際に使われるようになったのは、ここ数年のことです。スマートフォンが普及し、ほとんどのビジネスパーソンがオンラインの状態で仕事をしています。コミュニケーションの必要がある時に、短い文章でさっと聞くことが出来、その答えがすぐに来る。激しい競争の中で、このような環境が求められ、サービスとして提供されるのも必然と言えるでしょう。ただ、上で見てきた通り、ただ入れただけでは、有効に活用できませんし、かえって利用者の負担を強いることになります。導入の仕方や、育て方について意識的に取り組むことが、ビジネスを次のステージに進めることにつながります。

来年も有益な情報を発信します

今年の記事はこれで最後になります。今年も一年ありがとうございました。来年は、より一層有益な情報をお届けできるよう頑張りますので、よろしくお願いいたします。

   Gluegent Gate

2019年12月18日水曜日

(続)ビジネスチャット導入が決定した。でもどうしたらいいの?

以前、ビジネスチャット導入時の、セキュリティ対策と利便性の両立について述べました。今回は、運用として考慮すべき点と、その解決に向けてのご提案についてお話したいと思います。


ビジネスチャットを含むクラウドサービス利用で、苦労しそうなこと

まず、そもそもですが導入するビジネスチャット以外にも、様々なクラウドサービスを既にご利用されているケースがあると思います。その場合、ユーザ側でそれぞれのサービス別のパスワードを管理されているのであれば、各ユーザに負担がかかってしまっていることになります。もちろん便利なパスワード管理ツール等も世の中にはありますが、今度はそれらツールの利用可不可の判断・コントロールなど、どんどん複雑になっていきますね。

大変なのは、ユーザ側だけではありません。
管理者も、(ビジネスチャットを含む)各サービス全てに必要なアカウントを作成し、初期パスワードの設定とユーザへの告知が必要になります。ということは、導入サービスの数が増えるほど…つまりビジネスチャットもですが…その管理コストが増大してゆくことになります。

さて他方、今回のテーマにしたビジネスチャットですが、「チャット」という名称がつくその特性上、どちらかといえば「気軽に」メッセージを投稿するものです。ですのでその中のやりとりを見てみると、組織の内情が赤裸々にわかってしまいます。意図して削除しない限り、コンフィデンシャルな情報がずっと残るものですしね。ということは、例えば組織を離れる人が出てきた際には、そのアカウントでその組織のチャットを利用/閲覧できないようにする対処が可及的速やかに求められます。

以上の問題を解決するGluegent GateのSSO

そこでGluegent Gateのシングルサインオン(SSO)を採用することにより、以上の問題を解決することが可能です。

まず、各サービスへのログイン時の認証が1つの画面に統合されることで、ユーザは「1つのパスワード」を利用するだけで各サービスを利用することが可能になります(これは、Gluegent Gateに限らず一般的なSSOの仕様です)。

管理者側としての課題は、各サービスのアカウント管理、それに各サービスへのアクセスコントロールです。
このうち各サービスへのアカウント管理については、Gluegent Gateにはプロビジョニング機能というものがあります。これは、対応しているサービスについては、Gluegent Gate側でアカウントを作成した際に、サービス側にもアカウントを自動的に作成出来る、つまりアカウントの同期が実現出来るものです。更にいえば、例えば3つのアカウント同期可能サービスを連携設定していれば、Gluegent Gateでアカウントを作成するだけで、その3つのサービスにも同時にアカウントが発行されることになるのです。つまり、サービスが増えれば増えるほど「楽ができる」というわけです。このプロビジョニング機能が可能、つまりアカウント同期が出来るビジネスチャットとしては、LINE WORKSとSlackがあります。特にLINE WORKSへのお問い合わせが最近増えている傾向にあります。他にはChatworkはプロビジョニングは対応していませんが、SSO連携が可能です。

またGluegent Gateのアクセスコントロール機能により、各サービスごとに接続可能なアカウントをきめ細やかに制限出来ます。これによって、あるアカウントが特定のサービスへの接続が不要となった際…例えば部署異動や退職が発生したときに、管理画面ですぐに対応することが出来ます。

更に、以前のエントリーにありますように、追加で証明書によるセキュリティ強化も可能となっています。

如何だったでしょうか。
以上のように、Gluegent Gateをご活用いただくことで、ビジネスチャットを始めとする様々なクラウドサービスへの接続について、きめ細かく、また出来る限りコストを抑えた運用が出来るものと思います。

もしご興味がありましたら、弊社までお気軽にご連絡くださいませ。

(Fuji)

   Gluegent Gate

2019年12月11日水曜日

Terraformのバックエンドで同じワークスペースでも環境を分けよう!

皆さん、こんにちは。グルージェント開発部のジャレド・ウォレスです。今回は前回の記事と少し変わり、エンジニア向けになってしまうかもしれませんが、技術の話をしたいと思います。皆さん、Infrastructure as Code(IaC)をご存じでしょうか?簡単にいうとコンピューティング・インフラ(仮想マシン、ネットワーキング等)の構成管理をコーディングで行う、という言葉です。Chef、Ansible、Puppet等、様々な管理ツールが存在しますが、最近ではTerraformという、Hashicorp様が提供しているツールが注目されてきています。弊社も開発ツールの環境の構築と操作でTerraformを活かしております。

Terraformの基本とバックエンドの必要性
Terraformでは、AWSなどのIaaSクラウドサービスを管理するコードブロック「resource」があります。複数のリソースを一緒に管理する時にモジュールにまとめることも可能であり、よく使うものはTerraform Registryからパッケージのようにダウンロードして使うこともできます。JSONのように、HCL(Terraformリソースを書く言語)は宣言的で読みやすいです。

しかし、せっかく書いたインフラコードをどう管理すればいいのでしょうか?ステートを定義する、人が読まない大量のJSONのtfstateファイルまでソースコントロールにコミットをするのも気持ち悪いですし、開発者の実行ローカルだけで管理するにデータロスの危険性もあり、プロジェクトが増えれば管理が難しくなります。なお、現在のTerraformでは全く同じインフラを複数の環境に分けて明確に管理する方法はありません。しかし、少し賢く使えば、リモートバックエンドがシンプルに解決してくれるので、その方法を紹介していきたいと思います。なお、リモートバックエンドの種類複数存在しますが、AWSのリソースを管理することが多いため、本記事ではS3タイプのバックエンドに注目します。

バックエンド定義と初期化
まず、サンプルのmain.tfを作成しましょう。

main.tf


ここに通常のリソースとAWS設定に空のS3 Backendブロックを追加します。空であることは別のファイルで詳細を定義することを意味します。その詳細は環境ごとに分けてバックエンド.tfvarsファイルを作成します。

staging.backend.tfvars


production.backend.tfvars



御覧の通り、リモートステートを任意のS3バケットのkeyで示すパスに置いて、ローカルから実行する運用になります。同じバケットでも、tfstateのkeyが違うのであれば問題はないので、ディレクトリで分ける( /staging/ 配下など)をおすすめします。こうして「開発者ローカルからの簡単さ」と「安全で一貫性のある」運用のバランスが取れます。ワークスペース初期化の際は以下のコマンドでできます。

terraform init --backend-config=staging.backend.tfvars



変数の定義と実行方法
変数ファイル(variables.tf)も似たような運用になります。

vars.tf


staging.tfvars


production.tfvars


vars.tfではデフォルト値のみを定義し、各環境の.tfvarsファイルに適切な変数を定義します。実行は以下のように行います。

terraform apply --var-file=staging.tfvars



ステージング環境が初期化されていればプランが表示され、確認してから実行します。



S3のバケットを見ればtfstateファイルの存在を確認できます。


まとめ
いかがでしょうか。Terraformコマンドの実行の際にフラグを忘れないこと等、少しややこしいところもありますが、かなりシンプルに環境の操作もできるようになります。S3の他にも、Hashicorp様が提供しているTerraform Cloudのリモートステート・バックエンドとクラウドからのTerraformコマンド実行もありますので、興味のある方は是非ご覧ください。

2019年12月4日水曜日

「予算を確認してから承認したい!」を実現させてみました

Gluegent Flowのご導入をご検討のお客様から、部門で予算が決まっているので稟議のときにそれを参照したいというご質問をいただきました。ちょっとしたアイディアで実現できましたので、皆様に共有いたします。

◯やりたいこと

「従業員から稟議書や物品購入申請書が提出されたときに、今期の予算、これまでの累積の実績額を勘案し、予算の範囲内だったらOK、予算オーバーならNGという判断をした上で承認したい」という運用を想定されています。
そこで、予算・利用額・差額をスプレッドシートに記述しておき、承認時の資料として参照する方法を検討しました。

◯実現方法
まず、スプレッドシートを作成します。
1シート目には上記のように「予算」「利用総額」「差額」を入力します。「予算」の下のセルには今期の予算額を直接入力します。
「利用総額」「差額」については後ほどご紹介します。
2シート目には「タスク番号」「利用額」を入力します。
このシートは申請されたタスクの各データが出力されます。2行目以降にタスク番号、入力された金額が出力されていきます。
1シート目に戻り、「利用総額」の下のセルには2シート目の「利用額」列の合計を算出する式を入力します。
「差額」の下のセルは予算 - 利用総額の式を入力します。
これで、スプレッドシートの作成は完了です。2シート目には実際には他の入力項目などもあるでしょうから、そのときは、それに応じて1行目に項目名を入力してください。
今回のポイントは、利用額の合計が1シート目に計算されて表示され、予算との差額が表示されることです。

続いて、モデルを作成します。「入力フォーム」にてタイプが数値の「利用額」という項目を作成します。
他の項目は運用に併せて作成してください。
「経路」にて、「承認待ち」の経路に「スプレッドシート行追加自動処理」を追加します。

自動処理の設定内容は以下の通りです。「ドライブ名」は「直接ドライブの項目を指定」を選択し、上記で作成したスプレッドシートを選択します。「シートの名前」は2シート目のシート名を入力します。
申請のときに「スプレッドシート行追加自動処理」を設定してはいけません。承認のタイミングで、予算や差額を確認した上で、承認を行うために、自動処理は承認後に実行しなければいけません。

◯動きを確認してみる

これで、設定は完了です。では、実際に挙動を確認してみましょう。
最初は予算が100万円、総額は0円になっています。
1回目は10万円の稟議をあげてみましょう。

続いて、承認者が対象のタスクを開きます。
利用総額と予算を確認するために、先程のスプレッドシートの1シート目を見て、「予算内だからOK」ということで承認します。

そうすると、今度は2シート目にタスクの入力内容が出力され、1シート目が変化します。



いかがでしたでしょうか。このように、スプレッドシートとの併用で実現できる方法があります。皆様も創意工夫して業務にGluegent Flowを活かしてください。もし「こんな使い方ができるよ!」「うちではこんな使い方しています!」というアイディアがございましたらどんどんお寄せください。このブログでご紹介させていただきたいと思います。
(SUTO)

 

2019年11月27日水曜日

ビジネスチャット導入しただけで、仕事がうまく回ると思ってませんか? (2)

今回は、ビジネスで広く受け入れられている「メール」と、その後継になりそうな勢いの「ビジネスチャット」の特徴を分析します。その上で、ビジネスチャットをただ「入れただけ」では、有効に機能しそうにないポイントを列挙してみます。


現在のビジネスのやり取りの王道は「メール」

ビジネスの現場で利用される コミュニケーションの方法は、その時代によって様々に変わってきました。インターネットが一般に普及する前は、電話や対面での「会話」が主流でした。その後、インターネットが普及し、多くのビジネスパーソンが自分のメールアドレスを持つようになってからは、「メール」が主流になったと言えるでしょう。最終的には、対面での会話でビジネスを成立させることになりますが、そこに至るプロセスの多くで、メールが使われます。

メールは、電話を含む直接的な対話と比べて、ビジネスにマッチした特性を備えています。いくつかありますが、大きなポイントは以下の2点であると思います。

・コミュニケーションの内容が文章として残る
・やりとりが非同期であるため、時間的空間的拘束を排除できる

一点目は、コミュニケーションの内容が、関係者が共有する形で残るという点です。これにより、対面の会議の際の議事録の役目を果たし、決定したことや、そこに至るプロセスが明確になります。ビジネスの場では、非常に重要なポイントです。さらに、Gmailのような検索性に優れたメールシステムの活用により、より高いメリットを享受できます。

二点目は、情報のやり取りの際に相手を拘束しないという点です。メールを書いている時も、読んでいる時も、相手は時間的、空間的に拘束されません。直接対話の場合は、同一時間に同一の場所にいる必要があります。電話は、離れた場所でも良いですが、時間的には拘束されます。ビジネスシーンでは、限られた時間の中で最大の成果をあげることが求められますが、会議等があれば、移動等も含めると、数時間特定の案件だけに、人的リソースがロックされることになります。非同期のやり取りであれば、都合が良い時に情報の発信と受信が出来ます。こま切れの時間でも、移動中でも、相手の都合を気にせずに、情報のやり取りができるのは、効率が良いと言えます。

このような利点から、ビジネスの場では、広くメールが活用され、様々なコミュニケーションの中心となっています。

直接対話とメールの間

前項で述べた特徴が広く受け入れられ、メールは、ほぼ全てのビジネスの現場で活用されています。ただ、以下のような、不都合を感じたことはないでしょうか。

・メールの文章の言葉が足りていないため、誤解が生まれている。そして、やり取りのテンポが遅いために、その状況がなかなか解消しない。
・対象とする問題が複雑で、メールの本文が長大なものとなり、読むのも、返答するのも苦労する。

このようなケースでは、メールという手段にこだわらず、直接対話した方が良いでしょう。全てのビジネスマンが簡潔で要点をおさえた文章をかけるわけではありません。やり取りしたい内容をよく考えて、適切なコミュニケーションを取る必要があるようです。また、反対に、

・メールでの通知で十分であったり、話す内容も多くないのに、会議の時間が設定されて、時間が無駄になる。
・事前に議題の周知もなく、会議が始まってから、全くのゼロから議論を開始することになり、情報が足りず、議論が煮詰まらない。

このようなケースでは、メールを活用するべきでしょう。「それ、メールの通知だけで良いですよね?」というような会議は日常的に経験されているのではないでしょうか。または、直接対話することを前提としていても、そこに至る前にメールで情報が周知されていれば、より有意義な対話が可能になるものです。

しかし、なるべく早く結論を出す必要があり、かつ内容があまり明確になっていない場合などには、直接対話とメールの間にあるようなツールが必要ではないでしょうか。

ビジネスチャット登場

ビジネスチャットは、前述したような「直接対話とメールの間」のようなツールと捉えることができます。直接対話とメール、チャットの特徴をあげて比較してみましょう。それぞれ様々な特徴がありますが、比較しやすいような項目をあげています。

直接対話の特徴
・内容が文章として残らない。
・同期コミュニケーションのため、参加者全員の時間を拘束する。
・やりとりは、リアルタイムで、テンポが早い。

メールの特徴
・文章が残る。
・非同期コミュニケーションにより、相手を拘束しない。
・文章が比較的長め。
・やりとりのテンポが遅い。

チャットの特徴
・文章が残る。
・非同期コミュニケーションにより、相手を拘束しない。
・文章が短い。
・やりとりのテンポがメールよりも早い。

チャットは、内容も残るし、テンポが早く、相手もロックしないという、ビジネスに有利なポイントを備えていて、構造的には非常に優秀なツールのようです。

ビジネスチャットを使うことでコミュニケーション問題は即座に解決するのか?

では、ビジネスチャットを導入することで、コミュニケーションがより効率的に、活発になり、ビジネスが加速するのかというと、そう簡単ではないようです。以下にビジネスチャットの「うまくない点」について思いつく限り、挙げてみます。

・メールでのやりとりが確立している環境では、利用率が上がりにくく、一部の人だけが利用するにとどまる場合がある。そのため重要な情報がどちらか一方だけに配信される。これを防ぐために、双方に情報配信するものの、隔絶された場でそれぞれ議論が進むため、結果的に合意形成されることはなく、情報伝達や議論の目的が達成されない。

・チャットを利用していても、返信が遅い、あるいは返信しない人がいる。慣れていないためか、あるいは、いつも見える環境にいないのか、チャットアプリ自体にたまにしかログインしないためと考えられる。重要な情報を握っていたり、決定権を持っている人が遅いと全体のテンポを下げて、チャットの利点が失われる。

・オンラインの人だけで話がすすみ、結論に至るが、それまでオフラインだった人が最後に登場して、結論が覆るようなことがある。議論するべき内容のステークホルダー全てがオンラインでない場合には、結論を出しにくい。つまり、やりとりのテンポを維持するためには、オンラインであることを強いることになる。参加者を拘束しているとも言える。

・職種によって、オンラインでいるかどうか、投稿できるかどうかという点で差があり、やりとりのテンポが異なる。テンポが異なると、一番遅い人に合わせることになり、チャットの利点が損なわれる。

以上のような問題は、チャットを導入した多くの環境で感じられることと思いますし、他にも、環境特有のものも含めて、多く出てくるでしょう。「入れただけで解決」とはいかないようです。そう甘くはありません。

次回は、ここで上げた問題点を解決する秘訣を探ります。

   Gluegent Gate

2019年11月20日水曜日

台風来る時は出社しないで自宅作業!だけどセキュリティは担保したい!


安全な環境であれば、自宅でもビジネスを遂行したい

昨今、BCP対策についてご相談を受けるケースが増えてきました。 地震等の予期せぬ災害もありますが、台風などの想定された災害の場合、もちろん生命が最優先されますが、自宅の安全が確保されている場合、そういった場所での作業を許可するケースについて、セキュリティをどのように強化すればよいか、またその運用方法について、話したいと思います。
このブログでも何度か記載していますが、普段オフィス内で作業されている環境に加えて、オフィス外での作業を行う事になった際は、ID/パスワード認証に加えてクライアント証明書による認証も行う、いわゆる多要素認証とすることが一般的になってきています。つまり、災害発生時など、いざオフィス外での作業が発生した場合には、ID/パスワード+クライアント証明書による認証方法への切り替えるということになります。

Gluegent Gateでは…

例えばGluegent Gateでは、まず認証としてID/パスワード認証を作成します。

そしてアクセス権限設定で、以下の2つのルールを設定します。
・ID/パスワード認証かつ特定IPからの接続制限(有効)
・ID/パスワード+証明書確認、IP制限なし(通常時は無効)


※IPアドレス制限設定画面

そしていざ社外からのアクセスが必要となったときには、上記2行目のアクセス権限ルール(画面内access_2)を「有効」に変更します。これだけで、社外からのアクセスに対して、ID/パスワード+クライアント証明書による認証になります。


ただし、認証に証明書が必要になったということは、ユーザ側への証明書の配布も必要となります。そこでGluegent Gateでは、端末認証 WEB / 証明書付き(NRA-PKI)オプションをご契約いただくと、Gluegent Gate管理画面でクライアント証明書を発行可能で、その証明書は各ユーザ側でGluegent Gateユーザポータルからダウンロード出来ます。

以上より、クライアント証明書の認証と、その運用をトータルでご支援出来る内容となっています。

予期せぬ事態発生時には

予期された災害への対応策を講じることは比較的容易ですが、予期せぬ事態が発生した場合には、いかに速やかに対処出来るか、ということが求められます。

そこで、避難訓練のように、運用者は認証方法を変更した場合の設定変更について、ユーザは挙動などについて予め体験しておくと良いかと思います。そして出来れば一連の内容をマニュアル化しておき、全てのユーザが閲覧出来るところに設置されることをオススメします。
(Fuji)

   Gluegent Gate