2020年2月26日水曜日

【この機能はこうして生まれた】グループキャッシュの更新処理は4時固定ではなくなりました

弊社で提供している各種サービスに新しい機能を実装するとき、お客様の声をもとにしていることは以前「お客様の熱い想いが機能充実に繋がります。ぜひご要望をお寄せください。」でご紹介した通りです。
今回は、グループキャッシュの更新処理の開始時刻が変更できることについてご紹介いたします。

◯グループキャッシュの更新とは?

Gluegent Apps 共有アドレス帳・Gluegent Apps グループスケジューラ・Gluegent Flowをご利用いただく場合、ユーザーやグループの情報はG Suite/Office 365から取得しています。データ源泉がG Suite/Office 365なので、共有アドレス帳・グループスケジューラ・Gluegent Flowでユーザーやグループを作成する必要がないのです。
G Suite/Office 365のユーザー・グループ情報の取得は1日に1回行われます。これを「グループキャッシュの更新」と呼んでいます。
古くからお使いいただいているお客様は「グループキャッシュの更新処理といえば4時から始まる」というイメージがあると思います。
各サービスの提供開始から長らく早朝4時開始固定となっていました。
実は、現在、グループキャッシュの更新処理開始時刻は変えられるんです。

◯なぜ4時開始だったのか?

グループキャッシュの更新処理は1日に何度も実行すると、サーバーに負荷がかかってしまい、サービスのご利用に支障が出てきかねません。そのため、1日に1回、日本のユーザーが使っていないであろう4時に開始するようにしました。
ユーザー・グループ数が極端に多くなければ、一般的な業務開始の9時には終了しているという設計のもとに、4時開始としていました。
しかし、ご契約いただいているお客様が増え、ユーザー数が大きいお客様にもご利用いただくようになり、4時開始では業務開始に間に合わないというケースが散見されました。また、海外の拠点を持つお客様の場合、日本時間の4時は海外拠点ではまだ業務時間中というケースもあります。
そういったお客様のお声に応えるため、グループキャッシュの更新開始時間を変更できるよう対応することにいたしました。

◯グループキャッシュの更新処理開始時間の変更方法

それでは、グループキャッシュの更新処理の開始時間を変更する方法をご紹介します。
(操作は特権管理者権限を持つユーザーで行ってください)
共有アドレス帳
共有アドレス帳にアクセスします。
画面右上のギアアイコンをクリックし、「ドメイン設定」をクリックします。
グループキャッシュの「開始時刻設定」のドロップダウンで時刻を変更してください。

グループスケジューラ
グループスケジューラにアクセスします。
画面右上のギアアイコンをクリックし、「設定」をクリックします。
「ドメイン設定」をクリックします。
グループキャッシュの「開始時刻設定」のドロップダウンで時刻を変更してください。

Gluegent Flow
Gluegent Flowにアクセスします。
画面右上のギアアイコンをクリックし、「ドメインの設定」をクリックします。
グループキャッシュの「開始時刻設定」のドロップダウンで時刻を変更してください。

◯開始時刻設定の賢い使用方法

上記でご紹介したように、各サービスでグループキャッシュの更新処理の開始時刻が設定できます。
例えば、新入社員が入社するときは、前日までにG Suite/Office 365でユーザーを作成して、所属グループにメンバーを追加するという運用をしているとしましょう。
連絡が漏れていて、新入社員の入社日が今日だった!?という場合、今までは明日まで待っていただいていました。開始時刻設定を変更できるため、大急ぎでユーザー情報を登録し、10時に開始するよう設定すれば、ギリギリ間に合います。

いかがでしたでしょうか。これを機にグループキャッシュの更新処理の開始時刻を利用状況に合わせて変更してみてはいかがでしょうか。また、急な実行が必要になったときはここで紹介したような方法でご対応ください。
お客様から「こうしたらもっと便利になるのに」というご意見がございましたら弊社サポートまでぜひお寄せください。
(SUTO)

 
 
 

2020年2月19日水曜日

【実録】 テレワークやってます(5)「心理的安全性」の確保

随分間が空いてしまいましたが、前回は、<実録> テレワークやってます(4) テレワークだとこうなります〜時間の使い方〜と題して、時間の使い方の実例をご紹介しました。今回は、テレワークという働き方における「心理的安全性」について書いてみます。


「心理的安全性」とは

「心理的安全性(Psycological Safety)」という心理学での捉え方があります。このテーマが提唱されたのは、1999年ですが、近年Google社内の調査で触れられたことで、一般にも、より広く知られるようになりました。Googleの調査に端的な説明がありましたので、引用します。

