残業を減らすために心掛けることや取り組むこと

ポエム 企業・会社・働き方

前提

筆者の観察範囲と主観をベースに書いているので職種や職場環境や視点に偏りがある:

  • 例1: 大企業
  • 例2: IT 企業
  • 例3: 乱暴だが文章をシンプルにするため「彼らは総じて～～」のように、いっしょくたにした書き方をする

本記事で主に取り上げる内容:

  • X 細かい仕事術やビジネスハック
  • O 残業をもたらす要因と、それら要因を多数持つ事象と回避方法
    • 「～～を行えば残業が減らせる」は書きますが、じゃあ「～～を行うためにはどうしたらいいのか」といった手段は取り上げません
  • しかし後半は仕事術っぽいトピックが増えてくるかも

会社や部署やチームの取捨選択

会社や部署といった「居場所」を選びましょうという話。「残業が多くついてまわる性質を持った居場所」もあるので、そのような居場所を避けることが重要。

リテラシーの無い人が居る場所には行かない

たとえばセクハラの自覚が無く平然と女性社員をプライベート質問でいじったり、LGBT や ADHD を知らなかったり、有給取得時に執拗に理由を訊いてきたりするような古い人が上に立っているような会社や部署やチームは避けるべき。彼らは総じて頭が堅く無知。彼らには「定時で帰りたい」といった価値観が通じない。ただの甘えや怠けだとみなされる。

逆に、上がリテラシーを持つ人間であれば、ある程度は配慮・尊重してもらえる。

転職する

会社は変わらなかったり変われなかったりすることが多い。優秀な人が転職するのは、変えるのが無理ゲーだから。会社を変えるよりも自分の居場所を変える方が（そのために受験勉強みたいな努力が必要だとしても）はるかに優しい。

異動する

（特に大企業は）部署ごとに世界観がまるで異なっており、部署Aでは残業当たり前でも部署Bでは半数以上が2日に1日は定時で帰れていたりする。部署Aに居る限り、残業は避けられない、なんてこともありえる。部署Aから別の部署に異動した方がてっとり早い。

仕事の取捨選択

「残業が多くついてまわる性質を持った仕事」があるので、そのような仕事を避けることが重要。また、自分の立ち回り次第で、そのような仕事が安易に降ってくるのをある程度防ぐこともできる。

本質的に時間のかかる仕事には手を出さない

本質的に時間のかかる仕事とは:

  • ステークホルダーの多い仕事
    • 打ち合わせが増えがち
    • そもそも「人」は複雑で不定で扱いづらい対象
  • 物理的作業の多い仕事
    • 物理的作業 = 実際に手や足を動かす作業
    • PC を使う作業だと効率化や自動化はしやすいが、物理的な作業はそうはいかない
    • 例:
      • 機材や会場の準備/撤収
      • 筆記や郵送を伴う諸作業
      • 印刷を伴う諸作業
    • つまりボリュームの多い物理的作業 ≒ 短縮の余地が少ない ＝ 必然的に残業になる
    • ボリュームが少ないなら特に問題はない
  • 管理職
    • ルールに従って調整/申請/管理するべき事項が山のようにある
    • 会社によっては「昇進する≒プレイングマネージャになる」のケースもある
      • 昇進前の業務 + 管理職業務となり仕事の物量が桁違い……
    • 作業で使うシステムやファイルも、レガシーなシステムだったり Excel/Word だったりしていちいち使いづらい、重い、遅い

QCD の要求されない仕事を選ぶ

QCD の要求がきつければきついほど残業が増える。なぜなら、

  • Quality がきつい → 必要な仕事量が増える
  • Cost がきつい → 必要な仕事をこなすための手段が限定される（効率的な手段を選びづらくなる）
  • Delivery がきつい → 必要な仕事の密度が増える

QCD が比較的緩い仕事の例:

  • 顧客がついていない仕事
    • 商用可や製品開発の前段階である調査業務や研究業務
  • クライアントが社外ではなく社内の仕事
    • 社内の社員向けのシステム開発や情報提供など
    • 社内の部署向けの……
    • 社内のチーム向けの……

ポテンシャルを申告して過剰分を断る

「ここまではこなせますが、これ以上はできません、今のままだとこれだけ溢れてしまいます。溢れた分をカバーするのにこれこれほどの無理をする必要があります。現実的ではありません。だから、これこれの部分はカットする必要があります」

これを言えるようにする。重要なのは主張の根拠として 私の実力(ポテンシャルや性格や病気やその他事情等)はこの程度だ を伝えること。もっと言うと、

  • 実力以上の力は出せない
  • 私の実力はこれくらい
  • 私の実力で考慮すると、ここまでしか終わらない

という風に主張を持っていく。チームや上司もバカじゃないので、ちゃんと伝われば「じゃあカットしよう」とか「じゃあ他の人に任せよう」と配慮してくれる（ というよりそうするしかない ）。もちろん、アピールが露骨だと評価は落ちるのでトレードオフではある。

PC が重くなるような仕事には手を出さない

（主に 性能の悪い PC しか使えない環境下にいる という条件付きだが）仕事内容によっては、どう考えても PC の処理能力を超えており、多大な待ち時間を要することがある。当然、待ち時間の分だけ業務時間も増えてしまい、蓄積すると残業に繋がるほどの被害になる。このような仕事は避けた方が良い。

  • 例1: 多数の Excel/Word/Powerpoint を開くような事務、雑務、管理業務
    • マニュアルや申請書類がことごとく Office となっている
    • 情報が散らかっており、複数のファイルを開くのが日常茶飯事
    • ただでさえ情報保護のために暗号化がかかっているので余計に重い
  • 例2: 保守対応
    • 環境再現のために仮想マシンをローカルで立ち上げなきゃいけない(自分のPCをホストOSにしなきゃいけない)
  • 例4: Java を用いた開発
    • Eclipse が重い
    • ビルドも重い

もう一度述べるが、上記業務が一般論として悪いという意味ではない。「性能の悪い PC しか使えない環境下で」という前提がつく。

スタンスの主張

残業は悪だと思っていない人も多数いらっしゃるので、価値観の話になるが、しっかりアピールする必要もあるかもしれない。そうしないと伝わらない。仮に伝わらなくとも「定時で帰るキャラ」とみなされれば帰りやすくなるので、主張は大事だ。

定時派であることを主張する

残業は当たり前だ、とする価値観を持つ人は少なくない。中には自分がそういう価値観に染まっている自覚さえない人もいる。そんな世界の人たちは残業に対する忌避感に疎いので、平気で残業を犯す。そうでなくとも「まあいいか」「仕事だし」と軽く考える人（勤務時間に特にこだわりがない人）も多い。

このような価値観に押しつぶされないためには、 自分が定時派であることをストイックに主張する 必要がある。そうしないと伝わらない。

行動例:

  • 毎日定時のチャイムが鳴り終わったら、即「お疲れ様です」と挨拶して帰る
  • 打ち合わせの開催時間が定時を超えた場合に「定時超えてますけど」と反発する
  • 「みんなもやっているから」と言われた時に「だからといって残業していい理由にはなりません」と主義思想や屁理屈をこねて反発する
  • 「就業規則でもあるだろ、命じられたら残業しなきゃいけないって」と言われた時に「命令の正当性を感じません。ホットライン部署に訴えます」などと反発する
    • 本当に正当性が無い場合、かつ当該部署があるような企業の場合に限るが

主張の説得性を持たせるために必要なこと:

  • やむを得ない理由があること
    • 例1: 子供の面倒
    • 例2: 親の介護
    • 例3: 持病があり通院している
    • 例4: 仕事のパフォーマンスが定時内しか保たない
  • 自分の仕事をちゃんとこなしていること
  • 必要な時（これをしないとチーム全員に迷惑がかかる等）はちゃんと残業すること
    • 必要な時が「いつも」だったら辛い
  • チームや PJ が極端に忙しくないこと
    • 忙しいと「お前も手伝え」となりやすい
  • 「私は定時で帰りたいんです」という価値観を周知させること

成功例の事例レベル:

  • LV4: 円満に認めてもらえている
    • 例1: 周囲「あの人には子供がいるから仕方がない」
    • 例2: 周囲「あの人は重たい病気を抱えているから仕方がない」
    • 理想ではある
    • 誰もが持てる理由ではないので使いづらい（というか使えない）
  • LV3: 個性として認めてもらえている
    • 例1: 周囲「彼は定時で帰りたい人だからね」
    • 例2: 周囲「彼は人一倍成果を出してるから文句は無い」
    • LV4 に至れない場合の理想
    • 周囲が寛容か、自分が人一倍できる人間でないと使えない
  • LV2: 面倒くさい、気難しそうな人間として認定されている
    • 例1: 周囲「あの人には仕事頼みづらい……」
    • 例2: 周囲「どうでもいいわ。関わるだけで疲れる。ほっとけほっとけ」
    • 一応認めてもらえてはいるが、マイナスの感情が多かれ少なかれ存在するため、あまり居心地は良くない
  • LV1: 放置、排除
    • 例1: 周囲「あいつには関わるな。放っておけ」
    • 例2: 周囲「あの人なんで仕事してないん？」「上司と以前めちゃくちゃ衝突して以来、干されているらしいよ」
    • 無関心や敵対が渦巻いているパターン。非常に居心地が悪い

※ただしやむを得ない事情や一人前の実力を持っていたとしても、LV2 や LV1 みたいにマイナスの雰囲気がまとわりつくことはある。

余計なプロセスの削減

労働時間を肥大化させていく無駄を省いていくというアプローチ。

「話しかけられる」という割り込みを減らす

割り込みはなぜ悪か:

  • 割り込みはコンテキストスイッチング(頭を切り替える)を発生させる。そうなると個々の仕事に集中しづらい。いわゆるマルチタスクのような状態になる
  • 人間が最も生産性を発揮できるのは、一つの仕事に集中するシングルタスクである
  • ピンと来ないなら将棋の棋士をイメージしてほしい。対局の最中に「ねぇねぇ」と割り込まれたら鬱陶しいはずだ。対局が終わるまで割り込みゼロが理想である

割り込みは極力防止したい。その割り込みの主因となるのが「話しかけられる」ことである。厄介なのは「人間だからそりゃ喋るでしょ」などと開き直りやすいこと。もっともらしい屁理屈で非効率の正当化をしている。良くない。

「話しかけられる」割り込みを減らすためにやること:

  • 人の良さを出しすぎない（頼られやすくなる）
  • よく喋る人には近づかない
    • 例: 席替え時に「よく話しかけてくる役員から離れた席」を希望する

打ち合わせはプロセス化する

人間は寄り道が好きで支離滅裂な生き物なので、何のサポートも無しに円滑・効率的に話し合いを進めるのは非常に難しい。だからこそ会議のハウツー本やコンサルが腐るほどある。

どうすれば？:

  • 会議のハウツーを読んで、効率的なやり方やフレームワークなどを理解し、ストイックに取り入れる
    • ゴールとアジェンダを明確にする
    • 脱線したら話を戻す
    • タイムキーピングする
    • 開催時間は守る（遅刻を当たり前にしてだらだらさせない）
    • ……

ハウツーを知っているだけでは意味がない。だらだらな会議に身を置きつつ内心で「こうやればいいのに」と思っているだけでも意味がない。大事なのはアクションを起こすこと。冗長でもダサくても面倒でも、ストイックにハウツーに頼ること。

必要なことだけをやる

