開発やサーバーの保守・運用などをやっていくなかで自分が問題にぶち当たった時、その対象となるシステムやソフトウェアは何らかのメッセージを返してきます。
そこにはその問題を解決するための重要なメッセージが含まれているわけですが経験の浅い技術者は、それを読み解く事ができません。
そこで何をするかと言うと、検索エンジンにそのメッセージを丸投げするわけです。
しかし、この方法は思ったより功を奏しません。
何故なら、そのメッセージを含んだ情報がWeb上にはあまりないから。
（大体出てくるのは英語のサイトで、しかもそれはエラーメッセージとしてではなく日常の会話であったり、Blogの記事であったり単なる単語としてマッチングされて引っかかっただけ）
次に色々語彙を変えて検索をしてみるのでしょうが、多くはあまりうまくいかないのでしょう。
理由は、自分の環境とまったく同様の環境を持つ人は思ったより多くないから。
大体のBlogを含むそういった技術情報には、前提を取り除いた結果だけが掲載されていたりします。
しかし、そこで上手く動作したLinux環境は、自分のLinux環境と全く同じではありません。
従って、必ずしもその結果がイコールになるとも限りません。
逆に、そのエラーメッセージの一部を自分が書く情報（Blog）に付け加えるだけで少しだけオリジナルなものになりえます。
自分の環境で出たエラーメッセージとその時の対処方法を書くことで、その環境の差を埋める何かヒントを与える事ができます。
結果を残すより、プロセスを残した方が多くの場合有効です。
もし何か構築情報を残そうとするのであれば、それが（まだ）ユニークなものであるならかまいませんが、そうでないのであればそのプロセスを書くだけで十分価値のあるものになるはずです。
自分のLinux環境が誰かのLinux環境と異なる事は明白ですが、その過程で出たエラーの内容とそれを回避するために行った設定、操作などはその人のLinux環境で行ってみる価値はあるからです。
業務上でも、このようなプロセスは重要なノウハウとなります。
もし、経験の浅い技術者に何かを教えるのであれば結果よりもそのプロセスを重視して教育した方がその人の役に立つでしょう。
その技術者は、そのプロセスに含まれる考え方や対処方法から多くのことを学べると思います。
関連記事
