元ネタ→件名：プログラムを修正してデバッグしても、修正した結果が反映されません。（Insider.NET 会議室）

しょっちゅう書いているけど、ウェブ コミュニティって、最終手段だと思います。

理由は簡単。単位時間当たりの情報の濃さが違う。

まず、問題が解決できる過程をおさらいしましょう。

ほぼすべての問題は、時間が解決してくれたりしません。解決に向けて何らかの行動を起こして初めて、解決に向けて動き出し、解決できます。

では、「解決できる」ために、どうすればいいのでしょうか。

1. 問題を把握する

   まずは、問題を把握しなければなりません。「問題を把握する」とは、ある事象を「問題である」と認識するところから始まります。

   1. 問題を認識する

      当たり前ですね。「問題だ」と認識しなければ、問題ではないのです。つまり、「見なかったことにしよう」「なかったことにしよう」というのは、問題を「問題である」との認識を捨てると言うことです。認識を捨てると、問題ではなくなります。したがって、問題を解決するためには、「問題である」と認識するところから始まります。

   2. 問題である事象を認識する

      問題であると認識ができれば、次はその問題の具体的な事象を認識します。人に話すとき、「問題なんです」としか言わなければ、「何が問題なの？」と聞かれるでしょう。その「何が？」を明らかにします。

      問題である事象を認識するとは、問題である事象と、問題でない事象の差異を明確にすることです。

      たとえば、我々が医者に行くとき、「何となくしんどい」とか、「何となく気分が悪い」という、不明瞭な不調を訴えます。医者は問診や検温、時には検尿なども行い、何が問題であるのかを明らかにします。この行為に相当する行為を、行うわけです。

   3. 事象の再現手順を確認する

      どんなことが発生しているのか、確認ができました。次は、その事象が必ず発生するのか、確認します。そして、必ず発生する条件、手順を明確にします。この、手順と条件が明確でなければ、もし修正しても、修正が正しく行えたのかどうかを確かめることができません。

   4. 問題を報告する

      多くの人が、何らかの組織に所属して、その組織の「仕事」として、問題解決に当たっていると思います。

      私は、仕事をする上で「報告」することが重要だと思っています。

      なぜか？

      報告するためには、上記のように明らかにしたことを、短くまとめなければなりません。この、「まとめる」という作業が、問題を把握するために役に立つからです。

      漠然と「知っている」ことを、明確に「理解している」に進めます。問題を理解していないと、次の解決策を練るときに苦労するからです。

      そのために、上役に報告します。上役が理解できなければ、理解できなかったことを補足するように求めてくるはずです。そこが説明できるかどうかで、問題を「理解している」かどうかがわかります。

2. 解決策を考える

   問題の把握ができると、今度はその問題の解決策を考えることになります。

   1. 問題である事象の差異を埋める

      先に、「問題である事象」と、「問題ではない事象」の差異を明らかにしました。この差異を埋める方法を考えるわけです。

      先に、問題が発生する条件と手順を明らかにしました。その条件と手順の時に、なにが、どうなっているのが問題かわかっているわけですから、そうならない方法を考えればいいわけです。

   2. 差異を埋めることで発生する影響を調べる

      あまり行われていないのではないか、と思われる事です。

      ある条件、ある手順の時のみ問題が発生しているのであれば、その他の条件では問題は発生していないわけです。では、今、その問題を修正することで、他の部分に悪影響が出ないでしょうか？

      あるバグを直すために別のバグを作り込む。そのバグを直すために、前のバグを取るために行った修正を元に戻す。なぜか、よくあることです。なぜ、よくあるのでしょう？修正が及ぼす影響範囲の調査が不十分であったり、そもそも問題を把握できていないためです。こんな事がないように、影響範囲を調べなければなりません。

   3. 試験してみる

      影響範囲の洗い出しを行って、その他のところに影響しないとわかったら、本当にそうか、試してみます。ここは、試すだけです。まだ、本当に修正を行うわけではありません。

   4. 解決策を相談する

      やはり、上役に報告です。しかし、今回は、「相談」です。これは、問題の解決のために何を行うか、どんな影響が考えられるか、実際に修正した結果どうだったかを報告することで、修正を行ってよいかどうかを尋ねます。決して、「解決策を尋ねる」わけではありません。

3. 修正する

   問題を把握し、解決策を出し、その解決策に Go! が出たので、修正を行います。修正を行った場合は、退行試験、デグレッション テスト、整合性確認を行います。今行った修正で、本当に他のところに影響がなかったのか、確認します。

   そして、やはり最後も報告です。どの問題について、どのように修正を行い、どんな確認をしたのか、報告します。

さて、元に返って。

ウェブ コミュニティで尋ねることは、上記の「解決策を考える」、その中でも特に「問題である事象の差異を埋める」になります。したがって、ウェブ コミュニティに出す「質問文」には、把握している問題の報告ができなければならない、と思います。

ここにあげた「問題解決の手順」は、ウェブ コミュニティで問題を解決するためには不十分です。

なぜでしょう？

上記は、「自己解決の手順」だからです。他の人と協力して解決にあたる場合、互いの認識をあわせる必要があります。この「互いの認識」とは、相手がどれくらいのことを知っているのか、相手がどのような制約を持っているのか、相手がどのような経緯をたどってきたのか、などです。

私が、「ウェブ コミュニティで聞く前に、周りの人に聞いてよ」というのは、この、「互いの認識をあわせる」ためなのです。あなたの周りの人は、ウェブの向こうの人よりあなたのことを知っているはずです。その人でさえわからないから尋ねることは、ウェブの向こうの人もほぼ間違いなくわからないのです。この、「伝わると思って伝えようとしなかったこと」を少なくするために、まず、周りの人に聞いて欲しいのです。

もう一つ、私は「損得」という言葉を使います。この言葉をなぜ用いるか、理解されていないようです。

10年ほど前。私の時給は、月給を標準時間数で割ると、1100円ほどでした。しかし、会社は、私が1時間働くと、4500円ほどの費用を費やしていました。私が「損」といっているのは、答えが得られる、得られないではありません。この、4500円というお金のことです。

このお金、開発者原価について、わんくま勉強会で「意識していますか？」と聞いたことがあります。個人で事業をされている方は意識されているのですが、会社勤めで給料をもらっている方は、意識されていない方がほとんどでした。

このお金を意識してください。10年ほど前にいた企業では、開発者一人につき、1ヶ月1百万円でした。人月です。ことあるごとに否定したい人月単価ですが、それで動いている（いた）以上、否定しても仕方ありません。1日の標準労働時間が8時間、週5日で40時間。月21日として168時間。1百万円を168時間で割ると、約5950円。

問題解決のために、1時間につき約6千円を消費しているのです。

私は、損だと思います。

私がそれを意識するようになった10年前にいた会社は、逆ザヤでした。時間当たり、本当は4500円ほどかかっているのに、見積単価は4400円だったのです。見積もった時間通りに実施すると、損が出るのです。

そのようなところにいたので、問題が解決できるかどうかを、他の時間で動いている人をアテにするウェブ コミュニティで尋ねるというのが、とてももったいなく思います。自分でコントロールできないのですから。

あ、タイトルは、「ほうれん草」、すなわち「報告連絡相談」です。「連絡」が出てこなかったな。これは、適切なタイミングで進捗状況を連絡することです。