TODO リストの公開のお願い	No.42019
Fzok4234 さん　25/06/23 09:48
おはようございます。Fzok4234 です。 最近、本会議室において、ユーザーからの「○○ができない。どうしたらよいの か?」という問い合わせに対して、 「現状ではできないです。ご意見参考にさせていただきます。」と回答されるケース が大変目立ってきています。 直近のものを挙げると、 https://www.maruo.co.jp/hidesoft/2/x41948_.html#41991 https://www.maruo.co.jp/hidesoft/2/x41981_.html#41984 https://www.maruo.co.jp/hidesoft/2/x41988_.html#41990 といった感じでほぼ連続して続いています。当方でも最近、ブックマークの 16 KB 制限に関して話題を取り上げ ましたが、やはり https://www.maruo.co.jp/hidesoft/2/x41993_.html#41996 という感じになっております。 そこで、ここ半年ほどの間でこのような言葉でスレッドが close されたのと同然状 態になった案件を確認しましたが、 その後の機能改善のための試みがほぼ全くと言っていいほど見られていないように思 われます。実際には、β版の 更新履歴にその案件に関する改善に向けての動きがほとんど見られない、といった感 じです。例を挙げれば、 当方が 1 年以上前に https://www.maruo.co.jp/hidesoft/2/x41085_.html#41085 として挙げた tags ファイルの文字コード問題も、その後の進展が全く見られません。 このようなやり取りを見て、問題改善のための機能の実装が「未来永劫」決して行わ れることがないような印象を 覚えます。正直言って、問題をわざと放棄したのではないかという疑念すら湧いてき ます。 その理由として、問題改善に向けたの動きの進捗状況などがユーザー側から全く見え ない状態であることが 挙げられます。ユーザーへの不利益に関することでありながら、御社の内部情報とな っていて外部から見えないため、 ユーザー側からは雲を掴むような感じです。 そこでお願いがあるのですが、今までの未解決であるユーザー提起の全ての案件の 　・問題解決の進捗状況。具体的にいつのバージョンまでに完了するかどうか。 　・実装の難易度。解決の障壁となっている技術的問題を列挙する。 　・優先順位。秀丸エディタの標準機能とするメリットの有無など。 を一覧にまとめた「TODO リスト」を公式サイトで公開してもらいたいです。 実例としては、GitHub の Issues に開発者自らが解決すべき課題を書き込むような 感じです。未解決の課題を 「Open」として目立つように取り上げ、解決済みの物は「Closed」として順次非表示 にしていく感じで、一目で 分かるようにしてもらいたいです。 この件に関しては、できるだけ速やかに対処してくれれば助かります。どうかよろし くお願いします。

[ △ ]

RE:42019 TODO リストの公開のお願い	No.42021
秀丸担当 さん　25/06/23 10:18
すみませんが、公開はしないです。 ご要望は承りますが、期待させてしまうと悪いので、要望の類は全てやらないものと 思ってほしいです。

[ △ ]

RE:42021 TODO リストの公開のお願い	No.42023
Fzok4234 さん　25/06/23 11:09
> ご要望は承りますが、期待させてしまうと悪いので、要望の類は全てやらないものと > 思ってほしいです。 ユーザーから提起された問題・提案に対して、せめてマクロを使ったユーザーが自力で 対処することが可能な解決方法の提示ぐらいは、提起されるたびにもれなく行ってい た方が よかったのではないでしょうか。

[ △ ]

RE:42023 TODO リストの公開のお願い	No.42024
(-L-) さん　25/06/23 12:15
>ユーザーから提起された問題・提案に対して、せめてマクロを使ったユーザーが自力で >対処することが可能な解決方法の提示ぐらいは、提起されるたびにもれなく行って >いた方が >よかったのではないでしょうか。 買い切りのシェアウェア（かつ、ここまで長期に最新OSに対応してきたソフトウェ ア）に、そこまで日々のサポートを要求するのは酷ではないでしょうか。 買い切りを判断した時点の機能で納得している筈のことですし、それ以上のバージョ ンアップが一切なかったとしても文句は言えない性格のものだと思います。 ユーザーが自力で対処できる云々は、そのために、このように誰もがその解決さくな どを提示できる場の提供までされています。 （要求するならば）解決方法の提供を受ける側ではなく、提供する側に回れるよう振 る舞うのが良いと思います。 個人的には、そこにリソースを割かれ新Verの公開が遅れるるよりは、たとえ自分の 要望方向とは異なるものだったとしても、何かしらの機能改善などでのバージョンア ップが、より早いサイクルで続いてくれるほうがありがたいです。 直近では、不採用だと思っていた重複行削除が、実際には採用されていたりと、その あたりのやりとりもひっくるめて楽しめるくらいが、シェアウェア系のユーザーとの 距離感だと思っています。

[ △ ]

