【ｍｙ格言】
-「やりたいことを仕事にする」もいいけど「仕事を、もっともやりたいことにする」というアプローチもあるのでは(20090912)
（格言と本文とはほぼ、関係ありません）
おつかれさまです、龍澤です。
ムカシの出来事。
ファイルサーバ等の障害対応手順をまとめておく、ということで。。
ファイルサーバって社内のエンドユーザが使うものだから、いちいちシステム部門に「つながんねーよ！」とか「ファイル削除しちゃった！ 復元してくれ！」とか、そういう問い合わせが入るのもウザいから、できるだけ主体的にユーザに対応してもらおう、と。。
各部署にも一応「ＩＴ担当者」みたいな方がいるから、（ＰＣ操作に詳しい、に毛が生えたぐらいの）そういうヒトたちにマニュアル配って、いっそのこと管理をユーザに移管してしまおう、と。。
まァ、ありがちなハナシで。
その手順っていうのは、実は前からあたためていた（引き継ぎたくてうずうずしていた）ものだったので、わーっとチームでつくった。
「ど」がつくかつかないかギリギリのところの「素人」に対する手順を想定して、相当丁寧に仕立てた。
おおかた出来上がったところで、常駐ＳＩｅｒのボス（Ａ氏）にレビューしてほしい旨報告したところ。。
「え、手順って、結局こまったらリブートするだけだろ？ それを手順化するだけだろ？（なんでそんな手順作成に工数かかんの？）」と、のたまいやがったねえ。
なんだかこのとき、すごくムカついたんだよね。（だから、すごくおぼえている）
でも、このハナシを聞いて、Ａ氏のいうとおりじゃん、そんなに工数かけてどーすんの、と思うヒトもいるだろう。
なんで僕がムカつくのか意味わかんない、というヒトもいるのだろう。
まず、「リブートするだけだろ」というのであれば、僕らがつくるべきはサーバの「リブート手順」だけでよかったのか？
ホントに、リブートの手順だけでよいのであれば、Ａ氏のいうとおり、さくさくっと手順などつくれる。
でも、リブート手順だけではユーザに引き継げないんだよ。
たとえば、リブート手順をつくるためには、そのファイルサーバなりが、マシンルームレイアウトの中でどこに位置するのか？ を示す資料も必要だろう。
そして、そのマシンルームについても何階のどこにあるのか？ を示す資料が必要になるだろう。マシンルームに入るためにはどうするか？ 認証が必要であるならばそれも記載しておく必要があるだろう。
などなど。。
そういう、エンドユーザがその手順書を実施するときの状況、たとえば、どういう情報がないと困るだろうか？ とか、イメージできないヒトが多いんだよねえ。。
イメージできないヒトというのは、設計構築するＳＩｅｒ寄りの思考回路なんだよね。
はっきりいってしまえば、手順書を作成して引き継ぐＳＩｅｒ側っていうのは、引継ぎ先の客なり、運用側をバカにしている。自分らのほうが上だと思っている。
なぜ上だと思えるのか？ それは、自分たちは「柔軟に対応できるエンジニアである」という自負心があるからだ。
運用に対して、自分らがフェードアウトしたいから手順をつくって引き継ごうとするくせに「いちいち手順がねーと作業できねーのかよ」とココロの中でバカにしている矛盾。
それが、違うんだよなあ。
引継ぎっていうのはね、ビジネスなんだよ。
引継ぎを受ける側は、ビジネスとして、やれることしか引き受けない。
それは当然。
その姿勢を「柔軟性がない！」とかいうほうが、ホントは間違ってんだよね。
「柔軟性みせてみろや」みたいなこといってるヤツに限ってさ、自分がつくるドキュメントの品質はまず棚に上げるからね。
そっちのほうが警戒する必要がある。品質の低いドキュメント（手順書）でお茶を濁して、そそくさと逃げ出す気満々だから。
手順書っていうのは、ただの操作マニュアルじゃないんだよ。
いってみれば、「分岐の集合体」なわけだ。
きっちりと、ユーザに引き継げるぐらいの手順書をつくるのには、それなりのクリエイティビティが必要なんだよ。
手順書というのは、設計を運用側の観点でドキュメントに落とし込むものであって、ただのマニュアルじゃないんだ。
設計書を仕上げて、その思想を盛り込んだ手順書をつくり、（誠意をもって）引き継いではじめて構築ってのは完了なんだよ。
たとえばdocomoのケータイのマニュアルをみると。。 （ムカシはちがったけど）もうこれでもかっていうぐらいに、いろんな情報が盛り込まれてるし、ゴテゴテに絵や写真が挿入され。。
相当に「手取り足取り」感満載の手順。。 あのぐらいサルでもわかるレベルにしないとユーザ満足度はあがらない。
でもね、ああいうケータイのマニュアルとかみてるとさ、「てめえらこれだけ精緻に書いて『やってる』んだから文句いうなよコノヤロー」っていう上から目線が透けてみえるけどね。。
とにかく、ケータイのマニュアルっていうのは当然、エンドユーザ（ド・素人）に引き継ぐことを想定しているから、ものすごい工数がかかっている（はず）。
ショボいＳＩｅｒは、小手先の技術によるその場しのぎのソリューションはできるのかもしれないが、ドキュメントのクリエイティビティがない。だからうまく引き継げない。
そして引き継げないことを逆ギレするから、手に負えない。
きっちりしたシステムをつくったのであれば、それを説明できにゃいかんと思うよ。そうじゃないとただのひとりよがりでしょ。
それは、僕は引き継ぐ側にも引き継がれる側にも参画するので、よーくわかる。
わかるんだよ、ドキュメントなんて書いてるヒマねーよ、っていう言い分もさ。
昨今、プロジェクトは期間も工数も絞るだけ絞られてるから。。
でもさ、次につなげるためにも。。後々まで残るドキュメントにもパワーを割いてほしいんだよな。それがそのまま、ＳＩｅｒの評価につながるんだから。
そして、後腐れなくきれいにプロジェクトを終わらせるのもＳＩｅｒの力量だ。
ＳＩｅｒのクリエイティビティはドキュメントをみりゃわかる。だから、もっと「美しく」書いてほしい。（日本語もね！ 理系の文章はけっこうムゴいのがあるから）
手順もヒドいの多いけど、設計書はもっとヒドかったりする。
突っ込みどころ満載の設計書書いてくるヤツらは、ホント多い。
でもそれは、ドキュメンテーションがヘタクソなわけじゃなくて、設計思想が貧弱なだけなんだけどさ。。
設計がしっかりしてりゃ、それを文章にあらわすのは実は難しくない。
結局、イケてるＳＩｅｒはスキがないってことだと思う。技術は超一流だけど文章はダメダメ、っていうことはゼッタイにない。
それを突き詰めてゆくと。。ＳＩｅｒも「人間力」ってことになってゆくんだと思うよ。
後々まで残るドキュメントをながめてると、手を抜いてんなあ、とか、適当に書いてやがんなあ、とかわかるし、作り手の人間力まで透けてみえてしまう。
そういう草の根の風評をおろそかにしていると少しずつ少しずつ、信頼を失ってゆく。