例1: 複数回のレビューを経るものづくりの場合

  • いきなり完成品クオリティを仕上げてあらゆる観点でレビューしてもらうのは（つくり終えるまでに時間がかかるため）非効率的すぎる。もし後戻りが発生したらと思うとゾッとする
  • まずは「この観点のみをつくりこんで FIX させてみる」など局所化する。少しずつクオリティを固めて、積み上げていく。
  • 漫画家を例にすると……:
    • 編集者にチェックしてもらうのに、いきなり完成原稿を出すことはしない
    • まずはネームというラフな落書きを出してストーリーやコマ割りを FIX した後、清書する
    • 中には「完成原稿に近いネームじゃないとチェックしません」という傲慢な編集者もいるかもしれないが、できる限り編集者のスタンスを改めてもらうべき

例2: チームメンバーの誰もが対応できるよう仕事のやり方をマニュアル化する仕事の場合

  • いきなり重たい Word で書き始めたり、本文を書きながらその都度図表や余白のレイアウトを整えたりするのは早計
    • 後戻りコストが大きい
    • 本文の検討に集中できない
  • 最初に目的と要求水準を確認する。たとえば「チーム内で見るだけなので口調も見栄えもテキトーでいい」だとしたら、Word を使わずテキストファイルにサクッと書くだけで済むかもしれない

一般的にまとめると:

  • 後戻りコストをできるだけ小さくすることを考える
  • マルチタスク（同時にこなす）のではなく、シングルタスクを積み上げていく方が集中しやすい
    • Before) いきなり Word で本文書きつつ、図表余白のレイアウトを整えていく
    • After) まずはテキストエディタで本文を書く、図表作成ツールで図表を書く、それらをレビューする、一通り済んだら Word にマージして全体の見た目レビューをする

手段の最適化

仕事で使っている道具や方法論について理解し、効率的に扱えるようにする。勉強や習熟は一朝一夕にはいかないが、知っている・知らない、やっている・やっていないとでは労働時間に 数十分/Day 以上の差がつくと個人的には思っている。

PCを軽くする

PC が重いことの弊害:

  • 作業中、常に触ることになる PC が重たいと……
    • 単純に作業を終えるまでに時間がかかる
    • ストレスが溜まり、エネルギーが削がれる

軽くする方法:

Windows PC を何の設定もしないまま使い続けている人は、一通り勉強した方がいい。たとえるなら誰にも何にも頼らず我流で一人暮らしをするようなものか。普通は両親や友人に訊いたりネットや本で調べたりして効率的なやり方をどんどん取り入れるはずだ。

よく使う手順を省力化する

  • 手順をチェックリスト化・タスクリスト化して、機械的にサクサクこなせるようにする
  • スクリプトやツールで自動化する
  • 毎日習慣的にこなす
    • 1日1分で済む作業をサボって月末に20分かけて行うと負担が大きい

よく使う資料は見やすい場所に配置する or 自分の言葉でまとめる

Bad:

  • 毎回チャットの過去ログを辿っている
  • 毎回共有フォルダの深い階層を「どこだっけ」と呟きながら探したりしている

Good:

  • ローカルにコピーする、要点をテキストファイルでまとめてそれを見るようにするなど「情報の複製」や「要約の記録」を行う
    • ただし資料によっては「コピー禁止」もあるのでルールや取り扱いは要確認。

作業ファイルは日付とコメントのフォルダで整理する

デスクトップにテキトーにファイルを置いて作業している人を見かけるが、どんどん散らかってくるためどんどん能率は悪くなる。

弊害:

  • 弊害1: デスクトップにアクセスする度に「散らかったデスクトップを」見て判断する作業が（無自覚であることも多いが）入ってしまい消耗する
  • 弊害2: ファイルを探す際、散らかったデスクトップという多数のファイルが常に相手となり、しんどい

じゃあどうすればいいの?:

  • YYMMDD_COMMENT フォルダを作って、そこで作業する
    • 例1: 180831_社内Git勉強会アンケート集計
    • 例2: 171120_新年会2018幹事

YYMMDD_COMMENT フォルダはいつ作るの？いつファイルを入れるの？:

  • 案1: 新しい作業が発生する度に作る、入れる
  • 案2: 普段はデスクトップで作業し、週一くらいで「あまり使ってない分」についてフォルダを作り、入れる

YYMMDD_COMMENT フォルダで弊害はどう解決する？:

  • 弊害1: 消耗 → 消耗しなくなる
    • 上記の案1 を取り入れたらデスクトップは「YYMMDD_COMMENT フォルダを並べたフォルダ一つのみ」で済む。常にスッキリ
  • 弊害2: 探しづらさ → 探しやすくなる
    • フォルダ名と記憶を頼りにスピーディーに探せる
    • フォルダ単位で関連ファイルがまとまっているので利活用もしやすい

もっともこれは数ある整理術の一つでしかないが、YYMMDD_COMMENT フォルダは（精神的負荷はさておき）比較的簡単に取り組め、かつ効果も高いやり方だと思う。

おわりに

かなり雑多な内容になってしまったが、まとめるとアプローチは以下に大別できるかと思う。

  • 逃避 …… 残業がつきまとう場所（会社や部署や人間）を避ける
  • 回避 …… 本質的に残業の多い仕事を避ける
  • 主張 …… 残業が増えないような事情や意見や価値観を主張する
  • 削減 …… 時間を消費する道具、プロセス、やり方などを潰す
  • 強化 …… 効率や生産性を高める働き方や方法論を覚え、実践する

Windows の PC 設定と周辺機器を最適化してストレスと労働時間を削減する

Windows 企業・会社・働き方

働き方改革が盛り上がっているが、個人的には仕事道具である PC の設定最適化も重要ではないかと思う。重たい、遅い PC で何秒何十秒何分と何度も待たされるのに平然としている人が意外と多くてびっくりする。ここを改善できれば、一日数十分から1時間くらいの労働時間削減には繋がると私は思っている。

どのような設定をすればいいかという考え方や方法を雑多に書きたい。

前提

  • Windows 7/10 を想定する
  • セキュリティ問題については言及しない(たとえば「アップデート頻度を下げたらセキュリティ上問題があるのでは」といった類の議論)
  • 制約のキツイ会社を想定する（個人や小規模チームには当てはまらないかも）
  • Windows カスタマイズを問題無く行える知識を持っていることを想定する
    • レジストリやコマンドプロンプトをいじれる
    • ググって調べて試す要領を持っている
    • ……

軽い PC を使う

据え置きPCを使う(シンクラは使わない)

シンクラ（ここでは VDI を想定）の利用を推奨させる会社は（特に純粋なソフトウェア企業でなければ）多いかもしれないが、シンクラは据え置き PC よりも圧倒的にストレスが溜まる。

  • 画面を転送をするため描画が重い、遅い、滑らかじゃない
  • 無線通信のため、通信品質にムラがある（遅くなる、繋がらなくなる等）
  • 自マシンを自由にカスタマイズできない
    • たとえばシステム設定やレジストリをいじって軽くしようとしても、そもそもいじれないように制限されている

シンクラと据え置きPCの関係を住居でたとえるなら、

  • シンクラ → 社宅
  • 据え置きPC → 持ち家

みたいなもの。持ち家の利便性を知らない人には、そこそこの環境を整えてくれるためかえって楽なのだが、持ち家を持っている人からすると窮屈で不便で不自由である。

持ち家派の人はシンクラには出来るだけ抗おう。でないとシンクラのストレスにずっと晒され続けることになる。

メモリを増設する

メモリが少なくて動作が重たい場合、下手な小細工や設定を頑張るよりもメモリ増設しちゃった方がグンと快適になる。申請やら手続きやらが面倒くさくても掛け合ってみる価値はある。

電源は入れっぱなしにする

起動に時間がかかる Windows を毎日バカ真面目に起動する必要はないし、今時の PC は電源入れっぱなしでも簡単には壊れない（環境による）。また電気代もたかが知れている。もし許されるなら、電源は入れっぱなしにしておく。

  • Windows は起動してから利用可能(バックグラウンドで重たい処理が走っていない)になるまでに 10 分以上を要する
  • アップデート等の再起動は空いた時にでもやればいい
  • 使っていない時に CPU のファン音などが気になるようならスリープや休止状態を使う
  • 勝手にスリープや休止状態にならないよう電源オプションの設定は見直しておく

許されていない場合でも、理由次第では許してもらえる。たとえば「評価でプログラムを夜間も運転し続ける必要がある」など。

また、許される部署に所属することも重要かもしれない。たとえば事務総務部署よりは、製品開発部署の方が、既に自前で何個も何十個のサーバーを常時立ち上げているわけだから、電源入れっぱなしにも寛容である。

PC の動作を軽くする

アップデートやスキャンの実行スケジュールを見直す

問題:

  • アップデートやスキャンといった処理はえてして重たい
  • ブラウザやテキストエディタさえカクカクするほど重くなることも
  • HDD がブンブン鳴ってうるさい、集中を乱される

対処:

  • 実行スケジュール設定を見直す
    • 例1: PC を使っていない昼休憩中にやらせる
      • 毎日10:00 → 毎日12:10
    • 例2: PC を使っていない深夜にやらせる
      • 毎日10:00 → 毎日23:00
    • 例3: 頻度を減らす
      • 毎日10:00 → 3日に1回
    • 例4: 起動時トリガーをなくす
      • システム起動時 → 無し
  • リアルタイムスキャン対象に例外を設定する
    • 例1: テキストファイルを溜めたフォルダ
    • 例2: 常時立ち上げている実行ファイル(ブラウザやエディタや Office)

もちろん会社規定等でルールが定められている場合は逸脱しない範囲で設定すること。とはいえ「どうせガッチガチでしょ」と最初から諦めるのはもったいなくて、案外融通を効かせられるようになっていたりする。

不要ファイルをローカルに置かない

会社 PC ではウイルス対策ソフト等のスキャンが働いているかと思う。もっというと ローカルに置いてるファイルが多ければ多いほど、これら動作の実施時間も長くなる。逆を言うと、ファイル数やファイルサイズを根本的に減らせば、その分短くできる。

ファイルの整理方法について（長くなるので）割愛。

余計な視覚機能やお節介機能をオフにする

Windows には余計な視覚機能やお節介機能が多数あり、デフォルトでは有効になっていて地味に重たい。一通りオフにしておくと違う。

Windows 7/10 でもぜひ設定しておきたいのは以下。見栄えはクラシックになるが Windows の（特にウィンドウ表示/操作まわりが）グンと軽くなる。

  • システムのプロパティ > 詳細設定 > パフォーマンス 設定ボタン > 視覚効果タブ > パフォーマンスを優先する

Windows 10 の場合、以下は見ておきたい。(Win7の場合はコントロールパネルから類似する設定を探せるはず)

  • 設定 > システム > 通知とアクション
  • 設定 > プライバシー
  • 設定 > 簡単操作 > キーボード
  • 設定 > 簡単操作 > マウス

余計なスケジュール実行をオフにする

Windows にはタスクスケジューラという特定スケジュールに特定プログラムを実行させる仕組みや、サービスというシステム起動時にプログラムを実行させる仕組みがあるが、ここにも Windows の余計な機能が多数登録されている。不要な分は無効にしておく。

  • タスクスケジューラライブラリ > Microsoft > Windows 配下
  • 管理ツール > サービス

基本的にはググって意味を調べて、大丈夫そうなら無効にする……という実験的アプローチになる。注意したいのは、ここらには Windows の動作に必須となる分も含まれているということ。無闇に無効にすると最悪 Windows が動作しなくなる。

(無効にする例) タスクスケジューラライブラリ > Microsoft > Windows > Application Experience は無効にしておくとよい。これは「カスタマー エクスペリエンス向上プログラム」というもので、Windows 利用者の利用情報を Microsoft に送信するための仕組み。CPU やらディスクやらをガリガリ動かすので地味にうざい。

参考:

重たいプロセスが動いてたら原因を突き止めて殺す