心理的安全性: 心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。心理的安全性の高いチームのメンバーは、他のメンバーに対してリスクを取ることに不安を感じていません。自分の過ちを認めたり、質問をしたり、新しいアイデアを披露したりしても、誰も自分を馬鹿にしたり罰したりしないと信じられる余地があります。
出典:「効果的なチームとは何か」を知る

この調査では、チームが効果的であるためには、どのような要素が寄与しているのかを調べ、最も影響するのは、「心理的安全性」であると結論付けています。今回は、日常的にテレワークの環境にあるチームメンバーの立場から、「心理的安全性」に注目して、まとめてみます。

テレワークでのチームの力学

前回までの記事で、テレワークでは様々な制約があることを見てきました。チャットやビデオ会議のようなツールを使うことで、物理的な距離やコミュニケーションの問題を軽減できることも示しました。しかし、チームから離れて単独で仕事をするのは、孤独感やチームへのコミットメントなど、「気持ちの上での問題を抱えやすい構造」であるのは、事実でしょう。特に、自分以外のメンバーは同じオフィスで仕事をしているようなケースでは顕著です。コミュニケーションに一定の制約がある場合と、そうでない場合が異なるのは、当然の事と言えます。
上で引用したGoogleの調査では、「チームメンバーの働き場所(同じオフィスで近くに座り働くこと)」は、効果にそれほど影響しないとされています。ただ、これはGoogle社内の調査結果です。多くの企業では、働き場所がチームの効率に影響するという方が考えやすいのではないでしょうか。特に日本国内で働くビジネスパーソンは、オフィスで机を並べて働くことが当たり前になっている状況です。しかし、Googleの調査結果は、働き場所に影響されない効果的なチームを作ることは可能であるということも示唆しています。
新型コロナウィルスの感染リスクや、東京オリンピックの開催を受けて、テレワークというスタイルへの要求が急速に強まっています。テレワークになったとしても、効率的なチームで成果を出せるのであれば、日本企業の当たり前が変わる契機になるのかも知れません。

実感としての「心理的安全性」と確保のためのコツ

筆者は、比較的長くテレワークの状態で仕事を続けていますが、「心理的安全性」を確保出来ていると感じています。チームの中でも、会社全体の中でも、「発言することでリスクがあること」を発する事に、不安感を感じることは殆どありません。問題領域の範囲を俯瞰し、議論の幅を広げるために、あえて、取りにくい意見や選択肢を出してみることもあります。そのような意見でも論理的な反論をチーム全体で検討することで、より本質に近づく議論をすることが出来ます。
このように「心理的安全性」が確保出来ているのは、いろいろな要因があると考えられますが、個人としては、以下の項目を心がけています。

(1) 意見が客体化できていること
その発言は、自分(主体)そのものとは分離(客体化)された「考え方」に過ぎないことを意識する。その考えが評価・批判されたとしても、それは、自分(主体)に対してなされたものではない。

(2) 心理的距離感が出ないようにする
物理的な距離は仕方ないが、心理的に距離が出ないように、できるだけ形式ばったコミュニケーションを廃する。礼儀は大事だが、儀礼的な枕詞や手続きを使わないようにする。

(3) 意見の多様性を許容する
自分が同意できない意見についても、まずは受け止めて、論理的な検討をする。立場や考え方の違いを考慮して、異なる意見も許容する。

心がけているものの、うまく行かないこともありますが、概ね自分の「心理的安全性」は確保できていると感じます。一方で、他のチームメンバーにも「心理的安全性」を確保してもらうためには、以下のような努力が必要であるように思います。

(1) 礼儀大事
必要以上に儀礼的である必要はないが、礼を持って接する。不遜な態度は心理的な距離につながる。テレワークでは特に伝えられる言葉以外の手段でのコミュニケーションが取れないため、使う言葉が適切かどうかを考えてから伝える。

(2) 相手の意見を否定する時には、ピンポイントで。できれば代案を。
評価できる点、出来ない点を明確にする。可能であれば、代替案を示す。代替案がない場合でも、前進させる姿勢を示す。

(3) 正論より配慮
反論を許さない正論は、議論を停滞させる。相手の意見を叩き潰すための正論による反論は暴力でしかない。相手の意見に寄り添った立ち位置からの発展的な批判をする。正しいかどうかは問題ではない場合も多い。

テレワークでこそ「心理的安全性」への配慮が重要

