（改行）

リスク管理には手順がある

リスク管理とはプロジェクトの成功のめに危険（リスク）を管理（マネジメント）することです。

リスクを管理することなんてできるのか？といわれそうですが、早く見つけて早めに対処していくことがプロジェクトを成功させるためには必要です。

ところが、多くのプロジェクトではそのリスク管理ができていません。

たいがいのプロジェクトマネージャは問題なく進むと信じていますし、リスクを管理するというよりは、問題が表面化してはじめてことの大きさに気づくことも少なくありません。

チーム内やプロジェクトの進捗の報告を読む人にリスクに対する感度の高い人がいればいいのですが、そうでなければ問題が大きくなるまで気づかないという致命的な問題になることもあります。

リスクマネジメントは難しく、結局現場やそれを見守るマネージャの力量に任されるというのが現実です。

リスクは早期発見・早期対策

病気と同じで、プロジェクトのリスクは「早期発見・早期対策」が重要です。

僕が関わっていたプロジェクトでは、その「早期発見・早期対策」ができずに大炎上してしまったことがあります。

新規のプロジェクトを率いていたチームリーダーは、他部門と仕様調整に難航し当初考えていたような計画では進んでいませんでした。

その辺りの問題を含め、「順調ではない」ことをたびたびアラートとして発していました。

しかし、なぜかプロジェクトマネージャはその問題を「そんなに大きな問題じゃない」と高をくくっていたせいで、何の対処も行われないまま数ヶ月が過ぎてしまいました。

僕は周りから見ていて新規のプロジェクトにしては人の割り当ても少ないので、「大丈夫ですか？手伝いますよ」とそのプロマネに進言していたものの、「大丈夫だ」ということで済まされていました。

しかし、数ヶ月経ってテストを開始する頃、問題は発覚します。

仕様通りに作られていない箇所がどんどん発見され、バグとして登録されたのですが、まさにバグの山。

しかも一つ一つは他部門との仕様調整が必要なものが多く、修正にはとても時間がかかります。

そして、とてもテスト期間内には修正できないような量になり、その後大量の人を投入して仕様の調整やバグ潰しをしました。

結果的に、半年以上の大幅遅れで導入となりました。

この問題は「早期発見・早期対策」で完全に解決できる規模のものではなかったかもしれませんが、早く着手すればもっと小規模な炎上で済んだかもしれません。

プロジェクトマネージャの判断ひとつがプロジェクトを大炎上させることもあります。

リスクはあらかじめ出しておく

リスクは何かその後のプロジェクトの進捗に影響を与えそうだとかなえたとき、早めにアラートを出す、ということがとても重要になります。

ところが、それぞれ経験によって同じことに直面しても大きな問題と感じなかったり、そもそも問題と感じなかったり、自分の中で何とか片付けたいという気持ちが起きてしまいます。

そうならないように、まずはこういうことが大きな問題につながる可能性がある、ということをチームメンバーで共有しておく必要があります。

そうすることで「これってリスクに関係するかな？」というような考えが出ることで、早めにアラートが出ることにつながる期待があります。

リスクに関しては具体的なもので、かつそれが起きたときにどういう対処があり得るか、誰に相談すべきか、といったことを決めます。

まずはリスクを見える化しておくということが有効でしょう。

とはいえ、それがうまく機能するかはそれをうまく活用できるか、ということに関係します。

リスク管理を機能させる

リスク管理をしている会社であっても、そのリスクとして挙げるものがあまり起こりえないものだったり、簡単に思いつくものであることも少なくありません。

確かに、「リスクを挙げよう」と検討を始めても、なかなか適切なものが挙げられないことも多いのが現実です。

リスク何がリスクなのかをわかっていなければ、問題が発生しても担当者が解決すべきことと思うかもしれません。

出てきたリスクは、まずは優先順位を決めて管理していくことです。

管理するためには、継続的にレビューをしていくことが欠かせません。

一定の間隔で見ていくことで、リスクマネジメントしていないことに気づくことがあります。

プロジェクトの進行中は、ついついプロジェクトを進めることばかりに目が行き、リスク管理を忘れがちになります。

また、プロジェクトが進行することで、初期の頃にはぼやっとしていたリスクがもっと具体的に見えてきたり優先順位が変わったり、あるいは別のリスクが浮上していることに気づくこともあります。

プロジェクトの実情に合わせて、リスクの優先順位を変えたり、リスクをより具体的なものに絞り込んだり、あるいは新たなものを追加して改めて見直すことが有効でしょう。

仮説を立ててスピードアップする

ある商品やサービスの企画をより売れるものにするためにマーケティング調査をするとき、ただ漠然とこの商品を買ってくれるかと人に聞いて回っていたのでは、なかなか正しい答えは得られません。

その商品やサービスが使う対象を明確にして、そのゾーンにいる人に聞いていくことでより速く答えに近づきます。

仮に40代に売りたい商品があったとして、30代の人にどれだけ聞いても「いらないかも」と言われる可能性があります。

働く主婦を対象にしている商品なのに、専業主婦に聞いても答えは違います。

40代の働く主婦という対象ゾーンにいる人に聞いてはじめて、「ここがイマイチなので使いにくそう」とか「こういう人が使うかも」というヒントが得られます。

実際はもっと細かく対象を絞り込むことが多いです。

「子育てしている」こと人を対象にするなら、そういう条件も入れることです。

欲しいと思ってくれるだろう人という仮説を立てて、検証していくということです。

ニーズ調査を聞ける人に聞くという失敗

以前社内でスマホアプリの企画をしていて、こういうニーズは本当にあるかな？？ということを調べようということになりました。

そのときある人が「私の知り合いに聞いてみますよ」と言います。

それはいいね！とは思ったのですが、その人がどういう人か、ということが気になりました。

よくよく聞いてみると、「電車の中で使ってほしい」ニーズなのに、その人は電車に乗らずに通勤している人でした。

つまりその人は企画しているスマホアプリの利用対象者ではない訳です。