急に CPU のファン音がうるさくなったり、動作が重くなったりした時は誰かが悪さをしているのでソイツを突き止める。また、再び悪さをしないように対処もする。

誰かを突き止める:

  • タスクマネージャや Process Explorer を使う
  • CPU使用率(CPU Usage)を見るといい

対処する:

  • プロセス名やコマンドライン等でググって正体を掴む
  • 殺しても良さそうなら殺す
  • 起動設定などをあたり、良さそうなら無効化する
    • たいていサービスやタスクスケジューラだったりする

Internet Explorer は使わない

ブラウザとして IE(Internet Explorer) は使わないこと。IE は描画や Javascript の処理が遅かったり、UI が使いづらかったりしてストレスが溜まる。IE を使い続ける行為は、テキストエディタとしてメモ帳を使い続ける行為に等しい。

Flash Player を使わない

Flash Player は度々アップデートが入るので煩わしい上、脆弱性を突かれてウイルスやら何やらにやられるわけにもいかないためアップデートを無視するわけにもいかない。面倒くさい。使わずに済むなら使わなくていい。

(余談) アンチウイルスソフトとのトレードオフ

企業利用の例ではないが、余談として書いておきたい。

アンチウイルス（ウイルス対策ソフトウェア）が無いとウイルスに感染してしまうが、アンチウイルスはこれ自体がウイルスじゃないかってくらいに動作が重たい。かといってアンチウイルスを全く利用しないのは、それはそれで危険で、ウイルスに感染すると一発で被害が出てしまう。

どうするかというと、これはトレードオフなのかなと思う。

  • (1)有償アンチウイルス: ウイルスには強いが、動作が重い
  • (2)無償アンチウイルス: ウイルスにはやや強く、動作もやや重い
  • (3)アンチウイルス未使用: 動作は軽いが、ウイルスには弱い

企業利用なら (1) になっているはずで、当然アンチウイルスを切り替えることもできない。たとえば「会社で使ってるアンチウイルスが重たいんで、こいつはアンインストールして、俺は Windows Defender 使いますわ」なんてことはできない。できることと言えば、上記でも少し述べたが、アップデートやスケジュールの実行スケジュールを見直すなど、設定面で工夫して少しでも軽くすることだ。

(3) は論外だろう。PC 初心者がたまに (3) だったりして、デスクトップやホームページに変な画像やアイコンがあったり、動作が妙に重たかったりするのを見ることはある。一方、PC に詳しい人間なら、Flash Player やダウンロードしたファイルの扱いなどウイルス感染経路に気をつけたり、閲覧サイトや使用ソフトを限定したりすることで (3) でもやっていけるかもしれない。しかし、ウイルスの攻撃は多彩で、全てを人手で防ぐのはまずムリだから、(1) なり (2) なりで機械にまかせて保険をかけておきたいところではある。私も出来れば (3) にしたいが、まだ試せるほどの勇気と知恵はない。

(2) は (1) を嫌う場合の選択肢として、個人 PC 利用なら多数を占めるだろう。上記では「ウイルスにはやや強く、動作もやや重い」と書いたが、いくつかバリエーションがあって、

  • ウイルスにはやや強く、動作もやや重い（有償アンチウイルスより弱いが、軽さは勝っている）
  • ウイルスにはやや強いが、動作が重い（有償アンチウイルスの劣化版）
  • ウイルスにはあまり強くないくせに、動作が重い（有償アンチウイルスの劣化版の劣化版）
  • ウイルスにはあまり強くないくせが、動作はやや重い（軽いけどアンチウイルス機能も弱い）

などがある。ソフトによって特徴は異なるので、よくよく調べて選ぶことになる。

※具体的なソフト名を挙げて議論するのは割愛する。

ワーキングメモリの負担を軽くする

ワーキングメモリ（短期記憶）とは、作業を進めるために一時的に記憶するための（脳の）記憶領域のことだ。あるいはそのような「一時的に記憶する」という概念を指す。

ワーキングメモリに負担をかけるとしんどいので、なるべく和らげてあげることが大事。

大きなディスプレイを使う

小さな画面だと「こっちに表示されていた内容を頭に入れた上で」こっちにスクロールする、みたいな作業が頻発する。いちいちスクロールバーを動かしたり、ウィンドウをドラッグ＆ドロップしたりして行き来することになる。画面が大きければ全体を丸々表示できるので、そのような行き来が生じない。

これは当たり前のことだが、（私の観測範囲では）見落としている方も多いように見受けられる。

スマホと PC とでは、PC の方が（画面が大きいから）圧倒的に作業しやすい。これはわかる。実際、スマホで仕事しようとする物好きはそうはいまい。同様に、小さなノート PC のディスプレイと大きなディスプレイとでは、後者の方が断然作業しやすい。しかし前者の、小さなディスプレイのままで仕事する人が多い。ディスプレイを一台入手して、そっちに投影（というより後述のデュアルディスプレイにするケースが多いかと思うが）してやれば後者が手に入るのに、である。これはあまりにもったいない。

もっとも「新しくディスプレイを調達するのが難しい」ケースもあるだろうが、多少の面倒をかけてでも手に入れる価値はあると思う。

デュアルディスプレイ

  • LV1: 小さなディスプレイ
  • LV2: 大きなディスプレイ
  • LV3: デュアルディスプレイ(ディスプレイ2台)

小さなディスプレイよりも大きなディスプレイの方がワーキングメモリの負担が少ない。同様に、ディスプレイ1台よりもディスプレイ2台の方が負担が少ない。

ただし、本質的には「画面を広くしたい」だけであるから、ディスプレイ1台でも広くできる(高解像度のディスプレイを使う等)のならそうしてもいい。

使いやすい道具を使う

会社から支給された道具をそのまま使い続けるケースが散見されるが、支給品はたいてい単なる量産品であり、使いやすさに優れていないことが多い。我慢して使い続けることはそれだけでストレスになり、また本領も発揮できない（たとえばキーボードが打ちづらくてミスタイプが頻発する等）ので、可能な限り抗いたい。つまり、（許されているなら）自分にとって使いやすい私物を使うか、あるいは経費で購入してもらう。

道具:

  • キーボード
  • マウス
  • 椅子
  • 机
  • 小物入れ、書類入れ
  • ……

とはいえ、どこまでできるかは会社次第だろう。

私の例（キーボードとマウスのみを取り上げる）でいうと「原則支給品を使う」というルールになっており、他のキーボやマウスを使えるかどうかは部署次第、となっている。お堅い部署であれば部長や上司が許さないし、そうでない部署なら部長や上司からして私物を使っていたりする。私は以前、前者の部署にいたが、不便すぎたので異動した。今は後者の部署にいる。

ただし、後者の部署であっても「客先や常駐先では使えない」など追加ルール（この例では常識だが）があったりする。私は「客先訪問や常駐を絡む仕事はしない」ことにすることで不便を回避している。

おわりに

知っている方からすると当たり前のことを長々と書いただけかも。

書いてみて気付いたが、重要なのは方法よりも、

  • （会社だし）一見するとダメそうに見えるが、最初から諦めずに粘る
  • 根本的に不自由に染まっている類の仕事や部署には行かない

という姿勢なのかもしれない。

git log で「data stream error (incorrect header check)」とか「fatal: loose object XXXX (stored in .git/objects/xx/XXXX) is corrupt」が出る件

Git

事象

とあるローカルリポジトリにて、先週くらいから git log するとエラーが出るようになった。まず Tortoise Git の Show log でエラーが出て、なんでだろと git コマンドで git --no-pager log をして全件表示してみると、ずいぶんと過去のコミットのところで以下が出る。

$ git --no-pager log
...
...
error: inflate: data stream error (incorrect header check)
error: unable to unpack XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX header
fatal: loose object XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (stored in .git/objects/xx/YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY) is corrupt

なぜかは知らんが Git オブジェクトが壊れてるみたいだ。

解決方法

以前バックアップしてたローカルリポジトリの .git/objects/xx/YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY で上書きした。

上書きする前、WinMerge で .git/objects/xx/ の差分を取ってみたら、見事に YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY のみに差分が出ている状態だったので、試しに上書きしてみたらエラーが出なくなった……という具合。

試したけどダメだったこと

上記は全部ダメだった。

で、壊れた原因は？

不明。

申し訳ないが Git オブジェクトを勉強するほど物好きではないです。……といいつつ、勉強して中身読んだりすると楽しいかもしれないなと思ったり。気が向いたら。

MkDocs で生成したサイトをローカルで開くと index.html が開かれない問題

MkDocs

たとえば以下のような Markdown を書いてビルドしたとすると、

- [page1へのリンクです](pages/page1.md)

生成したサイトでは「page1へのリンクです」ハイパーリンクが表示され、これをクリックすると page1.md に相当する HTML ページにアクセスできるはずだ。

しかし実際の挙動は、

  • サイトの構造は pages/page1/index.html となっている
  • リンクをクリックした時は pages/page1 という ディレクトリが開かれ、index.html まで開かれない

となる。なぜなのか。

なぜ？

ディレクトリにアクセスした時に index.html を開く、という挙動はウェブサーバーが行っている から。ローカルから生成サイトのファイルにアクセスした場合、当然ならウェブサーバーは動いていないので、この挙動も働かない。

どうすれば開くようになる？

方法1: index.html まで開かれるようにする

mkdocs.yml に use_directory_urls: false を設定することで実現できる。

use_directory_urls が true だと HTML 変換後のリンク先は pages/page1 までとなる。その先の HTML ファイルをどう補わせるかはウェブサーバー任せ。デフォルトだと true。

use_directory_urls が false だと、このお任せは行わず、リンク先は明示的に pages/page1/index.html と index.html を指すようになる。

参考: use_directory_urls - Configuration - MkDocs

方法2: サーバーを立ち上げる

mkdocs serve コマンドでローカルサーバーを立ち上げてから読む。

方法3: どっかにデプロイする

GitHub Pages など、どこかウェブサーバーが稼働してるとこにデプロイしてから読む。

参考

MkDocs でスペース2個のインデントをリストのネストとして認識させたい場合

MkDocs

Markdown を HTML 化する手段として MkDocs は有用な選択肢だ。Sphinx の Markdown 版みたいな使い心地である。

しかし唯一残念なのが (リスト等をネストさせる時の)インデントがスペース4個強制 であること。これがスペース2個だと認識されない。

そこでスペース2個で認識させるにはどうしたらいいか調べてみた。

結論

Python-Markdown の Extension である Mdx Truly Sane Lists を取り入れる。

適用手順

まずはインストール。

$ pip install mdx_truly_sane_lists

インストールされてるか確認。

$ pip freeze | grep mdx
mdx-truly-sane-lists==1.1.1

お使いの MkDocs プロジェクトに組み込む。具体的には mkdocs.yml に以下を記述。

site_name: 2space indentation test
markdown_extensions:
    - mdx_truly_sane_lists:
        nested_indent: 2

nested_indent の値を 2 にする。

詳しく

関連情報や背景などを雑多に取り上げておく。

MkDocs が持つ Markdown to HTML 変換の仕組み

Python-Markdown を使用して変換している。

つまり Markdown 変換の挙動を制御するためには、この Python-Markdown に与える設定値を変える必要があるのだけど、MkDocs ではこの変更を設定ファイル mkdocs.yml 経由で行えるようになっている。それが上記の markdown_extensions の記述。

Python-Markdown の拡張機能については以下を参照。

mdx_truly_sane_lists はサードパーティー製の拡張機能にあたる。

mdx_truly_sane_lists のソースはどうなってんの？

mdx_truly_sane_lists/mdx_truly_sane_lists.py を見るといい。

20行目 あたりだろうか、

    TrulySaneBlockProcessorMixin.truly_sane_tab_length = self.getConfigs()['nested_indent']

