今回の発端は、こちら。
https://twitter.com/saya1001kirinn/status/1093441567493316614
アジャイル開発にて納期が過ぎてて遅れている状況で、 詳細設計はなく、画面設計には書かれていないけど、ここはお客さん的に必要になるだろうとか、ここに入力制限かけておかないとシステムロジックが破綻するのでは？というところが出てきたらその都度上に確認して実装しますか？？
A) 現段階の仕様のまま実装。お客さんに指摘されたらする
B) 現段階の仕様で実装。お客さんに見せる時に伝えはする
C) 上に確認をとり実装(納品に更に遅れは生じる)
D) 確認とらず実装(どちらにせよ後に必要になるから)
A～Dは、語るのに必要そうなんでおいちゃんが勝手に採番しました。
さて。
簡単な前提条件としては
・詳細設計はなく、画面設計には書かれていないけど、ここはお客さん的に必要になる
・ここに入力制限かけておかないとシステムロジックが破綻する
ってな課題に対して「ど～する？」っていう疑問でございます。
まずAは、基本的に「悪手」です。
なにが悪手って、顧客側から見たら「こいつらプロフェッショナルな面して金取ってるくせに、俺らが指摘しないとこんな事にも気づかない/気づけないのか？」という疑念を抱かれる事が多いために、悪手です。
勿論「気づかれなくてそのまま納品」って可能性も博打的にあるのですが、それで実際に「必要になったり」「問題が起きたり」したら、事前に分かってるよりももうちょっと「緊急でタイトで厄介」になる可能性が高いので、原則として悪手です。
Bは、基本的に「悪手」ですが、選択せざるを得ないシーンもあります。
色々とアレがナニな話も絡むので詳細は伏せますが、まぁ「やむを得ず」というシーンは、割と、色々。
ただこの場合「詳細設計はなく、画面設計には書かれていない」責任分岐点とかコストとか費用とかの話を置いてきぼりにしすぎると後で痛い事になりがちなので、その辺はしっかりと押さえておいたり〆ておいたりしたほうが無難です。
Cは、本来的には「この選択肢の中ではベストな選択」と言えます。
ただ「遅延」に対するお客様の反応(と、今までに積み上げてきたポイントに起因する会員ランク( https://gallu.hatenadiary.jp/entry/2018/10/11/234610 ))によっては、なかなか切り出し難いケースというのも無くはない、のが現状ではございます。
その場合、Bに限りなく近いC、とか、まぁグラデーションが出てくるのかなぁ、と。
で、本題(やっとかい)。
Dは、定期的に見かけるのですが、実はこれ、結構な「悪手」である可能性が高いものでございます。
かみ砕いて。
まず端的に、発端が
・詳細設計はなく、画面設計には書かれていないけど、ここはお客さん的に必要になる
・ここに入力制限かけておかないとシステムロジックが破綻する
なのですが。これ「本当にそうなの？」っていうあたりから、まず検討が必要です。
もちろん「設計時に抜け落ちている」可能性もあるのですが、一方で「別にいらない/なにか別にガード手段がある」等、「実は必要ではなかった」なんてケースも少なからずあるんですね。
おいちゃんの観測の範囲内だと
・「ちゃんとお客さまに確認する人」の提言は、実際に提言を受け入れたほうがよいもののほうが多い
・「ちゃんとお客さまに確認しない人」の提言は、提言が蛇足だったりお客様のニーズと逆方向だったりする事が多い
ように思われるのですが、どんなもんでしょ？？
それは、本当に「必要」なんでしょうか？ 「あったほうがよい」ではなくて「ないと困る/システムが破綻する」？
で、もう一つ。
「じゃぁ必要」であるといったん仮定をして(そうしなきゃ話が進まん)。
「そのコストはどこから捻出されるんでしょ？」というお話。
事前の設計やらそれの合意やらは、ほぼ確実に「その案件の金額」に関連してくるので。
その辺の調整抜きに「これは必要だと思うから余計に手を動かしておこう」は、割と本気で「余計というより蛇足」になる可能性が、色々と否定できないんですね。
比較的無難なところで「その着手は無駄だった」から、比較的面倒なところで「前回も無料で修正してくれたんだから今回も無料で修正してくれるべきだ」っていう厄介な顧客教育の方向性まで、まぁ色々。
この辺で、個人的には「黄金律」とかいうあたりを想起する事が多くて。
黄金律自体は、以前に https://gallu.hatenadiary.jp/entry/20120404/p1 でも言及していたことがあるのですが。
「自分が良いだろうと思うもの」をそのまま相手に提供して、それが「本当に相手にとってよいものである」かどうか、ってのは、個人的には割と「びみょ～～」だと思ってるんですよねぇ。
割と定期的に「余計なお節介」だったり、下手をすると「相手にとってはbadな提案」である可能性だって、無いわけではない、わけで。
「自分が良くないと思うもの(銀の教訓)」はまぁ「相手にとっても良くない」可能性も高いので、「ここに入力制限かけておかないとシステムロジックが破綻する」あたりはまぁまだ「提言をしておいたほうがよい」ような気もするのですが、とはいえその辺も「工数と納期とご予算次第」ってところもありますしねぇ。
この辺、自分の善意だけで「きっとこれが必要なはず！！」をあんまり推し進めると、それが「必ずしも良い結果を招き続ける」とは限らないんですよねぇ。
「地獄への道は善意で舗装されている」なんて言葉もありますし。
或いは。
「カウボーイコーディング」とイメージ的にかぶる事も多いんですよねぇおいちゃん的に。
一端、カウボーイコーディングについては
https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA#%E3%82%AB%E3%82%A6%E3%83%9C%E3%83%BC%E3%82%A4%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%81%AF%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA%E3%81%A8%E3%81%AF%E7%95%B0%E3%81%AA%E3%82%8B
カウボーイコーディングは、各々の開発者が「自分が良いと思うプログラミング」をバラバラに行うことである。好ましくない状態を指すのに使う言葉であり
https://tmytokai.github.io/open-ed/activity/scrum/text01/page03.html
チーム内の開発者達が各イテレーション内でコミニュケーションを取らずバラバラ好き勝手に開発をおこなう状況を考えてみましょう。
このような開発手法を「カウボーイコーディング」と言います。
https://www.nttpc.co.jp/yougo/%E3%82%AB%E3%82%A6%E3%83%9C%E3%83%BC%E3%82%A4%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0.html
情報システムやソフトウェアを開発するとき、それぞれの開発者が自分が最も良いと思う手法で作業を行って、統制が取れていないこと。
あたりを参照してくださいませ。
システム開発……に限らんと思うのですが。
複数人が関連している以上、「必要なコミュニケーション」は、必要ってぐらいなんだから当然に「必要」なものでございます。
別にコール・ド・バレエのように「(ほぼ)寸分の狂いもないほどに均一」であれ、とは思わないのですが。
とはいえ、何のためにコーディング規約が存在するのか？ とか、もう少し考えてもいいんじゃないかなぁ、と思う瞬間は、少なからずあるものでございます、し、それ以前に「この言語を使っているんだから」とか「このフレームワークを使っているんだから」とかいう暗黙の了解も、限度や程度はあれど、多少は存在していると思うのです*1。
そういった時に。
いや別に「積極的に四六時中、のべつ幕無しに語り続けろ」とは思わないのですが、必要なコミュニケーションすらまともに取らずに「絶対領域( https://gallu.hatenadiary.jp/entry/2018/12/01/112949 )の中にこもりっぱなし」というのも、果たして如何なものなのかなぁ？ と。
で、そういった系譜の延長線に「確認とらず実装」っていう選択肢があるような気がする……というか実際に幾度か実例を見ているので*2。
その辺を考えると。
選択肢のDは「一見、親切に見える」のですが、実際には「地獄へ続く善意＋コミュニケーション忌避」に起因する「結構、山盛りの地雷」がある可能性が高いんですよねぇ。
…………なんていうことを考えながら、くだんのツイートを拝見しておりました。
その辺、他の人はどうなんでしょうかねぇ？
とかいう疑問などを投げかけつつ、書いてみました。
追伸
「そもそも"アジャイルで納期"ってなんだよ？」ってのは、一旦、丈夫な棚の上に上げておいてくださいませ。
