問題の解決の見通しと過去の経験

去年の夏頃から、所有しているWindows Vistaがインストールされているdynabook SS SX/15AにNetBSD/i386をインストールして環境を構築してきました。Vistaのサポート期限は2017年4月11日ということですからあと2ヶ月ほどです。現時点では内蔵HDDにはVistaの環境が入ったままになっており、NetBSDの環境はUSBの外付けHDDに作っています。4月前後には内蔵HDDをNetBSDにしようと考えています。

NetBSDの環境を構築してみて、全てが順調という訳でもありませんでした。大小様々な問題がありました。

• 直近ではサウンドデバイスがカーネルで認識できない問題がありました。カーネルのソースを追いかけて問題個所は絞り込めましたが、どうしたら修正できるのか不明なのでsend-prしました。予想していたとおり放置されていますが、僕個人的には許容できる障害なので、いずれ解決できれば十分です。
• 当初はNetBSDではなくFreeBSDを使うつもりでした。しかしUSB接続メディア（メモリでもHDDでも）から起動できず、簡単には解決できそうもないので、FreeBSDを断念してNetBSDに決めました。
• X11のログイン画面をxdmではなくLightDMを利用しようとしました。コンパイルは出来たものの、設定方法が分からないので、現時点ではxdmを使っています。xdmよりはLightDMの方がログイン画面の見た目がカッコよいと感じています。これはログインする瞬間だけの問題ですが、ゆくゆくはxdmを止めてLightDMにしようと思っています。
• Linuxエミュレーション環境上のLibreOfficeでiBus-Mozcが動きませんでした。Windows環境から移行するにあたり、LibreOfficeで日本語が入らないのは大問題なので解決方法を模索しました。幸いにして、完ぺきではないものの、解決に至りましたが、これは必然ではなく、偶然の賜物だと思っています。
• pkgsrcからMATEをインストールしていたら、一部のパッケージでコンパイルエラーになりました。修正箇所がわかってみると、pkgsrcが提供する枠組みにおける設定不備のように見えます。どうして本家のビルドではエラーになっていないのか、逆に気になるのです。

上述した以外にも細々と問題が起きていて、解決できている問題もあり、当面は放置している問題もあり、決して順調にNetBSDに移行できているわけではありません。しかし少なくとも、Windows VistaからNetBSDへの移行そのものについては、まちがいなくできると見込んでいます。

ここで述べてきたような問題と、その解決の見通しの関係について考えてみたいと思います。但しあまりにも単純な問題（typoとか）ではなく、ある程度深刻な問題を対象とします。

真っ先に考えることは、過去に同じ経験をしたことがあるか否かです。もし過去に（全く）同様の問題を解決していたことがあるなら、その問題で過去に如何に苦しんで解決に時間がかかったとしても、今回は容易に解決できるはずです。そのためには記憶に頼るのではなく、記録を残してあることが重要です。往々にして問題があった時だけ記録を残そうとしがちですが、それでは必要な情報を記録できずに取りこぼす恐れがあります。普段から淡々と記録を残していくべきでしょう。そのために僕はTiddlyWikiを活用しています。

自分で経験したことがなくても、世界中の誰かが経験しているかもしれません。運が良ければ、それをWebで検索できるかもしれないので、検索エンジンで探してみることは大切です。単純な検索キーワードで直ちに見つかることもあるし、いろいろなキーワードを駆使して情報を見つけ出すこともあります。いずれにしても情報が見つかれば幸運ですが、見つからないことの方が多いのです。

しかし仮に見つかったとしても、その情報が直ちに役立つとは限りません。その人物はそれで解決したとしても、こちらの環境とはOSやバージョンなどが異なっているため、同じ方法では解決できないかもしれないのです。ただし解決方法としては役立たないとしても、解決に至るアプローチを示唆する情報としては役立つ可能性があります。自分では気づかなかったアプローチが提示されていることもあるので、決して無駄という訳ではありません。

問題を認識した時、それが解決するまでの見通しは、過去の経験を基準にして考えるしかないでしょう。今までに経験した類の問題ではないならば、その解決までに数日で済むのか、1週間ほどなのか、1ヵ月は見込まなければならないのか、それ以上なのか、はっきり言って、やってみなければわからないというのが正直なところではないかと思います。

かと言って、闇雲に問題に没頭して時間を費やしたところで、問題が解決しないまま時間だけが過ぎていたというのは、避けたいところです。

「やってみないとわからない」ということと、「時間だけが過ぎるのは避けたい」ということのトレードオフはどうしたら良いでしょう。一つの方法として、1週間ほど問題に没頭してみて、問題が解決しそうか見通しをつけるというのは、どうでしょう。もしかしたら1週間もしないうちに問題が解決してしまうかもしれませんし、それならそれで結構なことです。もし問題が解決しなくても、今後の方向性は見えてくるのではないでしょうし、費やす期間も見えてくるでしょう。

個別の問題点は上述した方法論でしのげるとしても、これは職人魂をもった技術寄りの発想です。一方で、全体の工程を管理する側であったり、何かの構築の依頼者側の視点ではどうなるのでしょうか。

問題が解決できるのは大前提だとしても、解決しない問題だったあるのは認められても、何時になったら解決するのか 見通しがたたないと仕事柄（それが管理者の仕事ですから）困るでしょう。

結局のところ、「見通しをたてる」のは「過去の経験」に依存するしかないのでしょう。そうすると、過去に経験したことがないことに対しては見通しが立てられないということです。新技術を採用した場合に発生する未知の問題における「問題の解決見通し」とは 、「ないものねだり」か「希望的観測」にすぎないと思います。そうかもしれませんが、そうも言っていられないならば、未知の問題を既知の問題に分割して持ち込むことでしょう。それが容易な事かどうかは、わかりません。