mkdocs.yml にて指定した nested_indent の値を読み込み、Python-Markdown に与えているという感じ。（詳しく読んでないけどたぶん）Python-Markdown 側で「Extension クラスを継承してパーサーを与えたら変換の挙動をカスタムできるよ」みたいになっていて、そのお作法に従って書いている＆インデント数の指定を(nested_indent として指定した)2にしている、のだと思う。

スペース2個インデントの是非

Python-Markdown では スペース4個が正義 だと捉えている。

markdown/index.md から引用しておくと、

The syntax rules clearly state that when a list item consists of multiple paragraphs, "each subsequent paragraph in a list item must be indented by either 4 spaces or one tab" (emphasis added). However, many implementations do not enforce this rule and allow less than 4 spaces of indentation. The implementers of Python-Markdown consider it a bug to not enforce this rule.

とある。Markdown の仕様としてはスペース4個 or タブ1個が正しいので、それ以外のインデントはバグですよ というスタンス。

ただ、それじゃ困る（既にスペース2個の Markdown 実装も流通している）というわけで、一応回避策が用意してある。

In the event that one would prefer different behavior, tab_length can be set to whatever length is desired. Be warned however, as this will affect indentation for all aspects of the syntax (including root level code blocks).

tab_length というプロパティを使えばいい。もっというと、以下のような感じでレンダークラス markdown.Markdown を使う時に指定する。

        md = markdown.Markdown(
            tab_length=2,
            ...
        )

ただし、ここを変更しちゃうと、リストに限らず（Markdown 文法中で登場する）インデントのスペース個数が全部変わってしまうので注意。

grep で input file 'XXXX' is also the output が出る件

grep

grep の結果を標準出力にリダイレクトすると、以下のようなメッセージが出てくる。

$ grep -rn "todo" ./ --exclude-dir={.git} > grep_result
grep: input file './grep_result' is also the output

これは （標準出力させている）grep_result というファイル自身も grep の走査対象になっちゃってるよ という意味。

詳しく

そもそも grep は走査中に「走査対象の中身が変わらない」ことを前提としている。いわゆる 冪等性（べきとうせい） というやつで、平たく言えば「同じオプションなら何回実行しても同じ結果が得られるよね」を保証するというもの。

ところが、上記のような使い方だとこの前提が崩れる。走査対象の一つである grep_result の中身が、grep を実行する度に変化してしまうからだ。

……と思っています。ホントのところは知りません。詳しい方、いらっしゃいましたら教えてください。

解決するにはどうしたら？

Ans: 標準出力させているファイルを grep の走査対象から弾く。

もっというと --exclude オプションを使う。

$ grep -rn "todo" ./ --exclude-dir={.git} --exclude=grep_result > grep_result

秀丸エディタで指定ディレクトリを除外する Grep を実現する

秀丸エディタ grep

結論

秀丸エディタ単体では無理なので

  • 別の grep ツールで grep 結果をファイルに吐き、
  • そのファイルを秀丸エディタで開いてタグジャンプする

というやり方を用いる。

別の grep ツール？

Git for Windows に同梱された grep コマンドがオススメ。

正しくインストールできているかどうかは以下で確認できる。

$ where grep
C:\Program Files\Git\usr\bin\grep.exe

$ grep --version
grep (GNU grep) 3.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
...

ラッパーバッチファイル

「別の grep ツール」と「秀丸エディタ」を中継する仕組みが必要。

やり方は色々あるが、ここでは私が考えたものを紹介。

考え方

以下のような仕組みをバッチファイルで作った。

  • カレントディレクトリ配下を grep する
  • 除外したいディレクトリはあらかじめ指定しておく
  • 使い方は grepex キーワード とする

動作としては、 grepex キーワード を実行すると grepresult なるファイルが秀丸エディタで開かれる。この中身は以下のようになっており、秀丸エディタで普通にタグジャンプすることができる。

./source1.js:36:    // @todo util.js からコピペしたままなので DRY する
./source2.js:103:   // @todo 変数名がわかりづらいので具体的にする
...

バッチファイル中身

grepex.bat

@echo off
setlocal
set keywords=%*
set outfilename=grepresult
set outfilepath=%~dp0%outfilename%
set editorpath=C:\Program Files\Hidemaru\HIDEMARU.EXE

grep -rn %keywords% ./ --exclude-dir={.git,node_modules,lib} --exclude=%outfilename% > %outfilepath%
start "" "%editorpath%" "%outfilepath%"

利用時に設定が必要なのは以下二つ。

  • editorpath 変数
    • 利用するテキストエディタのフルパス
    • 動作確認は秀丸エディタでしかしてない
    • 上記の grepresult フォーマットに対応したエディタなら何でも良い
  • --exclude-dir オプション
    • 除外したいディレクトリを指定する
    • ここでは以下三つを指定している
      • .git
      • node_modules
      • lib

schtasks コマンドでリマインダーを実現する

リマインダー/アラーム Windows

以前 Windows の at コマンドでリマインダーを作ろうとした けど、at コマンドは Windows によっては使えない。代わりに schtasks コマンドを使うようになっている。

ならば、と schtasks でもリマインダーを実現できないかを調べてみた。

結論

  • schtasks はコマンドラインが煩雑なので、素で使うのはキツイ
  • リマインダーを実現したいならラッパースクリプトとか書いた方がいいと思う

前提

以下のようなシンプルなリマインダーを想定。

  • 今日の HH 時 MM 分になった時に指定メッセージを表示させたい
  • リマインド設定時に与えるもの
    • HH:MM
    • メッセージ
  • メッセージ表示 = メッセージを書いたテキストファイルを開く、とする

リマインダーを登録する

$ schtasks /create /sc once /tn タスク名 /tr "起動したいテキストファイルのパス" /st HH:SS /f

パラメータについては以下のとおり。

  • タスク名
    • リマインダーの名前を指定
    • 例: reminder1
  • パス
    • 起動したいコマンドラインを指定
    • ここではテキストファイルパスを想定(関連付けられたテキストエディタで開かれる)
  • HH:SS
    • リマインド日時を指定
    • 現在時刻より1分以上遅い時刻にすること
    • 現在時刻以下だと『/ST が現時刻よりも早いため、タスクは実行されない可能性があります』警告が出るし、実際実行されない

新規も設定もこれ一本で済む。

リマインダーをn個作りたければ「タスク名」をn個分指定する。

登録したリマインダーを見る

$ schtasks /query /tn タスク名 /fo list

フォルダー\
ホスト名:        XXXXXXXXX
タスク名:        \(ここにタスク名が表示される)
次回の実行時刻:  ★1
状態:            準備完了
ログオン モード: 対話型のみ

★1 については以下の通り2パターン。

リマインダーを設定していない場合:

  次回の実行時刻:  N/A

リマインダーを設定している場合:

  次回の実行時刻:  2018/07/30 16:39:00

登録したリマインダーをお試し実行する

$ schtasks /run /tn reminder1
成功: スケジュール タスク "reminder1" の実行が試行されました。

シンプルなので解説は無し。が、一つ高度な補足説明をしておく。

リマインダー登録時にコマンドラインを同期実行させていると、以下のように連続で実行できない。実行させたいなら、実行されたプログラムをいったん終了させる必要がある。

$ schtasks /run /tn reminder1
成功: スケジュール タスク "reminder1" の実行が試行されました。

$ schtasks /run /tn reminder1
情報: スケジュール タスク "reminder1" は現在実行中です。
成功: スケジュール タスク "reminder1" の実行が試行されました。

$ schtasks /run /tn reminder1
情報: スケジュール タスク "reminder1" は現在実行中です。
成功: スケジュール タスク "reminder1" の実行が試行されました。

★ここで最初に試行した時に実行されたプログラムを終了させたとする★

$ schtasks /run /tn reminder1
成功: スケジュール タスク "reminder1" の実行が試行されました。

/create 時のオプションについて

$ schtasks /create /sc once /tn タスク名 /tr "起動したいテキストファイルのパス" /st HH:SS /f

/sc once

一度だけ実行されるスケジュールを登録する、の意。

本当は hourly(一時間毎)、daily(一日毎)、みたいな定期指定もできるのだが、今回は扱いを単純にするため ONCE(一度実行したら即終わり) という最も単純なオプションを使うことにした。

/tr コマンドライン

実行させたいコマンドラインを指定。

例として複雑なコマンドラインを書きたい場合を示す。以下はテキストファイルを非同期に実行させる例。

$ schtasks /create /sc once /tn タスク名 /tr "cmd /c start \"\" \"起動したいテキストファイルのパス\"" /st HH:SS /f
  • Point1: start コマンドで非同期的に実行させる
  • Point2: でも start コマンド単体では動かないので cmd を経由させる
  • Point3: 二重引用符は \ でエスケープして記述する

非同期に実行させることのメリットは schtasks /run による試行を（起動したプログラムを終了させることなく）何度も試せることくらいか。

/f

上書き登録時の確認メッセージを省く。

省かないと以下のような確認が出てきて邪魔くさい。

$ schtasks /create /sc once /tn reminder1 ...(略)...
警告: タスク名 "reminder1" は既に存在します。置き換えますか (Y/N)?

感想

  • schtasks はコマンドラインオプションが豊富なので不自由は無い
  • しかし煩雑なので、これを素でリマインダーとして使うのは苦しい
    • 何らかのラッパースクリプトを書くのが良いだろう
  • schtasks の使い方で困ったら /? でヘルプ見ればいい

煩わしい会社雑務の負担を軽減するためのアイデアや方法

雑務は煩わしいので極力減らしたい。まずは整理も兼ねて、自分の立ち位置や考えなどを雑多にまとめてみることにした。

前提

「雑務」の定義:

  • 雑務 = チームメンバーや部署全員のために誰かが背負わねばならない、（PJではなく）会社や部署として必要な雑務、と定義する
  • その雑務を自分が背負ってしまっているという状態を想定する

自分の立場:

  • 自分 = 下っ端(新人とか平社員とか)
  • 自分は大企業に勤務している。さらに以下を満たす。
    • ホワイトワーカー
    • お茶くみやコピー取りといった古臭い雑務が無い程度にはリテラシーがある
    • 会議室予約システムが備わっている程度にはシステムが整っている

本記事が扱う/扱わない観点:

  • 雑務を行う意義については議論しない
  • あくまで雑務にかかる手間をできるだけ減らす、という観点のみを語る

(フォーマット)

(ここに雑務の概要)

Before:

  • (ここに従来のやり方や問題点)
  • (ここに従来のやり方や問題点)
  • ...

After:

  • (ここに負担を軽減するアイデアや方法)
  • (ここに負担を軽減するアイデアや方法)
  • ...

コメント:

  • (その他補足などをつらつらと)
  • (その他補足などをつらつらと)
  • ...

出欠確認

飲み会やイベントの参加可否を尋ねる系の雑務。

Before:

  • 口頭で一人ずつ
    • 尋ねる側の負担が大きい(一人ずつ物理的に回っていくのは面倒くさすぎる)
    • 尋ねた時に雑談が発生して時間を食われやすい
  • メールで訊く
    • 受信ボックスが錯綜する
    • 状況を俯瞰できない
  • 共有フォルダに置いた Excel ファイルを各自が編集
    • 編集ロックや競合が発生して記入がだるい
    • 重い

After:

  • ブラウザで答えられるシステムを使う
    • ロックや競合が発生しない
    • 軽い
    • :x: システム構築とメンテが大変
  • ホワイトボードをぶら下げておいて「各自記入して」にする
    • 準備が簡単
    • ロックや競合が発生しにくい
    • :x: 勤務場所が違うメンバーには使えない

