イライラの原因を絶つカンペキな予防措置の事例3選を紹介します

2019-01-042020-06-13

仕事や夫婦生活でイライラしないためにはどうすれば良いんだろう

という悩みにお答えします。

結論、イライラの原因を絶つカンペキな予防措置を取る事です。私は予防措置という言葉が好きです。半生をこれに費やしてきました。

私は、問題が起きてからそれを解決する事に時間を使うよりも、問題を未然に防ぐために時間を使いたいです。風邪を引いて寝る時間を体を鍛える時間に使うイメージです。

特に、イライラの原因を絶つ予防措置は最上級です。原因が無くなるので100％予防する事が出来ます。

本記事では

イライラの原因を絶つカンペキな予防措置の事例ベスト3

を紹介します。

イライラのカンペキな予防措置：最上級は原因を絶つ事

まず、『予防・対策』という言葉の定義です。

予防：悪い事態が発生しないように気をつけ、前もって防ぐこと
対策：発生した悪い事態に応じて取る手段

事例です。

	予防	対策
風邪	手洗い・うがい	風邪薬を飲んで寝る
インフルエンザ	予防接種を受ける	タミフルを飲んで寝る
足のむくみ	着圧ソックスを履く	マッサージを受ける

予防は能動的なもので、対策は受動的なものです。たまに、予防が不十分である事で問題が発生し

こうなった以上全員で何とか対策するしかない

と声高に叫ぶ人がいます。

センスないなー。その前に予防をちゃんとしようよ。

って思う事が多いです。

イライラを解消するためには予防措置が大切です。予防措置の最上級は 問題の原因を絶つ 事です。問題の原因を絶てば問題が発生しないからです。

イライラのカンペキな予防措置第3位：液体歯磨きを使う

『嫁が歯磨きのチューブの真ん中をつぶして押し出す。俺は端から綺麗に押し出す性格だから我慢できない。何度注意しても治らなくて困っている。』と友人が言っていました。

問題：嫁さんが歯磨きのチューブの真ん中をつぶして押し出す。几帳面な友人は嫁さんの行為にイライラする。

対策：嫁さんに注意する (→治らなくて困っている)

という状況です。

友人はイライラの予防措置をしていません。問題が発生しないためにどのような予防措置が考えられるでしょうか。

(1) 立つタイプの歯磨きを使う

悪くないですが、不十分です。これでも横に置いて真ん中をつぶす人がいます。

こんな風に。

(2) 袋止めクリップを付ける

こんな商品です。

⇒ 袋止めクリップ80 5個入 100円ショップの詳細と価格を確認する

悪くないですが、不十分です。クリップを付けても真ん中をつぶすでしょう。

(3) 液体の歯磨きを使う

例えば以下の商品があります。普通の値段で売っています。

⇒ 薬用ピュオーラナノブライト液体ハミガキ(400mL)の詳細と価格を確認する

これが最も効果的な予防です。問題の原因を絶つ事が出来ています。

嫁さんが歯磨きのチューブの真ん中をつぶして押し出す可能性がなくなります。

イライラのカンペキな予防措置第2位：ビールのストックを買っておく

我が家の事例です。

結婚前に嫁さん(その時は彼女)と一緒にテレビを見ていました。

旦那がビールを飲みたい時に冷蔵庫にビールがなかった。旦那が嫁さんに『ビールを買って来てほしい』と言った時に嫁さんはどのような行動を取るか。という話題でした。

女優の大石恵さんが

私は尽くす性格だから迷わずすぐに買いに行く

と言っていました。旦那さんはラルクアンシェルのhydeさんです。最高の嫁さんだなぁと思った私は

俺が同じ事言ったらどうする？

と嫁さんに聞きました。嫁さんの回答は

『冷蔵庫にビールがない』状態を作らないようにビールのストックを買っておく

でした。

問題の原因を絶つ予防措置です。素晴らしい切り返しです。この発言が結婚を決断したきっかけの一つになりました。本当に。

結婚して10年経ちやんちゃな子供が2人いる今は

自分で買ってくればー

と切り返されていますw

これは仕方ないです、笑。

イライラのカンペキな予防措置第1位：コードを書かないソフトウェア開発者

私は15年ソフトウェア開発をしています。過去に出会ったソフトウェア開発者の中で、私が『最も優秀』と考える人がいます。

その人は安易にコードを書きません。

世の中のプロセスが

Aさんは作業1をやりたい
Bさんは作業2をやりたい
Cさんは作業3をやりたい

とします。

この要件からソフトウェアを開発する際に大きく3つの選択肢があります。

(1) 世の中のプロセスをそのまま実装する

ソフトウェア開発で、世の中のプロセスをそのまま実装(ソフトウェア開発)してしまう事があります。今回の事例では作業1-3用のソフトウェアそれぞれを実装する事です。

この方法は正しくない事が多いです。『作業1-3の共通部分が重複して開発される』事になるからです。

特に開発後のメンテナンスが大変です。後から別の開発者が理解するのに3倍のコードを読まなければなりませんし、問題や仕様変更が発生したら最低3か所を修正しなければなりません。

この悪いパターンになってしまう例は実は多いです。マネージャーと開発者にとってはこの選択肢を選ぶと仕事がやりやすいからです。

例えば、要件を出す人が3人、開発者が3人いるとします。

マネージャーは、作業1-3に担当者を1人ずつアサインして仕事が終わりなので簡単です。開発者は、要件を出す人が1人いるので、その人だけとコミュニケーションして開発すれば良いので簡単です。

仕事がやりやすいので安易に考えると選ばれやすい選択肢なのです。

ソースコードのライン数でお金を支払う契約のオフショアと協業している場合はこのパターンが多いです。本当は1万行で十分なのに

3万行のコードを書きました。お金ください。

というパターンです。典型的な失敗例です。

(2) 共通部分を切り出して実装する

Aさんは作業1をやりたい
Bさんは作業2をやりたい
Cさんは作業3をやりたい

場合に、作業1-3の共通部分を作業0とします。

作業0
作業0と1の差分
作業0と2の差分
作業0と3の差分

を開発します。こうする事で作業1-3の共通部分を重複して開発するコストを削減できます。共通部分をモジュール化するのはソフトウェア開発の基本です。

一見良いように見えます。でもさらに良い方法があります。

(3) 開発者が咀嚼・抽象化して本当に必要な機能だけを開発する、さらに、顧客に最適な運用を提案する

作業1-3の共通部分を作業0とするときに、作業0 だけを開発します。さらに、A、B、Cさんのプロセスを作業0のプロセスに変更してもらいます。

多くの場合、A、B、Cさんは連携して要件を作っていません。でも、みんな似たような事をやりたい事が多いんです。『顧客の言う事を真に受けずに開発者が咀嚼・抽象化して本当に必要な機能だけを開発する、さらに、顧客に最適な運用を提案する』事で

開発費が抑えられる
問題発生時の対応が早くなる
プロセスが正規化される

というメリットが得られます。

私が『最も優秀』と考える人のアプローチはいつもこれでした。その人は安易にコードを書きません。このアプローチだと、当初の開発案件が

作業0
作業0と1の差分(*)
作業0と2の差分(*)
作業0と3の差分(*)

の場合に、(*)の開発をしないで済みます。(*)の部分で問題が発生する可能性がなくなります。問題の原因を絶つ事が出来ます。

ソフトウェア業界には『問題の原因を絶つ』という考え方は分かっていても実行できない人が多いです。関係者とのコミュニケーションが大変だからです。

問題の原因を絶つための行動が出来る人が優秀な開発者です。