叫ぶうさぎの悪ふざけ

うさぎが目印のWebエンジニアが、得たことや思ったことを言の葉に乗せて叫ぶ場所です。

学習記録:12月18日(火):はじめよう!要件定義 Chapter-06 [準備編]企画を確認する(つづき)

これは 俺のインプットアウトプット記録 Advent Calendar 2018 の18日目のエントリーです。

ちなみにこのエントリー、最後に盛大なポエムというか、なんというかな話が入ります。そんな話はいらんわ、って場合は飛ばしてもらえればなあと思うんですが、本題よりそっちの方をエントリーにした方がよかったんじゃないかな…と思わなくもないので、もし何か思うところがありましたらば、忌憚のないご意見をいただけたらいいなあと思います。

閑話休題

本日は約4時間の研修を受けてきて、情報が溢れ気味でございます。が、間違いなく今後の仕事の仕方を変える内容でしたし、いかに僕らが 当たり前を具現化する仕事をしている のか、そしてそれを しょっちゅう忘れて頻繁に事故を起こす のかを思い知らされました。

研修内容をそのまま公開するわけにはいかないので研修レポートは書きません(手元にはしっかり残す)が、はじめよう!要件定義、を読み進めるにあたり、研修で学んだことなどは取り入れつつアウトプットにしたいと思います。

というわけで、前回の 学習記録:12月17日(月):はじめよう!要件定義 Chapter-05 要件定義、その前に & Chapter-06 [準備編]企画を確認する に引き続き要件定義の学習を進めます。

Chapter-06 [準備編]企画を確認する

昨日はこの章の途中までで終わっていました。企画書でゴール、つまり実現したいものを確認し、実現したいものからの逆算で「UI、機能、データ」を合意して進めていくわけですが、そのゴールが曖昧だとダメで、じゃあまとめるためにどんな項目があるのか、ということで以下の項目があればいいよ、まで進みました。

  1. プロジェクトの名称
  2. なぜこのプロジェクトをやるのか
    • 目的
  3. 何を
    • 目的達成のために作るもの
    • 作るものの説明
    • 作るものを利用する人
    • 利用する人が得られる便益
  4. どのように
    • 作るための体制
    • 期限

企画の内容を関係者が理解するための企画書

重要なのは企画を通すための企画書ではなく

  • 通った企画がいったいどのようなものなのか、を
  • 企画を実現するために作業する関係者、が
  • 理解するために必要な企画書

である、とあります。当たり前すぎてぐうの音も出ないんですけど、今まで多数の 企画を通すための企画書 を見てきましたし、そういう企画書ほど、 企画をするための企画書 だったりしたなあと思い返したりしました。

そもそも出発点は何かしらの情熱であり、それを実現するために前に進むための企画であり、その内容を共有するための企画書である。

だから、意思決定に対する「企画提案書」ではなく、実施が決まった企画の「決定報告書=プロジェクトそのものの仕様」が必要とあります。

つまり企画書を通す前の お願いします!の企画書 と 企画書を通した後にやる決定報告としての これをやります!の企画書=プロジェクト仕様書 が必要と理解しました。

RFPやプロジェクト計画書との違い

RFP支援の仕事もしたことがあるので、大変興味深い章です。要望を形にして、実現可能性や技術検討ができるようにするもの、くらいのふわっとした認識でした。

企画書が、RFP、いわゆる提案依頼書や、プロジェクト計画書と何が違うのか。

プロジェクト計画書から、マネジメント向けの情報を除外したサマリー

それが欲しいとあります。

  • 除外したいもの
    • 予算、リスクなど実務スタッフの担当領域外の情報
  • 不安や反発をなくす
    • プロジェクト仕様を知らないまま指示通りに作業しろ、と言われても…
    • 知らないことは先手を打つこともできない。プロなのに。
    • 何より人間は腑に落ちないことに不安や反発を覚え、手が止まりがち
    • 作業そのものが停滞しちゃうよね、と

企画書とは何か

プロジェクトについての紹介を、5分で手際よく事前知識のない人にできますか という問いかけが出てきます。

実務担当に不要な情報や、不安や反発を招きそうな内容だと、これから目指すゴールを紹介するのは難しいよな、と思います。

今から自分たちはこういうゴールを目指していくのだ と大雑把に理解できるために、 紹介するための企画書を作成 する。

