search
LoginSignup
80

posted at

updated at

Organization

「技術的には可能です」と発声するその前に

技術者はよく、実装可否の問い合わせに対して本当はやりたくない・すべきでないと思っているのにやればできることだからと「技術的には可能です」と答えてしまいハマる⋯って本当ですか? 私は最低でもここ10年は「技術的には可能です」と発言した記憶がありません。なぜそう言うことがないかというと、可否の問い合わせを受けた時点で次のようなことを考えてしまうからです。

  • 運用は回る?
    人力操作が絡むフローがあるけど利用数が増えたときにちゃんとスケールする?
    休日深夜対応が必要になりそうだけど要員と人件費コストは確保できてる?
    カスタマーサポート対応激増しそうだけど(以下同文
    誤操作があったりしてデータの修正依頼が来たときに訂正しようがない要件っぽいけど大丈夫?
    エンジニアがDB直操作対応するサービスメニューが存在するけど事故リスク、工数コスト、今後の開発停滞リスクは織り込み済み? 事故の際の責任はエンジニアに?
  • 事故リスクは?
    操作ミス一発でテナントデータを他社に公開しちゃうことになる要件だけどリスク額はちゃんとコストに含んでいる?
    警告ダイアログを出すから大丈夫としてあるけど、警告ダイアログを読まずにOKを押すことがない人間っています?
  • セキュリティリスクは?
    新しい操作フローの追加で、ユーザーが無限に不当な利益を得られるようなコースが生まれてしまっていない?
    同じく、知ってはいけない情報を知れるコースが生まれてしまってはいない?
    同じく、できてはいけない操作を可能にするコースが生まれてしまってはいない?
    意図しないコースが生まれてしまっていないか検討しきれないほど、操作ルートマップが複雑化してしまわない?
  • 保守は?
    顧客対応の特別版を作ってしまって、今後の機能追加の際には本流にもすべての顧客対応版にも同じ改修を入れていく感じ? 今後の永続的な開発・QAコスト増は織り込み済み? 改修を計画するときにすべての顧客対応版の仕様と齟齬ないかまで毎回全部考慮していく?
    特別対応のためにロジックに特別フローを入れてしまって、今後すべての改修(以下同文
  • データ分析は?
    画面側の動作モデルを変更して、それでデータの意味論が変わってしまうと既存の集計・レポートロジックが間違ったものになり得るけどその調査棚卸し・修正の工数は積んである?
    データの変更と誤入力訂正がまたっく同じ操作になっているけど、それは集計・レポートの際に区別が付かないですよ、困りません?
    この機能の利用実績をレポート・分析する必要が間違いなく出てくるはずだけど、どんな履歴データを持っておきたいか検討済みです?
  • 利用増対応は?
    利用者数が今の10倍に増えたら、もうまともな時間では画面を表示できなくなりそう。
    利用者数が今の10倍に増えたら、カスタマーサポート対応も比例して増加するタイプの施策なので人件費増まで織り込んだらそもそも利益計画が成立しないサービスでは?
    利用者数が今の10倍に増えたら、バッチが突き抜けるようになってシステム動かなくなるのでは?
  • 法的な問題は?
    個人情報の無許可流用では?
    著作権の侵害では?
    顧客との信義則違反では?
    良俗公序に反するのでは? 公になったら大炎上するやつ、もしくは利用者のレピュテーションリスクが大きい

これらに引っかかってしまう場合、その対策工数も含めて考えたときに答えは「非現実的ですね」「技術的にも解決不能な問題を含んでいますね」にしかならないわけです。何か要件の筋が悪い、やりたくないとあなたが感じるときは、ちゃんと言語化すれば上記のような問題を複数含んでいるはずです。言語化して、技術的にも解決不能であるとちゃんと回答していただければと思います。

では「解決不能」と回答すればそれで依頼者は引き取ってくれるか。そうはならないわけですね。依頼者も依頼者で、解決しないといけない問題を抱えているわけだからです(そうでない、ただの思いつき爆弾の人の存在はここではおいておいて)。
そんなときに前に進むためには、「そうでなくこうすればあなたの問題は解決しませんか?」の案を返すことです。それも複数。

そのためには、その場のアクションとしては背景の深掘りが重要。セリフ回しとしては、「技術的にも解決不能な問題を多く含んでいます。問題解決に協力させていただきたいので背景について詳しく聞かせていただけませんか?」。

そして日頃からの自分のスキル養成として、どんな問題解決にも、設計にも、コーディングするにあたっても常に複数の実現案を出しては、それらのメリデメを出し、今回はこのデメリットを特に重視するからこの方法を取ると意志決定するというトレーニングです。

やり方が上から降ってくるだけで裁量がない仕事であっても、意志決定する直前のステップまでは考えて、「つまり今回ボスはこのメリットを重視していてこのデメリットを特に避けようとしているのだな」と解釈するところまではできますのでトレーニングは同様にできるはずです。ボスとの関係次第では、「今回は○○重視ってことですね、勉強になります!」とフィードバック。そしたら自分が思いついていなかった観点がもらえるかもしれないし、ボスがあまり複数案のメリデメを考慮しない人だった場合にはボスのことも一緒に鍛えられますね!

関連項目

この件と同様、問題解決を前に進めるためのセリフ回しのヒント集を最近書きましたので、こういうのもっと読みたいという方はこちらもどうぞ。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
80