「心理的安全性」を持てるかどうかという点は、テレワークに限らず、留意するべきものですが、テレワークの場合、それが損なわれていても、分かりにくいものです。毎日会っていれば、表情や雰囲気から分かるものも、リモートにいるメンバーの心理状態は把握しにくいでしょう。適切にサポート出来ていないために、チームの活動が滞ったり、最悪の場合は、いきなり退職ということもあるかも知れません。
「心理的安全性」にだけ注目していれば良いわけではありませんが、今後、ますます場所にとらわれない働き方が当たり前になってきます。そのような時代には、今まで以上に「心理的安全」というものを意識していくことで、メンバー全員が幸福で安心した気持ちで働くことが出来、チームの力が最大化されるものと思います。
(ま)

   Gluegent Gate

2020年2月12日水曜日

Gluegent Flow活用例:添付ファイル名をそのままG Suite上で共有するには?


Gluegent Flowには、申請時の添付ファイルをそのままG SuiteのGoogle Driveにアップロードできる自動処理があります。その上で今回は、アップロード後のファイル名を、添付したファイルのファイル名にする小技をご紹介します。

入力フォームの準備

まず、添付ファイルの入力フォームを追加します。ここでは、”ファイル1”とします。「複数添付することを許可する」にはチェックしないでください。(今回の小技は、1入力フォームにつき1ファイルのみの技となります。)

次に、プレースホルダーにより、上記ファイル名を内部的に入れておく領域としてカスタムラベルを追加します。今回は名前を”カスタムラベル1”として、フロー上は必要がないので、非表示としました。

決裁時の自動処理登録

ファイルをアップロードしたい経路の「自動処理設定」で「+」ボタンをクリックし、自動処理の追加ダイアログを表示します。

添付ファイルアップロードの「+」ボタンをクリックします。


添付ファイルアップロードの設定画面に必要な項目を入力します。今回の例では、${カスタムラベル1}が添付元のファイル名となります。今回は、ファイル名が重複しないよう、タスク番号とファイル名を組み合わせて、${タスク番号}-${カスタムラベル1}としました。タスク番号を前にしたのは、拡張子がファイル名の最後についている場合があるためです。オーナーについては必要に応じて設定します。今回は処理者としましたが、申請者、フォロワーも設定可能です。添付ファイル項目名は、今回の場合は「ファイル1」となります。

以上でモデルを保存します。

実際に試してみる

それでは実際に申請して動作を試してみましょう。上記で作成したモデルから申請を始めてみます。下図は、「サンプル.xlsx」というファイルを選択したところです。


そして、このまま決裁完了まで進めてみます。そして、自動処理が設定された決裁経路が完了すると、以下のようにファイルが添付ファイルのファイル名そのままに(今回はタスク番号付きで)アップロードできていることを確認できます。


いかがだったでしょうか。このように、Gluegent Flowの機能を組み合わせることで、ちょっとした運用をスマートに自動化することが可能です。これ以外でも、皆様の方で新しいアイデアなどありましたら、是非お寄せいただければと思います。
(Fuji)




 

2020年2月5日水曜日

アメリカ人からみた「キャッシュレス社会」

背景

アメリカ人の私にとっては、キャッシュレスで払えることが幼い頃からでも当たり前のことであり、日本に来る前に意識したことがありませんでした。日常的にお金を使うようになった頃、自分の銀行口座を開いてデビットカードを作成しましたが、その時からずっと、ネットでの買い物はもちろん、店頭での買い物や(PayPalによる)友人にお金を送ることもデビットカードを使って支払うことがすべてでした。通常お財布に現金が入っていることが珍しく、持っていても4000円程度で祖父などお年寄りの方からお小遣いとしてもらったもののみでした。このような決済文化は決して珍しくもなく、30歳以下の方ならば一般的と言えるでしょう。
その文化圏から初めて海外に旅行し「素晴らしい技術の国」日本に足を踏み入れてみると多くのお店で現金のみの支払いという現実を見せられ、どのくらい驚いたか皆様想像つきますでしょうか?観光活動の半分程もカードが使えなかったので、何回もATMを利用し海外の口座からお金を下ろさなければならず、外貨両替手数料とATMの利用手数料が思いのほか、かかってしまいました。旅行者が感じるカルチャーショックと言えばそれまでなのですが、正直にいうと、日本に住んでいる今もまだそう感じることが少なくありません。

意外と長所もある

一方でキャッシュレスじゃない状態であることが国の評価に対してオールマイナスということもありません。盗まれたりする恐れがあるため、多くの海外の国では数万円程度でも現金を持つことが危険だと思われています。そういう意味では現金払いが主流の日本は安全であるという証なのかもしれません。そして、個人としてお金を使うときにカードより現金で支払った方が無駄遣いをしないと学術的にも証明されているため、預貯金しやすくなる効果があるとも言えるでしょう。
昔ながらのお店で会話しながら買い物するようなお店では情緒的にも現金決済が似合うところもあるかもしれません。

