たいぞーのブログ

【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 #気づき

【Day302】障害よ、ありがとう！！

8月

27日

おとといの話ですが、10年近く前から運用している同期システムに障害が発生しました！

このシステムは、双子の息子たちが１～２歳のときに、１年近く、彼らの面倒を見ながら、夜中と休日の時間をフル活用して、ゼロから開発した思い入れのあるもの。
１年近く、ほとんど休みなく、自宅でこのシステムを開発していました。

この仕組みのおかげで、「システムA」と「システムB」、どちらのシステムから入力しても同じ状態を保つことができるんですね。

ここしばらく安定していたのですが、おとといの午後早々に異常終了してしまいました。

おとといの夜の時点では、原因を特定できずに帰宅。。。

しかし、ここで執念を燃やすのが私の努め。

技術者の端くれとしては、例外動作も把握できていないことがどうしても許せないのです。

徹底的に、ログや入力データを調査した結果、
昨日の午前中には原因を特定することができました。

原因を特定さえすれば、あとはしめたもの。

恒久対策の打ち手を取るだけです。

来週早々には、適用させたいと思っています。

いや～、本当にスッキリしました。

モヤモヤ潰しが、今の趣味の１つかもしれませんね！

それにしても、技術者の技量を上げていれるものナンバー１は、「障害」だと思っています。

俯瞰し、細部を見極め、あらゆるパターンを想定し、これだ！という仮説をもとに検証するので、嫌がうえでもレベルアップしてしまいますね！

障害よ、今回もありがとうございます！！！

#work #自信