100 ポエムを目指してみています。問題を解くことと、問題そのものを小さくすること、どちらが大事か。
問題解決の基本となる「発生型問題解決」と「設定型問題解決」とは？問題解決力の重要性も紹介｜トヨタ式改善で現場を変えるメディア「改善ライブラリ」
デザイン思考の2nd step：問題定義(Define)｜西村 悠 /デザイン思考エバンジェリスト
問題定義 — Design Thinking Studio
お仕事をしていると、問題を解いたほうが良い時と、問題を解きつつ、問題そのものを小さくすることを考えて答えにするときがあります。ユーザーが問題としているものが既に非推奨の API だったりしたときに、その API を使うことをそもそもやめてほしいと言わないといけないのだが、初めからそれを言ってもダメで、お客様なりにその非推奨の API を利用し続けている理由を一応は聞かないといけない。
- まず問題を小さくできるか確認する。新 API へ移行できるならそれが最短経路
- 移行できない事情を聴く。互換性、既存システムへの影響、コスト、期限、など？
- その制約をふくめて、どうすればお客様の業務が継続できるかを考える
- その問題に対してサポート可能な選択肢を提示する
- 一時的な回避策、段階的な移行、影響範囲の限定、移行方法の案内等
ユーザーが解決しなければならない問題そのものを減らすことでも貢献したいと思うわけです。
以上、IT エンジニアのお仕事を雑多に考えてみています。
人に対するバイアスを取り除くには、どうすればいいと思う？ #ポエム - Qiita
「仕事ができる人」って、結局どんな人だと思う？ #ポエム - Qiita
早く答えることと、正しく答えること、どちらが大事だと思う？ #ポエム - Qiita
「分かりません」と言えることも、技術力だと思う？ #ポエム - Qiita
難しいことを簡単に話すのも、エンジニアリングだと思う？ #ポエム - Qiita
どんな人を見ると「技術力が高そう」と感じる？ #ポエム - Qiita
エンジニアの技量って、どうやって測ればいいと思う？ #ポエム - Qiita
「IT に詳しい人」と「IT エンジニア」は、何が違うと思う？ #ポエム - Qiita
「便利屋」と「エンジニア」の境界線はどこにあると思う？ #ポエム - Qiita
「何も作らないこと」が最善のエンジニアリングになることはある？ #ポエム - Qiita