捨てるものを決めることの重要性

サーバで作業を行っている際にコマンドの入力ミスをしてしまうと言う経験は、SEとして働いていると、誰しもが持っていることだろう。

直ちにシステムトラブルにつながらないものもあれば、大切なファイルを消してしまう、などという顔面蒼白のものまであるが、多くの場合、落ち着いた後に同じ過ちを二度と起こさないための方法の検討、すなわち是正措置の検討が行われる。

そして、是正措置として多くのケースで、誤操作を防ぐための手順が追加されたり、チェックリストやテスト項目などが追加されたりする。誰かがミスをするたびに新たな手順が追加されるが、それが減らされることはあるだろうか。

本稿では、SEの生産性向上のため、何を捨てるか、何をやめるか、と言うことに注目してみたい。

[adsense]

何が捨てられないのか

SEの仕事で膨れ上がり、形骸化しがちなタスクを例として紹介する。

チェックリスト

是正の王道ともいえるチェックリストは、上手く活用すれば非常に強力なツールだが、それだけに盲目的にチェックリストに項目を追加してしまいがちだ。

作業のたびに発生する膨大なチェックリストはその煩雑さからいつかは形骸化し、効果が減っていってしまう。チェックリストは定期的な見直しが必要、これは古今東西に共通する鉄則だ。

プログラムのデッドロジックや非効率なコード

巨大なプログラムが抱えるデッドロジックや歴史的経緯により埋め込まれてしまった非効率な処理は非常に大きな問題だ。

多くの場合、既存の巨大なシステムに新しい機能を追加する場合は、既存機能への影響を最小限にとどめることが重要視される。そうした中で、場当たり的にプログラムをつぎはぎしていった結果として重複処理が複数存在し、全体として非効率なシステムになってしまう場合も少なくない。

レビュー、承認プロセス

プロジェクトの各チェックポイントにおける成果物の承認や、設計、コーディングのレビュー時の承認プロセスは、品質向上の名目で多段階化しがちだ。結果として、中身をよく知らない上の立場の人間が細かいモジュールを隅々までレビューしなければならない承認プロセスとなり、時間は無駄になるわレビュー品質自体も低いわで非効率になる場合が多い。

会議体

会議体の参加者は無駄に増加していく場合が多い。とりあえず、耳に入れておきたいから、という理由で呼ばれた会議の内容が耳に入ることは少なく、多くのSEにとっていつの間にか時間を奪う原因となっている。自分に関係のない会議には思い切って出ない、必要のない人は呼ばないことを徹底することで多くの人の時間を有効に使うことができるだろう。

[adsense]

何故捨てられないのか

では、何故SEの仕事は増えるばかりで減らすことが出来ないのだろうか。その理由とどうすれば捨てることができるのかと言うことを考えてみたい。

責任をとりたくないから捨てられない

やめる判断をして何かあったら、それをやらなくて良いと判断した自分の責任になってしまうから判断できない、というパターン。システムの内部構造に疎いマネージャーが陥る場合が多い。

とりあえず、これまでやってきたことを変えて悪影響が出ると嫌だから、とりあえず続けてしまう。状況の変化と共に不要となった作業にもかかわらず、同じやり方で続けているので、生産性への悪影響は当然だ。

どうすれば捨てられるか？

客観的に判断できる事実を集めて根拠を示し、関係者の合意のもと捨てることが有効だ。本来、上に立つものは、責任を持ってリスクをとった判断をしなければならない場合もある。しかし、現実にそういったリーダーは多くないのも事実である。

「うちの上司には、それをやめる判断は出来ない」と嘆くより先に、彼らが客観的に判断できる事実（＝彼らにとっての後ろ盾）をもって提案することを考えてみよう。

楽だから捨てられない

意外かもしれないが、慣習として行っている無駄な作業は、それを省くための方法を考えることよりも何も考えずにそれを続けるほうが簡単だ。そのため、ダラダラと続けてしまい、結果として無駄なことをしている、という場合も少なくない。

どうすれば捨てられるか？

思考を停止せず、一度習慣づいたことでも見直しを行うことが重要だ。

そのためには、一度、習慣づいた行動であっても定期的にチェックポイントを設けて議論する必要がある。いざ、運用に乗った後でチェックポイントを設けることは難しいため、新しくやることとを決めたら、同時にどこで見直しをかけるかも決めておこう。

背景がわからないから捨てられない

システムには過去の経緯で作りこまれた不思議なロジックや、何故この運用を行わなければならないのか、理解できないような運用も存在する。なんとなく、やめたほうが良いようにも感じられるが、それが行われている背景が理解できないため、判断がつかずに放置してしまうパターン。

どうすれば捨てられるか？

遡って背景を確認することが一番だが、昔ながらのシステムでは既に開発者が現場を離れていると言う場合も多い。

そうしたケースでは思い切って不要と思われる箇所をやめてみること、そして、テストをその分厚く行うなど、別の方法で品質担保を行うことが有効だ。ポイントとしては、問題が発生したときにすぐに元に戻せるようにしておくこと。現在の運用上で懸念点が見つからない場合は、導入した当初から状況が変わり、既に不要になっている場合も多い。