パスワードを忘れた? アカウント作成
13799971 journal
日記

delta-keeperの日記: 「設計根拠を示せ」という話題 7

日記 by delta-keeper

最近、比較的大きな案件に参加してる。

今は設計工程で、何かについて「設計根拠は?」って聞かれる。
質問の相手は社内のPL、もしくは諸先輩方。

昔からこの手の質問が苦手なので、不具合ゼロなどの実績で上手く質問を回避しているのだが、この案件はそういうことはできない。
1つの機能やI/Fが色々なところで使われており、少しの変更が使い勝手に強いインパクトを持っている。

まぁそんな訳で、日々調整と質問攻めにあっておりヘトヘトなんです。

ところで、設計根拠が無いと議論できないというのは非常によく分かるから、重要性は否定しない。
だけど設計根拠(思想?)なんて個々で異なる訳だし、それをいちいち精査するのかと。
「処理フローのここに何故分岐が必要なのか?」とか「なぜI/Fするメッセージにこのデータが必要なのか?」等
聞かれたら社会人という立場上、回答はする。

だが、その質問で得られた回答から得られるものをよく考えてから質問して欲しい、と僕はいつも思っています。
質問したら、必ず何らかのフィードバックをする。是非徹底して欲しいです。

この議論は、delta-keeper (31927)によって テキ禁止として作成されたが、今となっては 新たにコメントを付けることはできません。
  • 「立法事実」を出せ、みたいなモノかと
    技術屋で言う設計思想や、政治家で言う政治的立場は個々に違っていたとしても、間違っていたり、いい加減なデータに基づくのはダメ(ちゃんとユーザにアンケートを取って要望が有ったので→実はアンケートを取ったユーザは1桁台前半)、顧客や他部署や上司に説明したのとは別の理由での設計変更もダメ、今のところ、不必要な機能なんかもダメ(法律で言うなら、火星移住禁止法が必要なら、火星移住が可能になりそうになってから議論しても遅くない)、って感じじゃないかと

  • 私もその質問攻めで疲れた事があります
    良い面は、その質問に答えることで気づきが深まってよりよい答えが出る事ですが、
    よくある状況としては質問攻めに答えることができても、ただ疲れて終わるだけということ。お互い得られるものはコスパ的に良くない

    このときは2つ疲れる要素があると思っていて
    ・思考回路で無意識にカットしたものを思い出さないといけない
        根拠を説明する際、こういう選択肢がある中でこういう理由で選びましたという時に、ありえない選択肢は自分の思考の中で自動でカットしてしまっています(候補にもあがらない)
        それなのに、なんでその選択肢がないんだとか、何でそれを選ぶんだとか言われてしまう。では他に何があるのですかと訊いても、ダメ案しか出てこない。
        そういうダメな案をわざわざ考えて拾い上げて、これはこういう理由で話にならないんですなんて説明するのが大変で疲れる

    ・根拠を説明した結果、根拠なしで否定される
        解が複数あるものを並べて、こういう理由で選びましたと言っても納得できないと言われてたら説明は失敗。せめて何で納得できないのかまでコメントを返さないといけないのでは?
        コメントなしで否定されて、それについて考えるてまた説明するというのにとても疲れる

    • 実はこのプロジェクトは経験した中で一番参加人数が多く、しかも
      自分の担当しているサブシステムがその他サブシステムのI/Fポイントになってます。
      各サブシステムはI/F仕様にそれぞれの言い分があるらしく、逐一それをヒアリングしてあげる必要もあり、結構面倒な役回りであると自覚しています・・・。

      > ・思考回路で無意識にカットしたものを思い出さないといけない
      これ、本当にコスト高くて嫌になります。
      人の分の思考を自分がやるってのは、作業が増えるだけで全くうれしくない・・・
      親コメント
  • > だけど設計根拠(思想?)なんて個々で異なる訳だし、それをいちいち精査するのかと。

    どっちかというと、根拠がないようなマズいのを弾くため、かもですね。
    たしかにインタフェースや内部の構成での根拠が経験則だけ(うまく説明できない)と、複数の手段からそれを選ぶ理由くらいは説明できないとまずいだろうしなあ。

    # 自分も苦手

    --
    M-FalconSky (暑いか寒い)
    • by minet (45149) on 2018年12月23日 12時14分 (#3538516) 日記

      状況を把握できているのかを確かめるためにちょっと掘ってみる、というのはありそう。
      あと、昔の上司が、つついてみて対応が変わるようなら、そいつはまだ成長過程にある、とか言ってた記憶が。
      なんにせよ直接その工程や案件と関わることではない、もっとメタな何かが狙いかもしれませんね。

      親コメント
  • もう15年も前ですが、デバイスの商品化開発をしていました。
    最終的に帳尻が合えば動くので自由に作っても良いのですが
    不具合時に対処が変わったり、マイナー変更品を違う人が
    担当するときに困るので、皆で設計(推奨)ルール集を作りました。
    これはルールと根拠(データ)をまとめたものです。

    作るときは面倒ですが、一旦作ると運用が楽でしたね。
    頭を使う必要のある部分以外は、設計ルールに従えば良いので。
    ただ安心したい人への処方薬にもなりますしね。

    今いる部門はその辺りが疎かでたまにイライラする。
    自分の役割が基礎開発なので、あまり口出さないけど。
  • >設計根拠(思想?)なんて個々で異なる訳だし、それをいちいち精査するのかと。
    同意。「設計根拠を示せ」は管理職の人が良く言う。

    設計の妥当性を示せならまだわかるんですがねぇ、、、

    で、最近は、客先からもよく聞くフレーズとなっております。
    よくよく聞くと、客がサービスではなく、システムの構成と
    仕組みを理解できてないからという事がわかった。

    --
    髪を切るべからず。
typodupeerror

コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell

読み込み中...