コメント:

  • デフォルト選択肢
    • Aさんは何も言わなければ参加、Bさんは何も言わなければ不参加、みたいなデフォを決めておく
    • n人分デフォを決めておくと、n人分の参加可否ヒアリングを省ける
  • マグネットプレート
    • ホワイトボード形式で運用する場合、名前を書いたマグネットプレートを動かす方がラク

電話応対

いわゆる電話番。ここでは「社内の誰か」から「自分の部署」にかかってきた電話を「常に自分が取る」という前提にする。

Before:

  • アットランダムにかかってくる＆かかってきたら取らないといけない
    • いちいち集中を乱される
    • （電話頻度にもよるが）コードリーディングや設計みたいな集中を要する作業はまともにこなせない
  • あまり集中しなくていい仕事をしてる人や、名指し人になる人が多いのに、無関係な自分が全部取らないといけないのが理不尽
  • もう仕事や対人関係には慣れたのに、年下だからと対応を任されているという理不尽

After:

  • 電話をかけてきた人の認識を改めてもらう
    • 例1: どうせAさんに繋ぐんだから、もうAさんに直に連絡してくれません？
    • 例2: 急ぎでないならメールやチャットでお願いできませんか？
  • 電話をかけてきた人と必要以上に仲良くならない
    • 仲良くなると頼られて何度も電話される
    • 仲良くなると雑談で時間を食われる
    • 無愛想くらいでちょうどよい
    • 雑談が発生しそうなら「打ち合わせがありますのでこれで」等で上手いこと逃げる
  • 電話応対のフローをマッスルメモリ化(手続き記憶化)する
    • 呼吸のようにサクサクこなせるようになれば心身的には楽
    • 練習すべきは...
      • 電話機の操作方法
      • 伝言メモの書き方や運用方法
      • 名指し人になりえる人物の名前と座席位置
      • チームメンバー全員の不在予定の把握(定期的に眺めることを習慣化しておくと良い)
  • 仕事に熱中していて電話に出れないフリをする
    • 本当に集中している時はこれで難なく回避できる
    • :x: 頻繁に使うとメンバー間で不満が蓄積されやすい

コメント:

  • 「こうすれば抜本的に改善できる」という銀の弾丸はないので、一つずつ対象を絞って削減していくしかない
    • 対象1: 電話をかけてくる人
    • 対象2: 自分(特に電話応対に関する習熟度)
  • 電話応対が向いてない or イヤなら、その旨を進言してみるのもアリ
    • ただしチームメンバーや上司を納得させる根拠が必要
    • 例1: 「私、ADHD なんです」

飲み会の幹事

懇親会、歓迎会、新年会忘年会など飲み会全般の幹事というお仕事。

Before:

  • 出欠確認、出欠確認フォロー、日程調整、店舗予約、代金徴収など雑務のオンパレード

After:

  • 飲み会ではなくランチに変える
    • 懇親会や歓迎会の類はランチで十分事足りる
    • 夜遅くないので参加しやすい
    • ランチは1時間くらいなのでだらだらせずに済む
    • アルコールが入らないのでだらだらせずに済む
    • 必要なら上司権限で +1 時間くらいして業務扱いしてしまえばいい
    • :x: 提案して承認してもらうまでが大変（というか役職高い老害には通じない可能性大）
  • 飲み会幹事対応が向いてない or イヤなら、その旨を進言してみるのもアリ
    • ただしチームメンバーや上司を納得させる根拠が必要
    • 例1: 「私、ADHD なんです」

完了フォロー

チーム全員が対応しなきゃいけない雑務に対して、「皆さん終わりました？」とか「Aさん、まだ終わってないみたいなのでお願いします」とかいったフォローをする役目。

Before:

  • 面倒くさい
    • 各自がちゃんと締切までに遂行しようよ、それくらいの自己管理もできないの？

After:

  • 上司に「私が言っても効果が無いのでお願いします」と代わってもらう
    • 下っ端の自分よりも上司の方が発言の力は強い
  • 終わってない人に恥をかかせる
    • 例1: メンバー全員が見ている場所で「Aさん、この件がまだですけど」と確認する
    • 例2: 例1に加え「フォロー回数カウント」を付記しておく
      • 「Aさん、この件、対応お願いします(フォロー累計: 6回)」
    • :x: 人間関係に亀裂を生みやすい

会社行事担当

（特に部署やオフィスを横断するような大規模な）会社行事の運用を担当する仕事。新人歓迎会や忘年会、その他クリスマス会や、場合によっては社内旅行もあるかもしれない。ステークホルダーと規模が増える分、雑務も鬱陶しくなりがち。

Before:

  • 進行させるために他チームとのコンタクトや返事待ちが必要でだるい（待ちが発生してもどかしい）
  • 担当者が集まれるタイミング≒定時後、というわけで雑務が定時後に食い込みやすい
  • 上の人間も多数参加するため、形式やら配慮やら何やらを重視せざるを得ず、制約が多くてストレス
  • （私の観測範囲だが）効率的な仕事術やものの見方を知らない人間（特に総務、事務、庶務サイドの人達）が多く、全体的にだらだらしがち
    • そして説明してみても通じない
  • 会場設営や撤収などの物理作業（力仕事）が発生する

After:

  • 会社行事担当が向いてない or イヤなら、その旨を進言してみるのもアリ
    • ただし部署のメンバーを納得させる根拠が必要
    • 例1: 「私、ADHD なんです」
    • 例2: 「前にやってみましたけど一悶着ありまして……」

コメント:

  • （会社にもよるが）これは下っ端の洗礼みたいなものなので、よほどの理由がなければ断れない
  • 現実的な回避方法は 一度参加してみて、そこで一悶着起こす ことだろう
    • 一悶着 ＝ 参加する、無駄や非効率を積極的に探し、指摘し、議論し、衝突する
    • 改善されればそれはそれで良し
    • 改善されなければ嫌われて、もう来るなとなる

会議関連

会議＝チーム内や部署内で行うローカルな会議、とする。またコードレビューなど開発上の打ち合わせは含めない。

会議全般

はじめに会議全般の TIPS をまとめておく。会議絡みの雑務は会議が無ければ発生しない ので、そもそも会議をいかに減らすかが重要。

After:

  • 会議時間を無闇に引き伸ばさない
    • やることがないなら「しない」もアリ
    • 「しない」勇気
    • 会議をしないことは罪ではない
  • 単に情報共有や報告がしたいだけなら「資料展開＆各自読んでね」で事足りる
  • ファシリテーターとタイムキーパー
    • 進行役と時間計測係を決めないと、凡人はすぐ話が逸れる
    • 凡人＝効果的効率的な会議テクを知らない or 知っているけど周囲に働きかける力が無い人
  • アジェンダとゴール
    • アジェンダ（議題と進行順序）とゴール（各議題で何をしたらゴールなのか）を決めておく
    • 会議時は事前に強調する
    • 必要最小限にアジェンダの通りにゴールに行くことだけを考える
  • 参加人数はできるだけ最小限に絞る
    • 多いと発散しやすいし、関係ない話題で手持ち無沙汰な人も出る

コメント:

  • 改善や削減の余地は腐るほどある（その手の本も山ほどある）が、下っ端レベルでは全員に周知させづらいのが辛いところ
  • 自分主体の打ち合わせ（自分がレビューイとなるレビュー等）では積極的に盛り込みたい

資料作成

会議中に投影、または配布する資料の作成。

Before:

  • パワーポイントやワードで作る
    • 重い。遅いしストレスもかかる
    • 見栄えの編集に時間を取られがち（無自覚なケースもアリ）

After:

  • テキストファイルで作る
    • 作るのが楽
    • :x: レガシーな人種から「手抜きだろ」と反感を買われやすい
  • 図表や別ファイルで用意する
    • 会議中は必要に応じて当該ファイルを別途開いて見せればいい
    • 原稿ファイルにマージする手間がない
  • 複雑で動的な図表は事前につくらず、会議中にホワイトボード等に描く
    • 事前に時間かけてつくるのはだるい
    • 時間かけてつくっても結局ホワイトボード使う羽目になる（ことがある）
    • だったら最初からホワイトボードで説明すればいい

コメント:

  • Plain Text で十分事足りるという点を周知できるかどうか にかかっている

会議室予約

会議を行う場所を確保する雑務。（環境は会社次第だが）ここでは「会議室を会議予約システムにて事前予約して利用するスタイル」を前提とする。

Before:

  • 競争率の厳しい会議室の空きを頑張って探して確保するというつまらないお仕事
  • 予約は入っているが使われていない会議室を見つけて、予約者にコンタクトを入れる（使ってないなら譲ってもらう）というコミュニケーションコスト

After:

  • 定期的に開催する会議なら定期予約しておく
    • before: n回分やるならn回分の予約が必要
    • after : n回分の予約が1回の予約で済む
    • :x: n回分まとめて取れるケースは稀
  • 定期開催が無くとも、とりあえず定期予約しておく
    • チームの会議開催頻度が週2回、各1時間程度であれば、1時間の予約 x2 を先に取っておく
    • 会議日時決定→予約ではなく「会議室予約→その日時で会議する」という発想 と言える
  • 本当に会議室が必要なのか考え、要らないなら予約しない
    • 例1: オープンスペース等で代用できないか
    • 例2: 廊下で立ち話で済まないか
    • 例3: 自席に集まって話し合うだけで済まないか

議事録

会議の議事録を取るお仕事。

Before:

  • 単純に面倒くさい
  • 議事録書いた後の承認フローがだるい

After:

  • 議事録のフォーマット/テンプレートを定めて機械的に書き込めるようにする
    • 精神的に楽
  • 決定事項とその根拠や意図はちゃんと書くべきだが、それ以外の過程は書かない
  • 議事録を Wiki などのオープンスペースに展開し、参加者が自由に加筆修正できるようにする
    • 承認フローを経ずに自浄作用で自然と完成する
  • 議事録を投影しながら会議する
    • その場で修正しながら FIX できるため会議後の対応がゼロになる
  • 議事録対応が向いてない or イヤなら、その旨を進言してみるのもアリ
    • ただしチームメンバーや上司を納得させる根拠が必要
    • 例1: 「私、ADHD なんです」

お土産の配布

出張時や旅行時に買ってきたお土産を、チームメンバー全員に一人ずつ配っていく雑務。

Before:

  • 面倒くさい

After:

  • 「ここに置いといたので一人一つ取ってね」で済ませる
  • 雑務マン（後述）に任せる

コメント

  • 雑務マン
    • 実業務よりも雑務を喜んで行ってくれる人
    • （私の観測範囲では）IT技術に全然興味は無い、やる気もないという女性社員が雑務マンとなって（エンジニア気質の多い）チームで重宝される、という事例が数件あった
    • 重要なのはその人 自らが能動的に雑務していて、かつ 「私、ぶっちゃけ開発とか技術とか興味ありません。その分、雑務方面で貢献したいです」的な主張をしている こと。そうじゃない場合に頼むとセクハラやパワハラになりかねない

おわりに

長々と書いてきたが、雑務を回避するための戦略は以下三つしかない。

  • 戦略1. やり方を工夫する（個人で出来るもの）
  • 戦略2. やり方を工夫する（上司やチームを巻き込む必要があるもの）
  • 戦略3. 雑務要員から自分を外してもらう

戦略1 はどんどんやればいい。が、これで対処できる雑務には限りがあるため効果は薄い。

戦略2 は一番難しい。そりが合わず（特に目上の相手によって）一蹴されるケースもしばしば。また下手に巻き込もうとすると反感を買われるデメリットもある。反感を買われないよう、周到に工夫を浸透させようと頑張ることもできなくはないが、それはそれでまた手間がかかる。

