
いつも、技術的な内容ばかりでしたが、今回は「問題解決のコツ」ということで少し広い範囲の課題についてお話ししたいと思います。
システム開発の仕事をするようになってから100以上のプロジェクトを経験してきましたが、ほとんどのプロジェクトは無理難題が含まれているものでした。
それらのプロジェクトを問題なく完了させるために、私なりの手法を用いて対応してきました。
順調に完了することを不思議がられ「あいつは運がいい」だのという評価しかされませんでしたが、それぐらい理解しにくいことをやってきたのかもしれません。
今までも隠してきたつもりはありませんが、独自の手法ということもあり、周囲の人に説明することはありませんでした。
体系的なプロジェクト管理についても勉強しましたが、私が考えているようなノウハウについては知識体系にないようです。
このようなノウハウに価値を見出いし、お役立いただけると幸いです。
今回はいくつかの例の「問題」を解決しながら、その工程の中で手法の説明をしていきたいと思います。
例その1:納期に間に合わない!
よくある話ですね。
プロジェクトの遅れの場合もありますし、個人で受けた仕事の場合もあると思います。
一般的にこの課題に対する対策は、「ガンバる」「残業する」ちょっとやり手な人だと「ユーザと交渉する」という感じと思います。
こういった課題でもきちんと対応すると意外と楽になったりしますので、まずはこの例を使って手法の説明をしていきたいと思います。
(注意!:どんな場合でも必ず楽になるわけじゃないですよ!)
分析
私の解決方法の中心となるのは「分析」です。
しっかりと分析すると問題の本質が見え、的確な対策を行うことができます。
結果として楽になり、納期に間に合い、品質も担保できたりしてみんなハッピーとなります。
もちろん、「分析」は誰でもやっていますよね。
それでも結果が異なるのは、単純に「運の良し悪し」なんでしょうか?
ここで、私の分析手法を説明しておきたいと思います。
そのあとで、この例題の解決手順を、分析手法をもとに説明します。
分析手法1.俯瞰(マクロ)と実態(ミクロ)の両面から分析する

日本の伝統芸能の能(ノウ)の奥義には「離見の見」(りけんのけん)という言葉があるそうです。
「離見」とは文字通り「距離を取って見る」ということです。
つまり俯瞰してマクロ視点で物事を見る。「物事を俯瞰してみる」ということは多くの人がその重要性を認識していますよね。
では、なぜ能の奥義は「離見」ではなく「離見の見」なのでしょうか?
「離見の見」とは「(客席から)俯瞰して見た舞台全体を使って演技をする」というような意味だそうです。(私的な言い回しです。正式な説明ではありません)
つまり、ただ俯瞰して見るだけではなく、その状態を理解したうえで自分の演技やほかの人の動きなどを一つの舞台として演技するということです。
これを行うには、舞台上の自分の動きだけではなく一緒に演じている人の動きや舞台道具などを含めて客先からどのように見えるかを見て、その全体が調和するように自分が動くということになります。
実は、この手法が今回説明する課題解決のコツの一つです。
分析手法2.構造を理解する
マクロ視点の分析は全体像を見ることなので、自然に(必然的に)構造の理解を行っています。
ただ、ミクロ視点では、特に自分が作業に入り込んでいるため構造的な分析を行わないことが多いです。
ですが、今回説明する手法はミクロでも構造分析を行います。
むしろミクロの構造分析のほうが重要です。
構造的な理解を行うと課題の本質が見えてきます。
この辺りは少し説明が難しいので例を使って説明したいと思います。
では、これらの手法を使用して今回の例「納期に間に合わない!」を分析してみましょう。
前提として、チームではなく、自分1人で担当しているプログラム開発業務(案件)ということとします。
手順1:マクロ分析(俯瞰)
過去のことを考えても問題は解決しないので、今から納期までのことを分析します。
分析するためには情報(材料)が必要になりますが、闇雲(やみくも)に情報を集めても分析が難しくなります。
今わかっていることから構造分析を行う上で必要な情報を集めるようにしていきます。
今わかっていること
- スケジュールでは納期まで10日
- 残り作業工数の合計は13日
- 残業と休日出勤すれば間に合うかもしれない

