たいぞーのブログ

【Day643】課題の分離

8月

3日

昨日、久々に仕事でミスをしてしまい、現場に迷惑をかけてしまいました。

30分以内にリカバリーをしたので、事なきを得たのだが、その際、現場サイドから、たくさんの指摘をいただいたのです。

迷惑をかけた話から流れて、他の話題に転換していったのですが、どうも話を聞いていると、私の課題では無いものばかりだった気がしています。

ミスをした直後だったので、ただただ「聴く」に徹していたのですが、そのどれもが「相手」のチームの課題だったのです！

なので、過剰に落ち込むことは無用でした。

アドラー心理学からの学びの中で、「良い出し」と同じくらい大好きな考え方が、この「課題の分離」です。

去年、しっかりと「アドラー心理学」を学んで良かったと思っています。

言われた直後は、正直、気分が悪くなってしまいましたが、今は何も感じていません。
リカバリーはできたし、お詫びもできている。

あとは、同じようなミスをしないように、恒久対策の仕組みを入れるだけ。

さあさあ、今日も楽しく、他者貢献してまいりましょう！！！

#work

【Day623】アプリも引き寄せ！

7月

14日

３日前に、運用稼働中のソフトウェアを自分でメンテできないとマズいと思って、そのソフトの開発環境を自分のパソコンに入れたのです。

そうしたら、昨日、突然、そのソフトでバグが発生したとのこと！

もう８年以上、障害ゼロで動いていたのに、急に潜伏していたバグが発覚したのです。

準備していたことで、原因究明までには２～３時間かかってしまったけど、準備していなかったら、その日のうちには終わらなかったでしょう。

こういうのも「引き寄せ」と言えるのでしょうね。

早速、本日、アプリの差し替えを行って、恒久対策を適用する予定です。

不思議な体験でした。

#work #引き寄せの法則 #法則

【Day620】仕事もタイパで！

7月

11日

Ｚ世代は、映画も、動画も、音声も倍速らしい。

私も１５年以上前から、倍速再生には慣れ親しんでいるので、よく分かる。

音声は、デフォルト倍速で、コーチング音声に関しては３倍速を日課としている。

ふと思った。

仕事こそ、タイパであるべきではないのか！！！

チームとしての流れを止めずに、全体として最大のパフォーマンスを発揮する。

もちろん、品質を担保したうえで。

半分の時間で終わらせることができれば、倍の仕事をできてしまう。

そうなのだ。だから、相手の仕事を止めてはならない。

読みやすい文章のように、相手に躓かせることなく、なめらかに仕事をさばき、そして引き渡したい。

そんなことを感じた昨日であった。

仕事こそ、タイパ。

肝に銘じていきたい。

#work #気づき

【Day619】リプレース！

7月

10日

昨日の日曜日。

休日出勤をして、無停電電源装置３台のリプレース作業を行いました。

非常時に備えてのアクション。

交換後、各機器の正常性確認をしっかりやった後、古い装置は廃棄。

何と清々しいことでしょう！

物は、どんなに高いものであっても、いつかは必ず壊れるもの。

最悪の事態になるまえに、こうやって定期的に交換していくことで、我々の仕事は維持されていきます。

表面化しない地味な仕事とはいえ、我々の大切なミッションの１つです。

お疲れ様でした！！！

#work

【Day617】テスト、大事！

7月

8日

今週は、来週リリースする業務アプリの「テスト」作業に集中しました。

テストに没頭した１日は、スタミナ切れになる時間が早まりますｗ

「ファーストテスト駆動開発」ではないので、実装後に「テスト仕様書」を策定します。

基本テスト仕様を考えるところは楽勝なのですが、「いじわるテスト」のフェーズでは、一気に疲労度が増してきます。

考えモレが無いか、徹底的に思考を使いますので。

各機能のあやゆる組み合わせ、ステートごとの動作検証などなど。

もう嫌になってくるーーー！

さらに大事なのは、「退行テスト」。

どんな理由であっても、ユーザーに迷惑をかけてはならぬのです。

過去には私も、思わぬ理由で迷惑をたくさんかけてきました（結局は「仕様」や「実装」、「テスト」が甘かっただけ！）

最後の砦となる「テスト」のフェーズ。

漏れなく作成された「テスト仕様書」に沿って、順番にアプリケーションのテストを行い、合格したものであれば、もう勝ったも当然じゃあ～！

それでも、この「不安」な気持ちは何なのだろう？

おそらく、この仕事をしている以上、決して無くなることのない「不安」なのでしょうね。

そんな時に、脳裏にちらつく言葉を紹介して、今回はペンを置きたいと想います。

人事を尽くして天命を待つ！

#work

【Day607】コンセプチュアルスキル

6月