RE:42024 TODO リストの公開のお願い	No.42025
Fzok4234 さん　25/06/23 14:29
返信ありがとうございます。 ---------------------------------------------------------------------------- -------------------- 一応、当方では秀丸エディタが Microsoft Office などのような大規模システムには 遠く及ばない 小規模なプロダクトであることは重々承知しております。 しかしながら、同時に秀丸エディタは小規模とはいえソースコードを始めとした開発 プロセスがユーザー の目に見えない「プロプライエタリ」なプロダクトであることも気に留めておくべき です。 世の中には、秀丸エディタよりももっと開発スケールの小さい、完全に個人開発かつ オープンソースの フリーソフトや Web サービスもたくさん存在します。このような極小規模な OSS プ ロジェクトに対して、 > そこまで日々のサポートを要求するのは酷ではないでしょうか。 > 買い切りを判断した時点の機能で納得している筈のことですし、それ以上のバージ >ョンアップが > 一切なかったとしても文句は言えない性格のものだと思います。 とおっしゃるごとくの無茶な要望を出すことは、確かに無理難題を開発元に突き付け ることにあたり、 歓迎されることではありません。 だが、たとえこのような極小規模プロジェクトにおいても、開発プラットフォームの  GitHub 上にて ユーザーから挙げられた Issues とか、あるいはプルリクエストに対するレビューと かを開発者が なおざりな扱いをして真摯に向き合わないことは、これもまた歓迎されることではあ りません。 一般的に開発者は、挙げられた Issues の返事として、これが解決可能な問題なのか をはっきりと示し、 解決の見込みがあれば Open のまま、既に解決したものは Closed にします。解決が 困難であると判った ときは、 　・実装の難易度が高いこと。解決の障壁となっている技術的問題の列挙。 　・優先順位が低い。要望された機能がプロジェクトの目的から逸脱するなど。 　・ユーザーが自力対応可能。 といった理由をきちんと示したうえで Closed にします。 実例として、当方で愛用している静止画ビューアーに NeeView という個人開発のフ リーソフトがあります。 https://github.com/neelabo/NeeView/ こちらの GitHub では上記に示した Issues の扱いが徹底しています。個人の極小規 模の OSS プロジェクトですら ユーザーからの各要望が実装できるのかできないのか、できないならその理由を表明 することがちゃんと 行われています。 翻って、秀丸エディタの方は、あくまで法人格を有するサイトー企画による開発で、 しかもソースコードが 非公開のプロプライエタリで、なおかつ有料製品であります。当然、個人開発の無料  OSS よりも「格上」に 位置しています。 ユーザーサイドが無茶な要望を出すのが好ましくない点は同じであっても、開発者サ イドが GitHub の Issues と 同等の情報を提供するのはごく自然なことであります。これができていないと、「格 下」である個人 OSS よりも サポート面で劣っていることになってしまいます。 今回の投稿は、秀丸エディタに自分勝手に特定の機能の実装を要望する「無茶な要 望」に該当するものでは ありません。あくまで情報開示の透明性という観点から、現状「格下の個人 OSS」よ りもさらに劣っている開発姿勢を 糺してほしいことを伝えるため、少し厳しめの筆さばきを行った次第であります。 ---------------------------------------------------------------------------- -------------------- また、 >> ユーザーから提起された問題・提案に対して、せめてマクロを使ったユーザーが >自力で >> 対処することが可能な解決方法の提示ぐらいは、提起されるたびにもれなく行っ >ていた方が >> よかったのではないでしょうか。 > > (要求するならば）解決方法の提供を受ける側ではなく、提供する側に回れるよう >振る舞うのが良いと思います。 とのことに関しても、「解決するためのマクロを丸々書いてほしい」というような、 他力本願な「無茶な要望」を 肯定するものではありません。 開発側からは、問題の解決に有用であるマクロの特定の文や関数の名前だけを紹介し てもらえれば結構であると 思っています。マクロ全文の作成を丸々依頼するつもりは毛頭ございません。あくま でマクロ作成の「ヒント」のみ 提供してもらって、後はユーザーが自力でマクロを組むという流れです。 ---------------------------------------------------------------------------- -------------------- 以上のことをまとめると、秀丸エディタがテキストエディタという「開発ツール」と 位置づけられている以上、 問題解決の主体はあくまでユーザーであります。しかし、ユーザーの力だけでは 100  % 問題解決できるわけでは ないので、クリーンな情報開示やマクロ API の提供という形での開発側からの協力 も必要不可欠となって おります。 これらの事柄を是非ご理解いただければと存じ上げます。

[ △ ]

RE:42025 TODO リストの公開のお願い	No.42026
(-L-) さん　25/06/23 15:50
格下呼ばわりされたその活動に関わる全ての人に対し、大変失礼だと思うことがない のでしょう。 そんな表現ができる考えの人とは世界線が違いすぎるので、私が議論する相手になり えません。故にノーコメント。（これに返事は要りません）

[ △ ]

RE:42026 TODO リストの公開のお願い	No.42027
Fzok4234 さん　25/06/23 17:23
「格上」「格下」とは、開発元が行うべきユーザーサポートのレベルです。悪しから ずご了承ください。

[ △ ]

