改善に関する考察
「見直し」「改善」「ムリ、ムダ、ムラの排除」等々言葉は、さまざまなビジネスシーンでみられます。しかし、システム開発の現場においてはほとんど目にした事がありません。これはなぜなのでしょうか。
原因の一つとして、開発プロセスが明確でないことがあげられると思います。改善するということは、改善されなくてはならない何かがあって、それに対し改善を加え、改善前と改善後のデータを比較することにより改善されたとみなせるわけです。まぁ、当たり前のことなんですが、これが開発現場では当たり前でないような気がします。
私が今までに見てきた開発プロセス改善等々を謳った記事や論文は、役割、ドキュメント、ツール、等々が網羅しているものが多いようです。実際にこれを自社の活動にあわせようとしたら、カスタマイズにかなりの時間と労力を割かれますし、実行者に対して浸透させるにも時間が経ってしまいます。また、このような形で開発プロセスの改善は、日々の改善活動と相容れないものがあるのではないかとも思われます。
では、現実的な改善活動を行なおうとした場合、どのような方法が良いのでしょうか。以下に、私の私見（超独断）を述べます。
トップダウンとボトムアップの改善活動を並行して行なう。
トップダウンは、会社の方針といったレベルから落とし込んでいく作業を指します。例えば、顧客満足度の向上や、品質の向上がこれにあたります。まずは、このくらい大きなレベルの目標を立て、社内にそれらが浸透してからさらに詳細化します。その際、落とし込みが早すぎるのは厳禁です。顧客満足度の向上という目標を一度立てたら、その細部まで決定せず、時間をかけてそれらについて話し合うべきでしょう。役員レベルから現場レベルまでにおいて、顧客満足度について語る場（管理職レベルの定期ミーティングで話し合う等。現場レベルでそのための会合をわざわざ開く訳ではない。現場の意見は、上司が適宜ヒアリングすればよい）を設けるのがよいでしょう。結果として、落とし込むべきところが自然と見えてくるはずです。
トヨタでは、「地球環境の保全」という非常に抽象度の高い目標を設定していますが、それがあるからこそハイブリッドカーや燃料電池開発のプライオリティ付けが明確になるわけで、結果として現場の末端までのプライオリティ付けにが明確になるわけです。
ボトムアップは、現場のレベルでの改善活動です。現場レベルで既存プロセスを認識・明文化し、それに対しての改善案を出し、改善前と改善後の比較を行ないます。顧客満足度のような大きなレベルでの方針設定がされていると、組織全体の方向性が明確になり、現場での改善活動のプライオリティが付けやすくなります。
総合的な改善活動を一度に行なわない
会社の上層部や特定の部署が制定した開発プロセスを全開発組織に押し付けるような方法は、現場レベルによる継続的な改善業務を阻害するのため行なうべきではありません。また、現場と管理組織の対立関係の原因にもなりますし、プロセス遵守のための組織にコストをかけることになります。さらに、そのコストを渋ると開発プロセスは形骸化します。何一ついいことありません。業務の遂行者は人間であることを肝に銘じるべきでしょう。
現場レベルにおける既存開発プロセスの認識・明文化について
全ての開発プロセスを明文化するという考えは、少し現実的でないような気がする人が大半だと思います。特にAgileを中途半端にかじった人物であれば、そのようなドキュメンテーションは不必要なものであると反論するのが容易に想像できます。しかし私は、開発プロセスのドキュメンテーションはAgileに非常にマッチすると考えます。まず、Agileにおいて避けるべきドキュメントは、冗長である、保守コストが高過ぎる、必要性に乏しい等々の特性を持ちますが、現在の開発プロセスを明示する文書はそのどれにも当てはまりません。また、プロセスの改善を行なうためには、現状のプロセスを明文化する作業は必須であることは言うまでもないでしょう。
明文化された開発プロセスは、コミュニケーションツール
明文化された開発プロセスは、皆が遵守する必要があります。そのため、皆が遵守していることをチェックするための人材や部署が必要となります。実際にそのようなMP(憲兵隊)のような部署が存在する会社があるという話を聞いたことがあります。
さて、この方法が正しいと思いますか？ 私はそうは思いません。皆が自主的に遵守する方向性に持っていく必要があると考えます。前者では、チェック部隊と開発部隊が開発プロセス文書を元に対立関係を築くことになります。これは、コスト的にも人間関係的にも組織全体の利益に反するということは明白です。後者は理想的ですが、どのようにすれば実現できるのでしょうか。
業務の継続的な改善には、業務の明文化と、組織の誰もが日々の改善に携われる環境が必要です。日々の改善は、どのような細かなものでも、関係者全員に周知することを徹底する必要があります。これは、十年前であれば不可能だったかもしれませんが、現在はCMS(Contents Management System)の機能により可能です。全ての関係者が情報にアクセスでき、情報の変更は常にメールやRSSリーダーによって関係者に通知される仕組みが既にあるわけですから、これを使わない手はありません。結果として、文書は決定稿として強制力を持つものではなく、コミュニケーションのツールとして常に改善され続けるようになります。
