アイロベックスメールマガジン　携帯版

ベトナムに視察に行って、日本からソフトウエア開発を請けている会社の方にお話を伺う機会がありましたが、「日本の会社は品質に非常にうるさい」ということでした。

「日本の」とおっしゃったのは、「欧州やアメリカに比べて」というような意味でした。

「品質」を英訳すると「Quality」であるとずっと思っていましたが、どうも、日本のビジネスにおいては、「品質」とは、ある部分のことが一定レベルに達していることを意味していて、一方で、「クオリティ」と言うと、全体としての目的や顧客要件にどれだけ合致しているかという意味で使用していることが多いようです。

そういった意味では、顧客の信頼を失うのは品質が悪いときですが、顧客の信頼を得るには品質が良いだけでは足らず、クオリティが高くなければならないというわけです。

システム全体として、顧客要件の合格レベルは、細かい部分の1箇所ずつの平均点や総合点ではなくて、もっと別の視点から見た、大きな基本思想といったものから発生するのではないかという気がします。

前々から、仕事の仕組みとして、建設業はシステム開発会社と似ていると思っていました。

実は、昨年、実家を新築しました。複数の人間（家族）のさまざまな思惑があり、まさに三谷幸喜監督の映画「みんなのいえ」を地でいくストーリーとなったわけですが、できあがった家を見たときの思いとして、システム設計と本当に近いものがある、と思ったのです。

施主にとっては、出来上がった家を見て、「まったく不満が無い」「全て思い通り」ということはほとんど無いことでしょう。

つまり、何かしら気になる箇所はあるものなのです。

しかし、幾つかの細かな不満点があったとしても、それを超える大きな満足感があるからこそ、施主は納得するのです。

そして、多少の不具合についても、すぐさま対処できることはすぐ対処し、相談に乗るといった姿勢、つまりフットワークが軽ければ、お客さまの不満が大きくなることは、それほどないのです。

一方、一番いけないことは、大きなことで満足感を与えられないような仕事をすることではないのでしょうか。

大きな満足があれば、多少の欠点は許されるのです。

しかし、その大きな満足を生み出す仕事の力、遂行能力というのは、細かなことの積み重ねからしか、実現できないことなのです。

手順、スケジュール管理、チェックといった作業は、どんなに細かく考えても、また行っても、やりすぎるということはないのです。

逆に、成果については、細かなことを全て実現しようとしてしまうと、コストや人間の時間さえもが些細なことだらけで奪われてしまい、「大きな満足という成果を、結果として達成できなくなるのではないか？」という気がします。

ちょっと抽象的だったでしょうか？

思想がある骨組みと細かな手順、クオリティをあげること、それらが、顧客満足を得るための重要事項です。

システム開発において、「上流工程」が重要であることは、言うまでもないことでしょう。
要件定義が間違っていたり、いい加減であれば、その後の基本設計がスムーズに進むことはありえないからです。

だからといって、基本設計、詳細設計、プログラミング工程等のあらゆる工程において「重要でないもの」は、ありません。

今回は、プログラム詳細設計に焦点をおいて、基本設計との違いを軸に考えてみたいと思います。

SEは基本設計書を基に詳細設計書を作るわけですが、この2つのドキュメントの目的は明らかに異なります。

それは、基本設計書はお客様に確認してもらう為の設計書であり、詳細設計書は、プログラマに説明する為の設計書である、という点です。

ですから、基本設計書は、お客様が理解できる言葉で表現される、業務内容に沿って説明されたものであるべきです。

一方、詳細設計書は、SEがプログラマに指示を出す為のドキュメントとなるわけですから、むしろ業務内容の説明ではなく、そのプログラムの構成や、細かなプログラミング工程となるものです。

しかし、プログラミングをするのが人間である限り、そのプログラムが、どの画面で、どんな役割をもって使われ、誰が、いつ、どのように使うのか？といった、意味をつけて引き継ぐことが、プログラマにとって、大きな理解に繋がることは間違いありません。

プログラムがどのように使われるかもわからず、ただ、詳細設計書から読み取って、さまざまな想像をすることは、理解する為に余分な工数を使わせることだけでなく、勘違いを引き起こしたり、考えなくて良いような余分な作業を重要とみなして、コーディングしてしまったり、といったことを引き起こします。

もちろん、プログラマがそれなりのキャリアを積んでいる場合は、プログラマからSEに質問があがることでしょう。
だからといって、あがってきた質問に答えればよいという仕事の引継ぎ方法は、間違いの元となります。