28日

リーダー以上の役割を持ったなら、必要になるスキル。

状況を整理し、本質を把握する力、解決策をつくる力。

それが「概念化能力」、コンセプチュアルスキルと呼ばれるものです。

「カッツモデル」というものを学んだときに、はじめて知りました。

「カッツモデル」を構成する必要な３つの能力は、「コンセプチュアルスキル」「ヒューマンスキル」「テクニカルスキル」。

多くの知識や情報を整理分析し、複雑な事象を概念化して、物事の本質を見極める。

自分たちなりの「成功観」を構築できる能力とでもいいましょうか。

この能力を高めるためにも、自分の感情をいったん切り離し、事象を俯瞰で様々な角度から眺める必要がありそうです。

難しい話はあまり得意ではないですが、伊藤羊一さんがおっしゃっていた言葉を思い出しました。

「リーダーとは、何とかする人」

たくさんの課題を何とかしていければ、経験則が出来上がってくるので、そこから「観」を作っていければいいのではないでしょうか。

#work #言葉

【Day524】PCのデスクトップのフォルダ数、ファイル数をカウントする

4月

6日

ずっと気になっていたんです。

職場のパソコンも、自宅のパソコンも、デスクトップにファイルがあり過ぎだって！

そこで思いついたのが、毎日、毎日、デスクトップに存在している「フォルダ数」と「ファイル数」をカウントしていって、その推移を「見える化」すればいいんじゃないかと。

さっそく下記のサイトから学んで、自分なりの batファイルを作ってみました。

【バッチファイル】指定したフォルダ配下のファイル数を取得する
【バッチファイル】指定したフォルダ配下のファイル数を取得するコードです！

desktopChecker.bat

@echo off



rem 対象フォルダ、ログ・ファイル保管先

set targetFolder=C:\Users\userName\Desktop

set logFile=C:\Users\userName\Desktop\Documents\desktopChecker.csv



if not exist %targetFolder% (

    echo 対象フォルダが存在しないため、処理を終了します。

    echo.

    pause

    exit

) 



rem フォルダ数を取得するコマンド作成

set cmd="dir %targetFolder% /ad /b | find /c /v """



rem フォルダ数を取得するコマンドを実行し、結果を変数「folderCount」へ格納

for /f %%a in ('%cmd%') do (

    set folderCount=%%a

)



rem 結果

echo フォルダ数：%folderCount%



rem ファイル数を取得するコマンドを作成

set cmd="dir %targetFolder% /a-d /b | find /c /v """



rem ファイル数を取得するコマンドを実行し、結果を変数「fileCount」へ格納

for /f %%a in ('%cmd%') do (

    set fileCount=%%a

)



rem 結果

echo ファイル数：%fileCount%



rem ログ書き出し

echo "%DATE% %TIME%","%folderCount%","%fileCount%" >> %logFile%



echo.

pause

exit

ほぼほぼ、参照にしたサイトのパクリなのですが、私のは「ログ・ファイル保管先」を作って、実行時のフォルダ数とファイル数をcsvに書き出ししています。

これにより、csvファイルを確認すれば、デスクトップ内の「断捨離」の実行結果がわかるようになりました！

近い将来、こちらの機能をバッチファイルではなく、Windows、MacOSやLinuxでも実行できるアプリとして、構築する予定です。

自分や周囲のためになる「ソフトウェア」作りは、非常にやりがいがありますね。

まずは、第一歩目として動き出せて良かったです！

#3c戦略 #pc #work

【Day386】クライアント・サイド月間、まもなく終了！

11月

19日

９月から本格的に始まった「PCリプレース」が、ついに本日で終了となる。

メンバーが減ったり、旧メンバーをヘルプとして招集したり、試行錯誤の３ヵ月間だったが、まずは「大成功」だったと思っている。

もちろん、Windows11の不具合も多くて、ヘルプデスクの本数も増加傾向ではあるが、１つひとつ検証し、原因を特定して、解決できてはいるので、とりあえず「合格点」は出せたと思う。

そもそも、ITって不完全なものである！？

今回のクライアント・サイドにとことん、フォーカスできたことで、たくさんの人と触れ合うことができた。

５年ぶりになるので、その間に入社した方とは初めて話をする機会も多かった。

皆、いい人ばかり。

新しいPCを前にして、「ワクワク」があふれてしまった人もいたのか！？

これで「サーバ」サイドの仕事やアプリ開発に戻ったとき、実際に利用しているユーザーの顔を思い描けるのは、プラスでしかない！！

さらに、クライアントPCの環境をとことん知っていることで、障害が起きたときでも、より具体的にイメージできるようになる。

この経験を通して、またチームが強くなり、前進していける気がした。