そういう人に聞いても、その人は「電車で通勤する人の気持ちになって」答えるわけです。

それだと欲しい答えは得られません。

実際に電車通勤している人から見ると、ぎゅうぎゅう詰めでスマホを開く隙間がないかもしれないし、毎日語学の勉強をしているから他のことはやらないかもしれません。

正しい対象者に聞くことが大事になります。

その人が「知り合いに聞いてみます」と言ったその姿勢は悪いことではないのですが、「知り合い」というお手軽さに惹かれてはいけません。

対象者選びは仮説検証の中では非常に大事なことになります。

自分も大事な対象者である

ニーズの検討をするときに起こりがちなこととして、「対象者は他にいる」と考えることです。

先日、あるチラシを配る際に読みたい内容を考えようというとき、「対象読者にアンケートを採りましょう」という話が出ました。

ところが、僕はすごく違和感を感じました。

なぜなら、そのチラシは自分たちも長年読み手だったからです。

わざわざその読み手を探して聞くのではなく、自分に聞けばわかることもある訳です。

そうすると、まずは自分の気持ちに聞いてみる。「どんな情報だと嬉しいか？」

ニーズに対して最も答えを聞きやすいのは、何より「自分」です。

自分の気持ちに聞いてみることは忘れてはなりません。

何かニーズ調査をする際、誰か他に聞かなければならないと思うことは少なくないと思いますが、まずは自分の心に聞くことが大事です。

仮説を立て自分で検証するコツ

仮説を立てて検証する際に、誰かに聞く前に自分はどうかと考えるようにすれば、人に聞くより格段に早く答えが得られます。

ところが、自分で考えるとどうしても偏りがあります。

そのサービスに対する思いやりが強くなるなど、第三者的な目線で見られない可能性もあります。

そのときは、自分の過去の経験と照らし合わせることがひとつ客観的に見る方法になります。

そのサービスが提供しようとしている価値が起こる場面は、過去に自分はどのように解決してきたかを振り返ります。

サービスがあったら使うか、ではなく、そのサービスがなかったときに自分はどうしていたか？です。

こういうことをしたいけれど、いいサービスがないので「まぁいいか」となってしまったなら不必要なサービスかもしれません。

反対に、いいサービスがないけれど、自分の力で時間をかけて何とか解決したのだとすると、少なくとも自分にはニーズがあったと言えるでしょう。

次の段落の画像を入れる

まとめ

仮説を立てて、対象ユーザーに聞いていくことでより速く答えを得ることができるようになります。

そして、その対象ユーザーに自分が入れば、他人に聞くよりももっと早く答えが得られます。

自分も対象ユーザーとして仮説検証に加わるようにしましょう。

それがニーズ検証ではとても有効になります。

計画の甘さがプロジェクトを遅延させる

プロジェクトマネージャであれ、チームリーダーであれ、担当者であれ、必ず計画を出す必要に迫られます。

計画とは、いつまでにどのようなステップを踏んで目的とする仕事を実現できるのか、ということです。

そのポジションに就いてからの時間が短い場合、経験値がないために見積が甘くなりがちです。

甘くなるとは、できあがりまでの細かいステップを考えずにだいたいの感覚で出してしまうことです。

一人一人の担当者が現実味のある計画を出さなければ、それを積み上げた全体の計画も不確かになります。

そして、実現までの大変さが見極められていないため、仕事の着手が遅めになってしまったり、仕事に着手しても楽に進むと思っていたり、予期せぬ問題に遭遇して立ち往生してしまうことも発生します。

つまり、計画が甘ければ、その後の仕事の進捗にも影響を与え、結果として計画通り進まないことになり、残業でカバーしたり最悪計画変更しなければならない事態に陥ってしまいます。

現実に即した計画を立てるためにはどうしたらいいのでしょうか？

プロジェクト成功のキーポイントを見極める

確かに計画を立てるのは難しい。ついついざっくりと期間だけを考えがちです。

「この仕様なら、○○ヶ月ですかね。」

といった具合です。

この計画の背景に緻密な計算があればいいのですが、そうではなくて感覚的に答えるケースも少なくなく、それが上に書いたような大きな問題になります。

緻密な計算とは何かというと、この仕様を実現するために「何をどのように解決して実現するか？」ということを見通すことです。

こういう技術を使ってこのように実現できそうだ、という仮説を立てたら、本当に実現できるのかを見極めます。

自分がすでに実現性がわかっていることは問題ないですが、そうではない新しい技術やサービスを使うのであれば、本当にやりたいことができるのか？ということを調べることです。

そのひと手間をかけるかどうかが大きな差を生みます。

技術検証も緻密にやる

新しい技術やサービスを使って事前に実現性を検証するとき、機能の一覧で確認するとか、少しサービスをかじってみる程度では不足です。

実際にやりたいことを実現してみる、という姿勢が必要です。

なぜかというと、プロジェクトを進めていって技術的な課題にぶち当たるとき、「事前に調べてできると思ったんだが、実現したい機能には適さなかった」ということが見つかるケースが少なくないからです。

つまり、実現性を検証する場合も、できるだけ現実で必要とされる機能が達成できることを確かめることが必要です。

「いやいや、そこまでやるのは無理でしょう？」

という声も聞こえてきそうですが、そこまでやるかどうかが成否の分かれ目です。

見積で8割の仕事を終わらせる

多くのプロジェクトの成否は、事前に問題箇所を把握して解決策を考えているかどうか、ということに尽きます。

もちろん、新たな技術開発やブレークスルーがないと実現できないプロジェクトがありますので、すべてのプロジェクトとは言いませんが、既存技術の組み合わせでやろうとするほとんどのプロジェクトでは、問題点を事前に解決できているか、で成否が決まります。

このことは、中嶋聡さんが書かれた「なぜ、あなたの仕事は終わらないのか」という著書に書かれていて、僕も非常に共感して読みました。

計画段階で実現すべきことの8割はできあがっている、ということです。

つまり、できない問題はないことがあらかじめ見通せている状態です。

