【我が家流】クリスマスを支える技術
これは 俺のインプットアウトプット記録 Advent Calendar 2018 の25日目のエントリーです。いよいよ最終日。
はい、寝るまでが25日!
で、最終日はエンジニアとしてのガチ技術じゃなく、クリスマスのブログエントリとしても書きたかったので、 【我が家流】クリスマスを支える技術 と題してポエムで締めくくりたいと思います。
はじめに
うちの子はサンタさんを信じてます。その夢と期待、僕も奥さんもすごく大事にしてます。
子供が親と一緒に見た夢って、一生忘れない んですよ。そして親と過ごした思い出って、次に自分に子供ができたときに、受け継がれていくものなんですよね。
それ以上に、 誰かの夢や期待にあったかく応えたい 、って思うわけです。恋人や家族同士の優しさやあったかさって、きっとそういうところから「も」生まれていくんじゃないかなって思ってます。
で、これって全ての人付き合いに言えるよなって思うし、それは仕事にも言えるわけです。
僕はなんども言いますが 生活と仕事の融合 が人生のテーマです。切り離して考えずに、仕事で期待に応える場合の思考やモチベーションの一部になればいいんじゃないかなと思っています。
人生、生活や仕事っていろんな輪が重なってると思うんですよ。優しさだって生活と仕事で違う要素が多いと思うけど、 どこかで重なる部分がある はず。
じゃあ、その根っこは?って思うと、自分自身だよなって思うんです。
だからこそ。生活と仕事を切り離さずに考える、という訓練を日頃やっていたりします。
その中でも、仕事しながらクリスマスの時間を大事にできたことを、1つの技術(?)として綴りたいと思います。
1年目のエピソード
ひとりでトイレに行けるようになったので、イブの夜もトイレにいきます。気持ちいいんでしょうね。ご機嫌に歌ったりしてます。また即興のオリジナルソングなので親が笑っちゃうんだよね。
静かに設置
でもまだまだお子ちゃま。おかーさんに「ついてきてー」って言ってる隙に。僕の仕事部屋の押入れにしまってあったプレゼントをさっと枕元に設置。
もちろん事前に オリジナルのプレゼント袋 に入れてあります。
子供に伝える
これまたコツが要るような気がします。わざとらしくてもいけないし、かといってどうすりゃいいのとなる。
うちの場合、1年目は
あれ、トイレに行ってるとき、寝室から何か音が聞こえた気がする…
って言いました。で、ここからは勢いです。
なんだろう!ちょっと見てきて!何かあったかなっ!!!!
すると子供はダッシュ。だだだだっと走って部屋に入り、何か変わったことはないかなー…ああああっ!!!
駆け寄る子供。見守る両親
感動して大事そうにプレゼントを抱えた子供が興奮気味に両親に報告します。
見てみて!プレゼントー!サンタさんきてくれたんだー!やったー!
その直後。プレゼントを開ける前に。子供的に窓からきたと思ったらしく。
サンタさんありがとおおおおおおおおおおおおおう!!
窓に向かって絶叫したのでした。
おとーさんとおかーさんにありがとうは言わないし言わせない。これがすっごい重要。だってサンタさんがくれたんだもん。
プレゼント袋の重要性
いつもいくデパートの包み紙で包んであるなら、すぐさま破り捨てましょう。そして 百均のいい感じのプレゼント袋でいいんです。子供が見たことのない袋に包みましょう。
子供は親と違って情報量が少なく、かつ勘が鋭いです。見たことある包装紙は全部覚えてるんです。
そのままにするとどうなるかっていうと、年数が早めにバレます。
あ、おとーさんおかーさんが買ってきてくれてるんだ と。
そうならないためのちょっとしたテクニックですけど、これすっごい重要です。
ちなみに僕は小学校2年のとき、寝て起きたら枕元にプレゼントがあり、それが前々から欲しいものだったんですが、包装紙がデパートのものだったため、親が買ってきたことに気づきました。
それからの数年は演技してたなあ。
どんなプレゼント袋を選ぶか
- シンプル
- 子供がおいそれと見ないもの
- 単なる紙じゃなくちょっと耐久性のあるもの
- 音が静かなもの
プレゼント袋はそれっぽければシンプルでいいです。我が家はおかーさんのクリスマスプレゼントとして買った小さめのバッグに付いてきた綺麗目の赤い、布っぽい袋を使いました。ハートのシールを添えて。
マイナーなブランドだったので、子供が子供のうちにはまず出会いません。ゆえに 気づかれにくい。
ただし思い出深い出来事のため、いろんなところで再利用されます。なので布っぽいそれなりに丈夫な袋を使いました。
音を立てない
音も重要です。 イブの夜のギリギリの時間に、枕元に設置する必要 があります。理由は以下です。
- 昼間は寝室で遊ぶこともある
- もちろん、寝室の押入れに入って遊ぶこともあり、それは止められない
- 子供は非常に気まぐれである
- 親が一瞬姿を消すのを気づかれないようにする
- 小さな子供は親の気配に非常に敏感です
- プレゼントの移動を伴うので音を出さないようにする
- 紙だとちょっとガサッといっただけでバレる可能性がある
うちの場合
寝室のある3階の押入れはよく遊んでるので、隠すスペースに使えませんでした。なので、僕の仕事部屋である1階の納戸の奥の方にしまっていました。
ゆえに、 隙を狙って1階から3階まで移動し、設置する 必要があったのです。
ここで役立ったのが布っぽい袋です。 掴んだまま動いても音がしない 。
設置
以下の手順で設置しました。今年一番緊張したんじゃないかな!
- 忍び足で1階に行きプレゼントを掴む
- 足音を立てないよう2階の階段前で雰囲気を察知
- 子供が何かに夢中になり
- 視線が一定時間階段方向から外れ
- おかーさんと会話してるのを確認した時点で
- 静かに3階へ移動
設置したら戻る
枕元に設置し、リビングの階段エリアで再び様子を伺い、わざとらしく冷蔵庫から個包装のピノを音を立てて取って「おいしー!」とか言いながら子供の元へ戻ります。
重要なのは 緊張して隠し事をしてきたことを自ら吹き飛ばす雰囲気づくり です。
あとは自分で見つけてくれるだけ、の状態にしたら、もう一仕事です。
能動的に報告しない
今年は、1年目と違い子供は成長しています。そして何より、2年連続 トイレに行ってる間にプレゼントを持ってきてくれた ことを子供は覚えてます。
なのでワクワクしてるし、あえてトイレに行きたくもないのにトイレに行き、長めに手を洗うという サンタさんへのフェイク行動 までしてました。
フェイクとは侮れない。
しかし夢と期待に100%応えるのがクリスマスの親の使命。
どうするか 家庭内Slackでおかーさんと相談 し、自然を装い早めに寝ることで、寝室へ移動することにしました。
今年からは 勢いで知らせて行動させる 方針から変更です。
フェイクの理由
あとで聞くと どうしても直接サンタさんにお礼を言いたかった とのこと。
子供なりの どうしたらお礼を言えるかな って考えた末の行動だったようです。
いい子に育ってるようで両親はにこにこですよ。
来年はどんな行動をするか想定して対策を立てておかねばならぬ。
子供なりの疑問
いつもはもう来ててもおかしくない時間。しかし今年は遅い。
サンタさんもう来たかな?どの窓から入ってくるのかな?忙しいのかなー?
もう待ちきれません。
なんでいつもの年より遅いのか。子供なりに一生懸命考えます。いいぞいいぞ。
両親としてはとぼけつつ、精一杯の勢いで
- サンタさんってさ、日本中の人に今、プレゼントを届けてるじゃない?順番変わったりして忙しいとは思うよー
- でも去年もその前もその前も来てくれたじゃない?今年も絶対に来るから大丈夫。だってお願いの手紙書いたでしょ?
と会話を繋ぎます。一応納得してくれたのか、 そっかー。世界の国に1人ずつ担当してるから、忙しいよね!おふとんで待ってたら来たりするかな! とか言いつつ寝室へ。
疑問を持ってくれることも嬉しいし、それに応える両親は、気持ちも顔もずっとにこにこですよ。
そして寝室へ
プレゼントを設置したとき、1つだけ工夫をしました。それは
いつもは夜に閉めているカーテンを半分開けておく
ことです。
あとは自然に発見してくれるし、いつも明かりは子供が自分で点けます。両親は後ろからついていくだけです。
発見、溢れる喜び
え?あああああ!うわああああああああ!
叫びながら枕元へ駆け寄ります。よっしゃ狙い通り!いや狙い以上!
喜びと驚きに気持ちが追いつかないんでしょうね。いろんな言葉が飛び出ます。
- いつ来たんだろう!
- どこから入ったのかな!ああ!ここだああああ!
- カーテン半開きの効果!
- (くんくん)サンタさんの匂いがするー!
- ただのカーテンと窓枠だけど、匂いがするならそれはするのだ!
- 入った窓は別かな、ここから出て行ったのかな?
- 隣の部屋から入って、ここでトナカイさんが待ってたのかもよ?
- だって空を飛べるもんね!
- わー!そうかもしれないね!
- あー!お礼言いたかったなああああ!
- そっかあ。でもきっと聞こえてるよ!
- 来年は会えるかな!
- きっと会えるかもしれないよ!
- (窓に向かって)サンタさんありがとおおおおおおおおう!!!
大切なこと
子供は本当に純粋で、素直に夢をみて、素直に期待をします。
それは 大人になっても絶対に失ってはならない大切な大切なもの です。
そんな大切な気持ちを育むためにも、家族との時間を大切にするためにも、生活の糧である仕事をやっていくためにも 生活と仕事の融合 の実現という 常に変化する目標 を追い続けようと思います。
あでぃしょなるたいむ
興奮と感動冷めやらぬとき。そのまま寝るわけがありません。そして両親はそのまま寝るとも全く思っていませんw
ゆえにプレゼントを開封し、みんなで遊びます。そのための時間を 今日は特別だぞ? って両方から挟み込んで。
とはいえ時間は迫り来る
子供がいつも寝る時間はとっくに過ぎているわけです。いくら翌日が休みとはいえ、あまりに遅い時間に寝せると風邪を引きます。子供ってそういうもんです。
大人のように夜更かしして翌日遅くまで寝る、ってことないんですよね。きっかり早く目覚めるんですよ。
なので、子供が睡眠不足になって体調を崩さないようにするのも両親の、というかおかーさんの命がけの仕事の1つです。
迫り来る時間に対応する必要があります。
ビルド
今回のプレゼントは 組み立てが必要 な割と難易度の高いおもちゃ。
ビルドと言えばおとーさん。 いやPHPはビルドしないけど。そんなこたあどうでもいい!とにかく
- 一緒に作りたい!
- でも早く完成形を見たい!
- 完成形で遊びたい!
- そして早めに寝なくちゃいけない!
を実現するために、おとーちゃんは 超集中力で組み立て ます。
- 子供は説明書を見て部品をおとーさんにトス
- おとーさんはしっかり組み立てる
- おかーさんは見守る&細かい部品を一緒に探す
という役割分担で迷いなく組み立てていきます。ちなみにうちの子は期待して何かを見る時、声に出して「わくわく」って言います。まあ最高にかわいいです。
完成!遊ぶ!仕舞う!
45分はかかったかな。そのあとひとしきり遊んだら、ちゃんと設置場所を決めて仕舞います。
はー楽しかった!って心から言う子供を見て両親はにこにこです。
年間を通してコンスタントに遊んでくれる大事な宝物が増えたようでなにより。
就寝
おふとんに並んで寝たら、 お礼を言えなかった申し訳なさでちょっと泣いちゃう 場面もあったりしました。
今年こそはお礼を言うぞ、って決意してたみたい。
お礼…伝えられなかったな…
ってしょんぼりする子供に、両親は左右から話しかけます。
- サンタさんはね、離れていても聞こえるんだよ?
- え、どうやって?絶対聞こえないよー…
- だってさ、お手紙書いて言葉にして、お願いしたじゃん?
- うん…
- それはサンタさんに届いたから、プレゼント届けてくれたじゃない?
- うん…
- ってことは、離れていても、お願いは聞こえてるよね
- うん…
- じゃあ、ありがとうの気持ちも聞こえてると思うよ。さっきありがとうって叫んだじゃん?
- そうかなあ…
- だって、去年のありがとうも、一昨年のありがとうも言ったでしょ?
- うん…
- それが伝わったから、毎年プレゼント届けてくれるんじゃないかな
- うーん…
- サンタさんって、世界中のお願いを聞いてるじゃない?
- うん
- てことは、キミが思ったことも伝わってるんだとおとーさんは思うな
- でもー…直接伝えたいなあ
- じゃあさ、今度お手紙書こうよ!お返事もくるよ!
- (英語で手紙を書くと返事が来るのは何かで見たらしい)
- でもさ、日本の担当のサンタさんは英語読めないよ!
- (世界中にひとりで配れない、の問いに、担当分けされてると答えてたのでした)
- 日本にも英語しか読めない人がいるから、英語も読めるよ!
- そうかなあ…
- とにかく今後書いてみようよ!
- んー…うん。
とかなんとか言いながら、おとーさんとおかーさんのおててをすりすりしながら、すやすやと寝たのでした。
大人の時間
熟睡を確認した両親はリビングへ。
そして お疲れさまっ って言い合って、お肉やケーキと一緒に買ってきた 獺祭(300ml) と はちみつのお酒(250ml) を開封。
ちょっと高いお刺身と、ちょっと良さげなローストビーフ。
互いにほろ酔いになり、ふにゃふにゃとした会話をしながら、更ける夜を楽しみつつ。
今日だけはお互いに、可能な限り仕事のことは忘れ、いつも以上に互いの労をねぎらったりしたのでした。
ちなみにそのあとは眠かったので、かなり早めに寝ちゃいました。2019年の目標の第一は早寝!
愛するということ
僕ら両親は絶対に妥協しないこと、許さないこと、許すこと、大切にすべきこと。
その思いがたぶん100%同じだと信じ合えます。どっちかというと 好きなことの共通度合いより、許せないことの共通度合いが高い と思います。だからこそ結婚したわけですし、紆余曲折ありましたけど本当に幸せです。
この我が家の幸せは、家族がいるからこそ実現できていること。お互いを思いやり、愛することが根源であること。
愛の形に決まりはありません。また、毎日同じでもありません。お互いに歳を取り、変化するのと同じように、愛の形も常に変わっていきます。不変なものなどこの世にない。
だからこそ僕らは、そのときそのときの想いを大切にし、1つ1つ愛していく。
いつか巣立っていくうちの子供が、好きになった人を素直に愛せるように。そして次の世代に愛を繋いでいけるように。
何より本人が、両親も含む本人たちが、幸せであるように。
そんな日々を過ごすためにも、これからも1つずつ。いろんなこと大切にして行こうねって夫婦で言い合った夜でした。
あっぺんでぃっくす
今までで一番穏やかだね。
僕を見て言った奥さんの言葉です。
とにかく仕事をして日銭を稼ぐことに必死だった時期。大変なものを抱えて頑張ってきた日々。
その間ずっと支えてくれたのは奥さんでした。家計のやりくりも、家のことも、毎日のご飯も、出産も、子育ても。
順風満帆だったわけじゃないし、ずっと変わらず仲良しで波風がなかったわけでもないです。喧嘩はしたことないけど。
でも、今が一番穏やかだね。って言い合える以上の幸せを僕は知りません。
変化していく毎日。変わっていく幸せ。
毎日少しずつ増やしていけたらいいなあって思いつつ、来年のクリスマスを支える技術のバリエーションと作戦を、また考える日を迎えようと思ったりした聖夜でした。
学習記録:12月24日(月):【我が家流】家具をお迎えする技術
これは 俺のインプットアウトプット記録 Advent Calendar 2018 の24日目のエントリーです。
クリスマスイブでした。僕は常々「生活と仕事を融合する」ことを人生のテーマにして生きていると明言してます。なので、クリスマスイブの出来事も重要なインプットだし、それは生き方のアウトプットでは?と思ったりしてます。
と思ったんですけど、今日はその前々日に行った 家具を選ぶ技術 的なエントリーにしてみようかな、と思って書いてみます。
エンジニアとしての技術的なインプットは、書籍を読んだり仕事をフリーランスとしての進めたりで必ずあるし、そこで書き留めたメモや手順、やりとりの全てがインプットであり、書き留める行動そのものがアウトプットではありますが、今日は個人的に語りたいポエムっていうかおうちでの出来事があったんで、それを綴るって意味もあります。
家具を選ぶ
12月22日(土)、レンタカーをタイムズカーシェアで借りてサクッとお出かけしました。
どうでもいいですけど、タイムズカーシェア、マジ便利。
タイムズカーシェアを使う理由
唐突ですけど語ります。
メリット
- 保険は都度300円
- 対人も通常の保険と変わらないはず
- 車両保険がついてる
- 例えば自分ちの壁にこすって車を破損しても
- 保険でまかなってくれる(実話)
- 6時間で約4000円
- 週末ドライバーとしてはお手軽価格
- 延長もお手軽
- 駐車場代、ガソリン代、税金などかからない
- 週に4000円と考える
- 月額20000円
- 年額24万円
- ローン、ガソリン、駐車場、税金、その他維持費を考えると
- 負担と気軽さが半端じゃない
- 洗わなくていい
- 扱ってる場所が多い
- 最近は住宅街のど真ん中でもたくさんある
- うちは5箇所の駐車場から選べる
- 車種もコンパクトからステーションワゴンまで(場所による)
- 結構近いので、自分ちの駐車場感覚
- 数が多いので、急な予約でも大抵使える
- 休前日、休日は利用率が高いけど
- 候補が8〜10台だとどれかは必ず空いてる
- 7月からほぼ毎週乗ってるけど空いてなかったことがない
デメリット
- 自分ちの駐車場に置き続けられない
- 返さなくちゃいけない
- カスタマイズできない
- 対物は保証してくれない
結論
デメリットよりメリットの方が圧倒的に勝ってます。今の所、車を購入する理由が全く見当たりません。自宅にガレージあるけど、ここは遊び場として使うことになりそうです。
家具の選びかた
我が家は今年の夏に引っ越しまして、いわゆる一戸建てを購入しました。でもまだまだ片付かないんですよこれが!
あのね、一戸建てって。なまじ自分のものであるがゆえに。
おいそれと家具を決められないんですよね。
思い入れがある、 この子ならうちにお迎えしたい、と思える場合にしか買えない んです。
それは僕と奥さんと子供の思いがマッチしてるからかもしれませんけど、 生活する中で毎日見て使う 子たち。
やっぱり この子と一緒に成長したいなって思う家具を選びたい んです。
んで、子供は英語のDVDやアニメ、教育用の映像などをDVDで見るわけです。一般的なTV番組は全然見ない我が家でも、映像を鑑賞するエリアは重要。
その見る、そしてその周りの環境は生活であり、妥協したくない。
要するにTVラックをどうするかでここ4ヶ月ほど悩んでました。
TVラック購入に到るまで
技術っぽく書くと、こんな感じかな。
- なんどもテスト
- リビングのレイアウトを変更
- TVラックが置かれるスペースを検討
- 壁面収納の要・不要
- 見通しの良し悪し(ラックに柱があるか、上部は壁に固定か)
- 吊り下げ戸棚の検討
- TVラック周りの見通しの良さは、床に置くだけのものが最強
- なぜなら視界を邪魔する柱がないから
- メタルラックなどのどんなに細いものも視界を邪魔する
- 視界だけじゃなく、部屋の見通しに大きく影響する
- 最終的に住み心地に関わる
- 今までメタルラック上部に収納していたものをどうする
- 壁に固定する吊り下げ戸棚で解決することを検討
- 寸法、モック(適当な箱)でのシミュレーション
- 結果から、ホームセンターのDIYコーナーでの相談
- 棚じゃなく、TV上部に壁に棚板が1枚置ければいいという結論
- そこには基本的にお雛様(段々になってないやつ)を設置
- 住みやすさの原則:高いものは置かない
- 最低でも、自分の胸以上の高さの家具は置かない
- できれば腰まで(テーブルまで)
- 圧迫感は家具屋さんでは完全に体験できない
- タンスも腰まで
- 背丈以上のものは、書斎の本棚と、キッチン周りだけ
- 食器棚、冷蔵庫、レンジ周り
とりあえず言えるのは、腰以上の家具を置くと圧迫感がすごいです。 床に座って快適かどうか。そこから始めるのをガチでお勧め します。
とにかくなんども計測
寸法だけでは、空間を計測したに過ぎません。実際の圧迫感や、生活してみての実感は皆無 と言っていいです。
ゆえに、そこにその寸法のものを置いたらどうなるか、を色々試しました。
- メタルラックを流用
- 既存のメタルラックに布をかぶせ、同じような大きさの物体を作る
- それを設置予定場所に置く
- 実際にダイニングテーブルやソファから見る
- 第一印象を最優先する
- 頭上にものがあることを徹底検証
- 圧迫感だけじゃない
- 出し入れする場合の導線を考える
- 同じく、労力を考える
- 人は必ず老いるので、10年先を見据える
- 地震がきたら?を念頭に置き、壁にきっちり固定可能か考慮
- 壁に固定するものが重すぎると壁ごと倒れるので一応考慮
- 少なくとも3軒の家具屋さんを訪問
1つの家具を買う場合も、うちは基本的にこれだけのことをやってます。結果として、 一度も失敗してませんし、100%満足できてます。
そして購入
そして、結局は近場で一番購入することの多い家具屋さんで見つけたTVラックを購入しました。最初に「あ、いいなこれ」って思ったんですけど、5回行って毎回見て、いいねーこれー、って言い続けた結果でもあります。
ソファもそうだし、ダイニングテーブルもそうだし、食器棚も、寝室のタンスも、子供のランドセルラックも。
思い返して見れば、同じ感じで購入してます。
値段も使い勝手も第一印象もシミュレーションも。絶対に妥協しない、を続けた結果 、我が家は全てに置いて満足できていて、あーここで暮らしてよかったなーって思えています。
そんなわけで、床に置くだけのTVラックですけど、ウォールナットでできた九州から直送の気に入った家具をお迎えすることとなりました。
届くのは年明けですが、今から楽しみです。
我が家の家具は家族
ものには九十九神が宿ると言われます。僕も奥さんもそれを信じています。 愛すれば、共に長く暮らせば、それは生活の、命の一部となる。
そんなことを信じてるんですよね。
なので、今までやってきた家具たちも、これからやってくる家具たちも。みんな家族なんです。
お迎えした際は必ず、奥さんと僕として綺麗に乾拭きし、そのあと満足げに撫でつつ、最後は子供が上に乗るなり中に入るなりして「これからよろしくね」って言ってたりします。
これから宿るであろう年月。一緒に行こうね 、って感じです。
我が家流、家具を選ぶ技術
完全に我が家独特の世界観で選んでるとは思います。が、住居も第一印象に勝るものはなかったし、なんども引っ越しして、家を購入して、その思いは変わらないです。
そして、その中で毎日使うもの。そのさきに引っ越したところで使うものでもありますし、うちの場合は「いずれ一戸建てを買う」ことは決定事項でもあったので、そこまで見据えて選んできました。
結果として、 全てが愛すべき我が家の一員だし、今でもこの子たちに囲まれて生活して います。
あと、うちでは間に合わせの家具を一度も買ったことないんですよね。ちょっとした折りたたみの座卓だったとしても、材質や色、大きさは徹底してこだわってきました。
それがたとえ3000円とかの合板の家具だったとしても。
で、同じことが電化製品にも言えるし、ちょっとした隙間収納にも言えます。
空間、過ごしやすさ、第一印象、シミュレーション。
これらを大事にして、少しでも快適な住環境を作っていければなって思っています。
我が家にとっては、たとえ1万円以下のお買い物も何かをお迎えする大事な決断なんですよね。
なので、可能な限りのことはやるし、できるだけ家族全員で吟味して決定してます。小さい子の判断も侮れないもんです。
これからも、本棚だったり、キッチン周りだったり、学習机、洗濯機周り、決めることも購入すること(常に財布と相談ですけど)も、まだまだあります。
けれど。それは全部新しい家族を迎えるためのワクワクでもあります。
今後もあったかく過ごすことを考えて、我が家の九十九神たちをお迎えできればいいなーって思います。
インフラの寿命は長いんだぞ?
学習記録:12月23日(日):はじめよう!要件定義 Chapter-09 [準備編]実装技術を決めよう(後編)
これは 俺のインプットアウトプット記録 Advent Calendar 2018 の23日目のエントリーです。
書いてたけどエントリーとして出し忘れてました。
昨日は実装技術を決めるということで、基本的なシステムアーキテクチャとして、メインフレームなのか一般的なWebなのかアプリなのか、などを決めた上で、各部の言語やフレームワークをどうする?のところで終わってました。
というわけで今日は Chapter-09 を読了していきます。
Chapter-09 [準備編]実装技術を決めよう(続き)
システムアーキテクチャを決めたら、次は各部の実装技術です。
各部の個別の実装技術を決定する
どんな言語やフレームワークを使って、それぞれの部位のソフトウェアを開発していくのか、という話になります。
毎度ながら、書籍の図を自分で描いてみます。
システムアーキテクチャを決めた後の第二段階、これだけのことを決めないと実装イメージに近づかないということがわかるかなーと思います。
大手企業の方言でいろんな表現があるものの、基本設計、詳細設計、システム設計、外部設計など、工程に合わせた内容を当てはめて行けば、必ず検討事項および決定事項になる項目が、緑の吹き出しで表現されているわけですが、これを全部要件定義の時点で蹴ってきているプロジェクトに出会ったことがない僕は、本当の意味で幸福ではなかったんだろうなあと思ったりはします。
とはいえプロジェクトにはいろんな事情があるのはわかるし、それを解決してこそ仕事と考えるのもわかるんですが。
でもここで思うわけです。俺たちもお客さんを選ぶのが普通である、と。お客さんと我々は真の意味で対等でしょうし、対等であるという姿勢で望むことが結果として、お客さんに対しての結果を正しく出せる、プロとして導ける。
それ以外の上下関係や、営業成績としての無価値な値引きは断り、対等なビジネスをできる相手を厳選していくのが本筋なんだろうなっていつも思います。
もちろん、要求、要望を要件にしっかり落とし込む、その過程でお客さんのやりたいこと、企画、熱意を形にする、という「仕事の大前提」があった上での話ではありますけれども。
と、それはさておき。
この図で検討すべき項目が書籍では箇条書きされています。
クライアント側
ユーザーが実際に使う内容ですよね。
- ユーザアクションの検知方法は?
- マウス
- タッチ
- 音声
- 入力や受信データの保持方法は?
- データと画面上の項目との連携方法は?
- 画面遷移はどのように行う?
- クライアント側のプログラミング言語はなに?
通信
- 通信プロトコルは?
- 通信データのフォーマットは?
サーバ側
解説
最低限のインタラクション(人間が何かアクション(操作や行動)をした時、そのアクションが一方通行にならず、相手側のシステムなり機器がそのアクションに対応したリアクションをする、の意味)を構成するだけでもこれだけの項目が必要ということです。
ここ、すっごい曖昧なまま進むこと多いよなって思うし、曖昧にした結果、例えば言語とフレームワークの決定が遅れて人員確保が遅れて失敗したまま運用してるプロジェクトもプロダクトも知ってますし、サンプル作るにも、何で作ればいいの、モックだけで無意味になるのはダメだよな、って思ったりしました。
実装技術を決める意味と僕の思い
要件を実装に落とし込む方法、それは選定した技術次第で多種多様になるよね、とあります。ここの落とし込みは要件定義のスコープ外になるのでこの書籍では深掘りしてませんが、
要件定義の前に、1つのインタラクションすら実装できないなら、実現は心もとない
という言葉に心から同意します。
上流下流という言葉を嫌う傾向にあるよね、でもそれ本質的に余計に曖昧にしてるんじゃねぇの?ってことは以前のエントリに書いた気がします。が、上流とそれ以外は別物と考える傾向もあるなと思います。無意識にね。
でもそこで、要件定義と実装ってどうなの?切り離せるの?となると
絶対に切り離せない
と僕は思いますし、切り離して成功したプロジェクトは見たことないです。それだけ僕が「切り離して、もしくは曖昧なまま失敗したプロジェクトに多く在籍していた」ってことにもなるんですけど。
それは別として、 前工程で決めたことを後工程に繋げて送っていく 、ってことが本題な訳ですよね、プロジェクトの。
その中で、後工程とのつながりを曖昧にしたまま もっともらしい日本語でごまかす のは、僕は愚の骨頂だと思っています。
そんなん炎上するだけだし、誰も幸せにならない。
基本的な実装の裏付けはこの「実装技術選定」の時点で用意しておかねばならんのだな、って思います。
感想
イケてる言語、フレームワークがこれだからやろうぜ、っていう技術選定、結構見るんですよね。
でも、ほとんど炎上してるんですよ。まじで。例を挙げるとキリがない。
一方で、 本当にそのプロジェクトに必要な技術は何か を妥協せずに決めていったプロジェクトは大抵成功してるし、いい人材も集まるし、 のちのメンテや運用も回って たりします。
今流行ってる言語やフレームワークが、少なくとも5年後に先端なのか。先端じゃないにしろ、生き残って言語やフレームワークコミュニティとして世界的に運用されているのか。
これはサービスの行く末と大きくリンクすると僕は考えています。
よりシンプルにできて、ロックインされない技術。基盤。
可能な限り、そういうものを選んで行きたいし、できる限り、枯れた部分に根ざしたエンジニアとしての活動をしていかねばな、っていうことを、読んでいて思ったりしたのでした。
だから俺は、データベースやDNSが好きなんだろうなあ、って思ったりもしました。
まだまだ根っこの技術の習得も知識も経験も深掘りも足りませんが、 足りないって自覚があるのは成長の証 だと思って今後もやって行こうって思ったりもしました。
未来はやることがたくさんあって楽しいぞ、っと。
学習記録:12月22日(土):はじめよう!要件定義 Chapter-09 [準備編]実装技術を決めよう(前編)
これは 俺のインプットアウトプット記録 Advent Calendar 2018 の22日目のエントリーです。
昨日は大まかに区分けしようということで、登場人物(ステークホルダー)と使うサブブロックによって区分けして、全体の見通しを良くしようという章でした。
で、そこから僕なりに以下を学んだ気がします。
- コツコツと丁寧に積み重ねる根気
- 根気を失わない1つ1つの小さな達成感
- 単一責任の原則に基づいた分解
サブブロックをみて、その先にある「合意しなければならないことの多さ」にめげるんではなく、1つ1つ分解してシンプルにし、明らかにしていくことが楽しくなるように考えて行けばいいのかなって思ったりしてます。
ほら、プログラミングしてる時も、Controllerに処理を書いてるうちに、どんどん切り出していって、名前を単一の責務にして、名前と処理内容を同一にできた時って楽しいじゃないですか。
それと同じだなって思ったりしてます。
閑話休題。
というわけで今日は Chapter-09 を進めます。
Chapter-09 [準備編]実装技術を決めよう
システムアーキテクチャと、その次の層の個別の実装技術を決めていく章のようです。
ソフトウェアアーキテクチャの決定
要件定義は合意事項を洗い出したら終わりというわけじゃなく、次の工程、つまり後工程に必要な情報を定める工程とあります。
最終的にプログラミングまで繋いでいくわけです。プログラミングとは言ってしまえばゼロイチに落とし込む仕事、白黒はっきりしてないと実現できないし、はっきりしないまま進めた実装は機能ではなく勝手な行動で、成果を伴うのが仕事であることを考えれば、はっきりしないまま進めるのは仕事とは言えばいはずです。
プログラミングで実現可能な要件にする必要がある
本来、アーキテクチャ設計と呼ばれる作業で、実施時期はプロジェクトマネジメントに基づくとあります。
- 何を使ってプログラミングするのかを決定しないといけない
- 技術選定
- 方式の方針決定(Webなの、スマホからなの、などかな)
実現する道具を探すことでもあり、道具を探すなら、先に要件を定義してからアーキテクチャを決めるべきだという論調もあるのは僕にもわかります。
要件が決まらないと採用する技術も決められないよ、と。
とはいえ。
実装の都合がわからないとソフトウェアの要件が決められないのも事実
とあります。この行間がわかりにくかったんですが、先に出てきた通り「何を使ってプログラミングするのかを決定」する必要、ここでいうとプログラミング言語とかではなく、
- ユーザーは何を使うのか
- スマホなのかPCなのか専用端末なのか
- どんな通信手段なのか
- Webだったらインターネットだろう
- クライアントサーバ型?社内の独自基盤?
- これは要求を聞いた時点でわかりそうだけど…
- 散々言うように「当たり前を定義する」必要がある
ということなのかな、と思いつつ読み進めます。
ソフトウェアアーキテクチャを決める手順
大きく2段階あるとのこと。
- 第一段階:基本的なシステムアーキテクチャを決める
- 第二段階:各部の個別の実装技術を決定する
なるほど大きく間違ってがいなかったようです。
基本的なシステムアーキテクチャを決める
第一段階に、もう少し細かい解説がなされ、以下の選択肢から組み合わせで決めるとあります。
メインフレーム
- 独自基盤のことで間違いないようです
- なんとなく90年代を思い出しますが、必要な理由もあるでしょうし、要望、要求から判断しないといけなさそうです
二層クライアントサーバ型
もう1ついうと、三層(プレゼンテーション・アプリケーション層が分かれていて、アプリケーション層をサーバ側に持つのも選択肢に入るような気がします。
Webブラウザ型
- インターネットを使った三層って解釈でいいのかな
- 一般的なPCサイトってこれでしょうね
モバイル端末+Webサーバ型
- スマホのネイティブアプリ
決めること
サーバの置き場所(オンプレ、クラウド)の検討が必要ではありますが、まずは
- 利用者がどこで
- どのような機器を使い
- ソフトウェアを利用するのか
を決める必要があります。
各部の個別の実装技術を決定する
上述のように、基本的なシステムアーキテクチャを決定したら、第二段階として、システムアーキテクチャを構成する各部に対し、
- どんな言語?
- どんなフレームワーク?
を使って開発を進めるのかを決めていく、とあります。
で、書籍ではこの後に詳細な図が続くのですが、本日はここで力尽きたので明日続きをやります。
感想
一貫して 上から順に1つずつ丁寧に確認して決定し、合意していくこと が身に沁みます。
可能性の低い内容は、ともすれば書籍や講義では略されたり飛ばされたりしがちだな、と思うんですが、例えばメインフレームなど、Web全盛時代に詳しく語るものに触れなくなってきたことも、きちんと触れています。
いやWebでしょ、と最初から思っていたら「あ、軽視しそう」って思ったし、それってそもそものユーザーとのコミュニケーションに問題発生しそうだし、ユーザーが本当に求めていることを要件として定義することをやってるのに、 最初から決めてかかるのはダメだよな って改めて思わされています。
徹頭徹尾丁寧で、諦めずにコツコツ積み重ねた結果、合意できる。これは本当にずっと忘れないように今後も進めたいと思います。
ともすればそれは「当たり前」で済まされそうだけど、自分で何回もテキストに落とし込んでいくし、 思ったら書く、の回数を繰り返す ことで 自分の中の当たり前を言語化する ってことも続けていかなくちゃなってことに気づいたりしました。
結局、要件定義から失敗しているプロジェクトは、
- どこかで軽視した
- 忖度がプロの仕事だと勘違いし空気を悪い意味で読んだ
- 決めてかかった
- モダンにこだわり過ぎた
- そもそもの本質を見極められなかった
ってことなんだろうなって思います。
それらをしないためにも、今後も丁寧にやっていきたいと思います。
学習記録:12月21日(金):はじめよう!要件定義 Chapter-08 [準備編]大まかに区分けしよう
これは 俺のインプットアウトプット記録 Advent Calendar 2018 の21日目のエントリーです。
さて寝るまでが今日。ということで12月21日のエントリーです。
完全に余談ですが、今日は研修最終日。その打ち上げのあと、DBAのすごい人たちの忘年会に呼んでいただき、 23:45までたらふく食べ、うまい酒をたらふく呑んで 参りました。いやー最高だった。どちらの会も、世の中にはすげー人がいて、そんな人たちがすぐそこにいて、会ってお話できる機会があるんだな、とひとり感謝の夜だったりもしました。
閑話休題。
前回までは要件定義のスコープを決めましょう、そのために全体像を描こう、というところでChapter-07 が終わりました。
なんとなく雰囲気で要件定義をし、合意形成の成果物はこれです!と自信を持ってやってこなかった自分としては、 最初にやるべきことがこんなにも多く、そして、最初にやるからこそ後に繋いでいくことができる 、ということを学びました。
工場のラインのように、物理で次の工程ができるできないが完全にわかるのとは違い、ITの世界は見切り発車できてしまうし、わかった気になってしまう。そして日本の場合は多いのでしょうが、忖度してこそプロ、みたいなことあると思います。
しかしそうじゃないだろうと。どんなに細かいことでも合意できてなければ、それは取りこぼしたことと同じ。 合意できてない要件は定義が終わっていない ということ。
ってことを自分なりに学び取りました。
というわけで、Chapter-08に進みます。
Chapter-08 [準備編]大まかに区分けしよう
大きなソフトウェアの場合、「新規システム」など1つの四角で表現するのは難しいよね、ということでサブブロックの話が出てきます。
サブブロック図を作成する
- 1つのシステムの箱の中を
- いくつかの区画(サブブロック、サブシステム)に区分け
- 見通しをよくする
- 内部連携を図示
- それぞれの区画間で何を連携するか書こう
- ステークホルダーを書くとごちゃごちゃするなら
- 利用者の記載については「全体像を参照する」ことにし
- 省略してもOK
以下の図は書籍中にある図を再現したものです。自分で書かないと手に馴染まないので、僕個人としては必ず図は自分で書き起こします。
で、書いてて思ったんですが、サブブロック、層に分かれているな。もしかして第一層はプレイヤー、第二層はパラメータ担当、第三層はマネージャの層なのかな、ステークホルダー(利用者)によって分けられるんだろうな、と個人的に読み取りました。
サブブロック図を作成する手順
- 手順は非常に難しい
- 担当する人の経験、実力、センスに左右される
- 大抵は利用者がやることを大まかにくくる
- 同じような物をくくっていく
- 収まるところに収まる
あ、なるほど「利用者によって層が分かれてる」はあながち間違いじゃないなと読み進めて思わされてます。
ということで、サブブロック図のサンプルがあるので書いてみます。
これは製造業の生産、販売、在庫管理システムかな。
これは新規商材を開拓して売り込む商社とかのシステムかな。
やってみて
最初読んだ時、このサブブロックがあんまり理解できなくて、 何を根拠にブロックに分ければいいのかわかりませんでした 。
なので、サンプルをみても「乱雑に箱が散らばっている」としか見えず、慣れるしかないのかなあ、と思ってました。
が、今日の研修で繰り返し 基本的に三層構造である ことが出てきました。もっというとその前のゼロ層には企画があり、三層の向こうにはソフトウェア要件の層があるわけなんですが、ゼロとソフトウェア要件を除く三層はそれぞれ以下になります。
- 商売の流れ
- ビジネスフロー
- ステークホルダーがそれぞれ何をして
- 互いに何を受け渡すのか
- 最後にユーザーに何を提供するのか
- ユーザーシナリオ
- ユーザーはシステムの利用者
- エンドユーザーだけじゃなく、社内の利用者も主役
- ビジネスフローの個々の仕事を手順化、例えばレストランのホール係
- 顧客の注文を聞く
- 注文を登録する
- 注文を復唱する
- 注文を確定する
- ユーザーはシステムの利用者
- 個別の機能の操作手順(UI)
- ここがユーザーインターフェース(UI)
- 手元のスマホのPOSを想定
- アプリケーションを起動する
- メニューを表示する
- メニューを選択する
- 注文が登録される
- 手元のスマホのPOSを想定
- ここがユーザーインターフェース(UI)
で、この三層を考えた場合、Chapter-08のサブブロックは、第一層のビジネスフローをステークホルダー別に「さらに層に」分けたものかな、と理解しました。
以下の画像の場合を僕なりに「大まかに」解釈してみます。
- 商材を売り込む営業
- 需要開拓
- 開拓したレポート、外部システム連携による分析とか
- 商談管理
- 新規開拓した商材を売り込んだ履歴
- やりとりの経過や結果
- アフターフォロー
- 次の商談に繋げるためのアクションの管理
- もしかしたら他部門や他システムからのアドバイスあるかも
- 要質問事項
- 需要開拓
- 営業サポート
- 案件管理
- 営業が開拓してきた新規商材の管理
- 売り込んでいる進捗の案件管理
- 社内での情報共有とかあるかもしれない
- 要質問事項
- 案件管理
- 管理部門
- 外注管理
- 新規開拓した商材をどこに発注するのか管理
- 発注状況、納品状況、在庫状況を管理
- 製造を依頼するならその進捗管理
- 要確認事項
- 顧客管理
- 営業が開拓してきた顧客の情報管理
- 過去の情報も管理
- 未来の可能性としての見込み顧客管理
- 外注管理
どうでしょう。致命的に間違ってる感じではなく、むしろここから質問事項や確認事項を1つずつ丁寧に明らかにし、合意していくことで、 抜け漏れなく要件を定義していく出発点に立てそうだな、という感触 があります。
これが第一層だと認識したので、この次の第二層、第三層、アプリケーション要件層、と続いていく、繋げていくことで、抜け漏れなく進められるんだろうなと感じます。
余談
抜け漏れなく進めるには、必要なものがあると感じています。
- コツコツと丁寧に積み重ねる根気
- 根気を失わない1つ1つの小さな達成感
- 単一責任の原則に基づいた分解
何より必要なのは根気だと思います。書き出すことが、合意することが 多すぎて心が折れることが容易に想像できる んですが、決してそうではなく。
単一責任の原則 に基づいた分解を行い、次から次へと分解して明らかにしていき、 片っ端から合意形成 していくことで、 お客と自分の小さな達成感を次のモチベーションにしていく んじゃないかな、って読み進めて思いました。
前にも書いたかもしれないんですけれど、これってプログラミングだけではなく、 要件定義の時点から単一責任が考えられてしかるべき なんだな、って強く感じます。
日本語の魔術(漢字の羅列による、あたかも1つに見える言葉に潜む複雑さ、曖昧さ)に惑わされずに、分解し、明らかにし、つまり抽象化し、 確実に合意形成できた仕事 を選んでいく。
それこそが 使う側も作る側も幸せになれるシステム と言えるんじゃないかな、というところで今日のエントリーを締めます。
幸せになるために働くんだもんね。
学習記録:12月20日(木):はじめよう!要件定義 Chapter-07 [準備編]全体像を描こう(つづき)
これは 俺のインプットアウトプット記録 Advent Calendar 2018 の20日目のエントリーです。
昨日は全体像を描く手順として、アプリケーションを真ん中に置いて、登場人物とやることを書き込んでいく、というところまで進みました。 結果、ソフトウェアが利用者に提供するものが見えることで、迷走しにくくなる、取りこぼしが減る、という感じだったかと思います。
今日もみっちり要件定義の研修を受けてきて、一昨日以上に濃密なインプットを得てきたところです。毎回発見があるし、毎回腑に落ちるし、確実に自分が前に進んでいるな、って実感できるのは幸せなものです。
この研修、有料であるにも関わらず受けさせてくれる代表には本当に感謝です。
閑話休題。
というわけで、前回の 学習記録:12月19日(水):はじめよう!要件定義 Chapter-07 [準備編]全体像を描こう(前編) に引き続き要件定義の学習を進めます。今週はずっとこれです。
Chapter-07 [準備編]全体像を描こう(つづき)
昨日に引き続き読み進めます。
全体像を描くときの注意点
2つあるとのこと。
システム管理者を忘れずに
あ、これうちの代表が言ってたやつだ。以前のエントリーに一言だけ追記した気がする。
というわけで 利用者としてのシステム管理者を忘れずに含める とあります。これ以上の詳細は書かれていませんが、書かなければ登場人物としての考慮が漏れることになります。
システム管理者は最高権限を持つユーザー。しかも使い回しではいけない。例えば複数いるシステム管理者のうち誰かが退職したとしたら、同じように最高権限を持つユーザーによって適切に削除されなければなりませんし、それは下位の権限のユーザーには実行できない。
そのほかにも書いてある通りの重要な機能があり、それらをうっかり定義し忘れてしまうと「あれ、ログ確認できない(残してない)ので監視できてなかった」などのトラブルを招きそうです。
連携するシステムを書く
外部、内部問わず、連携するシステムやソフトウェアがあればそれも書くとあります。他システムからCSV取り込んだり、逆に他システム用にCSV出力したり、API叩いたり、色々あると思います。
また、特に業務システムの場合は 旧システム(移行元、現行)から新システム の流れとしても、連携するシステムを書くのを絶対に忘れないとあります。
書籍の図にちょっと書き足すとこんな感じかな。
解説
システム管理者が「不正アクセスを監視する」のなら、それは逆に「システム管理者に対し、不正アクセスを監視できる仕組みを提供する」という要件を 定義しないと機能が実現できず漏れてしまう 、とあります。
なので、「この人が必要なものって他にあるかな?」と指差し確認できる必要があるよ、と。よかったさっきの認識間違ってなかった。
また、連携しているシステムやソフトウェアがあるなら、連携先の要求に応える仕組みを要件に追加しなくちゃいけない。 場合によっては連携先に追加や変更を依頼する必要も出てくる 。それをこの時点で洗い出すということと理解しました。
特に移行元のシステムがある場合、移行に必要な要件(データや一時的な機能などかな)、並行稼働のための要件が想像以上に出てくるよ、と。それらを常に確認できるよう、利害関係者(ステークホルダー)としての、連携するソフトウェア、システムを必ず記載すること、とあります。
感想
新しいシステムですから、なにがしかのデータ設計変更、もしくは作り直しが発生し、データベースが違ってくることの方が多いでしょう。
普通ならデータベースも刷新だと思いますし、その間の並行稼働やデータ移行は各所で苦労しているのを見かけますし、話題が尽きることもない気がします。
関係するものは最初から全部洗い出すのは、言われてみれば当たり前ですけど。普段からずっと使っていて当たり前になっていたり、滅多に連携しないけど重要なシステムがあったり、意識から外れてしまう、言語化されない、ということがあるよな、と思いながら読んでました。
連携する内容も忘れずに
連携先を書いたら、何を連携するのか描きましょうねと。全部書き切る必要はないよ、というのは登場人物(利用者)のところと同じです。極端な話として、移行先との連携は「移行対象データ」とだけでも構わないとあります。
そこに意識することができるのがまずは重要なんだなと理解しましたし、何も書かないとミスの遠因になるということなので、やはりそういうことだなと思います。
というわけで自分なりに書籍から内容を書き足して図にしてみます。
利用者不在のものも連携対象
IoTなど、利用者不在のセンサーコンピューティングでも、そのセンター端末がステークホルダーでもあるし、連携先でもある、というようなケースもあるよ、とあります。
その場合もきちんと明記しましょうね、と。
複雑なIoTの環境を構築しているのなら、書いておかないと絶対に漏れるなってのは容易に想像できます。
余談ですけど、農業でもIoTが利用されていて、ビニールハウスの温度湿度管理や、農作物の様子など、いろんな使われ方をしてる場合もあるなって思うし、これがクルマなら、これまた様々なセンサー類があるよなって思いながら読んでました。
全体像を魅力的にお化粧する
全体像を作ってきたわけですが、全体像はパンフレットのようなものでもあり、誤解を招かない程度に装飾するとあります。
社内業務システムならば、利用者つまりスタッフへプレゼンテーションもするでしょうと。お化粧にはUIイメージなども加え、より魅力やメリットを感じてもらわないと、先行き心もとないよね、ともあります。
使ってもらう人に魅力的だと期待してもらえるほうが良いですよね。(過度な期待を持たせない程度に)
というわけで、この全体像の枠内が今回の要件定義の対象範囲、つまりスコープであり、引き続きこの枠内を掘り下げていきます、ということで Chapter-08 に続きます。
読んでみて
登場人物から、連携するソフトウェアやシステムを書いて、全体像を把握する。それをスコープとする。今までなんとなく感覚で書いてたものが 明確な理由と根拠を示されながら解説された ことで、わかってるけど説明できなかったことが、なんとか説明できるレベルにはなったと思います。
で、研修でも出てきたんですけど、この説明ができないとプロとは言えないよね、ということがよくわかります。
当たり前のことなんですけど、その当たり前に敏感であれ、という話も聞けて、それは要件定義だけじゃなく、コードを書く場合にも言えることだなって思いながら研修を受けてました。
今日の研修では、要件定義するには層がいくつかあるという話もありました。
- ゼロ層
- カスタマージャーニ、カスタマーエクスペリエンス
- このソフトウェア、システムでBeforeがどうAfterで幸せになるのか
- 第一層
- ユーザーシナリオ、ビジネスシナリオ
- とにかくユーザーが何をやるのか書き出していく
- 第二層
- サービスシナリオ
- 業務側が何をするのかを、ユーザーシナリオと1対になりながら書き出していく
- 第三層
- 操作シナリオ、UI
- 操作の流れ、ユーザーが触れる部分
- その先
- ソフトウェア要件
で、この層を意識しつつ、それぞれの層で抜け漏れなく、かつシンプルに分割していく。これって僕らが普段やっている単一責任の原則にも繋がるよなって思いました。
ここら辺の、いわゆるプロセス設計の話は別の書籍「はじめよう!プロセス設計」に詳しいので、次の課題図書だったりもします。
引き続き学習しながら、プロセス、要件定義からコード、運用まで、単一責任の原則(もちろんそれ以外もですが)を意識しながら今後の仕事を続けていこうと改めて思ったりした次第です。
追加変更しやすく。それは実装以前に始まってるんだなって思ったりした今日でした。
学習記録:12月19日(水):はじめよう!要件定義 Chapter-07 [準備編]全体像を描こう(前編)
これは 俺のインプットアウトプット記録 Advent Calendar 2018 の19日目のエントリーです。
昨日は要件定義からかなり脱線して、家事育児をどうするかを考えてたりしました。結論は 家事育児は生き物、人間のコピーを作れないのと同じ ってことがわかりました。個別に切り出してタスク化することはできても、それは家事育児を生き物として扱ってる人からみたら本質の解決にはならんよ、ということを学びました。
閑話休題。
というわけで、前回の 学習記録:12月18日(火):はじめよう!要件定義 Chapter-06 [準備編]企画を確認する(つづき) に引き続き要件定義の学習を進めます。今週はずっとこれです。
Chapter-07 [準備編]全体像を描こう
どんなものができたら嬉しいのか、を描いていくんだろうな、という予想をしながら読み進めます。
全体像を描くプロセス
企画を確認(プロジェクト仕様)したら、これから作るソフトウェアの全体像(オーバービュー)を描こうとあります。
仕事とは行動と成果がセットなので、という意図で以下の図が書かれているんだと思います。
- 材料:企画
↓ - 仕事:全体像を描く
↓ - 成果:全体像
全体像とは
確認した企画の中の、 「何を」の部分をビジュアルに表現したもの 、コンテキスト図と呼ばれる場合もある。
利用者が何を使ってどうなるのか、を大枠で書いていくのかな、と想像します。
描き方のポイント
緻密さよりも大枠で、とあります。よかったあってたっぽい。
大枠の理解を共有することが主眼であり、この枠を超える要件はスコープ範囲外だということが関係者に伝わるものを描く、とあります。
なるほど、今まで僕はちょっと誤解してたな。全体像を描く=必要と言われてること全部を「納まるように描く」ことあったなって思いました。
んで、今から作ろうとするソフトウェアのパンフレットを作る、企画から確認したプロジェクトの紹介から、全体像として プロジェクトの成果としてのソフトウェアの紹介 を作っていくことだとあります。
- 材料:企画
↓ - 仕事:ソフトウェア開発プロジェクト
↓ - 成果:ソフトウェア
全体像を描く理由
これは企画を確認する理由とほぼ同じで、 何が出来上がったら完成なのか という問いに こういうものを実現しようとしているんだよ と提示できるようにする、ということとあります。
なので、要件定義そのものじゃなく、その前段階で描かれていて然るべきものである、と。
よくある話
企画書の一部に「実現する機能の例」としてスクリーンショットが貼られていることがあるが、これは断片的であり、全体像ではないし、全体像ではないのに全体像っぽい資料に描くことで、逆に 目に見えない重要な機能が漏れることがある とあります。
で、その重要な機能とは 実現できて当たり前 と企画立案者が考えているためであり、当たり前のことに対しては あーそりゃそうよね って感じでぞんざいに扱うので、重要なのに忘れられがちだよ、と。
結果として、次の要件定義の段階でも大雑把に検討されたり、そもそも忘れたれたりするぞ、と。
要件定義って 企画者と、ソフトウェアを実現する側の当たり前を漏れなく定義するもの だと僕は認識しているので、あーなるほどな、そうだよな、って思いながら読んでました。
なので、指差ししながら「こういうことを実現するよ」と言える状態にする、上空からの俯瞰図を用意する、とあります。
全体像を描く手順
把握できればどんな形でもいいけど、最低限これだけは欲しいよね、ということで解説が始まります。
ソフトウェアを真ん中に置く
- 真ん中に四角を描く
- これが今回作るソフトウェア
というわけで広いキャンパスの真ん中に、ぽつねんとソフトウェアを描きます。
利用者を配置する
ソフトウェアを利用するあらゆる人を描く感じですかね。
利用者が行うことを書く
それぞれの利用者に、このソフトウェアを使って行うことを書き込んでいきます。おお、全体像っぽい。
解説
全体像を逆からいうと このソフトウェアは利用者に対してこういうことを行えるようになることを提供する ことを示すとあります。
細かい機能は書ききれないし、要件定義を進めていくと修正なども出てくるのは大前提、とはいえ 全体像が杜撰だと合意形成が迷走しやすくなります よ、と。
んで、全体像を描いていくうちに、意外といろんな疑問が生じるので、要件定義の前にたくさんのことが確認できる。ゆえに この時点での疑問はしっかり確認を取り、その確認結果を、前行程の企画書、本行程の全体像に反映 させましょう、という内容で、全体像を描く手順が締められています。
この時点ですでに、前工程との回転が始まり、ブラッシュアップがされていくのだな、と認識しました。
読んでみて
なるほどこれをやれば、当たり前を見える化できるな、と思いましたし、発注側の業務の当たり前は、おそらく発注段階で必ず漏れるんだろうなって思いました。
実際に漏れてる要求の方が圧倒的に多いし、以前RFPの仕事をした時も、ソフトウェアを開発する際に必要なもの、という観点でお客さんに接した記憶が蘇ります。
要件定義って 企画者と、ソフトウェアを実現する側の当たり前を漏れなく定義するもの だと僕は認識している、と書きましたけど、まさにこれを漏れなく見えるように落とし込んでいく工程なのだなと思っています。
余談
僕がこの業界に入ったのは1992年、バブルが崩壊したと同時でした。今から見ると、まだまだ旧態依然とした体制だったし、古い言葉の定義から、新しい世界へと一生懸命変わろうとしすぎて、言葉ばかりが一人歩きしていた時期でもあったなあと思います。
が、古いと言っても悪いわけじゃなくて、枯れた言葉や技術って、普通に有用だったりするし、むしろないがしろにしてはいけない筆頭になることの方が多いと僕は思っています。
何が言いたいかというと。
上流工程、下流工程っていう表現はなんだかアレなので別の表現を使った結果、かえってわかりにくい場面が往往にしてあるな、ってことです。
いいんですよね、上流下流で。別にどっちが偉いわけでもないし、使役されるわけでもない。
どっちもがないと何も生まれない。
けど、これも日本的文化なのかもしれませんが、職人気質をずっと引きずっているがために、つまんないところで民族的なプライドが顔を出すのかなあ、などと妄想したりもしました。
余談2
先日の研修でも面白い話が聞けて、英語圏と日本語圏ではそもそもいろんなことが違うよ、ってことがありました。
英語圏の彼ら、特にアメリカは、ジーザスに誓いを立て、自分の言葉と行動と結果に嘘偽りがないことを無意識に証明しながら動いている、というような意味のことでした。それをやることで、死後の世界が約束される、ってのが染みてるんだよと。
だからこそひとつひとつの意味を明確にしていくし、そこに自分は何ができて何ができないのかはっきりさせるし、呼ばれたMTGでの役割やMTGのBefore-Afterの定義が曖昧な場合は「なんやねん」っていうし、などなど、興味深い話でした。
ここはもっと思考を深くして、色々検証したいなと思ってはいますが、主題と大きくそれるのでこの辺にしときます。
別に日本の文化を否定してるわけじゃないんですけど、そう考えた方が自然に仕事ができるよな、という話のうちの1つとして書いておきたかったのでした。
というわけで
小出し小出しにいきますが、研修が終わってその結果をインプットし、アウトプットし、回転させるまでは、しっかりとやっていくぞ。