そしてそれを共有する。 これが最初の材料 となる。

サンプル①:施設予約システム

サンプルとして、以下のプロジェクト仕様が掲載されています。僕なりに少し情報を足してみます。

サンプルには別紙参照の別紙がありませんが(そりゃそうだ)、それも含めてプロジェクト仕様書だと認識しました。で、そのプロジェクト仕様書を関係者で共有することで、自分たちが向かうゴールとその理由がわかる、ということかなと理解しました。

  • プロジェクトの名称
    • 施設予約システム
  • なぜ
    • 目的
      • インターネットを通じ、利用者が手軽に施設予約できるようにすることで、施設の稼働を活性化する
  • 何を
    • 目的達成のために作るもの
      • インターネットからの施設予約
      • 予約状況の確認
      • 実績データの他のシステムとの連携
    • 作るものの説明
      • 別紙参照(各機能の必要性とかUIとかかな)
    • 作るものを利用する人
      • 一般利用者
      • 窓口担当者
      • マネージャ
      • 経費部門
      • システム管理者
        • アカウント管理にシステム管理者を常に含めるのは重要
    • 利用する人が得られる便益
      • 別紙参照(フローや図があったりして別資料なのかな)
  • どのように
    • 作るための体制
      • 別紙参照(体制図が決まってないからかな)
    • 期限
      • 今年度中に完成
      • 新年度から運用開始

書籍にはもう1つサンプルがあったのですが、そちらは割愛します。ゲームを作るとなった場合にどうなるか、が書かれていました。

コラム:企画の良し悪し

企画もなしにいきなりソフトウェアは作れないよね、要件定義できないよね、狙いや企てのない取り組みはあり得ないよね、とあります。

まさにその通りで、企画の原点には情熱や思いから発する狙いや企てがあると僕も思います。

それは、趣味のプログラミング(他の趣味にも当てはまりそう)ですら、狙いや企てはある、と。そして、企画には良し悪しがある。

企画の良し悪しはどこに起因する?

利用者便益(ベネフィット)の観点から精査されているかどうか。

と述べられています。

成果と評価は違うとあります。

  • 成果はアウトプットであり、作り手が生み出す
    • 目玉焼きそのものは成果、しかし評価じゃない
  • 評価は受け入れる側が生み出す
    • 成果を受け入れ側がインプットし、そこから生まれる
    • 美味しい、いまいち、など
  • 評価の後は効果
    • 美味しければ嬉しくなったり幸せな気持ちになる
    • いまいちなら残念な気持ちになったり怒ったりする

この違いを認識せず、成果ばかりに目がいってしまい、評価や効果に対する狙いがあやふやなのが、筋の悪い企画であると述べられています。

効果の想定が曖昧

使い勝手のいいアプリを作る、という例で進んでいきます。

  • 使い勝手がいい、と評価するのはユーザーであり作り手ではない
  • ユーザーが評価した結果、どんな効果を狙うのか、が意外と曖昧
    • たぶん、職人文化を色濃くもつ日本人にすごくありがち
    • So What?(で?だからなに?) と問われたら回答できない

あるよなあそういうこと、って思いながら読んでました。

ストーリーを描けることが重要

  • 成果=例えば完成した「在庫管理システム」
  • 利用者が「仕事がしやすくなった!」という評価の先に…
  • 在庫回転率が向上するという効果が生じる
  • というストーリーが描けるものが良い企画

しかし実際にはストーリーに飛躍や断絶があって、実際の要件定義をする段になると、プロジェクトの目的に対して辻褄が合わない、矛盾した要件になってしまうよね、とあります。

重要なのは個別の正確性より全体の一貫性

