というテーマに触れておきたいと思います。

ただし、前提条件として次のことだけは肝に銘じておいてください。

そもそも丸投げするにあたって必要不可欠なインターフェース（引継ぎ情報、言い換えれば引数（パラメーター））を提供しようとしない丸投げは社会悪である、ということです。

丸投げとは言い換えれば『業務委託』であり、企業間の契約で言えば"委任"や"準委任"契約に相当するもののことを言います。もしも、本来依頼・命令する側の人が実施するべき仕事を他人に丸投げしたのなら、相応の追加報酬を支払うべきものであるということですね。

また、そうやって委託されるものは「業務を担う役割」だけでなく「責任」や「権限」も委譲されますので請ける以上はそれなりの覚悟が必要になります。

しかし、業務委託や委任／準委任がそうであるように、その業務を遂行するための事前情報、引継ぎ情報は必ず取り交わされなければスムーズに事が進みません。

ですが、社内で上司から部下へと仕事を丸投げする時は

　上司「おう、これやっとけ」

の一言で済ませる上司もいたりしますがこれはＮＧです。業務を引き受けるにあたって必要最低限の情報が取り交わされていません。こうした丸投げは請けた側に相当な負担がかかるか、そもそも業務が失敗するかのどちらかにしかならない不幸な仕事の仕方になります。てゆか、そんな上司、無能以外のなにものでもありませんけどね。

ただまぁ先ほども言いましたように「丸投げ」と言うととても印象が悪く聞こえますけど、基本的には"委任／準委任"の範疇となります。ですから、請ける以上はしっかりと進め、問題なく完了させなければなりません。

たとえば、要件定義工程の作業をSIerから丸投げされてしまった下請け企業あるいはエンジニアの立場になって考えてみましょう。

「丸投げ」は下請け開発の典型的な問題です。

この風習は無能な上司と部下の関係のように、請け元と下請け企業との間でも往々にして起こることがあります。それは本来「社会悪」だと言うのは変わりません。しかし、そうは言っても未だに無くならないものでもあります。

なぜなくならないかと言うと、先ほどから言うように無能な上司から部下に対して行われるケースがあり、上司が日々そういう仕事の仕方ばかりしていると「自分より下の立場には、そうしても良いんだ」と言う低劣な甘えが湧いてきて、それが下請けにも同じことをしてしまう理由となってしまっているのです。

ですから、企業全体として日常の業務から「丸投げ」をなくす努力をしない限り、ソフトウェア開発においてもお客さまから「丸投げされてしまうリスク」は常に頭の片隅で考えておいた方がいいでしょう。

常に、『委任／準委任（SES）契約』を結ぶ時には、そう言う覚悟を以って締結された方が良いと思います。

中には設計・実装を請ける契約でプロジェクトに参画したのに、実質的に要件定義作業まで行うはめになることがあります。発注者が要件定義工程の間にしっかりと要件を定めておくことができなかったのでしょう。そのしわ寄せを、お金も責任も権限も何も与えられていない契約の中で無理やり押し付けられるのです。

こうした状況下で九投げをされて辛いのは、

　負うべき責任とやっている作業のギャップがある

からです。特に優秀なエンジニアは下請けの立場であっても期せずしてチーム内で「出世」してしまい、本来の役割から逸脱した重大な働きを期待されてしまうことがあります。

それでもプロジェクト全体のことを考えれば、あるいは自信の評価を覆されないようにするためには要件・仕様を想定し、お客さまに提案しながら前に進めるしかありません。会社や立場は違えど、お客さまも元請けも同じプロジェクトチームの一員です。

そんな中、あなたが力を発揮することでプロジェクトが前に進むのであれば、よほどブラックな内容でない限り会社の垣根など気にせず協力するといいでしょう。

おそらくは、結果的に最もスムーズな終わり方になるからです。他人に丸投げすることしかできないSIerやマネージャーに自信の人生を委ねるよりは、はるかにマシな結果になると思います。

ただし、「チームワーク」と「馴れ合い」は違います。

馴れ合いはただの仲良しごっこであり、既にビジネスですらありません。後々お客さまに迷惑がかからないよう、常に責任の所在だけは明らかにしてください。

これを疎かにすると、ただただすべての責任を押し付けられるだけになってしまいかねません。そうなったら正直、依頼してきた人って『何のために存在してんの？』ってことになってしまいますよね。わざわざいない方が、余計なマージンを抜き取られる必要もなく、お客さまにとっても都合がいいはずです。

具体的な例として、「ドキュメント作成」作業の塊を丸投げされた場合の対応方法を考えてみましょう。

「ドキュメント作成」作業の塊を丸投げされた時点で、少なくとも次のようなことがわかってきます。