だからこそ「いつまでにできます」と自信を持って言えるようになります。

残りの2割の仕上げを時間をかけてやるということです。

こうなれば失敗はないのです。

ぜひ中島さんの著作を読んでいただけると得られるものは多いと思います。

自分にとっての課題をクリアする

若かりし頃、勘に頼った見積を出し、実際に進めるとさまざまな課題にぶち当たって計画がどんどん遅れていました。

まさに出たとこ勝負の開発をしていました。

そんな開発をしていたのでは計画通りに行くはずもありませんし、自信のある発言もできるはずもないのです。

周りができると言っているからとか、枯れた技術を使うから大丈夫、ということではなく、自分にとっての課題をクリアしておくことが大事です。

他の人はすでにそのスキルをマスターしているかもしれません。

ところが、自分にそのスキルがないなら身につけないといけません。

経験値がないなら、その分事前に経験してみることが必要です。

自分に与えられた仕事に対して、不明な部分があるならなるはや着手して解決しておく、その姿勢が自分を助けることになります。

見積で成否の8割が決まる

残念なことに多くのエンジニアは炎上プロジェクトに遭遇しているのではないでしょうか？

そうでなければ、プロジェクトマネジメントの重要性を問われることはないし、そのためのスキルに関する書籍も多く存在しないのではないかと思います。

プロジェクトとはある目的を達成するための計画や業務のことです。

定型のものではないため、一つ一つ課題やリスクが違いますので、同じ方法で解決できるものがありません。

だからこそ、必ずしも成功させることができず、時に炎上することもあります。

いくつかの炎上プロジェクトを経験した僕の目からは、「炎上プロジェクトは最初から負け戦であることが多い」と実感しています。

ゴールが不明確、期間が短い、人員が足りない、予算が足りない、などなど、経営の思惑や営業の思惑などの事情により、最初からリスク含みで始めるから炎上するのだ、と思います。

そのために、エンジニアができることは見積精度を高めて、必要なリソース（期間・人員・予算等）を確保して始めることが求められます。

ざっくり見積の恐怖

見積で出した期間や人員、費用は、プロジェクトの基礎となりますので、ここを間違えればすべて狂います。

よくあるのは、これからプロジェクトを実施するのにどのくらい期間と予算が必要か見積もってほしいと言われて作るものです。

しかも、なぜか数日で作ってくれというものが多く、「ざっくり」作るしかなくなります。

これが「ざっくり見積」です。

よくあるざっくり見積は、実際の作業内容を十分に把握せずに、1ヶ月何人ほど必要で、それがだいたい半年・1年・2年などといった期間で総工数を把握するだけのものです。

ところが、「ざっくり」だと言うことを伝えているにもかかわらず、それがあたかも正式な見積であるかのように、実際の計画にそのまま入っていくことが多いです。

ざっくり見積もったはずが、その条件でプロジェクトが承認される結果、プロジェクトの期間や予算が使われてしまっています。これは本当に恐ろしいことです。

ですので、ざっくりとした数値を出すにしても、できる限りプロジェクトの仕様や難易度、どんな人が必要かなどをできる限り詳細を調べて見積もる必要があります。

見積時の条件と変わってしまう

開発チームが見積をするとき、具体的ではない仕様のことがほとんどですので、情報不足の中で見積もる必要があることは少なくありません。

プロジェクトの内容を理解するための情報は多くなく「○○を実現する」のような標語程度の目的のこともあります。

その場合、「○○」とはどういうことか？「こういうことではないか」といろいろ想像しながら進めます。

それならこのくらいの難易度だからこのくらいの人数と期間が必要ではないか、というようなことを少しずつ決めていきます。

怖いのは実際にプロジェクトが始まると、そういった前提条件が全く崩れてしまうケースがあります。

どんなプロジェクトも、見積時と実行時で差があるのは当たり前ですが、根底から崩れることもないわけではありません。

「いまさらそんなことをいわれても･･･」といいたい状況になりますが、四方を固められてにっちもさっちもいかないことも多いです。

そうなるとひたすら納期に間に合うように死ぬ気でやるしかない状況に追い込まれます。

エンジニアの悲哀

炎上プロジェクトは関わっているエンジニアの進め方に問題がある場合もありますが、開発チームの力を超えていたり、顧客が作りたいものと見積が合っていないなど、プロジェクトの開始前から問題がある場合も少なくない。

このような場合、どんなに現場ががんばっても成功することはできず、いわば最初から負け戦なのです。

こういうプロジェクトに関わるエンジニアは本当につらいだけで楽しいことは全くありません。

こんな時、本当に割に合わない仕事だと思います。

だけど、エンジニアはがんばるんですね。本当に悲しいくらい真面目です。

どうやって防ぐか？

何とかそんなつまらないプロジェクトにしないためには、まずはプロジェクトのゴールと現実に実現できる計画の差をなくすことが求められます。

両者にズレが起きる責任の多くが、プロジェクトが始まる前のざっくり見積にあると僕は考えています。

上層部だけで考えた見積や、時間がないから急げと言われて要求もはっきりしないまま出す見積もりほど怖いものはありません。

見積を出すからには、条件を明確にしできる限り積み上げること。

そして条件が変わったのなら見積も変わることを明確に伝えて、その条件が変わったときには見積も変えられるようにしておくことです。

そして、納期を間違っても「○○年△月」のように実際の日付で書かないことです。

着手開始から「○○ヶ月」のように、開始日によって完成日も変わるように書くことです。

このように自分たちを守る手段はあります。

自分たちを守れるように条件を明確にして見積を出しましょう。

仕様変更を管理する重要性

仕様変更とは、もともと「こういう動作にしよう」と決めていたものをある理由によって変更しなければならなくなることを言います。

ところが、仕様変更をきちんと管理して関係者に共有しておかないと、例えば次のような問題が起こりえます。

• 仕様変更が影響する箇所を見落とし矛盾が起きる
• テストをする人が仕様変更を知らずテストされない
• マニュアルを書く人が変更に気づかず、マニュアルに反映されない

