株式会社クイックのWebサービス開発blog

HAPPYなサービスプランナー・エンジニア・デザイナーのブログです。

【Windows 10 Pro】業務時間外のPCシャットダウン方法について

お久しぶりです。シスアド 兼 情シス担当のスカイ(甘党)です。

夏ですね~!はい、今回も「あるあるPC管理者の悩み」を書かせて頂きます。

第四回あるあるPC管理者ネタは働き方改革で話題になっている、
業務時間外はPCを強制的にシャットダウンしたい」です。

働き方改革の一環で「PCを強制的にシャットダウンする」ツールを導入した結果、
長時間労働が是正されました!って事例を最近よく聞きますよね。

個人的に、いつ導入検討と言われてもおかしくない状況になってきたかと思います。
終業時間が強制される事により生産性があがるのか疑問ではありますが、
本題へと移りたいと思います。

要件

業務時間外になったらPCを強制的にシャットダウンしたい\(^o^)/

  ※Windows 10 Pro環境で検証済です。
  ※前提条件はActive Directory環境がある事です。
  ※あるある管理者ネタなので新規ツールを導入する予算はないものとします。

はじめに

まず要件を細分化して箇条書きにしてみます。

平日(月~金):勤務間インターバルを11時間で設定。
 A.21:00にPCのシャットダウンを実施する。
 B.08:00~21:00はPCにログオンができる。
 C.21:01~07:59はPCにログオンができない。

休日(土日):簡単に説明がしたいので祝日は除外。
 D.24時間PCにログオンができない。

Aはタスクスケジューラとshutdownコマンドで設定ができます。
B、C、DはActive Directoryを利用して設定ができます。
分けて考えてみると、1つ1つの作業が簡単であることがわかりますね。

設定方法

シャットダウン時間をタスクスケジューラに登録する方法(箇条書き:A)

 ①タスクスケジューラから「タスクの作成」をクリックします。
   [名前]を入力し[セキュリティオプション]を変更します。
  f:id:aimstogeek:20190711155113p:plain

 ②トリガータブを開き「新規」をクリックします。
   [毎週]、[21:00]、[曜日]を変更します。
  f:id:aimstogeek:20190711160033p:plain

 ③操作タブを開き「新規」をクリックします。
   [プログラム]に「C:\Windows\System32\shutdown.exe」と入力し、
   [引数]に「-s -f -t 30」と入力します
  f:id:aimstogeek:20190711155508p:plain

ログオン時間制限設定手順(箇条書き:B、C、D)

 ①Active Directoryで対象ユーザーのプロパティを開きます。
  f:id:aimstogeek:20190711150152p:plain

 ②[アカウント]タブの[ログオン時間]をクリックします。
  f:id:aimstogeek:20190711150208p:plain

 ③月~金の21:00~8:00、土日の全時間を「ログオン拒否」に設定します。
  f:id:aimstogeek:20190711150219p:plain

設定時の動作

業務時間外にログオンを試みますと以下のようになります。
  f:id:aimstogeek:20190711150632p:plain

さいごに

最低限の要件を満たしていますが注意点があります。
Active Directoryを利用する為、社内NWに接続している環境である事が条件です。
 =キャッシュでログオンする際には設定の影響なくログオンができます。

わかりやすく言いますと抜け道があります/(^o^)\
ノートPCであれば自宅に持ち帰りPCを起動しログオンする事が可能です。
※上記で述べたキャッシュでログオンしている為。

ローカルにデータがある状態であれば自宅で仕事ができますので、
データを持ち出される事でセキュリティリスクが高まってしまいます\(^o^)/

