low hanging fruit

どんなプロジェクトでも、要件を出す側（ユーザーなど）と開発者の綱引きが行われます。限られた時間とリソースを考えると、すべてテンコ盛りにできるはずはないわけで、優先順位付け(Prioritization)が重要となる。ここでいつも問題になるのが「ユーザーはいったいどこまでシステムがわかっているのか」です。「すべてユーザーに聞け」という格言もありますが、「ユーザーは常に正しいわけではない」というのも現実です。「○○は絶対に必要な機能だから、これをはずしたら今回のリリースの意味がない！」と罵倒され、結局リリース後、その機能はそんなに使われなかった・・・という例は星の数ほどみてきました。特に自分のフィールドが、翻訳者や通訳者など言語の専門家がかかわるシステム開発なので、非常に特殊な機能や性能が必要とされる。残念ながら「言語の専門家」にはコンピュータに疎い人が多く、そもそも「何が必要か」という要件の掘り起しからしていかないと、ただ単に「どうしましょうか」という御用聞きでは通用しません。そういったときに、どう優先順位をつけると「幸せ度」が最大化するのか、常にその疑問と格闘することになります。あるひとつの機能が重要だといわれても、そこに時間を集中させるよりも、UI上のちょっとした機能などをいくつかまとめて盛り込んだほうが生産性が上がることはいくらでもあります。そういったときに、バグなどのリスクを最小限にした上で「さっとできる」要件は何かを考えるのが非常に大切になるわけです。
前段が長くなりましたが、そういった「さっと仕上げることができる機能」のようなことを指して、low hanging fruitといいます。
We could release one quick enhancement version with some low hanging fruits. （簡単にできる機能をまとめて、ちょっとした拡張バージョンを出すこともできるよね）
ここから、low-hangingという表現が「簡単な」という意味に転じて使われます。
We need to achieve 100% success in low-hanging issues. （簡単な問題に関しては完全やらないといけない）
さて、逆に「困難な」という意味でhigh-hanging fruitという表現も使われますが、low-hangingと対照的に使うケースが多いと思います。本当にどうしてよいかわからない難問であればconundrumといえば実感がこもります。
It's quite a conumdrum.（それはたいした難問だ！）