仕様変更を例えばメールや会議などで連絡しても、周知されないことも発生します。

特に開発途中の場合、あとでまた変わるでしょ」と思われてあまり真剣に受け取られなかったりすることもあるからです。

テストを担当する人から見れば、「どのバージョンからその仕様変更がされたか」ということも大事になります。

ですから、後できちんと追跡できるように、開発チームとして仕様変更をきちんと管理し、履歴を残しておくことはとても重要な仕事になります。

なぜ仕様変更は発生するのか？

そもそも仕様変更はどうして起きてしまうのでしょうか？

ありがちなのが、要求そのものが変わったり、あっちとこっちで仕様の矛盾が発覚したり、いざできあがってみると使い勝手が悪かったりということを解消するために起こります。

要求の変更とは、「こういう風にしてほしい」と要望を出した側が変更することです。

• 開発に入って仕様を詳細にするために話を聞いていくと、そもそも考えていたことに間違いがあることに気づき、そのまま作っても問題があるので、要求を変更することになった。
• 納期に間に合わないなどの理由で、影響のない部分の仕様を初期段階ではカットしようと考え、それに伴い仕様が変更なった。

などがあります。

仕様の矛盾とは、

• ある機能を実現するために決めた仕様が、別の機能と相反することが発覚した

というような場合に起こります。

他にも、

• UIをこのようにしようと考えていたが、いざできてみると思ったように使いやすくはなくて改良したい。
• 実装上の都合でもともと狙っていた仕様は実現に時間がかかるので、仕様変更して納期に間に合うようにする

などもあります。

仕様変更を安易に判断してはいけない理由

仕様変更しよう！と要求されたときに、「はいわかりました」と安易に引き受けてはいけません。

あなたがプロジェクトマネージャーやチームリーダーであればなおさらです。

というのは、要求というのは常に「ある切り口から見たときに改善したいこと」でありますが、別の局面から見ると、改悪になるようなこともあります。

そういうことは、違う部門で目線が全く異なる人から出ることが多いからです。

例えば、

• こういう操作にした方が使いやすい、このような表現がわかりやすい、と思っていたが、全く別の使い方を考えたらかえって使い勝手が悪くなったり、ユーザーに誤解を与えることがわかった
• 期間短縮しようと機能を落とそうとしたら、かえって修正に時間がかかり納期が遅れる
• ユーザーの利便性は上がる機能だが、セキュリティリスクが上がるため情報システム部から反対された

などです。

一面だけしか見ずに仕様変更を判断していたら、後々大きな問題になることもあります。

仕様変更は関係者が集まって判断する

仕様変更は、当初に仕様を決めたときより重い判断が求められることがあります。

上に書いた例のように、納期に間に合わなくなるとか、セキュリティリスクが新たに発覚するとなると、かえって問題が大きくなるからです。

その割に緊急度が高く、すぐに判断しなければならないことがあるとなおさらです。

開発の側から見れば小さな変更にしか見えないことも、別の立場から見れば大きいものですし、小さな変更と思われるような機能が実装上は大きな変更を伴うこともあります。

そんなことがありますので、仕様変更をするかどうかを考えるときは、関係する部門の人を集めて協議するなど、広い視点で確認することが欠かせません。

そういう多方面の分野の人の目で判断することが確実な商品開発につながります。

まとめ

仕様変更はいろいろなタイミングで要望されます。

要求するつもりだったが入れ忘れた、仕様の問題点に気づいたなど、仕様変更したい理由はさまざまでしょうが、安易な思いで受け入れた結果、納期が遅れたり、別の問題を生むことがあります。

「このくらいの変更ならたいしたことないだろうし、何とかしてあげたい」

そういう技術者の良心もあって受け入れてしまいがちですが、グッと踏みとどまり広い視点で見ることが大事と思います。

専門用語でしか話せないようではダメ

技術者に限ったことではないが、その道の専門家でない人に専門用語でとうとうと説明する人がいます。

専門用語をしっかり説明した上ならまだしも、専門用語でしか説明できない人もいるから困ります。

特に相手が上司や部門長であっても、自分と同じ専門的理解をしているとは言えません。

ましてや別の組織の人や経営層の人に説明するのに、専門用語を使って説明しても相手には伝わりません。

いかに専門用語を使わずに説明するか、というのは日頃からやっておかないとできません。

専門用語を使うことで何を伝えたいか？

どういう言葉が専門用語でしょうか？

ソフトウエアの世界でいうと、一例ですがビルドとかバッチなどのソフトウエア開発のプロセスに関するものや、UMLであるとかJavaScript/Pythonといった名称もそうでしょう。

その道の専門家同士で話しするなら、専門用語の方が間違いはないし話しが早いので、それで良いです。

ところが、非専門家に話しをするなら、専門用語を使わずにもっとわかりやすい言葉で話すべきです。もしかすると、その用語を使った話しをする必要もないことだってあります。

大事なことは、その専門用語（あるいはそれをわかりやすくした言葉）を使うことで何を伝えたいのか？ということです。

JavaScriptを使うことが必須の条件だから、JavaScriptをバリバリ使えるエンジニアが必要だ！と訴えたいなら、JavaScriptを全面に押し出す必要があります。

ところが、これこれのシステムをこういう仕様で作ります、と説明する際に「開発言語はJavaScriptでバックエンドでもフロントエンドでも使える便利な言語で開発します」という説明をしようとするなら、この説明がそもそも必要か、ということを考えるべきです。

なぜなら、聞く人が何らかの判断をしなければいけない立場の人ならば、JavaScriptを使うということに自分はどう判断すればよいか迷うからです。

その人に判断をしてもらう必要があるなら、JavaScriptとは何でどういうメリットがあるかを説明する必要がありますし、そうでないなら説明は不要なのです。

カタカナ用語を安易に使うのは聞き手に失礼

専門用語だけではないが、経営層もすぐに旬な英語を使いたがります。

