odstudy 2011.11 に行ってきた

odstudyという主にドキュメントに関するらしい勉強会に行ってきた。
現在、サーバ・インフラの仕事をしていながら、純粋なそっち系の勉強会に行ったのは実は初めてのような気がする。その世界にも神と呼ばれたり、仙人と呼ばれる方々がいらっしゃるらしい。。。

テーマは「属人化をなくすために」ということで、前半トークセッション（LT）、後半がディスカッション＋その発表でした。まとめとかはtwitterで#odstudyで検索すればそのうち見つかる事でしょう。。。

ディスカッションとその発表が面白く、色々考えさせられました。いくつか覚えている範囲で、勘違いも多々あるかと思いますが。（書いている時点でまだまとめとかが無いので、うろ覚えだけで書いてます）

• 自分はディスカッションに参加したチームの内容だけど、ドキュメントをwikiで管理すると、情報が分散される→情報が何れが最新かとかが分からなくなる→結局人に聞く→属人化orz。を防ぐために、wiki書き方にルールを設けましょう、システム的に制限を加えると効果的（運用部隊に開発出来る人が居ると良いなあ。。。）。全てのドキュメントを同じレベルで運用すると死ぬので、レベル分けして、内容の精査とかもレベルに応じて扱おう、というのが参考になりました。
• ディスカッションの中で、システムの変更にあわせて、システムの監視とかが自動的に追加されるような構成管理があると良いし、ドキュメントも自動で最新に変更されると良いねえ、なんて話も。とんでもなく難しいかと思いますが。
• 属人化を排除した方が良いものもあれば、属人化はそれなりにメリットもある（SPOFが倒れない限りは障害対応が早い、標準化する時間が必要ない、小さい案件なら特に）。
• ドキュメントはどの程度のレベルの人にあわせて書かなければいけないのか？グッド○○○の人でも出来るようにしなければならないのか、運用する側にもそれなりに知識レベルが必要で、属人化は排除し無ければならないが、属グループ化ならそれなりに行けるのでは？
• ドキュメント管理にPDCAサイクルの考え方を導入して、継続的なメンテナンス出来るようにしよう。
• ドキュメントを書く事によって属人化は排除出来ない。あくまで属人化の問題を減らすために行っている。ドキュメントは手順書ではなく、教科書だと思って書け。またドキュメントはあくまで自分のために書くと思えば、モチベーションとかも上がるし、真面目に書く。ドキュメントを書く事自体は（会社的に）評価されないこともあるので開発部隊が運用のためにドキュメントを書こうとしても、モティベーションが上がらない。運用部隊が自分たちのために（ドキュメントが無いと自分たちの仕事が出来ないから）、開発部隊に協力してもらって書いた方が良いのでは？

もうちょっとあったような気がするけど、などなど。色々参考になりました。会社の人達にも共有したいなあ、と思える事も多々。

最後にとてつもなくとりとめの無い個人的感想を、、、

• 人が介在する以上、属人化って言うのは完全排除は無理なのだろうなあ。理想は、工場とかの一通り訓練を受ければ誰でも作業可能な製造ラインなんだろうけど、、、
• でも、その人が倒れた時に最低限の引き継ぎが行えるように、ドキュメントを残しておく事は意義があるし、特に長期間のシステム運用においては立ち上げの時のメンバーと現在運用中のメンバーは大半が入れ替わっていて、その際の引き継ぎコストを下げるためには不可欠だろうなあ。
• 個人的なドキュメントと属人化の問題って、ドキュメントを如何にメンテナンスしていくか？かなあと思っています。
• システム構成が変わってドキュメントも修正する必要があるし、時にはドキュメントのリファクタリングも必要だと思っていますが、特にPDCAのPとDは出来てもC以降が難しい。時間がないとか、現在うまく行っているものを何故あえてメンテナンスして修正する必要があるのか、という心理的不安。さらには、手順はあっても何故その手順になっているのか、なぜこのようなシステム構成なのかと言う歴史的経緯や思想的な部分が、必ずしも残っていなくて（それこそ口答伝承されている程度）、手順を直したくても直す拠り所となるものが無い、とか。
• システム運用においては、属人化は絶対に排除出来ない、その上で、その人が倒れた時に被害を何れだけ最小限に留めるか、という想定で進めた方が良いのだろうなあ。

考え始めると難しいなあ、しかも明確な答えなんて多分無いと分かっているのに。。。

あと、システム運用側以上に属人的になっているのは営業サイドのような気がする。営業倒れたら代わり居なさそう。人とのコミュニケーションが発生する以上、これも仕方ないかなあww。