ここから構造分析をしつつ、足りない情報を集めます。
- 追加要員はいない。いたとしても説明などのオーバーヘッドが発生するので追加しても間に合わない。
- 納期を伸ばすことはユーザ業務を止めることを意味するため不可能
- 残業(3時間/日)や休日出勤(計2日)は可能、徹夜はNG
- さらに遅れるリスクが最大2人日分、存在する
- 体調は良好、残業や休日出勤は可能
ここまでで以下のような構造が見えてきます。
不足日数:残工数10日 ー 工数13日 ー リスク2日 = -5日
追加工数:残業10日×3時間 + 休日出勤2日 = 5.75日

俯瞰して構造的に理解することで、少し光が見えてきましたね。
ただし、「ガンバる」という結論に近いものしか見えてない気がします。
多くの場合、ここまでの分析で「何とかなりそう」なので「頑張るぞー」ってなると思います。
(土日無し、毎日9時まで残業。まあまあ、ブラックですねぇ。。。)
手順2:ミクロ分析(実態)
ここでもう一歩踏み込んで、「ミクロ(実態)」の分析をします。
今わかっていること+構造分析に必要な情報収集
- 総プログラム数は10本
- 残った作業はプログラム3本、単体テスト8本、結合テスト
- プログラムは1人日/本、単体テスト1人日/本は、結合テストはシナリオ作成と実施で2日
- プログラムは複数の変数の条件によって処理を分けて実行する内容だが条件が1プログラムにつき30パターンになるため実装工数がかかる
- 残り3本のプログラムの分岐条件はすべて同じだが実行する内容が異なる
- 単体テストはすべてエビデンスを取得することになっているが、フォーマットは指定されていない
- 結合テストのエビデンスについては言及されていない
これも構造的に理解してみましょう。
- 3本のプログラムの大半は分岐処理で共通化が可能
- 分岐処理の共通化をすることで、実装とテスト工数を大幅に削減できる
- 単体テストフォーマットを工夫することで手間を減らせられる可能性がある
- 結合テストはシナリオに結果を記載することで報告書と兼用とし、コストを削減できる
1.は大きい発見ですね。
場合によっては今まで作ったプログラムも共通化してしまえば単体テスト工数を大幅に減らせられますし、品質も上がります。
結果として以下のようになります。
開発 : 3人日 ⇒ 2人日(共通化1日 + 3本実装と過去分の改修1日)
単体テスト: 8人日 ⇒ 4.5人日(テストケース数の半数を削減 + フォーマット変更0.5日)
結合テスト: 2人日 ⇒ 1.5人日(フォーマット変更0.5日 + エビデンス取得を省略したテスト1日)
リスク : 2人日 ⇒ 2人日
合計 :15人日 ⇒ 10人日

スケジュール通りに終わっちゃいそうですね。
共通化するときにうまくいかない場合があるかもしれないので残業などで納期までの日数にバッファを持たせたほうがいいでしょうけれど、かなり楽になると思います。
前半のマクロ分析だけではこの結論は出ませんでした。
私の経験上、ミクロ分析で解決できることが多いですが、ミクロ分析だけやっていればいいということもないと思います。
マクロ分析を行ったうえでミクロ分析を行ったからこそ効果的な解決策が見えているとも言えます。
実際、今回の分析でも、マクロ分析をしていなければ「残り工数の大半が単体テスト」ということが認識できないため、ミクロ分析で「単体テストのコストを下げる」ことの効果を見出せません。
また、ミクロ分析でも構造的に分析が必要です。
今回の場合、プログラムコードレベルまで掘り下げた構造分析を行ったことで「単体テスト工数削減」の可能性が発見できました。
このように、マクロ、ミクロで構造を理解して効果的な解決策を発見することが「問題解決のコツ」といえます。
例その2:技術的に実現できない!
例が一つだけでは、手法として使えるといえないのでいくつかの例で説明してみたいと思います。
2つ目の例は技術的な課題です。
ここでいう技術的な課題とは、例えば、「ユーザの要求に対して、規定されている環境(OSやDBやブラウザやPG言語など)で実現が難しいという状況」とします。
こういった問題は課題の要因が多岐にわたります。
例えば、こんな感じ。
- 技術的に実現不可能
- ライセンスに抵触
- 購入資金がない
- プラットフォームが対応してない
などなど。
では、新規開発するシステム要件の中で、以下の要求が出たとして分析してみましょう。
今回のユーザ要求
- 「ユーザが画面項目の配置を変えたり追加したりできるようにしてほしい」
- 「この機能を実装したいのは、トップメニューと一部の検索画面のみでほかの画面は固定でよい」
- 「トップ画面は各機能へのリンクの配置や特定画面へのショートカット機能を付けたい」
- 「検索画面は項目単位の検索条件の追加や列の入れ替えや削除を行いたい」

