目的は一緒だ！ 変わるマネジメント（1）
はじめまして。東（ひがし）と申します。最近は、八朔という名前で活動をしております。
わたしは、独立系ソフトウェア会社に勤務しておりますが、委任契約という形で、約10年間、大手ソフトウェア会社にて設計・開発を担当しておりました。
何年か前に委任契約を終了し、自社に戻ることになりまして、社内受託案件のプロジェクトリーダーとして働いております。
2002年頃より、仕事上でマネジメントすることが多くなり、独学で勉強するうちにプロジェクト・マネジメントに興味を持ち、さまざまなコミュニティ活動を通じて、諸先輩方から多くのことを学びました。
わたしのコラムでは、日頃のプロジェクトを進める上で実施しているソフトウェア開発のマネジメントについて、いろいろな視点から分析し、ご紹介していきたいと思います。
今回は、初めてということもあり、あいさつ程度に、現在に至るまでの生い立ちを紹介します。
●プロジェクト規模の変化
わたしは、大手ソフトウェア会社に勤務していたこともあり、ほとんどの開発をウォーターフォール型の方法で行ってきました。
大手ソフトウェア会社には長年の様々なノウハウが蓄積されており、特に多くの技術者（協力会社）が集まるようなプロジェクトでは、誰もが理解している共通言語のように有効に機能していました。
大量の仕様変更や設計不備などで訂正が発生すると、追加作業として後工程に伝播していましたが、それなりにプロジェクトとしては（苦労はしていましたが）うまく回っていたと思います。
ただ、時代とともにシステムが複雑になり、要件定義や設計が難しくなりました。設計工程で決めるべき事項も、ビジネスをわかっているお客様ですら把握できず、確定を先延ばしにしていることが多く発生していました。
わたしの中では、ウォーターフォール型プロセスのあり方について、いろいろな葛藤がありました。
その後、晴れて（？）自社に戻ることになり、比較的小規模のプロジェクト案件を任されることになりました。
●共通言語の違い
最初に、一番苦労したことは「共通言語」です。
共通言語とは、文字通り、「組織において使う同じ定義の言葉」ということです。
例えば、「製造完了」という言葉の認識レベルの違い。
- 共有部分ができていないので、コメントアウトして、自分のコーディングが完了した
- コーディングが終わり、先輩のソースレビューが完了した
- 設計書にチェックを入れて、必要機能の実装が完了した
- 各自の判断で簡単に動作確認までが終わった
- 簡単な完了チェックシートの確認が済んだ
- 単体テスト項目票を作成し、異常系を含めた確認が完了した
例えば、「単体テスト完了」という言葉の認識レベルの違い。
- 簡単な完了チェックシートの確認が済んだ
- 単体テスト項目票を作成し、異常系を含めた確認が完了した
- ユニットテストモジュールを作成し、C2（注1）レベルで95％を超えた確認が完了した
（注1：出典「知っておきたいテストの“イロハ”（1）」より）
「製造完了」「単体テスト完了」という言葉でも、リーダーの期待とメンバーの認識がずれていたら工数も大きく変わってきます。
これでは、スケジュールや品質がマネジメントできるわけがありません。
●プロジェクトの目的を共有（認識）
また、大規模なプロジェクト同様、プロジェクトの目的が共有（認識）されていませんでした。
例えば、進捗管理のため、ツールを用い、プロジェクトメンバーの進捗管理をしていたとします。
しかし、なぜ、このツールに入力しているのか？ 管理の必要性がメンバーと共有されていない場合、メンバーにとっては「ツールにデータを入れる」ことが目的となり、「煩雑な業務が増えただけでどんなメリットがあるの？」という疑問を持つようになります。管理側の当初の目的からすると、本末転倒になりかねません。
プロジェクトの方向性を決める場合にしても同じです。
お客様が持っている、システム導入の背景、目的を明確にし、的確に判断する必要があります。
そうでないと、納品直前に「こんなの違う。作り直して！」などと言われることになります。
●コミュニケーションの違い
共通認識は、職種によっても違うし、仕事の内容によっても、立場、年齢、風土や文化によっても変わってきます。
そんな共通言語の重要性に気付かなかった、いや気付かないふりをして、無意識に「バカの壁」を作っていたような気がします。
年齢がいくつでも、経験者であってもなくても、立場がどうであれ、同じ日本語を話しているから、分かっているつもり、分かってもらえるはず、という誤解の元にコミュニケーションが行われ、ズレていたのだと思います。
●そしてプロセスの違い
弊社は、小規模のプロジェクトでも、ウォーターフォール型の開発プロセスを採用していました。
今まで、大規模プロジェクトで培ってきたやり方と、小規模プロジェクトとでは、やりたいことができなかったり、必要でなかったりと、使えるプロセスの違いに戸惑いました。
次回以降は、自分との葛藤、変化への対策、対策への対立など、具体的に行った内容、そして失敗談を紹介していきたいと思います。
あなたや組織が変わるための「気付き」になれば幸いです。