　「逃げたんだなぁ…逃げてなかったら、うちに来ないもんなぁ」
　「そういうことしてるから逃げられたんだろうなぁ…
　　逃げたくなるような客なのかぁ」
　「翻って、このお客さまはこちらが上手く回さないと
　　失敗するお客さまなんだなぁ…たぶん」

たとえば、ソフトウェア開発の世界では、システムのリプレース（再構築）案件を請け負った場合に、「既存システムのドキュメント」と「今回はこうしたい」という簡単なメモだけを渡されて「あとは宜しく」的な雰囲気に流されてしまうことがあります。もちろん、不明点はヒアリングする機会を作ってはもらいます。けれども、お客さまはもう任せた気になっているので、面倒くさそうに接してきます。場合によっては途方に暮れる瞬間ですが、それでも前に進まなくてはいけません。

次のステップに従ってドキュメントを読み込み、要件を少しずつ固めていきましょう。

　①既存ドキュメントの一覧を作成する
　②既存ドキュメントの目的や経緯を調べる
　③次に自分たちが作る「もの」にフオーカスする
　④「もの」とＩＮ／ＯＵＴを意識する
　⑤説明ドキュメントを書く
　⑥シナリオを具体的に書きながら検証する

こう言う時こそ、悩む暇、途方に暮れている暇があったら、まずは情報整理です。ポイントは整理した情報の「見える化」ならぬ「見せる化」です。こちらから積極的に成果を示し、説明しましょう。

　「内容拝見させていただきました。
　　一度、弊社の理解が正しいかどうかについて確認いたしたいのですが、
　　ご説明する場をいただいてもよろしいでしょうか。」

丸投げされてしまったとはいえ、お客さまには要所で確認を行います。
あとになればなるほど、思い違いからの復旧コストが高くなるからです。

「後で確認すればいいや」なら、まだマシな方です。
「これは〇〇なはず」と言う思い込みのまま確認もしないで進めるようであれば、目も当てられません。

①既存ドキュメントの一覧を作成する

まずは既存ドキュメントの一覧表を作ります。
現在持ちうるリソースをすべて把握するためです。

この一覧が当面必要となる作業のベースとなりますので、メンバー全員がアクセスしやすい場所に配置し、こまめに保守します。

もしも余裕があれば、それらの関係性などを整理しておくと良いでしょう。成果物E-R（Entity-relationship）を明確にすれば、それぞれの依存関係も把握でき、修正を加えた際に、影響して同じく修正しなければならないドキュメント群も抜け・漏れが起きません。

たとえば、私なら一覧とは別に、こんな感じでざっくりと整理するでしょうか（工程が先に進めば、もっと詳細化していくと思いますが）。

②既存ドキュメントの目的や経緯を調べる

次に各ドキュメントの目的を調べます。

ドキュメントの目的とは、言い換えれば作り手の意図です。本来ならドキュメントの様式や立ち位置そのものに意図があるのですが、それとは別に作り手の立場を想像しながら、どのようにして作成してきたのか読み解いていきます。

ドキュメント間の関係性や様式に目的が明示されていればいいのですが、そうでない場合は中身を読み込みます。量が多い場合は「見出し」に注目してください。書籍でもそうですが、目次や見出しには、その文書の概要がまとめられています。具体的なことがわからなくても、「結論として何が言いたいか」は察しやすくなっているはずです。

調べてわかった「目的」は①で作成した"ドキュメントー覧"に追記していきます。目的が入った一覧があると、ドキュメントへのアクセスが早くなります。

③自分たちが作る「もの」にフォーカスする

いくら丸投げとはいっても、自分たちのチームが何を作るのかは契約時点である程度は決まっているはずです。自分たちが期待されている部分にグッとフォーカスし、ドキュメントを読み込みます。

この作業の目的は作る「もの」が何なのか把握することです（コンセプト実証や研究開発プロジェクトでは、開発対象が具体的に決まっていない場合もあるのです）。

特に複数の開発チーム（やマルチベンダ)での開発を行う場合、他のチーム（や会社）との役割分担をはっきりと意識しなくてはいけません。そのためにも、まず「自分たちが期待されていること」に深くフォーカスし、次にシステムの全体像と他チームとの関わりを理解していきます。

④｢モノ」とIN/OUTを意識する

「モノ」…すなわち中間成果物の具体像は、最終成果物となるソフトウェアやシステムの特性によってまちまちです。ある機能を実現するコンポーネント（部品）だったり、画面や帳票といったユーザインタフェースだったり、あるいはデータベースかもしれません。

いずれにせよ、「モノ（Object）」として区別できることが重要です。