詳細設計をSE同士で確認レビューを行うように、プログラマへの引継ぎも、できれば1対1ではなくて、1対2以上の関係で、引継ぎをする者と、引継ぎチェックを行う者がいることが望ましいでしょう。

詳細設計書に書いてあることを、一字一句守ってプログラミングすることは、プログラマにとっては当たり前のことです。
しかし、その詳細設計書が間違っていない、と誰が保障できるでしょうか。

人間が作っている以上、コピーしてきたものの未修正や、思い違い、うっかり、といったミスはつきものなのです。

頭ではわかっていたことが、ドキュメントとなると正確に表現できていない、というのは、ドキュメント作成者のミスだけでなく、人と人との「伝言ゲーム」的なコミュニケーション能力に起因することもあるわけです。

ありとあらゆるリスクを廃して無駄なことを省く。

その為には、一見無駄なように思われる「複数人数でのレビュー」や「ドキュメントチェック」を確実に行うことが、後々の工数の何倍もの節約になるのです。

「急がば回れ」といった諺を思い出すのは、こういうときなのです。

新しいプロジェクトが始まるとき、顧客は、素晴らしい成果を思い描き、その成功を期待します。

そのプロジェクトを請け負うシステムエンジニアも同様に、顧客の期待に応えるため、また、自分自身のためにも、最高の成果を挙げようと思うものです。

ところが、実際にプロジェクトが始まるや否や、その想いは、数々の困難に直面します。

納期までの残された時間、スタッフの能力や人数、顧客の社内の制約条件など、
どれをとっても理想通りにいくわけもなく、顧客もシステムエンジニアも、プロジェクトが始まったその瞬間から、何かを諦めていくことを求められるものです。

従って、当たり前のことですが、プロジェクトを成功に導く唯一の選択は、すべての仕事に優先順位をつけていくことなのです。

しかし、開発側にとっての優先順位と、顧客側にとっての優先順位が違うという、難解な問題も含んでいます。

今回は、顧客側との意識の摺り合わせは横において、開発側だけの問題について考えてみたいと思います。

開発側のシステムエンジニアにとって一番先に解決可能なことは、自分のこと、つまり、開発側の「コスト」であったり「時間」であったりするわけです。

ましてや、自分自身の時間の使い方については、
一番先に解決可能なことなのです。

ところが、システム開発において人を使って実行していく為に、「様々なことを決断していく」ということは、リーダー自身に精神的にも肉体的にも、かなりの重労働を課する仕事です。

ましてや自分が、「重要だけれども、どうして良いか分からない」問題にかまけている間に、チームスタッフたちの作業がどんどん遅れてしまうことが見えてきます。

そこで、若手SEにとっては、簡単なこと、出来ることから作業をしていくことが、目先の生産性をあげるために必要だと思えてきます。

確かに「できることからやる」というのは、スケジュールを遅らせないためには、唯一の方法であるかのように思われます。

しかし「できることからやる」ということにのみ集中してしまうことは、絶対に許されません。

中長期的に見れば、「重要なことを後から決断する」というやり方はリスクが大きく、
取り返しのつかないような工数で、後に修正を強いられる原因にもなるものです。

迷っている状態で走り始めるべきなのか、それとも無理やりに決めて走り始めるべきなのか。

どちらかが正しいというわけではありません。

決めることは、怖く、つらい作業なのかもしれません。

時に、顧客が決めてくれることだけを待っているSEには、自分達の問題さえ、まるで誰かが決めてくれるのを待っているように見えるときさえ感じます。

直感で感じることもSEの大事な資質であると知ることです。

もちろん、その前には、考え、考え抜いて、人にも相談し、情報を集めるという作業が伴う必要があるのは当たり前です。

しかし、最終的には、捨てる物は捨て、決めなければいけないことはきっちりと決めることが「SEの仕事」なのです。

それが「仕事」ともいえます。

全てのシステムに同じ時間が流れているわけではありません。

しかし、プロジェクトに臨むリーダーの態度は、同じものが求められています。

余裕はない、だが実行すれば、終わる。

実行することは、決断することである。

決断して、実行する。

するべきことを正しく選択し、実行し続ける。

そして、しなくていいことを正しく選択し、顧客に理解を求め、部下に指導し続ける。

正しい方向に進んでいるかどうか、必ずレビューとスポットチェックで確認する。

「決断しなくて実行することほど、悪い手はない」ということを、SEは常に意識するのです。