初めて、痛いと思うほど辛いカレーを食べました。

今週の週報です。

1.連絡の頻度

仕事で相手に依頼するときに、まとめて送った方がいいのか、都度送った方がいいのかという問題に直面しています。

都度送られるとうざがられるような気もするし、でも都度送らないと「なんでもっと早く（もしくは細かく）送ってくれなかったんですか」ともなるような気もする。
「でも細切れになると、スレッドやメールボックスの中で埋もれてしまうかもな」とも思う。

困ってしまったので、今は「相手に聞く」と「都度送るし送ったことはどこかにまとめておく」の方式をとっています。
この相手にとって何がベストか系の問題は、私はずっと悩んでいくんだろうなと思います。

2.通知を切ってみた話

最近打ち合わせに集中できてないなと思い、理由を考えてみるとSlackの通知が画面の右下あたりにカットインしてくるせいだなと気づきました。

カットインしてくると一瞬そちらに目がいきますし、内容の冒頭部分も見えていてヤバそう系の書き出しだとそっちが気になって会話に集中できません。で、自分があまり関係なさそうな話題に変わるとSlackの方の処理を始めてしまうと。

これはよろしくないなと。打ち合わせは打ち合わせで集中して臨まないと、仕事もうまく進まないし相手にも失礼です。
ということで、昨日から打ち合わせ中はSlackの通知を切ることにしました。
なかなかいい感じなので、しばらくの間継続したいと思います。

この通知が気になるという話は今読んでいる本から得た気づきでもあるので、その辺の話は読み終わった後にまたnoteで書きたいと思います。

3.「変化バジェット」を考えよう

ウチの会社では「ITを使ってどんどん業務を変えていくぜー」という方針があり、私の部署にも業務側からシステム開発・改修の依頼がいろいろと来ます。
私としても「皆さんが楽になるんだったら喜んで！」という気持ちでどんどん案件を進めていくのですが、いざリリースの時になると相手から「他にも新しいシステム導入があって、何個も作業のやり方が変わると現場がついていけない…」ということが起きています。

よく聞く話ですが、人はなかなかやり方を変えるというのができません（特に現状でもなんとかできていれば）。
この話について先日、「変化バジェット」という言葉を聞いたので皆さんにも共有したいなと思います。

今回の場合は、現場側の許容量が超えてしまって起きた事態かと思います。
これを防ぐためには、システム開発側での案件整理と業務側とのリリース時期調整が必要となります。「今回のシステムは具体的にどの部署に影響があるのか」「リリース時期の近辺で他案件のリリースはあるか」「どれくらいで業務に慣れてもらえそうだから、次のリリースはここでいいか」といった議論がされるべきなんだと思います。

「なかなか変化は受け入れられない」とはよく聞く話ですが、こんなにも抵抗感があるのかと身をもって感じています。
これからの業務では、変化を受け入れられやすい下地作りにも力を入れていきたいなと思います。

––––––––––

いよいよゴールデンウイークが始まります。
長期の連休を取られる方もいるでしょうが、私は暦どおりの休みを取ります。取引先がお休みなので、いろいろと思考することに業務時間を使いたいと思います。

ということで、皆さんの一週間はどうだったでしょうか？
今週の週報でした。