• フィジビリティ（実現性）
• アサイン（任命）
• イシュー（論点・課題）
• オルタナティブ（代替策）
• ジャストアイデア（思いつき）

などなどあげればきりがないのですが、僕は括弧内の日本語の方がはるかにわかりやすいと思っています。

なぜカタカナ用語を使うのかわからないことも多いです。

ネットの時代とはいえ、聞きながらわからない用語をスマホで検索するわけにはいかず、知ったかぶりで聞くことになります。

聞き手にそんなことをさせるのではなく、誰もがわかる言葉で話すべきだと思います。

それができないのは聞き手への配慮が足りないと思います。

専門用語をわかりやすい言葉に置き換える

専門用語をそのまま使わないようにするためには、その言葉の意味を別のわかりやすい言葉に置き換える作業が常日頃必要になります。

ソフトウエアの中でも説明しにくいのが、アーキテクチャやフレームワークなどがあります。

アーキテクチャは「ソフトウエアの論理的構造」という説明が見つかりますが、ソフトウエアにおける「論理的」というのも非専門家には理解が進まないものです。

時と場合によりますが、僕はアーキテクチャを「全体の構成」と説明することが多いです。

もう一つのフレームワークは、ビジネスでも「考える仕組み」のような意味で使われるので言葉としては浸透していますが、ソフトウエアにおけるフレームワークは機能や仕組みを持っているものを指すので、似ているけれどもビジネスで使うフレームワークの理解だと少々違うと思います。

ソフトウエア開発におけるフレームワークは、ソフトウエアを効率的に開発する仕組み、などと説明すると良さそうです。

難しい言葉を使わずに説明する事が大事

人に伝えるためには、専門用語を使わないことがいいですが、そうすることでそれ以外の部分もわかりやすくなります。

なぜかというと、どうやって専門用語を使わずに伝えるかを考えることは、ひいては説明のわかりやすさにつながるからです。

単に専門用語を少しわかりやすい日本語に置き換えたところで、それだけでは説明がわかりやすくなったとは言えないことも多いです。

専門用語を使わないでいかに伝えるか？ということを考えていくと、説明が人に伝わりやすくなります。

その人が持つ専門性を考えながらバランスよく考えていく必要はありますが、難しい言葉を使わずに伝える、これが大事です。

「やったこと」は進捗ではない

仕事に就いていれば、仕事の進捗報告は必ず求められることの一つです。

進捗報告を「作業の報告」と思っていないでしょうか？

作業の報告とは、「○○をやりました」というような報告です。その報告で問題ない仕事もあるでしょう。

ところが、納期のある仕事に携わっている場合、それは進捗報告ではありません。

進捗とは「ものごとの進み具合」をいうわけですので、進捗報告では「進み具合」がわかる必要があります。

「先週は○○のプログラミングをしました」と報告したとします。

上司は「それでうまく動いているの？」と聞きます。

それに対し「いや、実はうまく動いてなくて･･･」と回答すれば、「それはどこがどうなっているの？」「誰かに相談した？」というような質問を浴びてしまいます。

つまり上司が知りたいことは「やったこと」ではなく、「その結果、どういう状況なの？」ということなのです。

上司は問題が起こってないか知りたい

仕事は誰もが順調に進むとは言えません。

それよりも、うまく進まないことの方が多いのが現実です。

上司から見れば経験が未熟な部下の仕事が何も問題なく進むわけがないと思っています。

だけど、なかなかそこがあぶり出されてこないので、上司はちょっとした部下の言葉をきっかけにあれこれ聞いてきます。

上司はとにかく仕事が順調に進んで欲しいと思っているのですが、問題の発覚が遅れることが多く、発覚が遅れれば遅れるほどその遅れの回復に時間がかかることも知っています。

だから少しでも早く問題をあぶり出したいと思っています。

それがいろいろな質問に現れてきます。

いろいろ質問されると部下は、「細かいなぁ」「うざいなぁ」「そんなに心配なら自分でやれば？」そんなことを思ったりします。

上司が少しでも早く問題に気づき軌道修正したいのは自分の組織で遅れを出したくない思いもありますが、仕事を順調に進めるための「親心」です。

親の心子知らずの状態はすごくあることです。

遅れを隠す気持ちが全体を遅らせる

一方の部下は、仕事がうまくいっていない場合には、そのことを隠したいものです。

何とか「問題ない」ということで通り抜けたいという気持ちがあります。

自分では解決できていない問題があっても、つい「大丈夫です！自分で解決します！」と言ったりします。

何とか自分の手で解決したい、そういう思いでいるものです。

上司だって、自分の力で解決してほしいし、とても難しい問題でない場合には、本人の自主性に任せることもあります。

ところが「何とか自分で」という気持ちが問題解決を遅らせ、その遅れが問題を大きくしてしまうことがよくあります。

特に若手の時がそうです。

なぜなら、その解決がどれだけ大変かということの経験値がまだまだ少ないから、必要な時間やその解決に至るまでのプロセスを見通せていないことです。

なるべく早く相談する

問題の多くは早く手を打てば解決することが多いです。

ところが、あとで大きな問題になるとは思えずに「何とかなるさ」と担当者が思っていると、チームとして手を打つのが遅くなります。

何か仕事がうまくいっていないなら、素直に上司にそう報告した方がいいです。

若いとかそうでないかに限らず、現状を話して上司の判断を仰ぐことです。

どういうことかといえば、「遅れている」「解決できていない」という問題の大きさを自分で判断しないということです。

担当者でしかない自分ではことの大きさを正しく判断できないことが多いです。

今の遅れがどれだけあとあと響いてくるのかわからないです。

ですから、上司が示した納期に間に合わないと思われるなら、なるべく早く上司に相談することです。

どのくらい早くとは、「なるはや」ということになります。

その問題の解決にどのくらい時間がかかるかわからない以上、どれだけ遅れても大丈夫かわかりません。

だから、問題が解決できないとわかったら、「なるはや」で相談しましょう。

進捗報告で話すべきこと

「なるはや」で相談といってもついつい遅くなってしまうのが人情です。