個々に優れていても、例えば洗濯物を片付けたい、と言われ、いかに高性能かつ最先端の洗濯機を激推ししたとしても、おそらく以下の「洗濯」というプロセスに置いて、洗濯機は一部の、つまり個別の正確性の1つでしかないんじゃないかな、って考えました。

  • 洗濯物が発生するタイミング
    • 毎日、毎時、人、など多数かつランダム
  • 洗うと判断するタイミング
    • 定量に達したら?
    • 旅行などのイベントに関連する?
  • 洗うという行為
    • 洗濯物別に区分け
    • ネットに入れる
    • 順番を考えて実行する
  • 洗濯開始までの導線
    • カゴに放り込まれている
    • 仕分けする
    • ネットで包む
    • 洗濯機に入れる
  • 洗濯機を操作する
    • 洗剤を入れる
    • 柔軟剤をポケットに入れる
    • 水の量を設定する
    • 時間を設定する
    • 乾燥が必要か判断する
    • 乾燥のON・OFF
    • 洗濯実行する
  • 洗濯機が回る
  • 洗濯が完了する
  • 洗濯機から取り出す
  • 干す
    • ハンガーに通す
    • 洗濯バサミで止める
    • 洗濯棒にかける
    • 乾燥にかける
    • 陰干しにする
  • 乾いたか確認する
  • 乾いていれば取り込む
    • 定められた位置へ積む
    • 分ける必要があれば分ける
  • たたむ
    • しまう場所別にたたむ
    • 利用する人別にたたむ
    • 簡単なものからたたむ
  • しまう
    • タンスにしまう
    • クローゼットにしまう
    • 脱衣所にしまう
    • あるべき利用位置に設置する

思うこと

まさにその通りだなってのは前回にも思いを綴った記憶があるんですけど、仕事のための仕事を作る人っているよな、とも思いました。誰かのために、つまり利用者に便益をもたらすことから発進しているはずなのに、そこがすっぽり抜け落ちている。

利用者に便益をもたらす観点から考えずに、 企画を立ち上げなくてはならないからターゲットと市場を考えて、無理に企画を考案する なんてことあるよな、と。

得てしてそういう企画は利益にも結びつかず、便益をもたらす利用者の数も非常に限定的かもしれないなって思いました。

とはいえ、世の中の不便なことをちゃんと調べないと、企画も出てこない、ということも言えると思います。ゆえに、思いつきを徹底的に精査する、矛盾や無理のない内容であるかを突き詰める。

そうして初めて、企画としての実現可能性が見えてくるんだろうなって思いました。

やってみたいこと&やったこと

洗濯する、をちょっと考えても、これだけのプロセスとタスクと手順があり、しかもそれが天気や家族の健康状態、学校、イベント、ともすると気分にも左右され、かつ大物(布団カバーとか)があるか否かで分岐も変化するよなってことに気づきました。

また、今までずっと考えていて行動に移せなかった おとーさんとして1日を回すために経験すべきこと をどう認識するか。それって要件定義と同じ考えで形にできないかな、と考えたりしました。

で、24時から1時間ほど奥さんとずっと話してたんですけど、

  • 「家事育児、俺ができるようになるために経験したい、見える化したい」
  • (この間、色々やりとりあり、奥さんは辛抱強く僕の主張を聞いてくれている。眠いのに)
  • 「で、何がしたいねん。母親の代わりをしたいのか、手伝いたいのかわからないよ」
  • ( ゚д゚)ハッ!
  • (自分に問いかけたのち)「俺にできる1日の回し方を体験したい」
  • 「つまり、おとーさんとして1日を回したいってことね」

ってことを話してました。かなり要約すると。このあいだの1時間、奥さんはすごい忍耐力と言語力で僕に接してくれたと思います。

我が家は僕が外貨を稼ぎ、奥さんが専業主婦です。当然役割も意識も求められるものも違う。

僕は外貨を稼ぐためにタスクを見える化し、確実にこなして成果に繋げ、評価してもらう。その結果として対価をいただく。

では奥さんは?

常に変動する要素に対し、分単位、ときに秒単位で判断し、行動している。毎日命がけで。その行動の元となる情報は天気だったり子供の健康状態だったり控えている学校行事だったりするし、ご飯をどのくらい食べたかで次のやることにも影響してくる。

これらを、家の中にあるあらゆる要素、あらゆる外的要因、あらゆる子供の状態をインプットとして無限の分岐から判断を下して行動する。

僕とは根本的にやってることが違うわけです。

で、その認識が僕にはない。なぜならそこまで全部判断するような一気通貫の1日を回しているわけではなかったから。

でも、知りたい。なぜか。できるようになりたい。なぜか。奥さんが1日家を空けても回るようにしたい。なぜか。奥さんが入院したら回らないから?それだけじゃない。俺にできることを増やしたい。なぜか。奥さんが大変そうな、辛そうなことを減らしたい。減るのか。減らない。それに意味はあるのか。意味はあると思う。経験を積むために協力してもらうことはできないか。それは可能といえば可能。