戦略3 は利己的でネガティブな戦略。方向性は二つあって「やむを得ないと思ってもらう」あるいは「嫌われることでハブられる」の二つ。後者は人間関係や居心地的にオススメはしない。前者も前者で、やむを得ないと思ってもらえるレベルの事情となると、かなり限られてくる。「ADHDなんです」みたいな病気のレベルになる。

結論として言えるのは 雑務を回避するのは意外と難しい ということ。雑務を回避することに尽力するくらいなら、転属や転職した方がマシかもしれない。実際、部署や会社によって、雑務の量は驚くほど違う。

バッチファイルで YYMMDD_HHMMSS みたいな現在日付時刻文字列をつくる

Batchfile

ファイル名に日付時刻文字列を入れたい場合などに重宝する。

バッチファイル実装

以下のようにする。

@echo off
setlocal

set shortdate=%date:/=%
set shortdate=%shortdate:~2,6%

set time_0padding=%time: =0%
set shorttime=%time_0padding::=%
set shorttime=%shorttime:~0,6%

set shortdatetime=%shortdate%_%shorttime%
echo %shortdatetime%

最終的に欲しいのは %shortdatetime% 変数。それ以外は導出過程。

解説

一言で言うと、環境変数の date と time から日付時刻文字列を取り出し、それを（色々と文字列処理を工夫して） YYMMDD_HHMMSS フォーマットに変更している。

現在日付時刻の取り方

環境変数 %date% と %time% で取れる。

$ echo %date%
2018/07/23

$ echo %time%
16:35:06.57

ただし %time% は時(Hour)が一桁の時に 09 ではなく 9 みたいなスペース埋めであり、使いづらいので、 置換記法でスペースを0に置換させる。

$ echo %time%
 9:12:34.56

$ echo %time: =0%
09:12:34.56

置換記法

%date:/=%

これは date 変数中にある「/」を空文字列に置換する、つまり削除するという意味。

以下に例を示す。

$ echo %date%
2018/07/25

$ echo %date:/=%
20180725

一般論で書くと以下のようなフォーマットになる。

%変数名%

  ↓ こう書く

%変数名:置換前の文字=置換後の文字%

スライス記法

%shortdate:~2,6%

これは shortdate 変数中にある2文字目から6文字分を取り出す、という意味。

以下に例を示す。

$ echo %date%
2018/07/23

$ echo %date:~0,4%
2018

$ echo %date:~5,2%
07

$ echo %date:~8,2%
23

口頭ではなくチャットでコミュニケーションするためのヒント集

チャット ポエム

「口頭を使うべきかチャットを使うべきか」はケースバイケースあるいは宗教論争。

私の職場では口頭ベースが多い。が、もうちょっとチャットに頼ってもいいんじゃないかと思っている。ひとまず整理も兼ねて、根拠やらアイデアやらテクニックやら（あとポエムも少し）を雑多に記してみたい。

口頭のデメリット

デメリット1. 集中阻害

話しかけられた時点で集中が阻害される。

口頭で話しかけられたら、基本的に必ずその場ですぐに応答を返さなければならない。たとえ作業中であっても。無視するという選択肢は無い（人として最低の行為）。

（一般論はさておき少なくともエンジニアの）仕事は集中して取り組むべきもの。いつ口頭で割り込まれるかわからない中で仕事をするのは辛すぎる。口頭による集中阻害を乱暴にたとえるなら、将棋の棋士さんが対局で思考してる時に「ねぇねぇ、ちょっと」と声を掛けられるようなもの。

  • Q: チャットを使うとどうなる？

話しかけられた時でも即座に応答せずに済む。集中している場合はいったん放置するか、とりあえずタスクリストに突っ込んでおけばいい。言い方を変えるなら、メールのように自分のタイミングで処理できるとも言える。

デメリット2. 記録されない

記憶違いや怠慢が起きやすい。

口頭でコミュニケーションした経過や結論は記録されないので、たとえば

  • 例1: 言った/言ってない論争
  • 例2: そんなの聞いてないよ
  • 例3: そんなこと言った覚えはないぞ

以上のようなことが起こる。

  • Q: チャットを使うとどうなる？

会話の経過が記録されるので記憶違いが起きない。書いていることが正義。また、記録という形で証拠が残っているので誤魔化しも効かない。

デメリット3. 共有できない

情報の属人化 が進む。

口頭で話された経過や結論は、会話したメンバーにのみ伝わる。逆を言うと、その場にいなかったメンバーには伝わらない。

  • Q: チャットを使うとどうなる？

（皆が見ているチャンネルで発言すれば）経過や結論を皆にもインプットできる。

1vs1 と 1vsN

チャットによるコミュニケーションは「相手の数」という観点で二種類に分類できる。

  • 1vs1: いわゆるDM(ダイレクトメッセージ)
  • 1vsN: いわゆるチャンネルでの発言

適宜使い分けると良い。

宗教論争だろうが、いくつか例を挙げる。

  • 上司にプライベートな事情について共有する → 1vs1
    • 理由: なるべく人に知られたくないことだから
  • 上司に承認依頼を出す → 1vs1
    • 理由1: 承認依頼は上司のみが絡むタスクなので上司にだけ知らせればいいから
    • 理由2: 逆に 1vsN だと無関係なメンバーに無関係なメッセージを読ませちゃうことになるから
    • ただし「私はあなたに承認依頼出したよ」という状況を皆に伝えたい場合は、あえて 1vsN + Mention を使うこともある
  • 技術的にわからないことを質問する → 1vsN
    • 理由1: メンバーの誰かに答えてもらえればいいから
    • 理由2: 他のメンバーにとっても参考になるかもしれないから

コミュニケーションの種類

四種類あると思う。

  • 報告: 相手に伝えたらおしまい
  • 依頼: 相手にお願いしたらおしまい
  • 質問: 相手から答えが返ってきたらおしまい
  • 相談: 相手と複数回やり取りするもの

細かい使い分けは後述するが、一点だけここで取り上げておく。相談についてはチャットで行わない方が良い。やり取りが発生すると 相手の意見がタイプされるまで待つ時間が生じる。これがバカにならない。口頭なら 1 分で済むことが、数倍は平気でかかる。じゃあどうすればいいかというと、 相談の依頼 だけ行い、相談は口頭など別手段でやる。

チャットの推進に必要なもの

これらを備えていないとチャットは浸透しづらいよ、というもの。

使いやすいチャットシステム

一言で言うなら Slack。

Slack はバージョン管理でいう GitHub みたいなもので、よほどの事情が無ければ他の選択肢は無いと思う。古いチャットツールや IM 等では役不足であり、使いづらさでストレスが溜まってチャットどころではない。

  • Q: オンプレじゃないと会社が許してくれないんだけど？

Ans: Rocket.Chat など非公式の Slack クローンもある。ただオンプレだと自前メンテが必要なため、どうしても管理者のスキル不足や大人の事情が生じる。「環境が貧弱で重たい」とか。なので多少苦労してでも Slack を使う方向に倒した方が幸せだと思う。

  • Q: グループウェアのコミュニケーション機能で十分だと思っているけど？

これは単に無知なだけ。Slack レベルのチャットの使いやすさには到底及ばない。この質問は「チャット使わなくてもメールがあるじゃん」と言っているようなもの。

(特に上司やリーダーは) タスク管理

上司やリーダーは読むべきメッセージ量が多く、報告や依頼される量も多い。そのため彼らには 「自分が対処すべきメッセージ」をタスク管理に落とし込み、対処を漏らさないようにするスキル が要求される。そうしないとメッセージ発信者が改めてフォロー（口頭であることも多い）する羽目になり、チャットの意義が薄れる。

ここで一つの疑問（主張）が生じる。

  • Q: 上司/リーダーは忙しいのだから部下がちゃんとフォローするべきでは？

確かに一理あるが、常にそうであるとも限らない。上司側の怠慢であるケースもある。

以下ポエム。

私が思うに、上司/リーダーレベルの人間であればタスク管理程度は習得して当然だ。タスク管理を使えば、受けたメッセージをタスクリストに追加するとか、一日数回ほど「メッセージを読んでタスク消化に落とし込む」タスクを設けておくだけで、これに対処できる。もちろん、それら管理作業に時間がかかっていては話にならないので、呼吸するかのように素早く使いこなす技術も必要だ。

通知をコントロールする技術

チャットにも通知という仕組みがあり、口頭ほどではないものの割り込みを感じることがある。これを対処するスキルも必要だ。

アプローチは二つある。

  • アプローチ1: 通知を切る＆自分のタイミングで読む

通知を意図的に無視する、でも OK。しかしクイックレスポンスを要するメッセージへのレスポンスが遅れがちになる。この点は「緊急な用事は口頭にして」とか「メンションは緊急な時のみ使って」など目安を決めて回避できる。

あと、よくあるのが「チャットを読むのを忘れる」だが、それはタスク管理なりリマインダーなりで忘れないよう制御するしかない。たとえば一日三回ほどチェックしたいなら、アラームソフトなんかを使って毎日三つほど「チャットを読む！」というアラームを設定しておくとか。

  • アプローチ2: 集中タイムを設けて、その間は一切反応しない

これは「この時間帯は一切反応しませんよ（集中したいんです）」という時間帯をつくる、というもの。集中タイムの時間帯をチーム内でしっかり共有できていれば案外機能する。

この方法の問題は「集中タイム時に送ったメッセージはどうなるの？」ということだが、そこは「集中タイムが終わった後に読んでくれるだろう」と信じるしかない。読んでくれないとしたら、それは受信側の問題だ（上述のタスク管理できてないケースが大半だと思う）。

運用時のコツ

チャットベースコミュニケーションの運用が捗る TIPS をまとめる。

既読リアクションをする

メッセージを送っただけでは「ちゃんと読んだのかな」と不安になる。読んでくれていたなら問題はないが、読んでない場合は「ちゃんと伝えたじゃないですか」「聞いてねえよ」となりかねない。

これを防ぐために 既読リアクション を導入する。

  • 絵文字でリアクションする ということ
  • 用意しておくと捗るリアクション
    • (1)許可: 「いいよ」とか「OKです」といった意
    • (2)認識: 「（まだ対応してないけど）認識はした」の意

特に重要なのが 2 の認識リアクション。今すぐ結論を下せない（あとで処理したい）メッセージも多いので、「とりあえず認識だけはしたよ（対応は後でやるよ）」というクッションがどうしても必要になる。

期限を添える

チャットで依頼を行う場合、相手に「いつまでにやればいいのか」という期限も与えておくのがよい。そうしないと「あのー、Aの件、まだです？明日までに必要なんですが」「え？そうなの？」となりかねない。

ただし「今日中」みたいな期限のキツイ依頼については、受信側の都合もあるので、口頭などで相談をした方がいい。

用途に応じて部屋を分ける

プログラミングには「一関数や一クラスは一つのことだけをさせる」というプラクティスがある。日常生活でも情報をフォルダやカテゴリやタグで分類する。会議でも目的とアジェンダを定めて、話が脱線しないようにする。同じように、チャットにおいても部屋を適切に分類するべき。

部屋を適切に分類できてないと、たとえば「このチャンネルにはどうでもいい雑談が多いけど、たまに必要なメッセージが混ざるので読まざるをえない（読むのに時間かかるのがだるい）」という状況になる。そんな部屋が 3, 5, 10……と多数存在すれば、メッセージを読む負担は計り知れない。

悪い例:

  • (Slack限定の仕組みだが) #general チャンネルで雑談する
    • 理由: #general は必ず全員が所属しており、どうでもいい雑談で注意力を逸らすべきではないから
  • #team_hoge チャンネルでほげチームに属する複数 PJ の話題を全部やり取りする
    • 理由1: 関係無い PJ の話題が多くて見づらいから
    • 理由2: 複数 PJ の話題が錯綜して読みづらい・追いづらいから