手順1:マクロ分析(俯瞰)
- ユーザ数は1000人ぐらい
- 要求元は運用管理チームで、旧システム運用中にユーザからトップメニューや検索画面に対するシステム変更の依頼が多かったことからこの要求が発生した
- 実現できない場合でも今までと同じ運用は可能なため必須機能ではない
- 実現できた場合は年間運用コストが最小でも2人月削減できる
- 実際の利用者への影響(メリット・デメリット)は未知数
- 実現のためには特殊スキルを持った要員が必要
- プロジェクト予算の関係から、この機能の開発は0.5人月以内に収める必要がある
手順2:ミクロ分析(実態)
技術的目線
- 技術課題は①ライブラリの選定と調達、②データ保存方法、の2点
- 対象機能を実現するためのオープンソースライブラリを調査したがマッチするものがないため独自ライブラリを作成する必要がある
- 独自ライブラリの開発にかけられる工数は0.3人月
- データの保存については、今回使用するフレームワークにユーザ設定保存用の領域があるため、そこに保存する
構造的理解
- オープンソースを参考に今までのノウハウを利用すれば実現できそう
- 今後の案件にも利用できるので投資の意味でも少しコストをかけても良い
顧客目線
- 今回の要求元は発注部門(システム管理部門)のリーダー
- 要求担当者は時期課長候補とされており、新規システムにおける成果を期待されているため、運用コストの削減を今回の成果の一つとしたいと考えている
- 我々の会社としても要求担当者が課長になることで案件受注が安定するため後押ししたい
- 政治的思惑が強い内容のため利用者のメリットはあまり確認されていない
利用者目線
- 旧システムのシステム変更要求は利用者部門の課長が行うようになっている
- 部門単位にシステムの使い方は画一的で、個人ごとの設定はあまり使わない。
- 実は部門単位に同じ設定を行う機能が必要。

もう一度、技術目線
- 利用者目線の分析からユーザ個々のデータ保存では運用に合っていないことが判明
- 部門単位に設定とデータ保存ができる必要がある。
- 部門単位のデータ保存を行うには新しいデータ領域を作成する必要がある。
- 利用者が使いながら設定する(D&Dなどで移動させる)想定だったが、新たに設定画面が必要
- データ領域の作成:0.5人月、登録画面:0.5人月、ライブラリ開発は不要:ー0.3人月
構造的理解
- 自社、発注元担当者の政治的意図から実現したほうがいい内容
- 利用者目線の要件を発注元担当者に共有し、コストを含めた同意を取る必要がある。
- クライアントサイド機能と想定していたが、サーバーサイド機能となるため難易度は比較的低い
つまり、もともとの課題「技術的に実現できない!」という課題を解決する必要がなくなってしまいました。
ちゃんとした分析をせず、要求担当者の依頼通りの機能を実装していたら実現することも難しく、ユーザも使いにくいシステムになってしまったいた可能性が高いということになります。
要求担当者には状況の説明と要求変更を容認してもらう必要がありますが、コスト超過を含めて十分に説明可能な状態と思います。
結果として要求担当者の株も上がることになるんじゃないでしょうか。
例その3:メンバー同士が険悪!
チームメンバーの人間関係の問題です。
ときどき発生する問題ですね。
細かい状況は以下の通りです。
メンバー構成
Aさん:2年目社員
Bさん:3年目社員
Cさん:5年目社員
Dさん:6年目社員
状況
- Bさんから相談:「Aさんが業務中に騒がしくて仕事に集中できない」
- Aさんは業務中にCさん、Dさんと明るく会話することが多く、職場は常に明るい雰囲気になっている。
- Bさんはあまり会話に参加することはなく、黙々と仕事し、作業に遅延もなく、残業することも少ない。
- Cさん、Dさんは不満に感じていない
- AさんはBさんに対して理解できないと思っているが不満はない
- Aさんの作業は遅延しがちで、ほかの3人でリカバリーしている