こんな問答に付き合ってくれて、以下のことがわかりました。

  • 1日のゴールは娘が時間内にご飯を食べ、明日のために19時台に寝ること
  • ゴールに到達するためには、日によって選択肢が全く違うこと
  • 正解は何もないこと
  • おかーさんの代わりは絶対にできないこと
  • 部分的な家事育児の積み重ねの経験は必要なこと
  • 経験から、部分の前後関係に気づけるようになること
  • 連鎖していくことで、イレギュラーな分岐に対応する能力が上がること(おかーさんほどではない)

他にもたくさん話したし、おかーさんの家事育児は本当に命がけで休みがないです。だからこそ話の途中では非常に厳しく固い雰囲気だなって僕が感じる場面もありました。

命がけだから当たり前の話し方をしてるんですよね。それは奥さんにとっては当たり前。

でも僕はその当たり前を本質的に知るまでに至っていなかった。部分的にやっていただけだった。

それがわかり、厳しいわけでも固いわけでもなく、淡々と解説して、先を読み、僕の話を聞いてくれ、それに答えてくれている。

で、上記のことがわかった、というか初めて共有できたんですね。

そして、なんでそんなこと急に、しかもこの寝る直前に言ったのか。という話になって。

そういうことが考えられるくらい、気持ちに余裕ができてきたのかもね

って言ってくれたのがすごく嬉しかったし、今の僕の状態を奥さんも喜んでくれている、ということもわかりました。

実際、11月に入ってから、僕はお腹を壊していません。それまでは何かある都度、ひどい腹痛に10年くらい悩まされてきましたが、それが初めてピタリと止んでいるんですよね。(なので、根っこの体調そのものは非常に良好です)

そんな話から、生活や環境を今よりもっとよくしていくにはどうしようか?来年度からPTA役員だから家にいてほしいスケジュールはなるべく早く共有するからサポートよろしくね。そういえば洗濯機そろそろやばいよね。2月になったら最終決断しようか。そういえば食洗機ってどう?便利は便利、でもたまに傷がつくのよね。えーまじで。ほらほらこんな感じ、だから使うときは洗えてもお気に入りの食器はやめようね。そうだね、大事な子たちだもんね。そういえばソファを占領している大きなぬいぐるみ(すみっこぐらしのプライズ、つまりゲーセンから連れて帰ってきた子たち)のおうちどおしようかしらね?壁に固定する家具を選ばなくてわ!そういえばクリスマスはお揃いのちっこいバッグでいいかな?娘も欲しいって言ってたから共同で使うかな。それはいいわね。

などなど話は飛躍したし、要件定義について学習した結果の何気ない(と思っていた)問いかけが、奥さんに負担を強いてしまったんですけど、少なくとも僕は 家事育児が全然わからない。俺は雰囲気で部分的にやっている 状態から 命がけでやってるし代わりはできないし、おとーさんとして考える ってことはわかったし、それによって 24時間臨戦態勢のおかーさん をたまの1日でも休んでもらえるために僕にできること、をより具体的に考えることができるようになったし、あとは経験を積もう、って意識になれました。

要件定義から大きく話は逸れましたし、家事育児はそもそも要件とかそういう次元ではないので、安易に仕事っぽく話した結果の責任は僕には負えませんが、僕としては言葉にできないくらいの出来事に繋がったりしました。

仕事の思考で家事育児をやろうとすると破綻するのはわかったし、根本的に違うのもいったんはわかったし、最終的に言えることは、僕の奥さんはやっぱり最高だな。

この人に命を預けるって決めてからもう10年以上経っていますが、様々な環境の変化についていけていなかった自分がいたんですよね。それはきっと自分にとっては負い目に近かったんじゃないかなって今では思います。

今年は色々あったし、 おとーさんとしての1日を回したい なんて話、奥さんにとっては「めんどくさい話だな!」って一言で片付けられてしまわれかねない。手伝いって意識じゃ全然ダメだし、やりたいって言った以上はアテにするわけだから、依頼したら100%やれるもんじゃないと依頼できないし、依頼するんじゃなく行動をみて自分で判断できないと本当はだめ、ってこともあります。

けど、僕の気持ちは汲んでくれて、僕自身は前に進むことができた。あとは行動で示すしかないなって気持ちを新たにして、今日は寝ようと思います。

( ˘ω˘ )スヤァ