ポメラ DM200 購入に迷っている方の背中を押す記事

ポメラ DM200(以下ポメラ)ユーザーが少なくて寂しいので、迷っている方を引き込むための記事を書いてみました。ありそうな疑問を Q&A 形式でまとめていきます。

自宅メインだから不要でしょ?

Ans: 自宅メインでも使えます。

ポメラのメリットは二つありますが、どちらも自宅メインな使い方でも効力を発揮します。

  • (1) ネット接続やゲームなど余計な機能が付いてないので、執筆に集中できる
  • (2) 起動が速く、小型で軽いのでどこでも(たとえばベッドでも)気軽に使える
  • (3) キーボードが静音なので同居人がいても比較的共存しやすい

(1) は、PC による執筆が捗らない人に刺さるでしょう。ポメラを使うと「今までの自分がいかに寄り道しまくりで集中できてなかったか」がわかります。たまに訪れる「かなり集中できる時」が、PC よりも簡単に手に入るようになる、と言えばいいでしょうか。これは実際に使ってみないとわかりません。私はこの点を知っているので、PC ではなくポメラで書くことが多いです。

(2) は、のんびり読書したり音楽を聴いたりするのと同じようにのんびり書きたい場合に重宝します。ソファーの上、ベッドの上、布団の上、とどこでもサクっと使えます。ただ(体勢にもよりますが)さすがに長時間の執筆はキツイので、長時間書く時はちゃんとデスクを使いたいですね。

(3) は、あくまでも私が普段使っている Realforce キーボードと比較しての話です。静音なので、会社の昼休憩中に小説をバリバリ書くこともできますし、集合住宅の夜でも気兼ね無く書けます。同居人が居て、キーボードうるさいと言われる方に関しても、同居人のストレスを軽減できるでしょう。

外出先で使える?テーブル無いケースが多いから無理でしょ?

Ans: 座れさえしたら使えます。

ポメラは小さいので、太ももや膝に乗せてタイピングできます。実際、私は病院や飲食店や電車内ではしばしばポメラを使います。

ただし、肩幅は取るので、隣席が埋まっている場合は使えない(小柄な方なら使える?)ですね。

バッテリーの持ちが心配なのですが?

Ans: フル充電で10時間くらいはもちます。

よほどずぼらでなければ、バッテリー切れの前に充電すると思います。

ポメラに書いたデータを PC に転送する方法がよくわからないのですが?

Ans: 複数あります。

以下のとおりです。

  • (1) 本体メモリに保存し、USB で PC に繋いで「ポメラをドライブとして」扱う
  • (2) SDカードに保存し、PC にも SD カードを挿して接続する
  • (3) ポメラ Sync(無線通信)を使う

どれも一長一短です。

(1) は追加の道具や設定が要らないのがメリットですが、PC に繋ぐ時が面倒です。USB ケーブルでポメラと PC を繋ぎ、ポメラ側で「PCリンク」を実行して初めて PC 側で認識されます。

(2) は (1) と似ていますが、SD カードを用意し、また抜き差しする手間があります。

(3) は無線ルータと Gmail アカウント設定が必要ですが、指定したメールアドレスにデータを送信できます。IFTTT と組み合わせると、Gmail からさらに別のサービスに流すこともできるようです。

ちなみに私は (1) にしています。一番シンプルだからです。

気軽に書けるのはわかったけど結局 PC で清書するんでしょ?だるくない?

Ans: 工夫しましょう。

たとえば私の場合、ブログは(基本的に調べながら書きますし一記事が短時間で終わるので)PC のみで書いてます。小説は、以下のようにしています。

  • プロット練ったり下書き書いたり、はポメラでする
  • ポメラのデータは定期的にバックアップする(週一)
  • 原稿がきりのいいところまで出来たら、PC 上で(よりリッチなツールと広い画面で主に推敲などの)作業を行う

ポメラは設定や下書きをバリバリ書き殴るのに適していると思っています。

他にもやり方はあるでしょう。自分に合ったやり方を模索してみてください。