今週は時間が取れなかったけど、来週時間が取れればすぐにリカバリーできる、などと思うものです。

ところが、来週には来週の仕事があり、またもや思ったように作業できないこともあります。

上にも書いたとおり自分で判断せず、上司に判断してもらうことが大事です。

そのためには「現状を適切に伝える」ことが必要です。

進捗報告が毎週行われているなら、そのときに「現状を適切に伝える」のです。

そうすることで「なるはや」の相談ができることになります。

「現状を適切に伝える」とは、大まかにいってこのようなことです。

• 求められている計画（ゴールとなる納期）
• 自分の担当分として何をいつまでにどうしようと思っている（ゴールまでの作業を細分化した自分の中の計画）
• それに対してどこまでできていて、何ができていないか（進捗）

そもそも自分の中の計画が甘い、ということも往々にしてあります。

上司から見たら、「その計画じゃ、後工程で問題が起きる」と考えるかもしれませんし、「何かあったときにリカバリが効かない」という不安を感じるかもしれません。

ですので、進捗報告でしっかりと報告すれば、その報告は同時にとても良い相談の機会となるのです。

適切な進捗報告が自分を救う

進捗報告して遅れがあると、上司から遅れを指摘されたり、大目玉を食らうこともあるでしょう。

ですが、それは自分が所属する課やグループの極めてローカルな問題で終わります。

上司だって、自分のチーム内の小さな問題で終われば幸せです。

ところが、遅れが取り戻せないような状態になると、部門長に相談したり、下手をすると別の部門に相談したりなど大きなことになりかねません。

ですので、いかに早く上司に相談し、小さな問題のうちに解消しておくか、それが大事になってきます。

その一番重要な相談が「進捗報告」です。

進捗報告が自分を救ってくれると思って、きちんと報告するようにしましょう。

開発工程を知らないと大問題に！

過去のプロジェクトで製品の最終段階で基本的な機能にバグがあることに気づきました。

全員真っ青です。

なぜ？今さらこんなバグが見つかるんだ？？

基本機能だから十分にテストをしているはずですから、そんなバグが見つかるということは「テストの網羅性が足りないのか」「テストの実施方法が良くなかったのか」というようなことが取り沙汰されます。

ところが、そのバグが混入した原因を調べた結果、「直前のテストではその機能に全く問題がなかった」ということがわかりました。

ではなぜそのバグが今起きているのか？

その機能を担当しているプログラマーに話を聞いたところ、「ソースコードに気になることがあり、よかれと思って直した」、という発言をしました。

開発の初期の頃ならともかく、テストも積み重ねた終盤に不用意な修正をし、しかもその修正が既存機能に影響しないかを十分にテストしていませんでした。

彼はプロジェクトリーダーから大目玉を食らって、ソースコードを直前のバージョンに戻しました。

プロジェクトの終盤のバグ修正は慎重に

よかれと思って直した行為がなぜ叱られる羽目になったのか？

プロジェクトの終盤、特に市場に出す直前当たりではバグの修正は慎重に行わないといけないからです。

バグを直す、すなわちソースコードに手を入れるということは、その修正が影響する範囲のテストをやり直す必要があります。

プロジェクトの終盤までには綿密にテストを積み重ねてきているので、ソフトウエアの修正をするとなればその修正がどこにどんな影響があり、どの範囲のテストをやり直す必要があるかを洗い出すし、それらに問題がないということを確認する必要があります。

その影響範囲が大きければ、もしかすると市場に出す納期に間に合わないかもしれません。

何とか間に合わせるために、人手をかけて頑張るしかないかもしれません。

そういった大きな問題になりかねないのです。

だからこそ簡単には直せないのです。

100%動作するコードもテストで検証が必要

残念ながら、「プログラマが絶対大丈夫」という言葉をそのまま信用してもらうことはできません。プログラマが100%動作すると確信を持っているプログラムであっても、テストによって問題ないと確認されない限り、OKは出ないです。

プログラムの初学の頃は、コードを教科書通り書いても思ったように動作せず、バグの原因を見つけるのに四苦八苦することがあります。

小さいコードですら、そうです。

熟練になってある程度の規模のコードを書くようになると、その部分だけ正しくても、他の部分と連携したときに正常に動作しないことも起きてきます。

こういうことは、プログラムのコードを見ているだけではわからず、動作させて検証する必要があります。

簡単な修正のはずなのに、プログラマのテスト不足で一発では期待通り動作しなかったことは、僕の経験でも多々あります。

だからこそ、必ず動かして検証することが必ず必要です。僕も動かして検証することが当たり前になっています。

ましてやテストが不十分なコードほど信用できないものはありません。

コード修正していいとき・悪いときを知る

すごく雑な言い方をすれば、開発の初期であればコードの修正はどんどん行っても問題ないです。

ところが、一旦テスト工程が始まって以降は話は簡単ではなくなります。

企業によって違いはあれど、テスト工程に入ってからのバグの管理は厳密になります。

というより、バグは厳密に管理しなければなりません。

どんなバグが発見され、それはどのような問題で直すべきかどうかが判断され、修正すべきものはどのように修正され、最終的にテスト工程で修正が確認される必要があります。

そしてバグの収束状況などを判断の上、次工程に進んで良いかが決まっていく。

バグには「実装のバグ」というプログラマの実装による問題のものもあるし、「仕様の誤解」などの問題もあります。

これらはプログラマが原因のものですが、もっと別の「バグ」が見つかることもあります。

それは「仕様バグ」というようなもので、仕様の間違いや仕様の矛盾に起因するものです。

これらはソースコードの実装を直す前に、仕様を考える必要があります。

バグの管理はソフトウエアの品質を知る上で重要

ソフトを仕様通りに作ったのに、予期せぬ動作になることがあります。

ソフトとしては仕様通りに動作しているのに、あるケースでは期待通りではない、というような場合です。それは仕様の矛盾であったり、仕様の間違いなどが原因で「仕様バグ」と呼ばれるものです。