そしてこれらの「モノ」のインタフェース、つまりＩＮ（入力）とＯＵＴ(出力）がなんであるかを見つけ出しましょう。

画面や帳票など、人間が直接使うものの入出力項目はわかりやすいのですが、プログラム同士が連携するような場合は、そのＩＮとＯＵＴがわかりにくい場合があります。

たとえば、画面設計書（画面定義書）と呼ばれているものは、次のように

　・概要
　・レイアウト
　・項目定義
　・イベント定義

と言った情報が記載されていることが多いと思います。

こうしたドキュメントの場合は、「画面名」「画面ID」と言ったものをキーにして、上位のドキュメント（要件定義書やワークフロー図等）のニーズを叶えるためのレイアウトになっているはずです。項目群は、先にデータ構成が決まっていれば、その情報をインプットとして定義されているはずです。

イベント定義は、ワークフローなどを元にして、具体的にソフトウェア（プログラム）の挙動を説明したものになっています。このプログラム動作前と後の状態を具体的に記載することで、「実際にプログラムとして動かしたい命令」の内容がわかってくるようになっています。

このように「もの」とＩＮ／ＯＵＴを数珠つなぎしていくことで、理解の範囲を広げていきます。１点を深堀し、それを中心に徐々に広げていく感覚です。ジグソーパズルでいえば、１つピースの位置が決まれば、そこから広げていくのに似ています。

⑤説明ドキュメントを書く

ドキュメントは読むだけでなく、書くことで、作成者自身もより深く理解できます。人の記憶や理解は、１つだけの知覚に頼らず、複数用いることでより大きな効果をもたらします。

プレゼンなどで、話をする（聴覚に訴えかける）だけでなく、プロジェクター（視覚でも訴求する）も使うのは、そのためです。１つの感覚だけに頼らず、複数の感覚を活用することで、スッと頭の中に入りやすくなるのは、なにも聞く人（見る人）だけとは限りません。書く人も、「書く（触覚）」「見る（視覚）」「他人に説明することで自分の耳にも入る（聴覚）」と言った効果を得ることが可能になります。

一般的に、「教わる側より、教える側の方が成長しやすい」のはそのためです。

ここまでの作業を通じて自分が理解したことを、説明用のドキュメントとして書き残しておきましょう。書く際は、別にExcelやWordである必要はありません。Wikiのようなコラボレーションツールを活用してもいいでしょう。説明ドキュメントは納品物ではありませんから体裁にこだわる必要はありません。

説明ドキュメントの基本フォーマットは次の３つです。

　・一覧（またはマトリクス）
　・図解
　・Q&A

まず説明したいものを一覧にまとめ、ポイントを図解しながら説明します｡Wikiを使うのであれば、ハイパーリンクを使い既存のドキュメントや図を活かします。そして、自分では解決できない部分はQ&Aの形式でまとめると、お客さまやほかの開発者に確認するときに便利です。

⑥シナリオを具体的に書きながら検証する

ここまでの作業で、「具体的に何を作るか」を固めました。
次にそれがお客さまの狙いとマッチしているかどうか検証します。

検証では、具体的なシナリオを中心に行います。

業務システムであれば、正常系／異常系など業務のシナリオをいくつも検討し、自分たちが作るものが期待どおり動作する（と思われている）ことがすべて記載されているかを確認します。組込みシステムであれば、さらにハードウェアの状態の組み合わせも検討しなくてはいけません。

要は自分が開発するものを、利用者や他システムなど、外からの視点で静的に検証するということです。

この作業は繰り返す必要があります。
シナリオは１本ずつ検証し、都度お客さまに確認してもらいましょう。

また、要件がなかなか決まらずに、作業が停滞してしまうことがあります。

仮にお客さまの都合であっても、そのせいでスケジュールが延長される…なんてことは稀で、そのまま放置していると、必ずと言っていいほど後々揉める種になりかねません。

この「待ち」は、自分たちの貯金を食いつぶしているのと同義です。揉める揉めないに関わらず、早々に解決しておかなくては、結果的に自身の人生に大きな傷を作ることになります。

このような状況のとき、

　「悪いのは要件を決められないお客さまだ。
　　どうせ責任はこちらにはないんだから、むしろ楽でいい」

と考えるか、

　「支払われたコストに見合う価値が示せていない」

と考えるかで、サービスの質に決定的な差がつきます。みなさんが会社から一歩出て、一般消費者の立場になった時、ほかのサービス業に対して期待するのと同じように、ビジネスの場においてはお客さまもあなたにコストに見合った価値と満足感を期待しています。仮にお客さま都合で待たされているとしても、です。

たとえば、美容院に行って髪形に迷ったとき、サービスの質が高い店はいろいろと提案してくれます。それでも決まらなかったら、「決まったら教えてください」と言って他の作業をしながら待ってくれたりもします。

「早く決めてください」などという店には行きたくないですよね。

それと同じことです。

できる作業は可能な限り先に進め、積極的に作業を巻き取ってください。

お客さまが要件定義に集中できるようサポートすることは、結果的にプロジェクトの成功に貢献します。たとえば、「技術的な調査」は「要件の抽出」とは別に進めることもできるはずですからね。