辞書変換がバカすぎて使い物にならないのでは?

Ans: DM200 の ATOK は割と賢いです。

個人的には Windows デフォの IME と同等以上です。自動学習や辞書登録もあるので、使い込むほど馴染んできます。

キーボードが打ちづらそうに見えますが?

Ans: 神経質な私でも結構打ちやすいですよ

Realforce を複数枚買う程度には神経質な私ですが、ポメラのキーボードは割と打ちやすいと思います。JIS 配列の91(テンキーレス)キーボードです。

ただし、細かいことを書くと、こうなりますかね。

  • 文字キーで日本語入力する分には問題無いし、そこいらのノート PC よりは打ちやすく設計されている印象。MacBookAir と同じくらい
  • 修飾キーや半角全角キーなど補助系キーは打ちづらい

エディタが貧弱そうで心配なのですが?

Ans: まあまあ使いやすいです。

少なくとも Windows のメモ帳やそこいらのメモアプリよりは上です。テキストエディタにはさすがに劣りますが、ポメラには以下があるので助かります。

  • (1) アウトライン機能
  • (2) キーボードショートカット

(1) はテキストを見出しで区切って階層化する機能です。目次みたいに見出しが表示されるので全体構造を把握しやすいですし、Ctrl + Up/Down で前/次の見出しに一発ジャンプできるので素早くあちこちを辿れます。私はポメラの魅力の 5 割はこのアウトラインだと思ってます。手放せません。

(2) は、ポメラの各種操作にショートカットキーを充てることができる、という意味です。キーボードカスタマイズですね。検索、置換、文字数表示、辞書引きなど基本的な機能は揃っています。

ファイル名、ファイル数、ファイルサイズ、対応文字コードが心配なのですが?

Ans: 端的にまとめておきます。

  • ファイル名上限は全角25文字くらいまで
  • ファイル数は空き領域次第だが、数百程度なら問題無い
  • ファイルサイズ上限は 1 ファイル 30 万バイト(日本語おおよそ10万文字)くらい
  • 文字コードは UTF-8、改行コードは CRLF だが、設定により変更可能

過去記事 ポメラ DM200 を買ったので仕様とか使い心地とかまとめる にもまとめてあるので参照してください。

マウスとか無いんでしょ?どうやって操作すんの?

Ans: テキストエディタをイメージしてもらえるとわかりやすいです。

上にメニューバーが並んでいて、メニューバーは専用のキーで一発アクセスして、カーソルキーで項目を選ぶという感じです。

Windows だと Alt キーでメニューバーを開きますが、ポメラではメニューキーがあります。ちょうど左 Alt あたりの位置にあります。簡単ですね。

ポメラを使っている人の感想を調べたいのですが?

Ans: Twitter で調べましょう

新機種 DM30 が出てますけど、DM30 が良いの?

Ans: いいえ。DM200 が良いです。

※(注) これは DM30 をネットで調べただけの意見です。

少なくとも画面の大きさ、キーボードの操作性、ATOK やバッテリーなどの性能面では DM200 が優れています。ポメラシリーズで DM200 が歴代最高傑作です。

で、DM30 はというと、「折り畳める」「電池式」といった特徴がありますが、使いやすさと性能面では DM200 より落ちています。特徴を愛せる人のみが使えばいいでしょう。私は違います。純粋な書きやすさと手軽さを求めている大半の方も違うと思います。

Chromebook や MacBookAir で良くない?

Ans: ポメラは軽さが魅力です。

Chromebook も MacBookAir も所詮は PC です。ネットやアプリは使えますが、起動は遅いし、ネット環境が無いと話になりませんし、同期も必要ですし、大きくて重たいし、アップデートとかだるいし、と PC の制約をやはり受けてしまいます。

ポメラは違います。デジタルメモです。PC よりもだいぶシンプルです。ただテキストを書くためだけの装置ですからね。Chromebook や MacBookAir よりも「ただテキストを書くこと」に関してはだけは、圧倒的に手軽に使えます。この軽さは病みつきになります。