PCの持ち出しができない環境のみで有効である手法でした....(´°̥̥̥̥̥̥̥̥ω°̥̥̥̥̥̥̥̥`)

今回の案は運用検討時にボツとなりました!失敗あるある~~!!

おまけ

私個人の持論ですが、働き方改革における情シスの役割とは
ITを利用して業務改善を手伝い、便利にしてハッピーにする事だと思っています。



\\一緒に『明日のはたらくを創る』仲間を募集中です!! // 919.jp

デザインの領域から考えるこれからのデザイナーのあり方

f:id:aimstogeek:20190704153930j:plain

こんにちは、デザイナーのachanです。

昨今、グラフィックデザイン・プロダクトデザイン・UIデザイン・UXデザイン・インタラクションデザイン・サービスデザインなど、たくさんのデザインが存在し、 デザイナーに求められる範囲が非常に広くなってきていて、これからのデザイナーのあり方はどう変化するのかと色々考え始めました。

そもそもデザインって何?

一般的に「デザイン=見た目」という意味として捉えている人が多いと思います。
しかし、デザインをめぐる解釈は決して一様ではないので、それは正しい認識だとは言えないと考えています。

デザインについて大辞源ではこう解説されています。

1 建築・工業製品・服飾・商業美術などの分野で、実用面などを考慮して造形作品を意匠すること。「都市をデザインする」「制服をデザインする」「インテリアデザイン」
2 図案や模様を考案すること。また、そのもの。「家具にデザインを施す」「商標をデザインする」
3 目的をもって具体的に立案・設計すること。「快適な生活をデザインする」

大辞林では、

作ろうとするものの形態について、機能や生産工程などを考えて構成すること

Wikipediaでは、

デザインは日本語では「設計」にもあたり、「形態」や「意匠」と訳されてきたが、それだけに限らず、人間の行為(その多くは目的を持つ)をより良いかたちで適えるための「計画」も意味する。

上記の解説の共通点からみると、
デザインは目的意識を持って機能や形態を設計・計画していくということがわかります。

また近年では、「デザイン思考」*1や「スペキュレイティブデザイン」*2などという考え方をよく耳にするので、そこで色々学んだ結果として、
私は「デザイン= 問題解決 + 価値創出」という自分なりの結論に至りました。
f:id:aimstogeek:20190704154116j:plain

デザインの領域

デザインの領域と言えば、一般的には下記のようなものを思い浮かべるでしょう。

  • 建築、インテリア、ステージなどの空間デザイン
  • 乗り物、家電・電子機器などの工業製品のインダストリアルデザイン
  • 広告、エディトリアル、インフォグラフィックなどのグラフィックデザイン
  • 縫製や服飾造形などのファッションデザイン

しかし、これらはまだ伝統的な分野のデザインだと言えます。

コンピューター(計算機)の誕生・発展とともに、デザインの対象は「モノ」から「コト」にシフトしてきました。即ち今まで通りのサービスや製品を提供するだけでは、ユーザーに感動を与えられない時代になっています。
そのため、デザインは下記のような領域に広がっています。

  • UIデザイン(ユーザーインターフェース)
    ユーザーと機械、コンピューターの接触面のデザイン、および接触面において行う操作方法の設計のこと。
  • インタラクションデザイン
    システム開発において、ユーザーの入力操作に対するシステムからの適切な反応を設計すること。利用目的に合致した画面遷移や、GUI 要素の自然な振る舞いをデザインすること。
  • UXデザイン(ユーザーエクスペリエンス)
    ウェブサイトやアプリ、電化製品など、単一のシステムや商品、モノなどを対象としてユーザーが使用する前、使用している間、使用した後までを含めた体験をデザインすること。
  • CXデザイン(カスタマーエクスペリエンス)
    広義のUXデザインと呼ばれている。ウェブサイトやアプリといったプロダクトだけでなく、コールセンターの対応やリアル店舗での接客など、人に関するものも対象となる。
  • サービスデザイン
    基本的にはUX設計に加え、リサーチやアイディア展開、試作等を通してサービスの体験を改善すること。
  • ビジネスデザイン
    デザイン思考という概念を具体的ビジネスに落とし込み、市場分析や財務分析、ビジネスモデルを策定すること。
  • ソーシャルデザイン
    どのような社会を築いていくのかという計画。
    ...

これからのデザイナーのあり方

次々と広がるデザインの領域。
現場では求められる能力が広く複雑になり、何を学び、どんな経験を積んでいけばいいか分からないのが正直なところではないでしょうか。

以前、私自身もデザイナーとして、将来像を見通すことはなかなか難しいと感じていて、今後、実装まで含めたエンジニアリングの部分を強化していくのか、ビジネスレイヤーから思考力を鍛えていくのか、それとも感性や造形の美を追求していくのかを悩んだ時期がありました。

その中で、デザインとテクノロジーの融合を追求する第一人者として知られるジョン・マエダ氏の「Design in Tech Report 2016」からヒントをもらいました。
彼は、これから必要とされてくるデザインとして、 「クラシカルデザイン」「デザインシンキング」「コンピュテーショナルデザイン」の3つを上げています。 f:id:aimstogeek:20190704154253p:plain

  • クラシカルデザイン
    グラフィックやプロダクトといった世間一般認識としてのデザイン。
  • デザインシンキング
    サービスやリサーチといったビジネス領域に踏み込んだデザイン。
  • コンピュテーショナルデザイン
    UIやインタラクションデザインのようなテクノロジー領域のデザイン。

上記の資料から見ると、
デザインはただ美しいものではなく、関連性や有意義な結果をもたらすものが必要だということがわかりました。
特に人間の欲求が日々高次元化していく中、感情意味といったこれまであまり重視されてこなかった部分での差別化が必要になるのではないかと考えています。
即ち、デザイナーは見た目をデザインしていくだけでなく、より体験と絡ませたデザインを提供することが必要になるでしょう。

もちろん、デザイナーは万能ではありません。万能にもなれません。
他の分野のプロはデザイナーがあまり持ち合わせていない考え方をたくさん持っているので、それぞれの強い部分を互いに認識し、組み合わせること(越境するチーム)がビジネスにおいて肝要だと思います。

まとめ

デザインの地位向上に伴って、その役割も複雑化している。
今後、デザインとビジネスの関係性はより深く、より濃くなっていく中、これからのデザイナーにとって、 デザインのイロハというよりも「ユーザー、サービスや事業、組織に対してどのようにデザインで価値を提供するのか」を常に考え、発信、実践すべきではないかと思っています。

ちなみに、弊社はデザイナーを絶賛募集中です!


\\一緒に良いサービスを作って成長したい、そんなメンバーを募集中です! //
919.jp

参考記事

デザインの世界への招待状 #3 拡張するデザイン領域|三宅佑樹 / FORCAS(UZABASE GROUP)|note

クラシカルデザイナーの生きる道|Takamasa Matsumoto|note

*1:デザイン思考とは、経営やマーケティングなど、いかなる種類のビジネスにおいても活用できる「デザイナー的」思考の事を言います。1→10

*2:スペキュレイティブデザインとは、問題解決型のように「未来はこうあるべきだ」と提唱するのではなく、「未来はこうもありえるのではないか」という憶測を提示し、問いを創造するデザインの方法論。0→1

Kibanaでアクセスログをグラフ化してみた

SREのmatsBです。

前回のブログでは、AWSKinesisとElasticsearch Serviceを使ってアクセスログの可視化方法の記事を書きました。
今回はElasticsearchに付随しているKibanaでグラフ化させたいと思います。
初心者向けの記事になっているので、複雑なことはやりません。ご容赦ください。


まずは前回のおさらいです。
Elasticsearchに飛ばすまではこの記事に書かれています。
aimstogeek.hatenablog.com

はじめに

「Index Patterns」など、可視化する上で最低限の設定は出来ているものとします。
今回はSREらしく下記2つのグラフ作成方法を紹介します!

また、弊社がどのようにKibanaを活用してるかの例も紹介します。

ステータスコード「5xx」の発生率をグラフ化

visualizeで新規グラフ作成

「visualize」から新規でグラフを作成します。
今回は割合を見たいので「Pie」を選択します。

f:id:aimstogeek:20190629171602p:plain
Select visualization type


使うIndexを選択

可視化したいIndexを選択します。
諸事情でIndex名を出せないのですが、弊社サービスのアクセスログを選択しました。

f:id:aimstogeek:20190629172112p:plain
Select Index


グラフを定義

割合を出したいので「Metrics」の「Aggregation」を「Count」にします。
「Buckets」は「Split Slices」にします。
「Aggregation」の「Range」を選択。*1
「Field」の「status」を選択
1つ目のfromは「200」を入力し、toは「499」*2を入力
2つ目のfromは「500」を入力し、toは「599」*3を入力

f:id:aimstogeek:20190629173553p:plain
New Visualization


グラフを出力

入力が終わったら、再生ボタンみたいなマークを押します。
入力に問題がなければそのままグラフが表示されます。
「Options」で円の形を変えたり出来ますし、画面右上で「Last 7 days」などの対象の期間を選ぶ事が出来ます。

f:id:aimstogeek:20190629174036p:plain
グラフ完成


グラフを保存

グラフを確認する度にこの作業をするのも現実的ではないので、一度作ったら保存します。
「SAVE」タブを押せば保存画面になるので、自分にとって覚えやすい名前を入力して保存します。
これで「Visualize」に保存されるので、好きなタイミングでステータスコード「5xx」の発生率を見ることが出来ます。

f:id:aimstogeek:20190629174449p:plain
save


レスポンスタイム1秒以上のリクエスト発生率をグラフ化

操作手順については「ステータスコード「5xx」の発生率をグラフ化」とほとんど同じです。
なので、唯一違いがある「グラフを定義」するところだけ紹介します。

グラフを定義

「Field」の「response_time」を選択
1つ目のfrom「0」を入力し、to「999999」*4を入力
2つ目のfrom「1000000」を入力し、toは空欄*5にします。

f:id:aimstogeek:20190629175646p:plain
response_time

「グラフを保存」して、完了となります。
※「ステータスコード「5xx」の発生率をグラフ化」と同じ

オリジナルのDashboardを作る

各グラフを1つ1つ見るのもいいのですが、一つの画面で複数のグラフを見たい場面も多いと思います。
複数Visualizeを1箇所で見るためにDashboardを作ります。


Dashboardを新規で作成

Dashboard画面に移って、新しいダッシュボードを作成します。
「Add」を押すと好きなVisualizeを追加出来ます。

f:id:aimstogeek:20190629180500p:plain
New Dashboard


Visualizeを追加

表示させたいVisualizeを選択します。
選択すると画面の下の方に作成したVisualizeが追加されていきます。
ここでの説明は割愛しますが、ダッシュボードもVisualizeと同じように名前を付けて「SAVE」できるので、作ったら保存しましょう。
弊社では各サービス毎に「ステータスコード「5xx」の発生率」と「レスポンスタイム1秒以上のリクエスト発生率」を出しているので、サービスの数だけグラフを作っています。

f:id:aimstogeek:20190629181222p:plain
Editing New Dashboard

保存が完了するとDashboard画面に作成したDashboardが表示され、いつでも見られるようになります。
f:id:aimstogeek:20190629181813p:plain
Dashboard


Dashboardの完成

Dashboardのオプションで「Use dark theme」というのがあり、無意味にチェックを付けてみました。
SLOやSLAを考える上で年間を通しての稼働率を重視するので、見る期間を「Last 1 year」にしています。

f:id:aimstogeek:20190629182202p:plain
稼働率計測


まとめ

簡易的ではありますが、年間どのぐらいの障害が発生しているのかを見られるようになりました。
このデータやグラフを元になんの対策をするのかなどを決めて、順次対応していくようにしています。
まだまだ簡易版なのでこれからもっとちゃんとした計測を進めていく予定です。

さいごに

弊社の開発チームがいつも見ているKibanaの画面を紹介します。
とあるサービスのアクセスログをグラフ化したものですが、状況の把握などに使います。

  1. インスタンスステータスコードのカウント
  2. サービス全体での5xxエラーカウント
  3. インスタンス毎の平均レスポンスタイム
  4. サービス毎のステータスコード
  5. サービス全体で発生した5xxエラーリクエストの詳細
  6. サービス全体で発生したレスポンス1秒以上のリクエストの詳細

f:id:aimstogeek:20190629183550p:plain
Dashboard
とても便利!これがあればリリース時に問題が発生してもすぐに対応できるはず!!
これからも、より良いサービスを作るための環境や土台に全力を尽くそうと思います。


\\一緒に良いサービスを作って成長したい、そんなメンバーを募集中です! //
919.jp

*1:statusを数値型にしています

*2:ステータスコードの200~499の意味

*3:ステータスコードの5xxの意味

*4:マイクロ秒表記で1秒未満の意味

*5:マイクロ秒表記で1秒以上の意味

基幹システム改修プロジェクトのカットオーバーを迎えたのでKPTで振り返ってみたよ

こんにちは。
サービスプランナーとして日々成長させていただいてます、コッティです。

ブログを書いている本日6/20は東京五輪のチケット抽選結果発表の日ですね!
皆さんは応募されましたか?

私は総額15万円分のチケットに応募しましたが、全部外れてしまいました・・
悲しさしかない。

さて、少し前の話にはなるのですが、表題にあるとおり、
基幹システム改修プロジェクトのカットオーバーを迎えました。
カットオーバー直後は問い合わせやら何かしらバタついたところもあったのですが、
少し収束してきたところで振り返りのKPTを実施しました。
seleck.cc
せっかくなので、プロジェクトとKPTで挙がった話について少し紹介したいと思います。


プロジェクトの概要

  • 基幹システムの改修プロジェクト
  • システム全体の大部分のプログラムに対して何かしら変更が発生
  • 全体の実績工数 23人月
  • 業務や基幹システムに関する知見の浅いメンバーが大半


開発期間

  • 2018年9月~2019年5月

KPTの実施結果

Keepの内訳

f:id:aimstogeek:20190620170133p:plain

keepの7割以上を占めたのがコミュニケーションでした

  • 週次での共有会を実施して情報の格差を最小限にした
  • 気軽にチャットや口頭ベースでの共有、相談が出来ていた


会話のハードルを下げたことが振り返りに現れたかと思います。

また、プロジェクトを通して、メンバー間で開発を前向きに楽しみながら、
実施できていたように感じました。

Problemの内訳

f:id:aimstogeek:20190621085414p:plain

4割が開発の進め方について、3割がプロジェクトの管理についてという内訳でした。

  • 開発を進める上でボトルネックが発生していた
  • プロジェクト管理ツールを活用する意識が低かった
  • 全体像を把握するのにツール以外の方法で実施していた


上記3点が主な要因かと思います。
属人化の課題はわかっていてもなかなか修正しきれなかったです。
特にプロジェクト管理のところは管理者しか見えていないところがたくさんあって、
もっと上手く見える化すべきだったと反省しているところです。


Tryの内訳

f:id:aimstogeek:20190620170237p:plain

Problemでも多かった、プロジェクト管理や開発の進め方のところが主に挙げられておりました。
今後に向けて日々精進ですね。


まずはこの辺から着手していきたいなと思ってます。

最後に

改めてプロジェクトを振り返ってみると、
メンバーに恵まれて楽しく物事を推進することが出来たなぁとしみじみ思います。

プロジェクトを円滑に進めるためには王道ですが
下記2点がほんとに鍵になると実感しました。

  • コミュニケーションのハードルを下げる
  • いかにボトルネックを無くすか


カットオーバーを迎えられたことでほっとした感はありましたが、
KPTでもあるように、まだまだ改善点もたくさん見えました。

また、プロジェクトのゴールはカットオーバーではなく、
その先にある目的を達成することだと思います。

カットオーバーはあくまでもスタートライン。
そこから目的達成に向けていろんな仕掛けをしていきたい、
そんなことを日々考えています。

おまけ

個人的にはこの2つのコミュニケーションがとても楽しかったです。

ブランチ切り替え時にチャット上で叫ぶ

なにげにKeep事項にも挙げられてました!
f:id:aimstogeek:20190620170837p:plain

要所で謎ポエムを入れる

探したのですが、ブログに載せられそうなのがこれぐらいしか無かった・・・


f:id:aimstogeek:20190621085621p:plain



\\一緒に良いサービスを作って成長したい、そんなメンバーを募集中です! //
919.jp

調べものを依頼されたときにちょっと役立つ話

こんにちは、サービスプランナーの
いのっちです。

「○○について調べてくれんか」
「□□について知りたいんや」
と言われた時、どうすればよいでしょう?

ある人は、「えー、そもそも○○って何???」
と動揺してしまうかもしれません。

ある人は、「はい、承知しました!」と
元気に答えて、頭真っ白かもしれません。

ビジネスでは判断に必要な情報を手に入れることはとっても重要です。
そのため、誰かが何とかしなければならないのです。
ここでは、何かしらの施策を実施する判断材料を求められた時の調べものを想定し、
あなたが何とかする人になった時、ちょっと役立つ事をご紹介いたします。

何が知りたいのか知る

打ち合わせの中で依頼を受けたときは、
その「知りたい」が出てきた流れがわかっているので、
何を知って、どのような判断をしたいかを捉えやすい場合が多いですが

顔を合わせた際やメールで、依頼を簡潔な言葉でされると、
なぜそれを知りたいのかが捉えられず、結果、その人が判断に使えるような調査結果を
提供できないような事も発生します。

なるべく、なぜ何を知りたいのか捉えられるように努力しましょう。

〇〇の意味があなたと依頼者でズレていないか

依頼者は○○にあまり詳しくない中で、あなたに依頼しています。
そのため、意味を捉え間違っていたり、捉え方が抽象的だったり、
特定範囲にフォーカスしていたりする場合があります。

○○について依頼者と会話してみましょう。
きっと、○○をどう捉えているか見えてきます。

例)
依頼者「チャットについて知りたいんや」
あなた「チャットというと、ユーザーとのコミュニケ-ション活性化ですか。
あのWebでホワンと窓がでるやつですね」
依頼者「違う違う。社内コミュニケーションの活性化や」

会話でちょっと具体的な話をすることで、
捉え方の粒度やレベル感が見えてくることもあります。

依頼者は何をどう判断したいか(するのか)

依頼者は自分の中で、これを重視するという判断軸をもっていると思いますが、
それが、常に言語化されるとは限りません。

依頼としては表出していないですが、この面は見たいという部分があったりします。
そのような事を意識すると、情報収集の際、収集だけはしておく事ができ、
結果、調査⇒検討⇒調査⇒・・・といったループの段数を減らして早く答えに行きつける場合があります。

そのため、過去、依頼者がどんな点を重視して判断していたかを捉えることは有用です。
このような事は文書化されない事が多いので、依頼者と付き合いが長い人に聞くのが
よいでしょう。

情報をさがす

昨今、流通するデータ量は爆発的に増えていると言われています。
Googleでやみくも検索しても、なかなかお目当ての内容にたどり着けません。

有用な情報はどこにあるのか、当たりをつけられると、調査が捗ります。
ここでは、いくつか私が参照している情報源をご紹介します。

e-Gov

電子政府ポータルサイトです。
統計や白書、政府の研究会・審議会へのリンクがあります。

研究会・審議会で議論された内容は、その後、政策に生かされることが多いです。
PESTを押さえる上で重要ですので、気になる分野があったらウォッチしておきましょう。

www.e-gov.go.jp

専門誌・専門紙

調べたい分野に業界がある場合、専門誌・専門紙があることが多いです。
専門誌・専門紙にはその業界の課題意識がにじみ出ていますので、
3ヵ月~1年分程を目次だけでもいいのでチェックすると、流れや空気がわかってきますのでおすすめです。

私は専門誌・専門紙を探すときは、網羅性が高いFujisan.co.jpを利用しています。
www.fujisan.co.jp

シンクタンク・調査会社の資料

民間会社の調査結果も参考になりますが、
社数が多くチェックするのが大変です。

私が調査する際は、 kezaireport.com で探しています。
ここでは、レポートへのリンクが纏められており、効率的に情報を探すことができます。

www3.keizaireport.com

いかがでしたでしょうか。
今回は、何を依頼されたのかという話と、
デスクリサーチのちょっといい話をしました。
今後もちょっといい話をご紹介してきますので、よろしくお願い致します。


我々はちょっとどころではなく、とんでもなくいいサービスを目指してます!
\\『とんでもなくいいサービスを創りたい』仲間を大募集!! //
919.jp

【スプレッドシート&GAS】毎週日報シートをコピーするのが面倒だったから自動化した

こんにちは、ねこです。
最近スプシばかりいじっているので暇さえあれば(無くても)スクリプトで自動化したがります。

今回はいろんなスプシで使いまわしてるスクリプトのうちのひとつ、「定期的にシートをコピーして先頭に持ってくるスクリプト」を紹介します。
「毎日じゃなくてそんなに手順あるわけじゃないんだけど誰かが定期的にやらないといけないやつ」を自動化しました。
こういうの、ふとした瞬間に面倒くささを感じるんですよね。
そんなモヤッとはコピペスクリプトに任せてしまいましょう。

スクリプトがやってくれること

毎週月曜日に↓の処理を実行してくれます。
speakerdeck.com

導入するときの反応

毎回シートを作ってくれる人に自動化していい?と聞いてみました。

f:id:aimstogeek:20190607143434p:plain:w380
ダブルねこハッピー
とっても嬉しそうですね!やりましょう!!

準備するもの

シート名等に日付を使うのでライブラリにMoment.jsを追加します。
tonari-it.com

実際のスクリプト

function copyNextSprintSheet() {
  var SS = SpreadsheetApp.getActiveSpreadsheet();
  var sheets = SS.getSheets();
  // コピー元(先頭)のシート
  var sourceSheet = sheets[0];

  // コピー後のシート名を作る
  var openDate = Moment.moment();
  var closeDate = Moment.moment().add(4, 'days');
  var nextSheetName = '入力シート_' + openDate.format('MMDD') + '-' + closeDate.format('MMDD');

  if (SS.getSheetByName(nextSheetName) != null) {
    // すでに作られていたらなにもしない
    return;
  }

  // ① シートをコピー
  sourceSheet.copyTo(SS);

  // ② 「(コピー元シート名) のコピー」というシート名になっているのでコピー後のシート名にする
  var sourceSheetName = sourceSheet.getName();
  var copiedSheet = SS.getSheetByName(sourceSheetName + ' のコピー');
  copiedSheet.setName(nextSheetName);

  // ③ 書式はそのままに中身をクリア
  var areaLastRow = SS.getRange('B:B').getLastRow(); // メンバー列(B列)の最後の行を取得する
  copiedSheet.getRange('D6:J' + areaLastRow).clear({contentsOnly: true});

  // ④ D4セル(day1)に開始日を挿入
  copiedSheet.getRange('D4').setValue(openDate.format('YYYY/MM/DD'));
  
  // ⑤ コピー後のシートを一番初めの位置に移動する
  SS.setActiveSheet(copiedSheet);
  SS.moveActiveSheet(1);
}

定期実行の設定

スクリプトを保存したら「編集」>「現在のプロジェクトのトリガー」>「トリガーの追加」で毎週月曜日に上記のスクリプトを実行するように設定します。

f:id:aimstogeek:20190607103050p:plain:w420
スプレッドシートは便利だなあ

これで毎週月曜日にシートをコピーしてくれる人の手間が消えました。やったね!
みなさんもGASをうまく使って良きスプシライフを!


こんな感じでスプシをゴリゴリ使いまくるわたしたちは
\\『明日のはたらくを創る』仲間を募集中です!! //
919.jp

成長のために累積矢面時間を稼ぐという考え方

こんにちは、サービスプランナーのyumeです。
アイドルに憧れすぎて、自分の結婚式でゲストをヲタクにしてアイドルごっこをしてしまうという暴挙に出てしまいました。
反省はしていない。


さて、ちょっと前ですが、「累積矢面時間」についての下記エントリが話題になりました。 note.mu

うちの社内では、「活躍している人って確かにこれが要因になっている感あるよね」的な方向で納得感があるような意見が見られました。

私自身も非常に共感すると同時に、「あぁあれって今思えば矢面時間なのかな」という気づきもあったため、今回はこの矢面時間を稼ぐ方法について思いを馳せます。


※辞書などでは、「矢面に立つ」は「攻撃・批判を受ける立場になる」と説明されますが、私はこの文脈では、広く「責任を持って行動をする」に近いニュアンスで捉えています。
必ずしも、攻撃・批判のケースにとどまらないというか。
例えば、成功したケースでも前面に立って行動していれば、それは矢面に立ったことに含まれると考えています

累積矢面時間がなぜ戦闘力に繋がるか

いまさら解説はいらないと思うのですが、

  • 責任を実感し、やりぬく経験になる
  • 行動した結果のフィードバックが得られる

ということの繰り返し(つまりPDCAを回すこと)によって、決断・行動の精度が高まっていく=戦闘力 ということだと理解しています。

矢面時間を稼ぐ心構え

では、黙っていても矢面時間が稼げるかというと、そうではないから話題になっているわけで。笑
個人的には、そのための心構えが必要ではないかと思っています。

小さい矢面機会を見逃さない

「成長するには矢面時間が必要」ということと、「矢面に立つためには成長(もしくは実績)が必要」ということは、いわゆる鶏が先か卵が先かの状態であり、ジレンマです。

ではどうすればよいかと言うと、身の回りにあるような小さな矢面機会を見逃さず、地道に累積矢面時間を稼ぐ、というのが大事だと思っています。

例:電話対応

新人ビジネスマンの最初の壁である(※個人差があります)「電話対応」業務について。

発信者の名前と用件を聞いて、適切なメンバーにつなぐ。
誰がやっても変わらない仕事と軽視しがちですが、「自ら受話器に手を伸ばし」「会社の代表として電話に出る」人は、短い時間でも確実に矢面に立っています

実際、保留の時間が長くなって、電話が「ピロリロ♪」とか鳴り始めたとき、「うわ〜〜〜待たせてるどうしよ〜〜〜〜」とヒリヒリする感じ、まさに矢面ですよね。

何か用事があって電話をかけてきた相手にとって、「今この瞬間に頼れる人間は自分一人である」という状況の経験は、矢面時間を稼ぐ絶好のチャンスだと考えています。

例:ミーティングの設定やリマインド

これも地味な仕事ですが、次のミーティングが適切に設定されなければ、案件が前に進みません。
つまりそこには責任があり、責任があるということは矢面だと言えます。


もちろん、いきなり大きな案件を担い、矢面時間を一気に稼げるのが一番いいです。
ただ、

  • 矢面時間を稼ぐ方法はそれだけではなく、身の回りにたくさんある。
  • 人から矢面時間を提供されるのを待つ間に、できることはたくさんあるかもしれない。

…ということを伝えたいです。

矢面に立った自覚を正しく持つ

小さい矢面機会って誰もがやったことあるような身近なものですが、
なぜ見逃されがちなのか考えると、「矢面に立ったと自覚しづらい」ということがあるのかなと思います。

そこで大事なのが、大小の矢面機会に直面し、行動した自分を、正しく認識・自覚することかなと考えています。


例えば、、、

  • 「こんな小さなこと自分がやる意味ない」「言われたから仕方なくやっている」と思ってしまっている
  • 自分の考えが採用されたのに、「上司がGOを出したことだから」と自分の影響を軽視している

このようなケースは、個人的に、「せっかく矢面に立ったのに、矢面時間に累積できずに終わってしまう非常にもったいないケース」であり、自分に何ができたかな、自分がいなかったらどうなったかな、ということを正しく認識できたら累積につながると思います。

失敗・成功に関わらず、それをかけがえのない自分の体験として、積み重ねていける人はそれだけで強いです。


メンバーの矢面時間を創出する

逆に、他のメンバーに矢面時間を稼いでほしい、成長してほしい場合は、

  • 矢面機会をたくさん作る
  • 矢面に立った自覚を正しく持ってもらう

ということに尽きるのかなと思います。


「決断の数だけ人は強くなる」という言葉を受けた私の友人が、「私は決断しているのに、全然強くならない」と嘆いていました。

話を聞いてみると、彼女は自分なりの決断を持って上司に提案をしているが、上司がいつもその提案を受け入れてくれず、
納得ができる説明もされないまま、却下されてしまっているような状態だそうです。

めっちゃかわいそう。


ただ、本当に気の毒だとは思うのですが、周りに影響を与えていない時点でそれは決断ではなく、矢面時間にはつながっていないんだろうなと思います。


このように、周りの人間が矢面時間を奪っているケースもあるでしょう。

私自身、自分の持っている細かいタスクについて、
「こんな地味な仕事を他の人にやってもらうのもなぁ…」
と、勝手に判断して後輩に渡さない、ということがありました。本当に悪い癖です。

自分自身は小さな矢面時間の積み重ねで成長したと思っていても、
先輩としては、「どうせなら後輩にビッグな矢面時間を提供したい!」という思いが強くなってしまうのです。

矢面時間は累積で考えるべき、大きいに越したことはないが小さな積み重ねも大事、ということを、他人に対しても求めていきたい今日このごろです。

また、ふりかえりをする、感謝を伝えるなどで、矢面に立った人に適切にフィードバックを送ることも、チーム全体の累積矢面時間を蓄積するために必要なことだと感じました。

まとめ

  • 「小さい規模でも矢面に立つ」「矢面に立った自覚を持つ」の両方を意識することで、累積矢面時間を増やしていけるのではないか
  • 周囲がそれを支援することも重要

まとめると、「何事にも当事者意識を持ち、責任を実感して取り組むことが大事」みたいな至極当たり前のことを言っているようにも思えますが、「累積矢面時間」という言葉がしっくりきたのでお借りして書いてみました。




\\一緒に矢面時間を累積していけるメンバーを募集中です! //
919.jp