ミクロ分析(実態・ヒヤリング)
Bさんへの視点
- 仕事は効率的に行い、残業をせずにプライベートの時間を大事にしたい
- ほかのメンバーがおしゃべりをしていて効率が落ちることも気になるが、おしゃべりをしていて残業をしていることも気になっている
- 人とのコミュニケーションは得意ではないので、話をすることなどは必要なことだけにしたい
- Aさんの人となりについては嫌ではなく、明るい性格であることを好ましく思っている
Aさんへの視点
- 基本的にマイナス思考のため、わざと明るくふるまっている
- 幼少期に軽い知的障害と診断されたことがあり、効率よく作業することが苦手
- 自身の作業の遅れについては後ろめたさを感じており、周りと同じように作業できるようになりたいと考えている
- Bさんはあまり話はしないが、いつもリカバリーをしてもらっていることに感謝しているし、効率よく仕事している姿を目標にしたいと考えている
構造的理解
- それぞれの仕事に対する考え方や個人的な事情があり、どれも尊重すべき内容である。
- また、お互いに人間的に嫌っているわけではなく、むしろ、好意的に思っているところがある
- ただ、Bさんにとって、Aさんの行動が都合が悪い状況となっており、それにより摩擦が生じ雰囲気の悪化につながっていると思われる。
マクロ分析(俯瞰)+ 構造的理解
- おおよそ、社会人にまで成長した人の性格や考え方の変更はかなり難しい
- それらが問題の原因だったとしても、その改善による解決はできないと考えるべき
- (不可能ではないが時間がかかる。長期間かけて育成する場合は別)
- 今回の問題はAさんが仕事に集中できないという一点のみ解決すればいいように思えるが、雰囲気の悪化は別に要因がありそう
- Aさんのみ別室で作業してもらうという解決策もあるが、それではチームとして結束はさらに薄れる
- Bさんの行動を制限したり、Aさんに忍耐を要求するのも解決とはいえない

今回のヒヤリングでわかるように、それぞれの事情や考え方に問題があるわけではなく、それらに対する理解があれば解決する問題と思われます。
日々の積み重ねの問題でもあるため、相互理解を行ったうえでチームである程度のルールを作ったり、定期的なミーティングを行ってコミュニケーションを増やすことも有効でしょうね。
こういった構造分析を当人たちを含めてチーム全体で共有することも重要で、問題解決だけでなく、よりけっそよく力の強いチームとなると思います。

まとめ
いかがでしたでしょうか?
一般的な「プロジェクト管理」とは全く違った観点での解説だったので、期待外れと思った人もいるかもしれませんね。
でも、タスクの洗い出しや工数見積もり、スケジュール、工数管理だけでプロジェクトがスムーズに完了した経験はありませんので、こういったプロジェクトで発生する課題を如何に的確に対処するかということが、プロジェクトのスムーズな完了に導くために必要不可欠であることは私の経験上明確となっていますし、それを行わないから予定通り終わらないのだということも間違いないと思います。
「開発」は前例がないことを実現することを求められるから「開発」といわれているわけで、前例がない課題を体系的な手法で解決することのほうが難しいと思います。
手法にとらわれず、その時一番必要な対処を思い切って行うという行動が開発のマネージメント(自己マネージメントも含む)には大切です。