まずは「チームメンバー」と今回関わりのあった「ユーザー全員」に感謝である！！！

#pc #work

【Day379】久々に「ひとり情シス」を体験してみての所感

11月

12日

今週の月曜日と火曜日の話です。

実際は１人ではなく、旧情シス女子のサポートがあったので、厳密には１人ではなかったのですが、主力のメンバー２名が出張により２日間不在になったので、そこでの気づきをまとめておこうと思います。

休む暇がまったく無し

まず、普段、我々の部署が担当している「日次ワーク」を１人でやる必要がありました（久しぶりにやる作業も多く…...）。
自動化できている部分もありますが、まだ手作業で確認したり、データを展開したりという作業が多く残っています。

日次ワークをこなしながら、サポート電話の対応。

予期せぬ依頼業務などなど。

昼休みも食事を早めに終わらせて、仕事をしていたくらい。

１５年前の「１人情シス」時代を思い出してしまいました......。

あの時は、１日１日を乗り越えるだけで精一杯でした（自分の時間なんて、まったくありませんでした）。

初日は21時過ぎに帰宅。結果、食事も22時過ぎ（翌日は、胃もたれ）。

２日目の午後からは、変な頭痛に見舞われることに（オーマイゴッド！）

普段、使わない脳をかなり使ったからだと思っています。

息をつく暇のなかった、あっという間の「２日間」でした。

意外と細かな手順がわかっていない

定常ワークをさばく中で、わかっていないタスクの存在に気づいてしまいました。

手順書の中に「もし○○だった△をする」という条件に応じた作業をしっかりと書いておく必要性を感じました。

今いるメンバーだけだったら口頭でシェアするだけでも、まったく問題はないですが、未来の仲間に対しても優しくありたい！

一度、定常ワークの手順書を整備を、しっかり時間を取って、やる必要がありそうですね。

仕事の難易度を下げる必要がある！

全部ではないですが、我々がやるタスクの難易度が高い！と思ってしまいました。

３０代の頃は、難易度に挑戦することで、自分自身の成長を感じて「悦」に入っていたのですが、もうそんな時代ではありません。

ミスの発生率を下げる工夫が必要。

「難易度が高い仕事＝価値ある仕事」ではありませんから！　残念！！

「事故が起こりにくいスマートな仕事をするためには？」という「問い」の答えを探していくのが、情シスのミッションの１つですね。

抽象的な話ではありますが、その「問い」を常に持っているかが大切な気がしています。

特に「組織活動」を止めないための「セキュリティ」、労働生産性を上げるための「品質向上」と「効率化」が最重要でしょう！

未来を考える時間の大切を知る

この２日間、１つ１つのタスクに対して、「この仕事は未来につながっているか？」という質問を投げてみたのですが、ほとんどゼロでした（笑）。

ユーザーの小さな課題解決を次々に実現できたという意味では、未来につながったとは言えるのですが、全体視点としては無かった気がします。

「未来を思い描く」時間の大切さに気づいてしまいました。

「余裕」って大事ですね。

まとめ

あらためて、チームのメンバーに「感謝」です！！！

１つの仕事をしているところに、電話やメールでの問い合わせ対応をしている間に、また別の問い合わせが入る。

そんなことって、毎日毎日発生しているはずです。

普段は分散されていたので気づきにくかったのですが、いざ１人でやってみると、眼の前のメモだけが頼り。

きっと、メンバーも、私がこの２日で感じたような「眼の前の仕事をこなす」だけで精一杯な日を多く乗り越えてきたのでしょう。

結果、この経験からの学びは大きい！

自部門の労働生産性を上げるためのヒントもあったので、少しずつ改善をして、次回「ひとり情シス」をやる機会にどのくらい楽になっているかを比較したいと思っています。

経験って大事ですね！！！

#work

【Day370】小タスクを１つずつ潰していこう

11月

3日

昨日の仕事は、比較的小さなタスクをたくさん処理することにしました。

１つ１つの仕事は、30分以下で片付くものばかり。

ずっと貯めていたものもあったので、
タスクが無くなっていくことが、実に心地良い！！

大きいタスクと向き合うのも大事ですが、小さな小石のようなタスクも、時には時間を取って片付けていかないといけませんね。

このブログを書いていると、「７つの習慣」に出てくるバケツに入れる石の大きさを思い出してしまいます。

バケツに、小さな小石ばかり先に入れてしまうと、大きな石は入らないという話です。

ただし今回は、大きい石に向き合うために、小さな小石を早めにやっつけようという話でした。

残った大きな石については、しっかり分解して、小さな石にしてしまいましょう。

あれ？

となると、毎回戦いは、小さな石をこなすだけということになりますね！

まさに「兵法」の極意と同じです。

#work #気づき