<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>全国個人事業主支援協会 | MT | Activity</title>
	<link>https://kojinjigyou.org/member-index/tamura_m4125/activity/</link>
	<atom:link href="https://kojinjigyou.org/member-index/tamura_m4125/activity/feed/" rel="self" type="application/rss+xml" />
	<description>MT についてのアクティビティフィード。</description>
	<lastBuildDate>Sat, 11 Apr 2026 03:58:50 +0900</lastBuildDate>
	<generator>https://buddypress.org/?v=6.3.0</generator>
	<language>ja</language>
	<ttl>30</ttl>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>2</sy:updateFrequency>
	
						<item>
				<guid isPermaLink="false">fce297d8552472f0e5be956ac6cdccea</guid>
				<title>MT wrote a new post, 「権限が足りない」で1日溶ける問題</title>
				<link>https://kojinjigyou.org/?p=116419</link>
				<pubDate>Tue, 31 Mar 2026 23:41:22 +0900</pubDate>

									<content:encoded><![CDATA[<p>IT業界では「権限ください」が日常会話レベルで飛び交う。新しい環境やツールを触ろうとした瞬間、「アクセス権がありません」で作業停止。管理者に申請するも、「担当が休み」「承認フローが多すぎる」「どの権限が必要か分からない」といった壁に阻まれ、気づけば半日経過。やっと付与されたと思ったら、今度は別のサービスでまた権限不足。結果、実装よりも“権限集め”のほうが時間がかかることも珍しくない。最終的に「この権限、何に使うんだっけ？」とな[&hellip;]</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">d966548c74f366e888763b0fc2bb81ac</guid>
				<title>MT wrote a new post, 「本番データでしか再現しない」問題</title>
				<link>https://kojinjigyou.org/?p=112115</link>
				<pubDate>Fri, 27 Feb 2026 08:13:42 +0900</pubDate>

									<content:encoded><![CDATA[<p>テスト環境では完璧に動いていたはずの機能が、本番に出した瞬間だけなぜかエラーを吐く。ログを追っても原因不明。開発環境でも再現せず、ステージングでも再現しない。違いを探していくと、データ量、文字コード、昔から積み上がった謎レコードなど、本番にしか存在しない“歴史”が牙をむく。特に長年運用されたシステムほど、想定外のデータが眠っている。結局、原因は「10年前に手入力された謎の全角スペース」だった、なんてことも。IT業界ではコードよ[&hellip;]</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">3211815328fbb387cfddbc8a09bc4176</guid>
				<title>MT wrote a new post, 引き継ぎ資料が「伝説」になっている問題</title>
				<link>https://kojinjigyou.org/?p=109422</link>
				<pubDate>Fri, 30 Jan 2026 10:03:55 +0900</pubDate>

									<content:encoded><![CDATA[<p>IT業界では、プロジェクトの引き継ぎ資料が存在するだけで評価されがちだが、中身を開くと「※詳細は口頭で説明」「この辺は雰囲気で実装」といった曖昧ワードが並ぶことが多い。図はあるが説明はなく、コードへのリンクはすでに404。しかも作成者はすでに異動か退職済みで、聞ける人が誰もいない。結果、現場では「この処理、触ったら何か壊れるらしい」という都市伝説が生まれ、誰も手を出さなくなる。引き継ぎ資料は“未来の自分への手紙”のはずなのに、[&hellip;]</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">33fe78e16fb34bd1d057f4226169d17f</guid>
				<title>MT wrote a new post, 見積もりはいつも「希望的観測」になる問題</title>
				<link>https://kojinjigyou.org/?p=105710</link>
				<pubDate>Tue, 23 Dec 2025 03:01:57 +0900</pubDate>

									<content:encoded><![CDATA[<p>IT業界で避けて通れないのが工数見積もり。要件を聞いた直後は「まあこのくらいですね」と余裕を持って出したはずなのに、なぜか提出段階で数字が削られている。「もう少し短くならない？」「他社はもっと早いらしくて」といった魔法の言葉で、根拠のある見積もりが“希望的観測”に変換される。そして始まる開発。仕様の抜け、想定外の制約、確認待ちの時間が積み重なり、結局スケジュールはギリギリ。最後は気合と残業で帳尻を合わせ、「やればできる」という[&hellip;]</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">ee104f4e3a16f4578d85af5bbc86221e</guid>
				<title>MT wrote a new post, Gitのコンフリクトは突然に</title>
				<link>https://kojinjigyou.org/?p=103370</link>
				<pubDate>Wed, 26 Nov 2025 00:47:06 +0900</pubDate>

									<content:encoded><![CDATA[<p>普段は何事もなく使っているGitでも、リリース前や緊急対応のタイミングに限って発生するのがコンフリクト。しかも内容を見ると、他チームが土壇場でこっそり修正を入れていたり、自分のコメントアウトと相手のデバッグ用コードが鉢合わせしていたりと、原因はさまざま。焦って適当に解消すると、テストで落ちるか本番で燃える。みんなが一斉に「pull した？」「rebase した？」と聞き合うカオス状態。結果、コンフリクト解消よりも「人間関係のコ[&hellip;]</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">6a7869cef10878c27b6da19a6ef4f8ed</guid>
				<title>MT wrote a new post, 「動作確認お願いします」が軽すぎる件</title>
				<link>https://kojinjigyou.org/?p=101206</link>
				<pubDate>Tue, 28 Oct 2025 09:54:43 +0900</pubDate>

									<content:encoded><![CDATA[<p>開発終盤になると飛んでくる「ちょっと動作確認お願いできますか？」の一言。だが、実際にやってみるとブラウザチェック、デバイス検証、エッジケースの洗い出し、ログの確認、時には仕様の再確認まで必要で、軽い気持ちで引き受けると泥沼化。しかも「確認ついでにここも直せますか？」という地味な追加依頼が忍び寄ることも。確認担当がいつの間にかバグ修正係になっているのはあるある。最終的には「動作確認」という名のQA業務＋αで丸一日潰れるパターンも[&hellip;]</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">41ad318cceec399b88f887c30d2417e6</guid>
				<title>MT wrote a new post, 「あとで直す」は永遠に来ない問題</title>
				<link>https://kojinjigyou.org/?p=98110</link>
				<pubDate>Thu, 25 Sep 2025 01:27:13 +0900</pubDate>

									<content:encoded><![CDATA[<p>開発中によく出る言葉「とりあえず今はこうして、あとで直そう」。一見柔軟な対応に見えるが、実際はその“あとで”が来ることは稀。特に期限が迫っている案件では、「一旦ハードコーディングで対応」「コメントでTODO書いといた」などの応急処置がどんどん積み重なり、気づけばそのままリリース。やがて誰も触れたがらない“謎仕様”や“禁断のファイル”と化す。「このコード、なんでこうなってるの？」に対して、「昔の自分が『あとで直す』って言ってた…[&hellip;]</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">7a0c6abe2435a23a1f5035694a3588bd</guid>
				<title>MT wrote a new post, 「技術選定会議」が宗教戦争になる問題</title>
				<link>https://kojinjigyou.org/?p=95582</link>
				<pubDate>Tue, 26 Aug 2025 07:19:58 +0900</pubDate>

									<content:encoded><![CDATA[<p>新しいプロジェクトが始まると、まず勃発するのが技術選定会議。ReactかVueか、それともSvelteか。Node.jsかGoか、それともRailsでいいのか。開発効率、保守性、パフォーマンス、学習コスト……と冷静な議論に見せかけて、実は「自分が慣れてるから」が最強の根拠になっていることも多い。最終的に「前回もこれだったし」という謎の安心感で落ち着くことも。誰もが納得しないまま始まる開発。しかし皮肉なことに、どんな技術を選んで[&hellip;]</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">c54af57e7358e2ed6c9731dec0b8e97c</guid>
				<title>MT wrote a new post, 「本番反映は一瞬で終わる」が一番危ない</title>
				<link>https://kojinjigyou.org/?p=94396</link>
				<pubDate>Sat, 02 Aug 2025 20:06:54 +0900</pubDate>

									<content:encoded><![CDATA[<p>「デプロイ自体はすぐ終わるんで」と軽く言われたときほど、トラブルが起きる確率が高いのがIT業界の怖さ。本番環境では、ステージングで動いていたコードがなぜか動かない、依存ライブラリのバージョンが違う、DBのマイグレーションでデータが壊れる――など、「想定外」がフルコンボで襲ってくる。特に金曜夕方のリリースは地獄。帰れない、誰もいない、焦る、バグる。結果、「やっぱ本番反映は慎重に」が鉄則だと身をもって学ぶ。そして今日もまた、静かに[&hellip;]</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">444a274808262a9621c9187fd1801645</guid>
				<title>MT wrote a new post, 「ログを見ればわかる」は幻想だった話</title>
				<link>https://kojinjigyou.org/?p=91002</link>
				<pubDate>Wed, 25 Jun 2025 10:20:06 +0900</pubDate>

									<content:encoded><![CDATA[<p>「とりあえずログ見よう」がエンジニアの合言葉。しかし、いざ見てみると大量の出力に埋もれて肝心の情報が見つからない。しかも肝心なタイミングに限ってログレベルが低すぎて詳細が記録されていない、あるいは高すぎてノイズだらけ。ログの出力形式もバラバラで「誰がこのフォーマットにしたんだ」と嘆く羽目に。さらに、本番環境のログは「見れるけどダウンロード禁止」「〇〇さんの承認が必要」などの制限で確認までに一苦労。結局、「ログを見ればわかる」は[&hellip;]</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">0fa83c780a53f0e92d5b0c825a3112af</guid>
				<title>MT wrote a new post, 会議なのに「音が出ない」「声が聞こえない」問題</title>
				<link>https://kojinjigyou.org/?p=89116</link>
				<pubDate>Mon, 26 May 2025 22:07:59 +0900</pubDate>

									<content:encoded><![CDATA[<p>リモート会議が主流になった昨今、開始直後の「聞こえてますか？」「マイク入ってないですよ」が風物詩のようになっている。画面越しに無言で口が動いている人がいれば、それはだいたいミュート地獄。中にはイヤホンを刺したまま話していて「全然聞こえません」と言われるパターンも。「一度抜いて挿し直してみてください」は、もはやおまじないの域。音声トラブルに慣れすぎて、誰も動じなくなるのもIT業界あるある。「じゃあSlackに書きますね」で会議が[&hellip;]</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">e41fa6f15113b2ad0943124b57b75f01</guid>
				<title>MT wrote a new post, エンジニアの「とりあえず動く」を信用してはいけない理由</title>
				<link>https://kojinjigyou.org/?p=87356</link>
				<pubDate>Mon, 28 Apr 2025 18:26:33 +0900</pubDate>

									<content:encoded><![CDATA[<p>IT現場でよく聞く「とりあえず動くから大丈夫」。一見、問題なさそうに聞こえるが、この言葉には「動くけど正しくないかも」「動くけどセキュリティ甘いかも」という裏の意味が潜んでいる。納期に追われる中で動くものを優先した結果、設計が雑になり、後々トラブルの温床に。しかも一度「動いてるからOK」とリリースされると、改修の優先度はどんどん下がる。結果、誰も触れたくない「ブラックボックス」が誕生するのだ。動いた瞬間こそ、本当は一番警戒すべ[&hellip;]</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">466b5824a2843c6d633c1360ecb66571</guid>
				<title>MT wrote a new post, 「それ、仕様です」――IT業界の魔法の言葉</title>
				<link>https://kojinjigyou.org/?p=84788</link>
				<pubDate>Sat, 22 Mar 2025 03:50:05 +0900</pubDate>

									<content:encoded><![CDATA[<p>IT業界に身を置いていると、一度は耳にする「それ、仕様です」。バグかと思ったら仕様。直してほしいけど仕様。クライアントが想像していた動きと違っても、「それ、仕様です」と言えば一応は説明がつく。不思議なことに、この言葉一つで空気がピリついたり、笑いが起きたりするのもITあるある。要件定義が曖昧だと仕様がどんどん拡張して、気づけば「誰も望んでいない完璧なシステム」が完成する。だからこそ、今日も私たちは言う――「ドキュメント、大事です」。</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">b5e1905e6015105a7e4b50b8ad7a212d</guid>
				<title>MT wrote a new post, エンジニアの天敵「動いていたはずなのに」</title>
				<link>https://kojinjigyou.org/?p=83250</link>
				<pubDate>Wed, 26 Feb 2025 01:15:33 +0900</pubDate>

									<content:encoded><![CDATA[<p>ITエンジニアをしていると昨日まで正常に動いていたプログラムが、なぜか突然エラーを吐き出す場面に遭遇することがある。「何も変えていないのに！」と叫びながら、原因を探すエンジニア。調べてみると、環境が微妙に変わっていたり、誰かがこっそりコードを修正していたりする。最悪なのは「バージョンアップによる仕様変更」。公式ドキュメントとにらめっこしながら、解決策を模索するのが日常茶飯事だ。こうして今日も、エンジニアは未知のバグと格闘し続けるのである。</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">4b4ab07db2f84f4182bf569fd17da482</guid>
				<title>MT wrote a new post, エンジニアの「ちょっとだけお願いします」が怖い理由</title>
				<link>https://kojinjigyou.org/?p=81104</link>
				<pubDate>Fri, 24 Jan 2025 09:51:17 +0900</pubDate>

									<content:encoded><![CDATA[<p>IT業界では「ちょっとだけお願いします」という言葉が飛び交いますが、実はこれが落とし穴。「簡単に終わるよ」と言われて受けたタスクが、気づけば仕様変更や深掘り調査に発展するのは日常茶飯事。特に「ついでにこれも」と追加作業が増えるパターンは、エンジニアの悩みの種。結論、軽く見えても裏に潜む闇を見抜くスキルが必要。経験を積むと「ちょっとだけ」の裏にある深さを嗅ぎ分ける力が自然と鍛えられます。</p>
]]></content:encoded>
				
				
							</item>
					<item>
				<guid isPermaLink="false">6b66bd88906b89d02247c02b08c05af7</guid>
				<title>MT さんのプロフィールが更新されました。</title>
				<link>https://kojinjigyou.org/member-activity/p/30511/</link>
				<pubDate>Fri, 24 Jan 2025 09:45:07 +0900</pubDate>

				
									<slash:comments>0</slash:comments>
				
							</item>
					<item>
				<guid isPermaLink="false">d05af73c7dd0f3279611e6b7a31b18bd</guid>
				<title>MT さんのプロフィールが更新されました。</title>
				<link>https://kojinjigyou.org/member-activity/p/30351/</link>
				<pubDate>Wed, 22 Jan 2025 03:40:42 +0900</pubDate>

				
									<slash:comments>0</slash:comments>
				
							</item>
		
	</channel>
</rss>