改善要求
http://d.hatena.ne.jp/teramako/20080929/p1 を読んでいろいろと思い出してしまったので私見を書く。ちなみに似たような環境にいたことがある。まぁ違うのは開発部門だったということだけなんだけど。そして gdgd なのは許してもらいたい。ほとんどカゼで朦朧としている深夜に書いた手紙なので。あと同じように愚痴を言おうかと思ったけど沈み込んでも意味がないので自重した。
- refactoring
- 一切のドキュメントが残っていなくて ( インターフェイスに関する部分でさえもなかった ) 誰も実装詳細を知らないシステムに対してバグフィクス・新機能の追加でどうしても手を加えなきゃいけないという状況。まずどういう処理をしているのかの把握からということでインターフェイスのピックアップをするんだけどこの時点ですでに矛盾が出てくる。他にも名前の付け方がおかしいとか言語仕様をわかってないとかの瑣末だけど重要な ( 絶対的に必要ではないけどあるとないとでは全然違う ) 部分が重なってきて読み解くだけで非常にコストがかかる。さらに後々のためにドキュメントを書きたいと思うんだけどそもそも整合性が取れてないので無理という始末。で、 refactoring を行う必要があると判断するという流れ。まぁ、よくあることだ。
- ここでとれる選択肢はぶっちゃけ 2 つしかない。 refactoring をした上でバグフィクス・機能追加を行うか何もしないか。 refactoring なしでバグフィクス・機能追加をするというのはメリットがない。というよりデメリットしかない。
- refactoring のメリットは処理の高速化、保守性の向上などがあるけど ( 他にもあるかも ) デメリットも時間的コストが必要 ( 金銭的コストが付帯することもある ) だったり regression test を行わなければならなかったり成功するかどうかわからなかったりするということがある。処理を理解できるレベルの技術者が必要だという条件や、行う技術者のレベルによって結果が異なる ( 幅広い解決法を知っている技術者だと成功する確率が高くなる ) 場合もある。さらにバグフィクスや機能追加を見据えた実装詳細の変更も行える可能性が高いので今後のコストが安くなるという効果もある。
- 対して何もしないという手段では、新たな問題を引き起こさないというメリットがあるけど現在抱えている問題を解決できないというデメリットも併せ持っている。あと対象に対して今後何も手を施さないという前提条件が存在しているべき。まぁ機能追加なら新しく付け加えることで何とかなる可能性もあるけどバグフィクスが目的ならこの前提条件を満たすのは非常に難しい。というかまぁ現実的には無理なんだけど ( 使用言語やアルゴリズムによって対象の改変無しに目的を達成することもできるかもしれない ) 。
- 要は現状のコスト ( バグを抱えたまま貧弱な機能で運用を続ける ) をとるか変化に伴うコスト + 変更後のコスト ( 最初に時間や金はかかるけどバグの少ない豊富な機能で運用する ) を取るか、さらにいうとどのリスクを取り除くかの選択 ( 運用におけるバグ回避もしくは補正のためのコストを取り除くか変更後の混乱によるコストを回避するか等々 ) ということになる。ここは運用、内部処理、動かせる資源などの問題・情報を深く把握したひと / グループが判断すべきかなり難しい部分になると思う。
- ここらへん考えると refactoring を禁止されている状況というのはきちんと判断して手をつけるのを禁止しているのか、わかってるわかってないにかかわらず判断する立場のひとが現状のコストに満足しているかのどちらかだと思うんだけど「惜しい」状況もけっこう聞く。
- たとえば手を施した上で問題を引き起こす可能性を 0 にしろと判断する立場のひとが言ったり ( それが無理だということを知らないわけだよね ) 、運用コストはものすごく高いですけど改修する予定はありません ( 現場が死にそうな思いしてることを知らないわけだよね ) とかいう状況。大体の理由はカッコ内のように情報が判断すべきレベルのひとにちゃんと届いてないということだと思うんだけど、たまに首が回らなくて何も手を打てません的な状況 ( 今後運用するコストも改変にかかるコストも払えない状況になるとても不運な状況 ) もあるのでその場合はもう心の底から同情する。
- VCS
- 比較的普及してきたとはいえまだ存在を知らない人も名前だけ知ってるって言う人も苦手という人もいるはず。というかコードを書く人の中でもキャズムは越えてないと思うんだけどどうかな。常識 ( common sense ) にはなってないよね。
- まずシステムとしてのメリットは複数人での作業を行いやすくなるとか個人でも思い切った変更をしやすくなるとかいろいろあるけど、デメリットとしてインストールしなきゃいけないとか使い方を覚えなきゃいけないとか管理しなきゃいけないとか守秘義務を守れなくなる可能性が生まれるとかがあるので一概に VCS 使わないプロジェクトはダメとか言えない。
- まぁここでもどのリスクを取るかなんだけど。改変が少なくて手作業でも管理できるという状況が未来永劫続くと仮定できるなら使わなくてもいいだろうし、使用する人すべてが使い方を体で覚える必要があるのでそのための時間や労力はどこから引っ張ってくるのかっていう問題もあるだろうしね。
- むしろソースコードが 1 行でも漏れたら即死とかいう状況のほうが考える必要がなくていいのかもしれない。まぁそんな状況はコード書く人の感覚からするとそんなにない ( だいたい自分が書けるコードは他のひとも書けると思うべき ) というのも正しいんだけど、コード書かない人から見るとそうではないことが多い ( コストかけて書いたものなのでタダで外に漏らしたくないとかかなー ) ということもわかっておくべきかなぁと思う。まぁたまに NDA 以外の法的な理由があって漏らせないとかいうのも聞くんだけどそんなしがらみのあるプロジェクトはさっさとつぶれるべき。
- あとはコストパフォーマンスの問題というか目に見えた成果が出にくいので有用性がわからないというひとも多いのかも。習熟にかかる時間がどれくらいでその結果今後の仕事がどれだけ楽になるかというのを定量的に示すことができれば導入への意欲も高まるのではないかな。というかここらへんのデータはどこかにあると思うんだけど見つからない…。まぁコード書くひとにとっては一回使えばわかるとは思うんだけど最初の一回が重いこともあるし、コード書かないひとへの情報提供はいくらしてもし足りないと思うしね。
- テスト
- テストの重要性はよくわかる。んだけどこれもメリット・デメリットの問題でそもそもテストの重要性がわかってないとかコストを割けない状況とかがあるわけだ。そしてテストがないとどうなるかを端的に示してそのための時間を確保するとかいろいろ努力すべき点はあるし、やむなくテストをせずにリリースしなきゃいけないけどそれによって生じる影響は想定できているとか受け入れる覚悟があるという状況もあるだろうしね。
まぁ上にあげた点以外にもいろいろあると思うけど、上記すべてにおいて共通するのは常識でないということと判断する際に必要な情報が非常に多岐のドメインに渡るということ。常識になるように努力すべきだし、出せる情報は出すべきだし、判断できるひとがいないならグループで討論すべきだし、直属の上長がこういったことに理解を示さないならさらにその上に掛け合うべきだし…、いくらでもできることはあるはず。
ただ普段の仕事に加えてプラスアルファでこれらを行わなければならないのでキツいということは言っておく。ひとを動かすには並大抵の努力じゃダメだということはよくいわれるけどホントにそうだと思う。いわゆるマッチョといわれるひと ( 10 年泥かぶって仕事できるひとでもいい ) はこれらを成功させてきた人ではないのかなと思う。そういう意味で Julius Caesar のいうリーダーの条件のうち持続する意思と肉体上の耐久力は必須なんではないかなと。
おれは覚悟して実行したけど先に体がくたばった。とはいっても別にひとりでやらなければならないものではないしね。モチベーション維持のうまい人とへこたれない情熱や体力を持っているひとが組めば成功率は高まるっしょ、たぶん。いまは意思疎通するためのツールがいっぱいあるんだから結束もしやすいだろうしね。
あと白状するとこういうことを考えるようになった元ネタは http://www.nurs.or.jp/~ogochan/linux/todo5.html 。ぶっちゃけたハナシ上記の文章なんか読まずにリンク先を読んだ方がいいと思う。