仕様バグの場合、仕様をどのようにすべきかをまず考える必要があるので、要求元に確認しないと決められないこともあり、かえって時間がかかることもあります。

仕様だからすぐに解決できるかと思いきや、ある仕様の矛盾を解決しようとすると、別の仕様との不整合の問題が発生するなど、一筋縄でいかないことが多いです。

そういう問題もあるので、テスト工程に入ってからのバグは要求者などの関係者を含めた議論が必要になることも多いので、きちんと管理していくことが必要になります。

こういうこともあり、バグを記録し、原因がどうで、どういう風に対処し、最終的にどうやって確認したか、ということを管理していくことが欠かせません。

これがソフトウエアの品質を上げるためにも欠かせない作業です。

そういったバグ管理が必要になり、後工程になるほど一つのバグが直って確認されるまでに時間がかかることになります。

ソフトウエアエンジニアとしては、早い段階でしっかりと品質を作り込む意識でやることが大事です。あとに回せば回すほど自分の首が絞まります。

要求と要件の違い

開発工程を知ろう！ということで始まった第1回目に続き、今回は2回目です。

開発工程は大きく次のようになっているという話をしました。

1. 要求獲得
2. 要件定義
3. 詳細設計
4. プログラミング
5. 単体テスト
6. 結合テスト
7. 運用テスト

この中で大事なのは要求獲得の段階にあります。

何はともあれ、顧客の要望を知ることが大事だということです。

さて、顧客の要求を知ることができたら、次はそれを実現するステップになります。

その最初が要件定義という段階です。

要求獲得と要件定義の違いは知っていますか？

要求獲得とは顧客が欲しいと考えているものを明確にすることで、「顧客」が主となり行います。

それに対し、要件定義は要求に基づき実現する「機能やコスト」などを明確にする工程で、発注されたベンダーが主となり行います。

要求：顧客が欲しいと希望しているもの。主たる関係者は「顧客」

要件：要求に基づき実現するシステムの機能等を明確にしたもの。主たる関係者は「ベンダー」

ということになります。

要件はすべて要求と紐付く

要求を要件にするとき、顧客が望んでいる「要求」を実現するためには細かな前提条件を定めていく必要があります。

例えばウェブサービスであれば、どれだけの人がアクセスする予定か、によってサーバーの規模なども変わってきます。

個人情報を扱う場合には、どんなセキュリティが必要か、ということも保存するデータの種類やどれだけ安全に守る必要があるかの考え方によって、セキュリティに関する要件も違ってきます。

そういったことは顧客が最初に話してくれることはほぼありませんので、仕様を決めていく前に聞いておく必要があります。

そして、すべての要件は顧客の要望と紐付く必要があります。

そうでなければ、顧客の要望にない「過大」なシステムを作ってしまうかもしれませんし、顧客の要望を満たさない「過小」なシステムを作ってしまうかもしれないのです。

要件を作る際、常に要求と紐付けることが大事です。

とはいえ、要求と要件は記述内容も記述量も大きな違いがあります。

というのは、要件はシステムの開発をするために必要な様々な情報を記載しないといけないからです。それを決めていくためにも、顧客から要求をしっかりと聞き出して、それを満たすシステムを作り上げるための要件にしないといけません。

できあがって顧客に引き渡す段階で、顧客から「そんなものを頼んだ覚えはない」と言われることのないように、しっかりと顧客の要求に即したものを作っていくことが何よりも大事です。

顧客への説明を尽くす

開発の最初だけでなく開発している途上では、作ろうとしているものが顧客の要求からズレていないか、ときどき要求者に確認をすることが有効です。

開発者にとっては開発物を定義した要件書はわかりやすいです。

しかし、顧客にとっては要件書は難解で、自分が欲しいものかどうかを理解することが難しいです。

これから作るものは何と問われたら、開発者であれば要件書を見せて「これです」と説明するのが正しいのですが、顧客にはもっとわかりやすい説明書が不可欠です。

Webアプリやスマホアプリであれば、こんなUIでこういう風に操作の手順を見せるとか、全体として仕事の流れがこうなってこういう風に使えます、というようなことを具体的に示すことが必要です。

説明を尽くし「それならいいね」と言ってもらっていても、できあがったときに「この部分はそういう風に思わなかった」というすれ違いはどうしても起きてしまいます。

そうならないように、顧客への説明は相手の理解を得られるように最善を尽くす必要があります。

顧客にとってはすべてが知らないことと思え

開発者なら常識と思う部分であっても、顧客は知らないことも普通です。

この辺が非常に難しいことです。

開発者にとって当たり前すぎて、つい説明が漏れてしまうことがあります。悪意ではなく、「つい」忘れてしまうことはなかなかゼロにはなりません。

顧客にとって「それは聞いていなかった」とできあがったあとで反発されることのないように、些細なことも説明する必要があります。

これはできるけれどこれはできないなどの機能的なことはもちろんですが、お金がかかる、新たな作業として行わなければならないなどのことは、「聞いてなかった」問題に発展しがちです。

スマホアプリを開発したときに、OSのバージョンアップごとに機能検証して、動作しない部分があれば追加費用を払って開発しなければならないことなどは顧客が知らない一例です。

もちろん、開発者はOSのバージョンアップに追随することの必要性は説明しますが、それをどのくらいの頻度で、どのくらいのお金がかかるかなどは顧客には全くわかりません。

どれだけ具体的に説明できるかは説明者の力量ですが、とにかく説明を尽くすという姿勢が必要です。何でもくどくど言えばいいというものではありませんが、顧客に不利益になりそうなことは特に欠かせません。

自分たちに仕事が欲しいので営業の方たちがいいことばかり先にいうケースはありがちなのですが、だからこそデメリットも正確に伝えることです。

これは顧客の満足を得るためでもありますが、自分の身をを守るためでもあります。

あとで「この部分は聞いてなかった。作り直してくれ」と言われたら、手戻りにかかるお金は自分の負担となるのです。

開発工程を学ぼう