RE:42027 TODO リストの公開のお願い	No.42028
(-L-) さん　25/06/23 17:45
>「格上」「格下」とは、開発元が行うべきユーザーサポートのレベルです。悪しか >らずご了承ください。 オープンソースを例にあげたのですから、その開発元とやらは、関わる人すべてを指 すと考えるのが普通です。 だから、GitHubを拠点にするようなオープンソースではIssuesを大事に扱うことも文 化のひとつでしょう。(各人が実装する際の共通認識にしていく） また、（私と世界線の異なる考え方をもつ）あなたが、これが上、これが下と上下関 係を定義しているにすぎません。 それぞれに文化、背景が異なり、ユーザーサポート始め、それぞれにやり方があるの で、それぞれに尊重されるべきで、そこに上も下もありません。 となりの文化を、こちらの庭に持ってきて声高に叫ばれても、そもそもが、それぞれ に尊重される話であると考えています。 故に、上だとか下だとかという発想自体が私にはありません。なので、あまりに考え 方が異なりますね。という話です。 そちらの考えが間違っているとか、そんな話もありませんし、しません。 それぞれに考えがあると思いますし、それも尊重します。 私とは考えがあまりにも合わない、ただそれだけです。

[ △ ]

RE:42028 TODO リストの公開のお願い	No.42029
秀まるお2 さん　25/06/23 18:14
僕がコメントするのもなんですが、ここの会議室の話とずれた方向に行ってしまった ようなので、すみませんがこの話は終わりにしてほしいです。 Fzok4234さんが秀丸エディタに対していろいろ期待されてることは理解しますが、正 直、開発者があまり乗り気でないという所が正直な所だと思います。 これはあくまで秀丸エディタの話じゃなくて僕自身の話ですが、会議室に書き込まれ た要望に対して正直に「出来ません」と返事すると、その後報復的にあれもこれもと 書き込み攻撃ともとれる質問の連発、要望の連発をしてくるユーザーさんがおられま す。そうなるとこちらも精神的に疲弊してしまって燃え尽きそうになります。そうい う過去の事例があるので、要望に対しては「検討します」みたいなあいまいな返事で お茶を濁すケースが多いです。 本当に検討していることもあります。 その辺ご理解お願いします。

[ △ ]

RE:42029 TODO リストの公開のお願い	No.42031
Fzok4234 さん　25/06/23 19:38
確かに、問題解決のための特定の機能の実装について、開発側があまり乗り気でない こともあることも 理解できます。その理由として、 　・実装の難易度の割にはユーザー体験の向上の度合いが小さい。 　・テキストエディタの機能としては過剰である。 といったことがあると思われます。 また、このことを明確に示せばユーザーによる攻撃的な報復書き込みを招いて現場が 疲弊するため、 その回避策として「ご意見参考にさせていただきます」とお茶を濁した表現を採用し ていることも よく理解できます。 ただ、今年の 5 / 20 あたりからから立て続けにこの「ご意見参考にさせていただき ます」との返答が 4 件ほど連続したため、会議室を眺めている当方でもさすがに「本音と建前の二枚舌 が充満して気持ち悪い」 という不快感を覚えてしまいました。 一応、今まで「ご意見参考にさせていただきます」と締め括られたやり取りを見てい ると、大半は マクロの紹介などユーザーが自力で対処可能な代替案が提示されておりましたが、残 りは何の案も 示されないケースもありました。 後者の場合、ユーザーは機能の実装をただひたすら待つことしか手を打つことができ なくなり、 問題に対して完全に「詰み」の状態となってしまいます。やはり「ご意見参考にさせ ていただきます」との 文言と「代替策の提案」とが必ずペアになっているのが理想的であると個人的には感 じています。 ---------------------------------------------------------------------------- ------------ 今まで当方においてもちょっと無茶な要望を挙げたりして開発チームを困惑させた時 期が確かにありました。 その度に代替策の提案を色々受けたり、新たな機能の実装に至ったりと開発側のキャ パシティーに 見合わない労力の増大を引き起こして、申し訳ないという気持ちからか、最近ではあ からさまな 機能の追加の要望は減ってきています。 ただ、だからと言って何か問題が発生したときに、それを我慢し続ければいいという わけにはいきません。 その時には開発側に何らかの助け船を求めることになりますが、その際に問題解決の 機能の実装が 早期に実現すれば、これほど嬉しいことはありません。実装が困難であることが判明 したため、 やむなく「ご意見参考にさせていただきます」との回答となった場合でも、その技術 的問題などの理由の表明 およびユーザー側での代替策の提案がきちんと行われてさえいれば、それほど苦痛を 伴わずに納得・了承 できます。 一番苦しいのは、やはり「ご意見参考にさせていただきます」と回答しておきながら、 理由や代替案が 全く提示されていない場合です。当然、素直に了承できるわけにはいかず、返答も攻 撃的にならざるを 得ません。 ---------------------------------------------------------------------------- ------------ 以上、長々と当方の思いを述べましたが、機能の実装が可能なのか不可能なのかにか かわらず、 「ユーザーに理解できるわかりやすい回答」を心掛けることこそが、問題発生時に事 を穏便に済ます カギであるとつくづく感じます。 その方法の 1 つとして「TODO リスト」の公開を提案させていただいた次第でありま す。 どうか今後ともよろしくお願いいたします。

[ △ ]

---