上記を読んだ。身近に経験したこともあったのでメモ
whyから始める
これ。何をするにあたっても一番大事かも。指示を受けた時「なぜこのタスクをするのか」をすり合わせたり、顧客の要望を受けたら、「なぜそれをしたいと思っているのか」を確認する。whyというより、モチベーションに近いかも。
この擦り合わせ作業を疎かにしてしまって、やらかした失敗もある。指示通りやったのに、リテイクの指示があった、とか。指示のタイミングでは言われなかったことを責められたり。
受け入れテスト表を作ってーーと言われて、、技術者視点の粒度で作ると、「お客様提出用だから粒度は粗く網羅的に出来るようにしてほしい」と言われて再作成したりとか。
指示や要望は目に見えるけども、その裏側には見えない経緯や動機が詰まっている。言葉で伝えられる内容は限界があるので、なぜ取り組んでいるかを深掘りしていきたいところ。
機能を考える前に業務フローを設計する
これも納得の視点で。ビジネスレベルで考えると、既存の業務フローに対してシステムを合わせるのが常だったりする。まあこの辺は、システム側に都合の良いように業務フローを変えるFitToStandardとか、DXだとかそういう改革案は出ているけどまだ浸透してないっぽい。まあそれはそう
となると、ビジネスモデルとシステムはきっても切り離せない関係となる。具体的には、業務のフローとヒトモノカネの動きを知り、既存の機能とのマッピング作業が必要になってくる。
システム屋だった身としては、システムさえ見ておけばよかった。こういう実装をするには、何をすれば良いか…と言った具合。また非要件機能や保守性を意識していれば良かった。
ただ、whyを尋ねることにも通じるが、全体像を把握しておかないと、成果物にギャップが生まれる可能性もある。僕自身凝り性な性格なので、モチベートや立ち位置を意識しておきたい
こと設計を含めるのであれば、この意識改革も大切だなあと。