また、キャッシュレス社会はプライバシーとセキュリティの悩みが多いでしょう。
ネットを使った決済の場合、セキュリティの穴を突かれることが心配ですね。大手コンビニのキャッシュレスアプリが不正利用され、サービス廃止に追い込まれたことは記憶に新しいです。
プライバシーという側面では、ネットショッピングをした際、買ったばかりの商品や関連アイテムの広告がGoogleを含めて様々なウェブサイトやアプリに表示される体験をしていると思います。キャッシュレス決済も個人の買い物歴情報が集められ、期待しない利用をされることもあるでしょう。当然ですが、現金で払う場合個人情報提出は不要なので、買い物の履歴を大切な個人情報と感じる人にとっては現金払いの方がキャッシュレスよりも有利になりそうです。

使えるところが限られていたりする

しかし、最初からキャッシュレス社会で生きていたアメリカ人の私にとっては、日本のキャッシュレス事情には軽い絶望すら感じてしまいます。出かける際に行くお店が決まっているならともかく、ぶらりと外出する際に現金を使わずに買い物ができる保証はあらず、仮にキャッシュレスで払えるとしてもたまたま入った店で自分のキャッシュレス決済方法が使えるとは限らないからです。私の近所のスーパーもクレジットカードが使えますが、Apple WalletやGoogle Payのようなアプリ決済やSuicaとPasmoの交通系電子マネーでは支払えない状況です。クレジットカードに関しても外国で発行されたものであれば手入力しないと使えなかったり不明エラーで拒否されたりすることもあり、かなり不便で過ごしにくい環境だな、と感じてしまうことがあります。

個人的になぜこうなっているのか?と思ってしまうのは「全ての人がどこでも使える」キャッシュレス決済がまだ存在しないことです。アメリカではメジャーなデビットカードが人気になれていないのもどうしてなのか理解できていません。日本人の友人に聞いたところ、クレジットカードとデビットカードの違いが分からない人もいて、大変驚きました。ともかく、セキュアでどこでも使える理想的なキャッシュレス決済の登場がなければキャッシュレス社会に対しての考え方を推し進めることは難しいのかもしれません。

ジャレド・ウォレス

2020年1月29日水曜日

どんどん増える! Works with Gluegent 第一弾公開

そもそもWorks withって何でしょう?よく耳にするところだと、Works with AlexaやWorks with Google Assistant, Works with Apple AirPlay あたりもあるでしょうか。辞書で引くと、”works with 〜”は「〜と動作する」、つまり”Works with Alexa”は「Alexaと動作する」ということになります。

Works with Alexaの場合は、『応答性、信頼性、機能性の高い基準をクリアし、ユーザーに対して最高のスマートホームエクスペリエンスを保証する認定プログラム』(Amazon Alexaのサポートページより抜粋)とあります。認定されることでその製品との動作を保証されるため、ユーザーに信頼して利用してもらうための指標になるのではないでしょうか。

Works with Gluegent はじめました。

このたび Gluegent も、Gluegent シリーズの製品を安心してご利用いただくために、Works with Gluegent を公開しました。Gluegent シリーズ製品と連携可能なサービスを、連携方法に応じた以下の3種類で定義して、約40サービスを提示しています。

(1) プロビジョニング(アカウント)連携
対象サービスに対して、アカウントやメールアドレス、グループ、組織などのユーザ関連データをプロビジョニング(作成・更新・削除)します。これによりユーザ関連データを一元管理できます。 

(2) SSO(シングルサインオン)連携
対象サービスに対するログイン認証を一元化します。一つのログインで、複数のサービスに対する認証・アクセス制御が可能になり、利便性とセキュリティが向上します。

(3) 機能連携
対象サービスと連携して Gluegent シリーズの各種機能を拡張します。クライアント証明書による多要素認証の強化や、セキュアブラウザによるデータ保全の強化、BOT 連携による通知の強化など Gluegent シリーズが提供する機能以上の連携が可能となります。

▶︎ Works with Gluegent のページ
https://www.gluegent.com/service/workswith/

どんなサービスがどんな機能でGluegent製品と連携できるのか、ぜひご覧ください。また、今後も月次でアップデートしていきますので、最新情報はこちらでご確認ください!

 
Works with Gluegent

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コマンド実行もありますので、興味のある方は是非ご覧ください。