2017年あけましておめでとうございます。また、初めまして。某ITベンチャー企業でITシステム開発プロジェクトのプロジェクトマネージャー見習いをしています。

年末年始ガッツリ休みをいただけたので長期休暇を使って「達人プログラマー」という著書を読みました。プログラマー向けの本ですがプログラムを書くことが本業ではない立場でも一考の価値があります。

著書：「新装版 達人プログラマー 職人から名匠への道」

参考になった「仕事に対する基本姿勢」・「プロジェクトを成功させるための技法」について抜粋してみました。

仕事に対する基本姿勢

プログラマとして生きていく上で達人になるために著者は仕事に対する基本姿勢を説いています。その基本姿勢はプログラマであるかどうかはかかわらず有用なものになっています。

「単に石を切り出す場合でも、常に心に聖堂を思い描かねばならない。」

上記の言葉は聖堂を作るための石を切り出す採石場作業者の心得からの引用です。単に石を切り出す作業として捉えるのではなくて「聖堂を作っている。」と常に思い描くことが重要という有名な話です。

実際に仕事をしていると目の前の仕事を、ただ言われた通りに作業してしまうことがありますが、達人は常に目の前の作業に対して全体像を見据えています。

「日々小さな奇跡を起こす」

常に自らの仕事に対する小さな改善を積み重ねることが重要です。単純計算ですが、毎日1分仕事が効率化されれば一年後には360分=6時間/日の改善になります。

日々小さな改善という奇跡を起こした先に達人の道が有ります。

「割れた窓を放置しない。」

「割れた窓を放置しない、一つのものを放置すると加速して全体が腐っていく。それは一つ見える部分が悪い設計、間違った意思決定、質の悪いコードであると、全体がゴミのように感じるので自分も適当に作業してしまう。」

上記は著書から引用です。プロジェクトを進めていくと共感できる方がいるかと思いますが、舌打ちしたくなるような品質の悪いコードやテストがされていないコードに出くわすことが有ります。プロジェクトの重要度から後回しにしてしまうと次同じものを見た人はそのコードを見て同じように幻滅し品質への意識が著しく低下します。

汚い街なら多少ポイ捨てをしても良いだろうと思ってしまいますけど、表参道のようなエレガントに整った場所ではポイ捨ては躊躇しますよね。

プロジェクトを成功させるための技法

情報は必ず単一、DRY

混乱をきさぬよう情報はユニークに保つ必要があります。情報となるドキュメントやソースコードは現在のプロジェクトメンバーはもちろん将来の保守・運用チーム、エンジニアに伝達されます。

その際にどの情報が「正」なのかが不明だと混乱が生じます。例えば、社内共有フォルダとgoogle docsの両方に設計書が存在してしまうと開発者はどちらの設計書が最新のものなのか分かりません。最悪、アップデートされていない間違った設計書を元に開発を進めてしまうかもしれません。

更に、単一ではない場合変更に対するメンテナンスコストが倍になります。同じ変更を共有フォルダとgoogle docs両方に上げる必要があるためです。

情報は常に単一にキープしましょう。Don't Repeat Yourselfです。

直交性

聞きなれない言葉ですが、幾何学の分野の用語で「変更しても他に影響を与えない。」という性質を著書では定義しています。

簡単に設計、製造、テスト、拡張できるシステムを構築する場合に必要となる重要な概念になります。

直行していないシステムは、単一機能の変更がシステム全体に影響を与える問題を引き起こす可能性が高まります。自己完結したコンポーネントの設計が必用です。

プロジェクトにおいても直交性は重要となります。直行していないプロジェクトはメンバーの役割が重複しています。そのような状態だと一人ひとりの責任範囲について混乱が生じ、一つの問題に対するミーティングに対して多くのメンバーの参加することになります。実作業の時間は必要か不必要かわからないミーティングに時間が割かれ妨害されてしまいます。

直交性の尺度としては各項目の会議に出席する人数の多さが尺度となります。

多くの未来をサポートする。

「最終決定等というものは存在しない、砂浜の砂に描かれたものであると考える。」

上記は顧客の要求についての著書の言葉です。システム開発の場合、要求をヒアリングし要求をドキュメントに落とし顧客の最終決定の承認を元に製造・テストの工程を進めます。

しかし、顧客の要望は往々として変わるものです。また、外部状況によって変更が余儀なくされる可能性もあります。

例えば、DBはMySQLだったがPostgreSQLに変更というようなのものもあれば、インターフェースのボタンの色を最初黒だったが青にしてほしいというようなものもあるかもしれません。

システムがどのような未来になるかは、「設計書の承認」の段階ではまだわからないということです。常に柔軟に対応できるよう構えておく、「ユーザーが行う不確実な意思決定の先の未来をどれだけシステムがサポートできるか」が重要になります。

要求の落とし穴、要求を掘り起こす

顧客にお伺いし要求をまとめるということが要求定義ではないということです。顧客が伝える要求は必要なものが漏れるものです。顧客の中にある大前提の業務知識などのために漏れます。

「ヒアリングする」ではなく「掘り起こす」という姿勢が必要になります。

著書で良い要求紹介されているは以下になります。

・従業員レコードは、あらかじめ決められた人々にしか閲覧できない。

・シリンダヘッダの温度は、エンジン固有の危険値を超えてはいけない。

・エディタは編集するファイルタイプに応じてキーワードを強調処理する。

上記の例は、「要求」の中に「ビジネスポリシー」「実装」を含んでいないことにポイントがあります。

「従業員レコードは、あらかじめ決められた人々にしか閲覧できない。」という要求を例としてあげます。

顧客からヒアリングした際、「従業員レコードは、人事部のみ閲覧可能にしてください。」と言われたとします。そのままそれを要求とした場合、実装は文字通り「人事部のみ閲覧できる」機能として実装されます。

ただし、プロジェクトの途中で「本当は今が人事部のみなだけで、労務が閲覧する事がありうる。」という要求が来た場合対応できなくなります。

「人事部のみ閲覧可能」というのはあくまでビジネスポリシーであり本当のシステムの要求は「特定の人々のみ閲覧可能」だったということです。

上記の例のように、要求の中にビジネスポリシーを含めた場合、柔軟性が低い実装が実現される可能性が高くなります。

要求はあくまで抽象的である必要があります。

最後に

プロジェクトを経験した人はこの著書を読むと共感できることや改めて身が引き締まる訓示が見つかると思います。

本著書の最終章「大きな期待」では、以下のようなことが書かれています。

アプリケーションが仕様を正しく満たしていれば、理論的には成功と言えるでしょう。しかし残念なことに、それだけでは現実の報酬は支払われないのです。プロジェクトの成功というものは、ユーザーの「期待」にどの程度答えたかによって現実的に判断されます。ユーザーの期待を下回ったプロジェクトは、どんなに素晴らしい成果物を構築したとしても失敗とみなされます。

ユーザーの「期待」をつかむことができるのは、プロジェクトの監督であり外交官となるプロジェクト・マネージャーとなります。

「仕様」を握ることに加えてビジネス上の「期待」を掴んでおくことも意識しようと思います。