壊れないか心配です

Ans: 乱暴に扱わなければ大丈夫だと思います。

私は 10ヶ月ほど、ほぼ毎日ポメラを「ロフトの A4 サイズタブレットケース」に入れて、これをリュックに入れて通勤やらお出かけやらに持ち歩いていますが、特に壊れてはいません。

でも、お高いんでしょう?

Ans: お高いです。

諭吉さん 3-5 人はお亡くなりになられます。

おわりに

以上、ポメラ DM200 の購入を渋っている方向けに、背中を後押しする記事を Q&A 形式でお届けしてみました。いかがでしたでしょうか。参考になりましたら幸いです。

ポメラ DM200 を快適に使うために必要な2つのコト

ポメラ DM200 を使う上で(個人的に)絶対に譲れない(と思う)点を二点ほど。

(1) アウトラインを使う

アウトラインとは要するに「目次」を導入する機能で、これを使うと「大見出し」「中見出し」「小見出し」といった単位で文章を構造化でき、格段に扱いやすくなる。

できること:

  • 目次のように見出し一覧が表示される
    • 全体構造を捉えやすい
    • どこにどんな文章を書いていたかを探しやすい
  • 「次の見出し」「前に見出し」と見出し単位でジャンプできる
    • 何百行あっても一瞬でジャンプできる

Markdown 記法かドット記法か

結論を言うと、どっちでもいい。お好きな方を。

記法を一発で打てるよう辞書登録を

日本語入力中でも入力しやすいよう辞書登録すると楽。

  • 例1: m1#
  • 例2: m2##

これをしておかないと、見出しを書く時に左上の小さな半角全角ボタンを押す羽目になる(見出し記法は半角文字なので半角モードで打たないといけない)。押しづらい。

快適にスクロールする二つの方法

  • Ctrl + Up/Down で前後の見出しにジャンプする
  • Alt + Up/Down で1画面分スクロールする

ちなみに Alt + Shift + Up/Down で1画面分の行選択ができる。惜しいのは、Ctrl + Shift + Up/Down による見出し単位の行選択には対応していないこと。本当に惜しい。

FOF と EOF をつくる

FOF(First Of File) と EOF(End Of File) を設けておくと便利。

# FOF

<ここに本文を書いていく>

# EOF

こうすると Ctrl + Up/Down の見出し間ジャンプで「ファイル先頭/ファイル末尾に飛べる」ようになる

(2) Sync は使わない

文章執筆に専念したいなら極力無駄は省きたい。ポメラ DM200 は既にインターネット機能を省いているが、まだ不十分である。Sync 機能もできれば省きたい。

Sync 機能のデメリット:

  • 「同期取れてるかな?」という確認や心配に意識が持って行かれる
  • Sync 機能が働く分、バッテリーの消耗が速くなる
    • 実測はしていません
  • Sync 機能が働く分、ポメラの動作が重くなる
    • 実測はしていません

じゃあどうやって PC にデータを送るの?:

  • USBケーブルで繋いで手動でコピーする
    • SDカードと同じようなやり方
    • デジカメだってそうしてる
  • SD カードを使う

手動コピーは面倒くさくないですか?:

  • 面倒くさいが、Sync 機能のデメリットよりはマシ

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

前提

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

  • 例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 設定と周辺機器を最適化してストレスと労働時間を削減する

働き方改革が盛り上がっているが、個人的には仕事道具である 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 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 が開かれない問題

たとえば以下のような 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個のインデントをリストのネストとして認識させたい場合

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 -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 ツール?

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 の 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 みたいな現在日付時刻文字列をつくる

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

バッチファイル実装

以下のようにする。

@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)。人数は小さい方が発言しやすい。目安は笑いを示す「w」が使えるレベルだろうか。

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

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

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

Mention の使い所

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

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

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

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

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

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

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

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

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

以下ポエム。

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

参考

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

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

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がおすすめ。

参考