[ 新規に投稿する ]

---

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 リスト」の公開を提案させていただいた次第であります。 どうか今後ともよろしくお願いいたします。

[ △ ]

---

[ 新規に投稿する ]