エキスパートではなく、プロフェッショナルに

本日はIC協会のセミナーがあり、久しぶりに参加してきました。今回の講演はIC協会理事長の田代さん。テーマは「私のIC論~収益安定化の道のりを振り返り、今後を展望する~」でした。私は田代さんのお話を何度か聴いていますので、そういった意味ではサプライズなお話はなかったのですが、大儲けしているわけでもなければ苦しくもない、そんな安定したICライフを送っておられるその秘密を改めて総括してくださいました。田代さんの考え方で共感しているのはエキスパートではなくプロフェッショナルたれということ。その中で今日学んだことは、エキスパートだと顧客は必ずしも満足しないということでした。少なくともどんな球でも打ち返せる守備範囲の広さは必要ですね。

ICという働き方と安定収入というのは業種・職種によってはなかなか両立の難しいテーマでもあります。ICとして働いたからと言って全てが田代さんのように実践できるわけではありません。こういったセミナーでタメになるお話を伺っても、ではそれをいかに自分に適用するかということは、誰にお願いするでもなく自分で取り組んでいかなければいけない問題であるのです。

今日のセミナーの参加者のある方から、よくICとしてやっていけますねといった言葉をかけられました。なるほど、私が田代さんや諸先輩方の働きぶりを見て一種の憧れや驚きをもって見ているように、ICでない方からすると少なくともICとして数年の実績を持っている人に対しては同じように賞賛というか驚嘆の思いで見ておられるのかもしれません。

いずれにせよ、今回のセミナーを終えて感じたことは、やはり多忙な折にも人と交流する時間を作ることは必要だなということ。そういった何気ないことの積み重ねがICとしての活動を支えることにつながるのだなということです。私自身も調子に波があるので、いつもいつも外に向けて活動できるわけではありません。時には内にこもって思索と自問を重ねる時間も必要です。ましてそういった時間すら取れない日々が続いた後は特にそう感じます。ですので無理せず自分のペースで、ただし危機感を持って過ごして参りたいと思います。


変更を想定しないシステムはダメなのか

こんにちは。今日は久しぶりに新聞記事を採り上げます。日経新聞の企業面(10面)に今日から「消費増税の焦点」という連載が始まりました。

「消費増税」という表現には違和感を覚えますが、これは2014年4月と2015年10月に予定されている消費税率の引き上げの事を指しているようです。(といっても巷ではほとんどこの言い回ししかされていないようですが)

コンピュータシステムの中でも勘定系や決済系のシステムでは諸税法の改正などにより日々のメンテナンスを余儀なくされます。基準日や割合(率)、基準値の境界などの定数を書き換えなければなりません。ただ変えれば良いのではなく、新しい率がいつから適用されるのか、またどの範囲に適用されるのかといったことを緻密に管理していかなければなりません。

今日の新聞記事で採り上げられていたのは東日本旅客鉄道のIC乗車券といえばお馴染みの Suica です。記事によると Suica のシステムは、サービスインの期日を優先するため消費税率の変更機能の作り込みを見送ったそうです。おそらく見送った機能はそれだけではないと思いますが、それでも、今度の税率引き上げ期日までに消費税率変更機能を実装するには1年以上の期間と数十億円の費用を見積もっているとのこと。

記事はここまでの状況を淡々と伝えるにとどまり、このことについてどう評価すべきかについては何も書かれていません。これは非常にげんなりする状況です。だからといって設計者や当システムのオーナーを簡単に責めるべきではないと思います。サービスインの期日を優先するということはビジネス戦略上の判断だったと思います。2000年問題の時もそうでした。多くのシステムでは将来の改修費用よりも現在のストレージ費用の節約を選びました。しかしその一方で、必ずやって来る2000年を想定して最初から年を4桁で格納するように設計されたシステムも存在していたのです。

最初からあらゆる変更に対応できるように、あるいはあらゆる業務に対応できるように汎用的なシステムを望むユーザーは多いです。しかしそのためにはシステムの設計からテストまで費用も時間もかかってしまうし、汎用的であるということは裏を返すと「どの局面においても使い勝手がイマイチ」となるリスクもあるのです。重要なことはあらゆる変更や変化を想定した上で、どこで折り合いをつけるかというトレードオフであるということ。そして判断には少なからず責任が伴うということではないでしょうか。


「パーフェクトソフトウェア」ジェラルド・M・ワインバーグ著

皆さんはシステム障害のニュースを耳にしたとき、どのように思われるでしょうか。私はこれまで何度もソフトウェアのテストを行ってきましたが、それでもシステム障害のニュースを聞くとつい「本当にテストしたの?」と思ってしまいます。これは本書の前文に紹介されているエピソードと丁度重なります。そしてその反応は「テストをすれば完璧な製品ができる」という誤解からくるのだと指摘されています。実際、全くテストをせずにリリースされるソフトウェアというのは存在しないでしょう。しかし、テストの結果を正しく使えていないソフトウェアというのはそこそこあるかも知れません。本書はそんなソフトウェアのテストについての誤解を解き、ソフトウェアのテストについて様々な示唆を与える著作です。

本書に何度か出てくるテクニックとして、バグの分類が挙げられます。実際の開発現場ではバグ(障害)をどのように分類するかということがしばしば議論になります。(もっとも何も議論せずに決められているパターンも残念ながら多いです)よくある分類は重要度や優先度でしょう。ところが重要度や優先度はどちらかというと主観的な基準であるため、誰かが統一的な判定を下すのでなければ基準が曖昧になり、せっかくの分類が機能しなくなってしまいます。そこで弊社では本書で薦められているバグレベルによる分類を次のようにアレンジして現場に適用しています。

  • レベル0 ・・・他テストを妨害
  • レベル1 ・・・業務遂行不可
  • レベル2 ・・・作業効率低下
  • レベル3 ・・・頻発すれば問題

この分類のメリットは基準がどちらかというと客観的だということです。それでも最初は迷うこともありますが、それぞれどういうケースかということを考えていけば自ずと分類は決まってきます。例えばログのメッセージが不適切というケースでは、障害時の原因究明に余計な時間がかかってしまうということで「作業効率低下」に分類できます。例えばサイズ0のファイルをDBに登録できてしまうというケースでは、通常の操作ではサイズ0のファイルを扱うことがないと考えれば「頻発すれば問題」に分類できます。このバグレベルのおかげで分類作業の効率が上がりました。これは一種の優先度による分類ですが、紛れもなくレベル0のバグは優先して対応すべきものです。極端な話、レベル3のバグであれば状況により対応を見送るという判断もあるでしょう。

本書でも紹介されているように、ソフトウェアの開発に理解がない(あるいは理解があると自認している)管理者や営業担当者が、開発者に対してバグゼロを要求するケースを何度も見てきました。しかし、何がバグであるかが自明なケースもあれば、ビジネス環境に応じてバグの基準は変化することもあり、仮にリリース時点でバグがゼロであったとしても(それもあり得ないのですが)それを将来に亘って保障することはできないのです。本書はテストを担当する技術者のみならず、開発チームに関わる管理者や営業担当者の方にも読んでいただきたい一冊です。

――――
書名:パーフェクトソフトウェア
副題:テストにまつわる幻想
著者:ジェラルド・M・ワインバーグ
発行:日経BP社/2010年5月31日
ISBN:978-4-8222-8429-9