良い例:

  • 全体連絡は #general、雑談は #random チャンネルを使う
  • #team_hoge_pj1、#team_hoge_pj2、というふうに PJ 毎にチャンネルを細分化する

ここで一つの疑問が生じる。

  • Q: 部屋数が増え過ぎたら逆に読みづらくならないか？

部屋数が少ないよりは確かに読みづらいが、一つの部屋内で関係無い話題が錯綜するよりは断然マシである。

一つたとえを出そう。ちゃんと整理された数十のフォルダと、未整理の1000個のファイルが放り込まれた一つのフォルダ、どちらがマシだろうか。ピンと来ないなら数百のフォルダと10000個のファイルで考えてみてもいい。

役職の高すぎる人は入れない

「役職の高すぎる人」がいると、一気に発言のハードルが高くなり、気を遣うためストレスも溜まる。また（彼らはリテラシーが低いため）下っ端は振り回されやすい。さらに言えば、彼らは高齢で、新しいことを学ぶ体力も気力も持っていないため、運用ルールにも従ってくれない。老害という言葉があるが、まさに邪魔者である。

邪魔者は 入れない に限る。

  • Q: 役職が高すぎる人って、どれくらい？

平社員、係長/リーダー、課長/マネージャー、部長……でいうと部長以上。「プロジェクトメンバーでない人」と言い換えてもいいかも。

  • Q: でもチャットシステムを使わせない、というのはさすがに無理があるのでは？

であれば、チームのチャンネルに彼らを入れないようにする。彼らは雑談チャンネルで喋らせておけばいい。自分も雑談したいなら、別に雑談チャンネルを作って、必要メンバーを入れればいい。

人数は少ない方がいい

参加人数が多すぎると、緊張や配慮が働いて発言しづらくなる（特に1vsN）。人数は小さい方が発言しやすい。目安は笑いを示す「ｗ」が使えるレベルだろうか。

会社雑務や技術的な質問は人数が多い方がいい

会社の雑務について、あるいは技術的な不明点を質問したいケースは多々ある。特に前者はググっても出てこないのでよく発生する。このような場合は、参加人数が多い部屋の方が回答が集まりやすい。

極端な例を言えば、全従業員が見ている雑談チャンネルに投下すれば、誰か一人は反応してくれるだろう。逆に、自分のチーム内のみの部屋であれば（質問内容にもよるが）回答はあまり期待できない。

Mention の使い所

正解は無いだろうが、たとえば以下の目安がある。

  • 相談と依頼には使う
  • 報告と（特に1vsNの）質問には使わなくてもいい

Mention は相手の注意を引く行為なので、極力抑えなければならない。「そのうち読んでもらえればいい」とか「最悪読んでもらわなくてもいい」ことは Mention しなくてもいい。

しかし（特にチャンネルが活発な場合は）相手が過去ログを辿らないかもしれない。そのあたりは運用時の観測が必要だろう。読んでもらえそうにないなら、Mention で喚起するしかない。

資料やノウハウをまとめておく

いわゆる「尋ねる前にここを見ろ」的なものを作っておく。そうしないと同じ質問を（違う人から）何度も繰り返されることになり、（特に「わかる人」は）回答に時間を取られることになる。

ちなみに「過去メッセージにあるからそれを見ろ」は参考にならない。チャットは過去ログを読むのに弱いため、面倒くさくて読むのを諦めてしまう。Wiki のようなストック性に優れたシステムでまとめるのが良い。

「ググる」という習慣を叩き込む

ググって調べればすぐわかることも質問してくる人がいる。そういう人は「ググる」という考え方を知らないことも多いので、しっかりと啓蒙しておく。

以下ポエム。

私が思うに、エラーメッセージをググって解決策を調べる程度のリテラシーは社会人なら備えるべきだろう。もちろん、だからといって（他に知っている人がいるのに）1時間調べるのは遠回りであるから、ちょっと調べてわからなかったら質問する、というのはアリ。その際、皆は知らなかったら「知らん」と反応してあげるとグッド（質問主は回答を待つことなく「自分が頑張って調べるしかないか」と腹をくくれる）。

参考

「口頭 チャット」でググると、色んな見解が出てくる。適宜参考にすると気付きが得られるだろう。

以下は私が読んだリンク先と簡単な感想のメモ。

Slack で指定メッセージに検索用のタグを付ける

Slack

ちょいとトリッキーな方法。

(2018/07/24 更新) 検索クエリは :has: じゃなくて has: でした。修正済。

どうやって実現するか

Ans: カスタム絵文字 + 指定した絵文字の付いたメッセージを検索するクエリ

Slack のメッセージ検索では「指定したリアクション（絵文字）が付いている」という条件を指定できる。タグ用のカスタム絵文字を適当に作った上で、これをメッセージに付けておけば、後から簡単に検索できる。

なぜこのような方法を使うか？

  • Pin は？
    • → 全員共有用なので個人用途では使いづらい
  • Star は？
    • → 一種類しかない

手順

まずはカスタム絵文字を登録する:

  • 適当なメッセージに対して Add Reaction
  • 一番下までスクロールして Add Custom Emoji…… みたいなリンクを探して開く
  • 絵文字名と画像をアップして登録
    • 画像は 64KB 以内かつサイズ 128x128 pixel 以内 でないと登録不可

タグの使い方

付け方:

  • タグを付けたいメッセージの Reaction として、上記で登録した絵文字を選ぶ

探し方:

  • 検索は has::絵文字名: というクエリで
    • 例: 絵文字が :tag_stakiran_memo: なら has::tag_stakiran_memo:

注意事項など

タグ名（絵文字名）のルールを定めること

絵文字は利用者全員に見える。各自が好き勝手にタグ用絵文字を登録しちゃうとカオスに。

なのでタグ名（絵文字名）にはルールを定めたい。たとえば、

tag_名前_タグ名

乱用するとメッセージの見栄えが悪くなる

乱用すると個人用のタグ用絵文字があちらこちらに付いている……という状況になる。自分以外の人にとっては気持ちのいいものではないし、同じことをする人が何人もいたら 物理的に見づらくなる問題（本来見たいはずのリアクションが埋もれる） も生じうる。

こういったことがあるので、無闇に乱用しないように気をつけたい。……といっても、じゃあどんなルール付けや運用をすればいいかという点は難しいところである（少しだけ後述する）。

タグ用絵文字の画像も固定すること

タグ名（絵文字名）の命名ルールは定めるべきと前述したが、リアクション全体の視認性（本来のリアクションとタグとしてのリアクション）を確保するために タグ用絵文字の画像も固定しちゃう 方法がある。

そうすると、仮に絵文字が5個くらい並んでいたとしても、タグ用絵文字については視覚的にすぐに判別できるので、素早く読み飛ばせる。

  • Q: どんな絵文字にするべき？

視認しやすければ何でもよいが、たとえば単色で塗りつぶした 128x128 pixel の画像など。

無理に導入しない

Star で済むならそれに越したことはない。

タグ名のルールはどうするべきか

スタンスは二つあるかと思う。

  • 案1: tag_ユーザー名_タグ名 のようにユーザー単位での追加を許す案
  • 案2: tag_タグ名 のように全員共用のタグのみ許す案

各個人が自分のためにタグを活用したいなら案1がおすすめ。

みんなとタグ設定を共有したり、ニコニコ動画みたくネタタグを作って楽しんだりしたいなら案2がおすすめ。

参考

ワーク・ライフバランス社の働き方改革講演を聴講したのでまとめる

企業・会社・働き方

働き方改革に関する講演を聴く機会があったので、内容をまとめてみる。

まとめ方について

ざっくりと表面だけなぞる。

講演では論理的に、かつ資料や数字などの根拠やソースも適宜用いて説明に割いていたが、そこまでメモできてない＆講演資料も展開されてないので、そのあたりのまとめは本記事では一切しない。

講演元

株式会社ワーク・ライフバランス さん。

働き方改革とは何か

「社畜（残業を厭わない男性社員）の長時間労働」に物を言わせた働き方を、社畜以外の多種多様な人間が短時間で成果を出せるような働き方に変えること。

※便宜上、前者を レガシースタイル、後者を モダンスタイル と呼ぶことにする。

働き方改革はなぜ必要なのか？

国視点と個人視点で一つずつ。

理由1. 【国】レガシースタイルがもはや通用しないから

そもそもレガシースタイルが通用していたのは昔の話。

昔:

  • 人口ボーナス期 といって、若者が多く高齢者が少なかった
    • 大量のニーズを満たすために、とにかく労働すればよかった
    • 当時は仕事として重工業（≒力仕事）が多かったため、筋肉の多い男性が適していた
    • 強い労働力を確保するために、会社は社員に重圧（パワハラやハードワーク）をかけた
      • 労働力は替えが利いたので「重圧に耐えられないとクビだよ？」と脅すことで社員を奮起させた

ところが今は時代が違う。レガシースタイルは通用しない。

今:

  • 人口オーナス期 といって、若者が少なく高齢者が多い
    • 技術や文明の発展が進み、ニーズが高度化・多様化している
    • 国が高齢者対応（社会保障）に忙しく、経済発展を後押しできない
    • ただでさえ少ない若者（労働力）が、育児や介護で退いていく

今の時代に対応するためには、働き方をレガシーからモダンに変える必要がある（モダンスタイルの解説は後述します）。そうしないと高齢化社会に押しつぶされちゃうよ。財政破綻するよ。

理由2. 【個人】仕事がなくなっても対応できるよう自己鍛錬が必要だから

  • これからの時代、少ない労働力で成果を出さねばならない
  • 単純な仕事は AI 等、技術によって奪われていく
  • 成果を出すためには自己鍛錬（スキルアップや人脈づくり）が必要

しかし会社で長時間働いていては自己鍛錬する暇もないし、そもそも精力的に生きるための身体や精神が蝕まれているケースもある。働き方改革によりモダンスタイルに変えて、プライベート時間を担保＆心身ともリフレッシュしてやれば、どんどん自己鍛錬していけるようになる。

モダンスタイルってどんな働き方？

確たる定義は無かったので、イメージが湧きそうな事項を適当に書き殴ってみる。

色んな人をなるべく生かす

色んな人とは、たとえば以下。

  • 育児に時間を取られる人
  • 介護に時間を取られる人
  • 障害を持っている人

レガシースタイルだと上記の人は切り捨てるが、オーナス期の今、労働力は貴重なので、これらの労働力もなるべく生かさねばならない。そのためには時短勤務やリモートワークなど、レガシーには無かった工夫（色んな人がなるべく働けるような配慮と仕組み）が必要。

短時間で成果を出す

オーナス期の今、労働力の単価は高いので、長時間働いてると人件費がヤバイ。短時間で成果を出さないといけない。といってもいきなり出せるはずもなく、徹底的な効率化とトレーニングが必要（やり方の一部は後述します）。

男性が長時間働かないこと

第一子を出産した後、夫が働き詰めだと、妻は孤独な育児に苦しむことになる。第二子を産む気が失せる。オーナス期を乗り越えるためには子供が必要なので、これはよくない。

じゃあどうすればいいかというと、夫が育児に参画して、妻の負担を和らげること。そのためには夫、つまり男性が長時間働かないことが重要となる。働き方改革＝女性の活躍、女性への配慮、と短縮化されがちだけど、そうじゃないよという話。

WFB ではなく WLB

WFB:

  • Work Family Balance
  • 育児や介護を抱えてる人のみが配慮される
  • 独身者などは配慮されない
    • 独身者にも事情があるのに
    • というか事情無くてもプライベート充実させたいやん？自己鍛錬もしたいし

WLB:

  • Work Life Balance
  • 対象は全従業員

働き方改革ってどこまで進んでるの？

国や企業の取り組みをつらつらと。

