misc.log

日常茶飯事とお仕事と

ASTERセミナー標準テキストというのが公開されています

ASTER、NPO法人ソフトウェアテスト技術振興協会というところがソフトウェアテストに関する研修資料を公開しています。

aster.or.jp

160枚弱の巨大プレゼンで、フォントや絵柄、色合いなどいろいろと手の入れ甲斐がある内容ですが、大筋のラインは筋の通った物になっているようですし、自社向けにアレンジすれば教育資料としてよさげな感じです。

参考にしたいところ、というわけで自分用の備忘録。

テスターちゃん 1巻

テスターちゃん 1巻

ソフトウェア・テスト PRESS Vol.7

ソフトウェア・テスト PRESS Vol.7

ファイル指定とフォルダ指定の指針

業務アプリだと、データファイルを読み込んでデータベースに記録したり、画面に表示しているデータをファイルとして保存したりというような処理がちょくちょく登場します。そのような処理の設計や実装方針で非常にぶれているような場面があったので、その際に行った行おうかと思ったけれどやめたアドバイスをちょっとまとめておきます。ほんと、初心者中の初心者向けの内容なのでベテラン勢は読む必要ありません。

ファイル指定ダイアログかフォルダ指定ダイアログのどちらを使うか

f:id:frontline:20190307122141p:plain
C# / SaveFileDialogの例

これは当然といえば当然なのですが、フォルダ指定ダイアログはフォルダを指定するだけなので、ファイル名などは指定できません。なので

  • ファイル名まで利用者が決める場合 …… ファイル指定のダイアログで、ドライブ、パス、ファイル名すべてを指定させる。
  • ファイル名が固定の場合 …… ログやエクスポートデータなどでファイル名が固定、または一定の書式に沿って自動命名される場合、フォルダ指定のダイアログでファイルの保存先を指定させるようにします。

このあたり、設計段階で「ファイル名は自由か、固定か」これを決めれば自然と方針が決まります。ぶれるところではないので注意してください。

フォルダ指定ダイアログを利用しなければならない場合

フォルダを指定するタイプのダイアログを使う場合、その用途は大きく2つに分けられます。

f:id:frontline:20190307121851p:plain
C# / FolderBrowserDialogの例

  • 1つ以上のファイルを保存する場所を指定させたい …… 1つ以上のファイル、それもファイル名はプログラム側が自動的に決めるようなものを保存する先を指定する場合に使います。
  • 2つ以上のフォルダやシステムの作業用フォルダなどを指定させたい …… システムがこの先ワークディレクトリとして使うような場所を指定する場合や、保存するデータが複数のフォルダ階層になった複雑なもので、その根元を指定したい場合に使います。

これを勘違いして、「指定したフォルダに、システム名をつけたフォルダを作ってファイルを1個保存する」なんて仕様を考える人がたまに居ますが、そのような場合はそもそも下記の点を見直してみてください。たとえばこんな感じ。「C:\指定されたフォルダ\MySystem001\」

  • そもそも、その「システム名のフォルダは必要か?」

1個のファイルを保存する先を指定するなら、極力、指定されたフォルダに直接ファイルを作るようにしましょう。わざわざ「システム名」とか「機能ID」のように、作り手の自己満足みたいなフォルダを作り、ユーザーが指定したフォルダから1段下層にファイルを作ることは混乱を招く以外何ももたらしません。なにより、システムIDやシステム名というものをユーザーが認識しているならいいのですが、昔ながらのシステムにありがちな「アルファベットと記号の羅列による本当のIDみたいなID」の場合、「何ですかこのフォルダ?」という質問につながる可能性もあります。

システム名や機能IDといったフォルダを作る必要があるのであれば、そのフォルダの場所をプログラムとして最初から固定にするか、最初に「そのプログラムのワークディレクトリ」として指定させたものを使い続ける、といったようにフォルダごと固定的な使い方にすべきです。ユーザーが指定するあちこちの場所にシステム名や機能名のサブフォルダが作られるのはあまり勧められる設計ではありません。

保存するという行為は、そのあと、「保存したものを閲覧する」という利用者の行動につながります。そのときの利便性も考えて命名や処理方針を考えてください。

システムを「外注」するときに読む本

システムを「外注」するときに読む本

システム設計のセオリー --ユーザー要求を正しく実装へつなぐ

システム設計のセオリー --ユーザー要求を正しく実装へつなぐ

他社登録商標を資料などに使う場合の記載

マニュアルを書く季節になりました。いや、自分じゃないんですけれど、少しかんでいるシステムのリリースが近く、操作マニュアルなどの話が上がってきています。一応かつての資料サンプルなどは提示しましたが、どこまでのものがどう作られるか……生暖かく見守ろうと思います(積極的に関与するつもりは一切無い)。

ところで、マニュアルといえば自分でもあやふやだったのが「他社製品を記載した場合の登録商標やトレードマークに関する注意書き等をどのように書くのか」ということ。

かつて、20年程前、新人だったころに海外向けシステムの操作マニュアル書きを1年以上担当したことがありました。おかげさまでWordの扱いについてはおそらく今までいたどの組織でもトップを張れるくらいのノウハウを得ることができました。そのとき、先輩に言われるがままに書いた表記がこれ。

f:id:frontline:20190306172137p:plain
英文マニュアルでの商標等に関する表記例

マニュアルの文中でいちいち「R」とか「TM」とか書かない代わりに、冒頭の注意書き末尾あたりにこの文章を記載していたのですが、これは本当に必要なのかどうなのか?ちょっと判らないまま今に至っていたので少し調べてみました。

いくつか検索したのですが、わかりやすくかいてもらっていたのが鎌倉の知財系専門の特許事務所ブログ。

blog.goo.ne.jp

ざっとまとめると

  • 他人の商標を自分の商標であるかのように書くのは何であれNG(まぁ当然ですね)。
  • 自分の資料等で、やむを得ず他社の商標登録された固有名詞などを使う場合、それが一般的な名詞、単語ではないことを記載すべき。

とのこと。記載方法は「~は~社の登録商標または商標です。」のような記載ですね。これ、よく見ると大手企業のWebサイトではまとめて1ページに記載したりしています。たとえばNTT docomo

www.nttdocomo.co.jp

また、都道府県などもきちんとしたところは記載していますね。下記の例は宮崎県のWebサイト。

www.pref.miyazaki.lg.jp

なるほど。ということはマニュアルなどで製品名を出す場合も、かつての自分が担当した案件と同様にどこかに記載した方がよいようですね。

なお、自社の登録商標を自社資料や自社サイトなどで記載する場合、日本だとRマークは必須ではなく、また、「~商標登録番号XXXXXXX号」といった記載も「努力義務」ということで必須ではないようです。ビジネス文書を作る場合、このあたりもある程度調べてルール化しないと全体的な品質の維持やリスク回避が難しいので、是非どこかで時間をとってやりたいものですね(ってか担当者がやれ!)。

riskzero.fareastpatent.com

すぐに役立つ商標・意匠のしくみと手続き 改訂新版

すぐに役立つ商標・意匠のしくみと手続き 改訂新版