ITの仕事で構造化できると強い

構造化できると強い。

特に、ITの仕事において。

思考を構造化する

自分の頭の中にある文字 = 思考を構造化するとはどういうことか？

生まれては消えてゆく思考に名前をつけて、それぞれの関係性を捉えるということになる。

そして、大見出し、小見出しを追加して、構造化する。

構造化とは「点」ではなく「線」

知識と知識の関係性を線のように捉えること。

それが構造化。

ChatGPTは構造的な視点を提供してくれる

例えば、昨日GPTと以下のやり取りをした。

この後に、構造的な文章が返ってきた。

■ 気にしてしまう傾向の共通点
完璧主義的な傾向
　→ 「文章の句読点の位置」「ファイルの更新確認」など、正確さを重視する姿勢。

責任感の強さ
　→ 「ドアの鍵」「ファイルを送ったか」など、人や物に関わるミスを避けようとする強い意識。

過去の行動や選択への振り返り
　→ 「相手の話を理解できなかった」「へに違和感」など、些細なことでも気になり続けてしまう。

■ このような気にしすぎに対して考えられる視点
1. 認知のクセを自覚する
これは「認知のゆがみ（思考のクセ）」の一つで、
心理学では「全か無か思考」「過度の一般化」などと呼ばれることもあります。

たとえば、「もし鍵を閉め忘れたら…」という考えが
「きっと閉め忘れているに違いない」に変わっていくような感覚です。

2. 確認と不安の境界線を作る
1回確認したらOKという「ルール」を設けると、確認のループから抜けやすくなります。

「送付済ファイルはこのステップでチェックしたら良しとする」と
自分ルールを明文化するのも効果的です。

3. 違和感は創造性の源とも言える
「へに違和感」など、普通はスルーされる点に気付ける感受性は、
言語感覚の鋭さや美意識の表れです。

それ自体は悪いことではなく、活かし方を変えると大きな強みにもなります
（たとえば、文章推敲の仕事やデザイン評価など）。

■ どう向き合うかのアイディア
「気にしてもいいけど、次に進もう」と自分に声をかけてみる
（気にしてしまう自分を否定せず、行動で切り替える）。

「不安をメモして外に出す」ノートやアプリを用意し、
繰り返し出てくる思考を書き出して自分との距離を取る。

信頼できる人やAIに「確認の最終チェック」を任せてみる
（それだけで脳が安心し、次に進めるようになります）。

ご希望があれば、「日常の確認ループを緩めるための小さな行動習慣」や、
「文章作成で迷いを減らすルール集」も一緒に考えられます。

少しでも心が軽くなるよう、あなたのペースで進んでいきましょう。
どこから整理していきたいですか？

■や1.などで大見出し、小見出しが表現されている。

GPT問答をすることで、構造化能力が鍛えられる。

自分の中の引き出しが増えるだろう。

問題が起こった時も構造化

今日、仕事で問題が起きた。

どんな問題かというと、クラウド移行に伴い、PentahoのETLをPythonに置き換えるということをしていて、置き換え後に、PowerBIレポートで、DB to DBの処理の結果のデータが確認できなくなってしまっていた。

原因は、Python化するときに、File to DBの処理とDB to DBの処理が元々あったが、DB to DBの処理はPython化しない方向で進めることになっていて、PentahoからPythonに切り替える時に、PentahoのFile to DBとDB to DBの処理が一体となったジョブファイルを停止してしまったから。結果的に、PythonでFile to DBの処理のみが動いている状態となってしまった。

そこで、Pythonの定期実行を止めて、Pentahoの定期実行を再開することで、DB to DBもETL処理が行われることになり、PowerBIレポートも正常に表示された。

その後の対応としては、Pentahoのジョブファイルで、DB to DBの処理のみが行われるようにして、Pentahoでは、DB to DBの処理を行い、Pythonでは、File to DBの処理を行うというようにしていくことになった。DB to DBの処理は、Python以外のPowerAppsなどのクラウド移行手段を上の人が考えていく。

「PowerBIでDB to DBの処理が見れなくなった件の緊急対応」というタイトルでRedmineのタスクを作成して、その詳細に上記のようなことを以下の記号を使って構造的に記入した。

■ 背景
ユーザさんから、PowerBIでDB to DBの処理に関するレポートが見られなくなったという連絡があった。

■ 原因
Python化したときにFile to DBの処理のみを残していて、停止したPentahoのジョブファイルで行われていたDB to DBの処理が行われなくなった。

■ 対応内容
◻︎ 本日の対応内容
Pythonの定期実行を停止して、Pentahoの定期実行を再開した。それによって、PowerBIでDB to DBのETL処理結果が問題なく確認できるようになった。

◻︎ 今後の対応内容
PentahoのジョブファイルからFile to DBの処理を削除して、DB to DBの処理のみを残す。PythonのETLでは、そのままFile to DBの処理を行う。PentahoのDB to DBについては、Python以外の手段でクラウド化すると理解している。

■ 対応内容の中に、◻︎ 本日の対応内容と◻︎ 今後の対応内容がある。その中に文章を書いている。

こうやって構造化することで、読み手の負担が軽減される。

問題をシンプルに切り分けて考えることができる。

この問題点についてもGPTに相談した

このように、構造的に階層化して整理してくれるから、ChatGPTは手放せない。

ただし、自分の頭である程度言葉を生み出す（= プロンプトを書く）ことができなければ、GPTは当たり障りのない一般的な回答しか返してくれない。

自責で考えて、自分が求めていることにピッタリとあったプロンプトを作成できるようにしていけば、生成AIは強力なサポーターになる。