月100時間超えたら罰則、に法律改正

  • 今までは労働時間長くても罰則は無かった
  • 今後は法律で、月100時間を上限にした罰則を儲ける

勤務間インターバル制度

徹夜明けなどキッツイ時間外労働をしたら、一定時間は強制的に休ませる（インターバル）という制度。

背景:

  • 人間、しっかり寝ないと集中力が回復しない
  • 職種や状況によっては、どうしても時間外の長時間労働が必要になる。どうすればいい？
  • 国「じゃあ仕事終わったら強制的に休ませる制度をつくりますよ（つくることを義務付けしますよ）」

働き方改革改革宣言

「うちは働き方改革してる素晴らしい企業ですよ」ってのをアピールするキャンペーンが活発化している。

企業データを載せたサイト

「女性管理職率」みたいな値を見れるまとめサイトもある。

女性が活躍できる≒働き方改革に取り組んでいる、なので、ここを見れば各企業の取り組み具合がわかる。今時の学生はここから企業を推し量っているらしい。

働き方改革の進め方

各種手順、手法、考え方などを雑多に書き殴る。

無題

特に名前はついてなかったが、

  • 1 女性の積極採用
  • 2 長期間休んでも就業復帰できる制度の整備
  • 3 長時間残業の是正
  • 4 成果主義の定義修正

これを 4 → 3 → 2 → 1 と取り組んでいくことが改革の目安になるみたい。逆に 1 → 2 → 3 → 4 の順で取り組むのは間違い（1と2を整備しても3と4が無いと結局離れていく）で、この間違い犯しちゃう企業さん、多いらしい。

長時間残業を減らす方法4つ

  • 属人性の排除（たくさん残業してる人の仕事を分散）
  • 不要な仕事を削る
    • 社内資料作成とか
    • 社内でしか通用しない仕事で張り切るのをやめる。言い換えると、対外客に対する仕事のスタンスと同じにする（対外客相手だと余計な仕事はしないよね、それを社内でも心がける）
  • 無駄話を減らす（特に立場のある管理職）
  • ITスキル不足の解消

カエル会議

PDCA サイクルで進められるようなフレームワークがあるみたい。

kaeru_kaigi

出典: タイムリミットはあと2年！ 「今」働き方改革が必要な理由 | スマートワーク総研

朝メール

毎朝、今日の予定と一言をメールでチームメンバーに共有する。

自分のデイリータスクリストをつくる習慣づけと、自分の現状を共有する効果がある。

集中タイム

「私、集中してるんで話しかけないでください」な時間帯を設ける＆周知させること。

他にも色々

なんか 10-20 個くらい名前が出てたけどメモしきれず。

そういえば「100社あれば100通りのやり方がある！」という一文で締めくくられていたっけな。

働き方改革の事例

企業の例が 10 個はあったけどメモしてないので覚えてない。

書籍って無いの？

これ。

働き方改革の必要性を後押しする理論的・数値的根拠も豊富に載っているっぽい？ 講演中も多数紹介されていたが、メモ取れるはずもなく＆資料共有もされてないため、ここでは紹介できず。

質疑応答

Q: 定時前に呼び出されて「明日までにやれ」的なことが多いんだけど、どうすればいい？

Ans: 原因を一つずつ潰していくしかない。

  • 例1: 契約が曖昧 → 追加料金もらうようにする
    • 契約を厳しくすると仕事が取りづらい？技術があればそれでも取れるよ

Q: 早く帰るのが絶対に良いわけではない。別に帰りたくない人もいる。そういう人に対してはどう啓蒙すればいい？

Ans: その人の真意を引き出して、会社に居る必然性がなければ帰ってもらう

  • 例: 「もっとバリバリ働きたいんです！」な人
    • 聞き出してみると、真意は「成長したい」「～～になりたい」だった
    • この場合、長時間残業は必要ではない。プライベートでも勉強はできるよね。つーか会社から給料もらいながら成長したいってのは甘えだぞ？

おわりに

SlideShare で資料無償公開したり YouTube で配信したりしてくれたら、もっと広まっていいのになぁと思ったけど、これでご飯食べてるから仕方ないのかな。

(A;;CCLCSWLORC;;;AU) ← こんな呪文みたいな随意アクセス制御リストを読み解いてみた

Windows

Windows 10 で IME が一切合切動作しなくなった話 にて sc sdset schedule D:(A;;CCDC…… みたいなコマンドを扱ったのだが、このコマンド、何してるのかさっぱりわからん。どうも「随意アクセス制御リスト」という仕組みらしい。

何も知らないのは気持ち悪いので、資料 サービスの随意アクセス制御リストを作成する場合の推奨事項およびガイド に従って読み解いてみる。

今回読みたいもの

以下の呪文。

sc sdset schedule D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;IU)(A;;CCLCSWLORC;;;AU)(A;;CCLCSWRPDTLOCRRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLORC;;;BU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

呪文を整理する

上記だと読みづらいので読みやすくしておく。行単位で分けてみた。

sc sdset schedule
D:
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;IU)
(A;;CCLCSWLORC;;;AU)
(A;;CCLCSWRPDTLOCRRCWDWO;;;BA)
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)
(A;;CCLCSWLORC;;;BU)
S:
(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

呪文の構成要素1: sc sdset

sc sdset XXXX で「サービス XXXX のセキュリティ記述子を設定する」という意味になる。つまりは随意アクセス制御リストを指定してセキュリティ設定を変えるということ。

ここでは sc sdset schedule を扱っている。schedule とは Task Scheduler のサービス名。つまり sc sdset schedule は「Task Scheduler のセキュリティ設定を、随意アクセス制御リストを指定して変えますよ」という意味になる。

(おまけ): 設定を見たいなら sc sdshow

sc sdshow XXXXX を実行すると、サービス XXXXX のセキュリティ記述子を閲覧できる。

呪文の構成要素2: D: とか S: とか

Windows のアクセス制御リスト(ACL) には DACL と SACL の二種類ある。

D: は随意アクセス制御リスト(Discretionary Access Control List、DACL) を意味する。本記事で扱うのもここ。例では五つ分のリストがある。

S: は System ACL を意味する。日本語名は不明。用途は管理者がログを見れるようにすることで、いわゆる Windows の「監査」機能に絡む部分。詳しいことはよくわからん。本記事では扱わない。例では一つだけリストがある。

参考: Access Control Lists | Microsoft Docs

呪文の構成要素3: A;;XXXXXXX の部分

いよいよメインに入る。ただし DACL(随意アクセス制御リスト) のみ解説する。SACL は取り上げない。

まず全体像は以下のようになっている。

<可否指定>;;<アクセス許可を変更したい操作名の列>;;;<SID>

これが意味するのは、

「SID が示すオブジェクト」に対して、「指定した操作を行う権限」を、「付与(許可) or 剥奪(拒否)」する

という具合。

可否指定

Aだと許可。Dだと拒否。

SID

SID とはセキュリティ識別子の意で、Windowsのオブジェクト(ユーザー等の資源や各種機能)を識別する識別子のこと。

例: S-1-5-21-917266621-1342861121-1792158721-512

厳密な仕様は英語だが [MS-DTYP]: SID あたりを読むこと。

この SID だが、随意アクセス制御リストでは Well Known SID という「よく使われる SID」の「短縮形」を入力する。

短縮形の正式名称は このガイド にて端的にまとまっている。

IU = 対話型ログオン ユーザー
AU = Authenticated Users
BA = ビルトイン (ローカル) の Administrators
SY = Local System
BU = ビルトイン (ローカル) の Users
WD = Everyone (World)

アクセス許可を変更したい操作名の列

アクセス許可を変更したい操作を 2文字1操作 で列挙していく。2文字略称と操作名の対応はやはり このガイド が端的。

例: CCDCLCSWRPWPDTLOCRSDRCWDWO を読み解いてみる

まずは見づらいので分解する。

CCDCLCSWRPWPDTLOCRSDRCWDWO

  ↓

CC
DC
LC
SW
RP
WP
DT
LO
CR
SD
RC
WD
WO

続いて、ガイドを参考に、正式名称を併記してみる。

CC = QueryConf
DC = ChangeConf
LC = QueryStat
SW = EnumDeps
RP = Start
WP = Stop
DT = Pause
LO = Interrogate
CR = UserDefined
SD = Del
RC = RCtl
WD = WDac
WO = WOwn

だいぶわかりやすくなった。この CCDCLCSWRPWPDTLOCRSDRCWDWO という呪文は、「QueryConf と、ChangeConf と、QueryStat と、……WOwn。以上の操作についてアクセス許可を変更したいです」という意味になる。

ここで「QueryConfって何やねん」という疑問が浮かぶ……が、残念ながら解説資料にはたどり着けず。リファンレンスがあると思うんだけどなぁ。ご存知の方、いらっしゃったらぜひ教えてください。とりあえず Start/Stop はサービスの開始/停止だよね？

まとめてみよう

呪文の構造について整理できた。では、今回読みたい呪文について、改めて読み解いてみよう。

もう一度、今回読み解く呪文を載せる。

sc sdset schedule
D:
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;IU)
(A;;CCLCSWLORC;;;AU)
(A;;CCLCSWRPDTLOCRRCWDWO;;;BA)
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)
(A;;CCLCSWLORC;;;BU)
S:                                        ★ 今回は SACL は扱わないので
(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)   ★ この二行の読解はしない。

ここから今回扱わない SACL 部分を省く。

sc sdset schedule                      ★Task Scheduler のセキュリティ設定を、
D:                                     ★随意アクセス制御リストを使って変更する、の意。
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;IU)
(A;;CCLCSWLORC;;;AU)
(A;;CCLCSWRPDTLOCRRCWDWO;;;BA)
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)
(A;;CCLCSWLORC;;;BU)

Task Scheduler のセキュリティ設定を変える、というところまで読めた。残りは、

(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;IU)
(A;;CCLCSWLORC;;;AU)
(A;;CCLCSWRPDTLOCRRCWDWO;;;BA)
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)
(A;;CCLCSWLORC;;;BU)

この部分。

これを上記ルールに従って読み解くと、こんな感じになる。

  • 対話型ログオンユーザーについて、QueryConf, ChangeConf, QueryStat, EnumDeps, Start, Stop, Pause, Interrogate, UserDefined, Del, RCtl, WDac, WOwn の操作を、許可(Allow)します
  • Authenticated Users について、QueryConf、QueryStat、EnumDeps、Interrogate、RCtl の操作を、許可(Allow) します
  • ビルトイン (ローカル) の Administrators について、……
  • Local System について、……
  • ビルトイン (ローカル) の Users について、……
  • Everyone (World) について、……

※すいません、途中で面倒くさくなったので一部書けてません（変換スクリプト書くべきでしょうね。人間がやる仕事じゃない）。

ともあれ、何をやっているのかがなんとなく見えてきた。

おわりに

呪文みたいな随意アクセス制御リストの読み方を最低限理解できたと思う。

これでひとまず「実は rmdir ／s ／q c:\ みたいな悪さしてるんじゃないか？」という懸念は解消できたかな。

※これは「c:\ 配下の全てのファイルをいきなり削除する」コマンドである。たまーにだけどネット上で「その問題はこのコマンド叩いたら解決するよ」というシャレにならないイタズラをする人がいて、知らない人が泣きを見ることがある。私も Windows 10 で IME が一切合切動作しなくなった話 の対応は機械的にコピペで実行しちゃったので、もしこれと同じ類の罠があったとしたら……と不安になっていた。今回、読み方をこうして理解してみて、罠は無いとわかったので一安心。

参考

p.s. 本記事を全部書いてから気付いたのがが、★1 のページ、日本語で網羅的にまとまっててわかりやすい。この記事書いた意味ないなぁ……