orange @[email protected]

cat、本来はファイルを繋ぐコマンドで表示できるのは副作用なのかなぁ。

まさにそこで、つまり「業務用のツールはモデルが明確である必要がある」という主張になる。

GitHub 然り Redmine 然り、ツールそのものは汎用的だけど、それらが管理するデータや機能については十分に限定的なモデルが定まっている。
対して、 Excel は「マス目 (方眼とは限らない) であり参照があり計算ができる」くらいのガバいモデルしか提示しない。そりゃ業務を落とし込んでも正規化できるわけないわな

まあそれはそれとして、本質的困難を乗り越えることを必要とせずかつ自明であるようなユーザビリティ改善については当然行うべきではある

人間の方が柔軟で、かつ安定的にパフォーマンスが悪いので、本当に効率化したいならどう考えても人間が道具に合わせるべき

好きなメーカーばっかやん！

「Tough(厳格)とは、『我々は、なぜそうするのか？』、『我々は、なぜ失敗に至ったか』について、我々自身が常に説明可能な状態を維持することだ。結果を受け止める責任について妥協と言うものは今後存在してはならない。」

ジーン・クランツのスピーチ原文＞＜
"...Tough means we are forever accountable for what we do or what we fail to do. We will never again compromise our responsibilities ... "(以下略)

ジーン・クランツのスピーチ＞＜

"From this day forward, Flight Control will be known by two words: Tough and Competent. Tough means we are forever accountable for what we do or what we fail to do. We will never again compromise our responsibilities ... "(以下略)

wikipedia日本語版の訳
"今日より以後、管制室は二つの言葉で知られることになるだろう。タフで有能であれ（Tough and Competent）だ。タフとは、自分がやったことや失敗してしまったことについて絶えず説明責任を持つということだ。自分の責任について妥協することは決してあってはならない…。"(以下略)

https://www.atmarkit.co.jp/ait/articles/1909/18/news009.html
>>
ネガティブなフィードバックをする際にやってしまいがちなのは、相手の、過去の言動に目を向けて、「なぜ、その問題行動をしたのか？」という原因追及です。そして、原因を取り除くことによって、問題の状況を改善しようとします。

一方、本来のフィードバックとは、エアコンの温度を制御するように、まず、目標値（理想）があります。それに対して現状と比較します。目標値と現状の間に差があれば、目標値に近づくような改善策を立てます。
<<
仕事の目的にすごくこだわる人が、前者のようなフィードバックをするのをよく見かける。なぜフィードバックの目的にはそこまで無頓着なのだろうか、と思う。