商品開発に関わるなら、開発工程を知らないといけないです。開発工程とは、今開発のどの段階にいるのかを表したものです。

開発工程は大きくウォーターフォール型とアジャイル型があります。

ウォーターフォール型はプロジェクトのゴールが明確に決められる場合に、作るものを決めて開発工程に沿って進めるプロジェクトの推進方法です。

一方、アジャイル型は最終のゴールが決めにくいプロジェクトに適用します。作りながらゴールを決めていくようなプロジェクトに適しています。

どちらを適用すべきかはプロジェクトや会社の方針によって違いがあるでしょう。

そういった違いはあるものの、どの工程で何をすべきか、という原則は大きく変わりません。

分類や名称は違うかもしれませんが、大きく次のものがあります。

1. 要求獲得
2. 要件定義
3. 詳細設計
4. プログラミング
5. 単体テスト
6. 結合テスト
7. 運用テスト

工程ごとにやるべきことは決まっている

開発工程ごとにやるべきことは決まっています。開発を円滑に進めるためには、各工程でやるべきことを終わらせてから次の工程に移ることが必要です。

なぜかと言えば、実施すべきことができているか確認してから進めないと、あとで実施すれば計画が狂いますし、やるべきことが間違っていて直す必要があれば大きな手戻りになってしまい、開発期間が延びたり開発コストがかかってしまいます。

また、遅れを挽回するのが難しい場合、会社としては早く市場に出したいからなどの理由で、機能を落としてでも納期を早めることが必要になってくるからです。その場合でも本来の機能をあとで追加で開発するなど、新たな開発費が必要になります。

そういった手戻りにならないために最も大事なことは、「顧客の要求をつかむ」ことです。

つまり「お客さんは何をほしいと思っているか？」ということです。

それはわかった上で開発に着手するはずなのですが、実態はなかなかそうならないです。

最も大事なことは要求獲得

「お客さんが作ってほしいものをつかむ」これがなんと言っても一番大事なことです。

そんなことはわかっている！当然じゃないか！

という声が聞こえてきそうですが、実はこれが難しい。

ちゃんと顧客の言うとおり作ったはずなのに、できあがってみると「こんなものが欲しかったんじゃない」と顧客の不満が出ることはプロジェクトではよくあることです。

なぜこうなってしまうのでしょうか？

多くの原因は、それぞれの立場の人が持つ知識や経験が違うために、同じ言葉を使っていても理解が異なることにあります。

顧客は実現した結果どうなってほしいかというのは頭の中にイメージはあるでしょうが、それをどんな仕様でどんな使い勝手で実現するのかを具体的な言葉にすることはとても難しい作業になります。

実際、顧客は要求を具体的に言うことはできません。

具体的な仕様にしていくのはプロジェクトのエンジニアたちですが、顧客の要求が漠然としているといつまでたっても作ることができませんので、一つ一つ解きほぐしていきます。

顧客の悩みを知り、課題を見つけて解決策を提供することが求められるわけですが、顧客が抱える課題を正確につかむのは難しいのです。

相手はその分野で長年経験しているし、そのことに関する知識はエンジニアは持っていません。

だから相当時間をかけないと同レベルの知識に至ることができません。

ですが、現場のエンジニアは作ることがゴールなので、頑張って理解しようと試みますが、簡単には埋まりません。

それでも頑張って仕様を作り込んで具体的にすればするほど、残念ながら少しずつ顧客の要望とエンジニアの理解にずれが現れてきます。

顧客のことを100%理解するにはかなり時間を要しますので、最初の段階でずれがあるのは当たり前です。問題はどうやってずれを小さくしていくか？ということです。

顧客の要求をつかむには顧客の困りごとを知る

顧客の要求をつかむためには「何が顧客の困りごとか？」を知ることが起点になります。

何に困っているかを知らずに何を作れば良いかを考えてはなりません。

間違っても「こういうものを作ってほしい」という顧客の言葉をそのまま鵜呑みにしてはいけません。

顧客なりに困りごとを解決するものはこういうものだ、という考えがあることはわかりますが、それが本当に解決策になるかを改めて第三者の視点で考えることが必要です。

顧客は知り合いが問題を解決した方法を聞いてそれをそのまま利用すればと思ったかもしれませんし、テレビや雑誌などで聞いた方法で実現しようと考えるかもしれません。

しかし、顧客はITのプロでも開発のプロでもありません。よりよい解決方法が顧客から出るとは言えません。

本当に顧客が導入して良かったと思えるのは、自分が抱える問題を解決できたときです。

そのためには、顧客の困りごとを知ってそれを解決してあげることが欠かせません。

顧客の要求を満たしているか常に考える

顧客の要求をつかめたと思っても安心してはいけません。

仕様を考えるとき、運用方法を考えるとき、これは顧客の要求からずれていないか？ということを常に考えます。

こっちの仕様とこっちの仕様とどっちがいいのだろうか？、計画を立てるときなど、何か判断に困ったとき、顧客の要求に立ち返って考えてみると答えが見つかることがあります。

顧客が望んでいることを実現していれば小さなずれはあっても許容範囲になります。

ところが大きなところで顧客の要望を満たしていなければ、それはのちのち大問題になります。

例えばこういうことです。

• 効率化を求められたのに効率化できていない
• 人員を減らすはずだったのに、ほかのところに人員が必要になって実質減らないあるいは逆に増員になる

最終的には経営として求める成果を出せたかどうかが成否の判断条件になります。

エンジニアはついつい「作る」ことをゴールにしがちです。

もちろん、約束の納期までに必要な機能を認められたコストの中で実現することが必要です。

そのとき、必要な機能は見かけ上はいっているけど、本来期待された経営上のゴールが満たされない、ということもちょくちょく起きる問題なのです。

経営上のゴールが満たされないということは、投資対効果が期待を満たせないということになります。

これでは最悪お金が支払われない事態となります。

そういうことにならないためにも、要求をしっかりつかむ、そして適時振り返り調整する、そういう気持ちを忘れないようにしましょう。