「ユースケース」を含む日記 RSS

はてなキーワード: ユースケースとは

2021-04-28

林檎信者から見た、windowsPC VS Macについて

僕はmacOSユーザ

windowsユーザwindowsPCを推す理由はなんとなくわかる。いろんなメーカーが出しているし、カスタマイズやすいんだろう?

Macのよさは、windowsPCのようにメーカーごとにカスタマイズされていない、どのMacを買っても同じmacOSが入っている、という純粋さがある。また、iPhoneなどの関連プロダクトとの親和性も高い。プロダクトの価格も高いけど、価値に見合ったものだと僕は納得しているし、なによりも大変満足している。

PCというユースケースにどれだけのコストをかけれるのか、そして、何に価値を感じているかは人それぞれなので、優越なんかつけられないよ。エロゲーをやってPCゲームをやる人はwindowsを買うべき。僕はエロゲーPCゲームはやらない。僕は、これから進化していくMac体験していきたいし、すごく期待しているからこれからMacを買う。

「5万で買えるwindowsで十分なのに、Macを買うのはもったいない。」論があるけど、うまい棒を1000円分食べて満腹になるよりも、3000円の寿司を食べたいでしょ?僕は3000円の寿司を払うだけの経済力があるし、3000円分の価値を受け取りたい。それだけなんだ。

以上。

2021-04-25

anond:20210425022947

日本のアホだけど偉い人名言集に加えておけ

?「よし、AIだ」

?「よし、ディープラーニングだ」

?「よし、ブロックチェーンだ」

?「よし、DXだ」

?「よし、マイクロサービスだ」

?「よし、DDDだ」

共通して言えるのはアーキテクト不在の技術ゼロ企業ほど、この傾向が強い

でも増田の言う通り、要所要所適度な加減で取り入れるのは賛成。ユビキタス言語とか、日本語使う我々が、更にSIerでもなければ何の意味もない。

過度な抽象というのは自分DDDに対する理解と異なるな。どこまでを抽象化するかは触れていないはず。ユースケース層は必ずしも最上レイヤーのみで収まる話ではないから、どこまでが抽象化の対象となるかはアプリケーションによる。

2021-04-24

DDDユースケース層でのエラーハンドリング言語化している情報ってありませんか?

ユースケース層ってドメインからエラーを受け取って翻訳して、呼び出し側へハンドルやすいようにエラーを投げるじゃん。もしくは、想定のエラーだったら握りつぶすみたいな役割あるじゃん

そのユースケース層のあるべき振る舞いの情報源って経験的でしかなくて、識者から情報が欲しい。

ドメイン駆動設計 モデリング実装ガイドって本にはサラッとしか書いていなかった。

2021-03-12

このコロナ禍に世界中鉛筆削り機が揃う展示会をやっていた。

日本メーカーからAIでその人に合った削り加減にする機種が出てたけど、いまいちユースケースが分からなかった。中国(たぶん)のメーカーから出てたのは面白かった。芯の入ってない木の棒を突っ込むと中心をくり抜いて芯をセットしてくれる。木の棒は専用のものを使い、一本80円するとのこと。コスパは悪いが夢がある。

いっぱい観たらお腹が空いてきたので、休憩コーナーでお弁当を食べた。休憩コーナーの壁には人工呼吸器のプラグがズラッと大量に設置されていた。有事の際はここで患者を受け入れるらしい。

そうこうしてるうちに辺りは暗くなっていて(ここの人達はなぜか頑なに電灯を使わない)、鉛筆削り機の説明員の顔が心なしか焦りだした。館内放送で「エレベーターエスカレーターはこの時間止まっているので階段を使ってください」とアナウンスがあり、仕方がないので階段を使おうとしたのだけど、運悪くこの階には階段がなかった。

2021-02-21

anond:20210221125927

たぶんだけど、COCOAテストは、

感染者との接触ちゃんカウントされないことの検証はしっかりやっていたんだと思うんだ。

このアプリユースケース検討したとき

一番頻度が高いのは、非感染者同士の接触だと思うし、

感染者同士の接触で正常に動作していたのなら、おおむね正常に動いていたと思っていいんじゃないかな。

2021-02-01

シーズケースっていうお菓子覚えてる?

シーケンス図とかユースケース図とかって聞くと思い出す

酸っぱくてうまい

2021-01-22

anond:20210122183458

ユーザーシステム機能意図しない使い方をするのはよくあることだし別に否定するものでもない。

寧ろそのユースケースから満たしきれていないニーズを探るもの

もしシステム提供者がそう使って欲しくないならば機能を変更すれば良いだけだ。

2020-08-04

anond:20200803092447

マストドン。あとは、Dabel

Clubhouse が来るかも知れないし、来ないかも知れない

▼ Clubhouseとは?

Clubhouseは音声版Twitterと言われている音声SNS。さまざま人の「部屋」に入り、話を聞いたり、手を挙げて参加することが可能だ。部屋に入っていれば友達を呼べるが、その友達承認しないと実際には入ってこない。オフラインのClubhouseっぽい感覚に近いサービスになっている。

 

テーマは参加している登壇者が決めるので、かなり自由ユースケースが生まれるのと、今現在テック業界などの著名人が集まっている。例えば、D2CエキスパートWeb Smith(ウェブスミス)氏がShopifyの話をしていたときに、ShopifyのCEOが自ら参加していた。

 

[TechCrunch Japan] 米国スタートアップ界で話題次世代SNS「Clubhouse」になぜ100億円以上も時価総額がつくのか?
https://jp.techcrunch.com/2020/05/17/clubhouse/

2020-07-31

頼むからセンスのないやつはプログラマにならないでくれ

本当に迷惑なんだ。

センスがない奴の何が問題かというと、技術がないとか、ベストプラクティスを知らないということではなく、根本的に「頭がおかしい」ことなんだ。

センスのない奴は、普通人間が到底思い付かないことを平然と行う。所詮、本に書いてあるようなアンチパターンは、「経験のない人は典型的にこういうことをしがち」という例であるが、センスのない奴はそういう典型的アンチパターンにすら当てはまらないほど意味不明なことをする。だから、「センスのない奴は典型的にこういうことをする」という具体例を挙げることが非常に難しいし、「ここがダメから直せ」という指摘もできない。

最近見た例を書いてみる。2次元テーブルを扱うJSONだ。

普通の人なら、何も考えず以下のような実装をするだろう。フィールド定義データが分かれているのは、ユースケースによってフィールドが可変だからだ。

[
{fieldName: "id", title: "id", type: "number"},
{fieldName: "name", title: "商品名", type: "text"},
{fieldName: "price", title: "値段", type: "number"}
]
[
{id: 1, name: "商品A", price: 100},
{id: 2, name: "商品B", price: 200},
{id: 3, name: "商品C", price: 300}
]

ところが、センスのない奴はたとえば以下みたいな意味不明実装ナチュラルに行う。

[
{id: "0-0", val: "商品名", type: "text"},{id: "0-1", val: "値段", type: "text"},
{id: "1-0", val: "商品A", type: "text"},{id: "1-1", val: "100", type: "number"},
{id: "2-0", val: "商品B", type: "text"},{id: "2-1", val: "200", type: "number"},
{id: "3-0", val: "商品C", type: "text"},{id: "3-1", val: "300", type: "number"}
]

一応言っておくと、これは実例の一部を分かりやすいように切り取っただけであり、本物はもっとひどい。

センスのない奴っていうのは、スキル云々の問題ではなく、そもそも認識している世界常人と異なるから矯正は無理だし、チームにいると非常に迷惑なんだ。だからプログラマにはならないでくれ。

2020-07-29

緊急避妊薬を薬局に置いたら女性悪用する

ってどういうこと? ユースケースを考えたら男性悪用する可能性の方がずっと高くね?

もし「性に奔放な女性が余計奔放になる」という意味だとしたら、それは悪用じゃなくて正用なのでは??

2020-06-09

https://b.hatena.ne.jp/entry/s/gist.github.com/mattn/488af4c3b3841ea901a1f9820636393c

ワイはallow/blockが好きやなあ

aとbだから

----

masterとslaveの意味がしっくりくるのはscsiくらいなもんだと思う

このユースケースにおいて適当な言い換えは思いつかない

(gist代替案が書いてあるけどfollowerでもworkerでもreplicaでもないよな)

----

白黒つけるって発言もそのうちできなくなるから、今のうちにいっぱい言っておいた方がいいんでないか

まああれは人種ではなくて囲碁なんですけどね

囲碁も赤と青の碁石を使うようになるかな?

----

一昔前ならそんな荒唐無稽なことは言わないのだけど、アメリカ社会馬鹿さ加減について認識が改まった昨今において、彼らがやらないという確信はもはや持てない。すまないね

2020-05-26

情報処理技術者試験なんて何の役にも立ちません

情報処理技術者試験資格を取っても実質的に得るものはありません。「実質的に」というのは、技術者としてのスキル向上に貢献するということであり、「報奨金が貰える」とか「履歴書に書ける」などの技術無関係ものを含まないということです。

なぜ、情報処理技術者試験が役に立たないのかと言えば、出題内容が表面的な知識問題に極端に偏っており、本質的理解を問うていないからです。たとえば、オブジェクト指向の三要素に「カプセル化」「継承」「ポリモルフィズム」がありますが、これらを御題目のように唱えていても何の意味もありません。しかし、情報処理技術者試験ではこれらの用語さえ覚えておけば、しっかり点になります

オブジェクト指向におけるカプセル化説明したものはどれか。

  1. 同じ性質もつ複数オブジェクト抽象化して,整理すること
  2. 基底クラス性質派生クラスに受け継がせること
  3. クラス間に共通する性質抽出し,基底クラスを作ること
  4. データとそれを操作する手続を一つにして,オブジェクトの内部に隠ぺいすること

https://www.fe-siken.com/s/kakomon/19_haru/q42.html

こんなのは単なるポエムであり、これが解けたところでコードが書けるわけでも、良い設計ができるわけでもありません。

数学で喩えれば、「加減法」とか「代入法」のような用語を暗記して、具体的な連立方程式の解き方は分からないようなものです。

ひどい問題は挙げればキリがありません。

UML2.0において,オブジェクト間の相互作用時間の経過に注目して記述するものはどれか。

  1. アクティティ
  2. コミュニケーション
  3. シーケンス
  4. ユースケース

https://www.ap-siken.com/s/kakomon/22_haru/q44.html

図の名称を答えさせる問題。図を読み取らせる問題なら、まだ理解できますが。そもそもUMLなど別に技術者として知っておくべき知識でもありません。

要求分析から実装までの開発プロセスを繰り返しながら,システムを構築していくソフトウェア開発手法はどれか。

  1. ウォータフォールモデル
  2. スパイラルモデル
  3. プロトタイピングモデル
  4. リレーショナルモデル

https://www.fe-siken.com/s/kakomon/23_aki/q50.html

これも、こんな分類自体、覚えたところで何にもならないわけですが、その用語を答えさせる問題いかに、この試験エンジニアリングプロジェクト管理本質関係いかがよく分かります

極めつけはこれ。

次の画像符号化方式のうち,携帯電話などの低速回線用の動画像の符号化に用いられるものはどれか。

  1. JPEG
  2. MPEG-1
  3. MPEG-2
  4. MPEG-4

https://www.fe-siken.com/s/kakomon/17_haru/q52.html

地方公立中学校定期試験レベルのひどい問題です。出題者は、1だの2だの4だの7だのといった数字語句対応を覚えることが重要だと思っているのでしょうか。

情報処理技術者試験で測れる能力は以下の2つだけです。

  • 内容の理解はともかく、ある用語を「聞いたことがある」かどうか。
  • 150分間、落ち着いて椅子に座っていられるかどうか。

まり、ある種の発達障害ではない意識高い系ポエマー認定するための試験であり、そもそも技術者のための試験ではないということです。あとは、中小企業診断士などを受ける人が試験免除を獲得するためとか。

そもそもコンピュータプロジェクトマネジメントの技術を、資格試験勉強しようというのがピントがズレています。それらは既に良質な解説書が豊富にあるのだから、それで勉強すればいいのです。

2020-03-31

anond:20200331104551

というか増田自体が新コロ特措法の話だからといって新コロの症状に考えが捉われすぎてると思うぜ。

ワイは極論言ってるけど、とはいえユースケースとしてあり得ない級の話でもなく、マウストゥマウスの話であれば

「急に症状が悪化して救急車呼んだはいいが到着時にはすでに心肺停止していた」状況なんかではあり得る話だからな。(まあ、新コロの症状を前提に考えるとやらないほうがいいが)

2020-03-04

anond:20200304120431

5Gはエリアが狭いことが逆にメリットであって「ローカル5G」みたいなシステム許可さえあれば作れるんよ。

からディスク無しPCユースケースとしては「情報持ち出し禁止」みたいな現場で「端末に情報持たなきゃええやん」みたいな発想をした場合システムってことな

古くはダム端末。

2020-01-16

anond:20200116120318

とあるあるユースケースだと、仕事上司部下の関係にある人が

「そのPC使ってGmailで疎通できるか確認して?」みたいな作業を依頼して、その次の日に使ったPC回収して…みたいなのはあるようだけどな。

2019-12-29

モバイルアプリハイブリッド実装で後悔したもろもろ

モバイルアプリ実装と言えば主力はKotlinSwift(Objective-C)だけど、簡単な作りであればcordovaベースフロントエンド開発ライクに進められる。

そもそもライブラリ選定には関わっていなかったものの、便利と思って使った結果後悔した思い出のお話

WebViewベースである以上、イベントレンダリング系統ネイティブに劣る

特にiOSが顕著だった。

Angular, Vue実装していたけどレンダリング系に属するイベント盛りだくさんの場合

結果的ネイティブ実装したほうが楽だしレンダリングの面で有利。

そもそもcordovaからと言ってネイティブ知識がいらないわけじゃない。

標準サポートしているプラグイン群でできることは限られてくるし、そのまま突き進むならネイティブ実装知識必要になる。

フロントエンド開発できない奴が作れる代物ではない

これは当たり前だけど…

JSパッケージングだったりCSSビルドが組めないとなると逆にコスト高。

Angularベースで進めていたときにそれは起こった。

そもそもNode.jsビルド根本的に理解してない奴がプロジェクトを作ったせいで

JSパッケージビルドもされない、jQueryを突っ込まれるなどひと悶着あった。

3年前くらいだったけど既にTypeScriptも出てたし、何故そうしなかったのか理解できない。

結果ロードが激重になった。そりゃそうだ、minifiedされてないのだから

用法用量を正しく守って使わないと、後で面倒になる好例だった。

ビルドが意外と面倒で手間

大概は専用プラットフォーム上でビルドしていくがこれがくせ者。

ブラウザIDE(という名のただのテキストエディタ)が使えるけどそもそも構成管理できない。

ローカルビルド乖離するし、ブランチすら切れないのだから本人以外は触れないシロモノになってくる。

ビルドのためにアップロードするんだがこれまた賢くない。

別端末でビルドしようとすると同名の新しいプロジェクト作成される。

ここまでくるともう触りたくなくなる。ただ、触らないわけにはいかないので何とか整合が取れる状況にした。

さらに言えば、ビルドが終わってステータスが見れるが、内訳が見れるのはそのタイミングだけ。

これはマジで止めてほしい。殺意が湧くレベルでやめてほしい。

多分、海外で公開したプラットフォームをそのまま持ってきてるんだと推測しているが流石にこれは悪意しか感じない。

やろうと思えばそりゃローカルビルドはできるけれども。

クライアントOSで動くビルドツールが使い物にならない

ただのCLIバックグラウンドで実行するだけのGUIラッパーと化している。

かといってlintを掛けてくれるわけでも無し。

個人的に要らないし今後は使わない。

WEB RTCを使うとiOS互換に苦しむ

突き当たったのはWebSocketを使うシーンが出てきたとき

ライブラリで何とかする方向で進めたかったけどそもそもwebpackビルドにすら対応していなかった。

件のAngularベース場合もっとひどくてクソラッパーを作りやがったせいで依存度が激高になった。

ちなみにネイティブはそれぞれにサポートするライブラリが出ていて、最新バージョンに向けてきちんとメンテナンスされている。

その辺はJS世界の闇に降れた瞬間でもあったりした。

総括

根本的にiOS側の実装レスポンシブ的なレイアウトが作りにくい現状を鑑みて、

WEBベースで新商品などの通知をしたい、残りは情報の閲覧のみでSPA構成的なシロモノで作りたい。

こんな需要には使ってもいいんじゃないかと思う。相当なレアケースだけれども。

いいところは確かにあって、CSSデザインの調整が効くところは大いに評価できる。

これがまたネイティブ実装だと面倒。特にiOS。お前はダメだ。

結局進めていくとネイティブ実装知識を求められるのだからネイティブ実装したほうが良くね?と言ったところ。

ユースケース的に超単純要件アプリを作りたい、かつ、ユーザに何かpush知的なやつを入れたいって場合は使ってもいい気がする。

うそ大手でもなければ無い気がするけど。

2019-09-29

anond:20190929144700

推奨は要求じゃないし、あくまでも運営者が想定する増田ユースケースの一端でしかない。いずれにせよ、それに反した使い方が駄目とは書かれてないから好きに使えばいいよ。

2019-08-07

単一責任原則vsカプセル化

投稿につき至らない点があるかもしれないが容赦してほしい。が、指摘は受け入れる所存。

俺はとあるUIコンポーネントライブラリ開発者だが、先日議論されたあるコンポーネント設計について悩み続けている。

これを読んでくれた人の設計センス知識経験から第三者の率直な意見を聞きたい。

悩んでいることの概要は、

ざっくり言えばこの2択だ。

どちらも間違った考えだとは思えないので、そもそもどちらかの捉え方がおかしいのだと思う。そういった意見も聞きたいが、まずは読んでみてほしい。

設計対象コンポーネントは、よくある触って動かせるスライダーである。下記リンク先のようなものだ。

https://material-ui.com/components/slider/

前提として、このコンポーネント構成要素を下記とする。

加えて、下記も前提としてほしい。

Sliderというコンポーネントクラスを作るとして、これらの構成要素をライブラリ-ユーザー間でどう分担するかという点で、AさんとBさんで意見割れた。

それぞれの意見を要約すると下のようになる。Aさんはカプセル化を狙い、Bさんは単一責任原則を重視している。

Aさんの構成イメージは下記のような感じ

画面
└ Slider         (ユーザー作成)
   ├ 背景バーノブ
   └ 進捗バー

Aさん案の場合だと、Sliderクラス内部で勝手にそれぞれの要素を作成し、自分の子にするなりして表示する。

Bさんの構成イメージは下記のような感じ

画面
├ 背景バー     (ユーザー作成)
├ ノブ         (ユーザー作成)
├ 進捗バー     (ユーザー作成)
└ Slider       (ユーザー作成)
   ├ 背景バーへの参照    (ユーザー指定)
   ├ ノブへの参照        (ユーザー指定)
   └ 進捗バーへの参照    (ユーザー指定)

Bさん案では、ユーザー構成要素それぞれを作成し、Sliderにそれを食わせる。

SliderはAさん案のように各構成要素を構築する必要はなく、ノブの移動や進捗バーサイズ変更だけすれば良い。

Aさんはユーザー制御する必要のない背景バーノブ、進捗バー構成隠蔽(カプセル化)しようと提案したが、

Aさん案に対しBさんは、単一責任原則観点から「各構成要素の構築や表示」という責任を外すべきだと訴え、Bさん案を提示した。

またBさんは、コンポーネントユーザーが扱うべきものであり、コンポーネントコンポーネントを内部で勝手使用しているのは混乱を招くとの見方もしている。

ただしAさんの考えの通り、実際に各要素の構成ユーザー制御するユースケース存在しない。

その場では「単一責任原則」を持ち出したBさん案で決定された。

しかしなんとなくAさん案派だった俺はモヤモヤしたまま家に帰り、本当に単一責任原則に反しているのか、カプセル化よりも大事なのかと悩み続けている。

ここまでが事実となる。

さて本当にBさんが正しかったのか、あるいは単一責任原則の捉え方が間違っているのか、はたまた・・

第三者による意見が聞きたい。周りのコメントに左右されない率直な意見が望ましい。なんとなくな意見も歓迎する。

満たすべき機能は見た目だけではないがそこは置いておいてほしい。

以下は個人的意見とか思ったことや疑問など。

2019-04-14

アプリログユースケースが知りたい

ログとはここでは、特にprintf()やロギングライブラリを使いアプリに仕込まれた明示的な出力とする。

サーバーサイドのログ必要だと分かる。

攻撃来てるかとか気付けるし、ビッグデータとしてゴニョゴニョ解析できるし。知らんけど。

でもアプリログってどう使えばいいの?

バグが起きた時とか、基本的再現手順を元にデバッガーのブレイクポイントとか使うだけで、ログは実際全然見てない。

あとネットワーク解析ソフトと、アプリに埋め込む系のデバッグツールあれば十分って感じ?

役立つログなんて、デバッガーの調子が悪い時にコミットしないものを一瞬入れるくらいかなぁ?

バグが起きた時はQAとかから再現手順と一緒にコンソール出力も飛んでくる。

その中で例外出力は有用なことが多いんだけど、それはハンドリングされなかったのが出てるだけ。

ロギングライブラリを使って何段階もログレベル分けてやって得られたものがあまりないなあって最近思う。

2019-04-03

anond:20190403152304

文章を書くとき主観的になりきる(感情移入する)必要があるが、プログラム客観的メタな考え方でつくる必要がある

コンピュータシステム立場になって考えている。UMLユースケース図は証左。たぶん、増田コンピュータ感情移入できないから、そのように思うのだろう。クルマを愛車と呼ぶのか、単なる移動手段の一機械しか思えないか。どちらが良い悪いは無いけど。

プログラム意味や内容がわかっていないことについて書けない

⇨かつてはやり直しコストが高かったのでウォーターフォールモデルが主流だったが、現在WYSIWYGのごとく、コードを書いて、動かしてみて、検討しなおしてコードを書く、といった繰り返しで調整して作っていくこともそんなに変ではない。

作りたい成果物が決まっているのは、文章も何らかの意図を持って書くのだから一緒。

私の結論プログラム言語は、英語にも増した世界共通言語(よく変わるけど…何処かの進学塾のセンセが書いていたけど、数式のほうがさら普遍性が高い)

2019-01-22

マキタ掃除機

言うほど良くはない。

しかに軽くてバッテリー容量もいいかもしれない。最初は吸引力がすごーい❤︎みたいなテンションかもしれない。だが、次第に弱点が見えてくる。そう、ヘッドである

マキタ掃除機のヘッドはおもちゃみたいな品質なので、人間が気を使わないと綺麗にならない。ビルテーマパークの清掃なら言うことないだろう。しかし、家庭の清掃においては必ずしもフィットするとは言い難い。自家用車の清掃など、どちらかと言うと利便性が重視されるユースケースにおいては力を発揮するだろう。

掃除に気を使いたくない人は少し高くてもヘッドの性能が高い掃除機を購入することをお勧めする。

2018-11-17

anond:20181117114626

Androidを6年使ってきて先月iPhone 8に乗り換えた人間私見

実際はそこまで不便じゃなかったり好みが大きく入っていたりするところ


本当にクソなところ


逆にiPhoneが優れているところ


個人的結論としてはFGOをやめさえすれば本当にどっちでもいいなという感じ.

文字入力ストレスなくできる点ではAndroidの方が好みかも.

2018-08-21

anond:20180821092925

よくある論破ごっこのユースケースでは、割と「仮想設定としてもありえない」ものを両サイドに設定するのが通例だから、そういう様式に慣れてない素人はてな―の無様な姿を見られるだけでも十分面白かったよ。

ちゅーかはてなー全体が論破ごっこに慣れてなさすぎ。

自分主体ではなく客体として演技的に語ったりとか、別に演劇部ではなくても一般社会人的なスキルとしてよくやるやろが。

2018-07-14

人を追加しても立ち上げれない

1.

仕様がわかるドキュメントがほぼユースケース(シナリオ)のみ

下位ドキュメントの内容は上位ドキュメント参照になっててなにも詳細になってない

かい仕様も載っていない

1.

仕様書、設計書がバージョン管理システム管理されていない

ファイル名+日付みたいなそんなちゃちなもんじゃねぇ

最新のドキュメントがどこにあるかがわからない&異なる仕様変更を反映したバージョン複数存在するんだぜ

1.

設計書と実装が一致していない

ドキュメントに変更が反映されてないとかそんなちゃちなもんじゃねぇ

アーキテクチャがまるっと変わるような変更(設計書)をしておきながら

めんどくさいからって実装は古いままなんだぜ

2018-03-30

anond:20180330140525

以前、あるシステムの開発にかかわることになって、それのマニュアルを渡された。

画面のスクリーンショットが貼ってあって

「〇〇画面」の「登録ボタン説明が「〇〇を登録する」。

「△△画面」の「削除」ボタン説明が「△△を削除する」。

というような説明が延々と続く。

画面を見るだけで分かるような情報量ゼロ説明があるだけ。

チュートリアルユースケース的な説明はいっさいない。

装丁は立派だからマニュアルを作れと言われてとりあえず形だけ作ったんだろうなと解釈して、操作方法質問しに行ったら真顔で「マニュアル渡したでしょ。読めば?」と言われた。

どうやら本気作っであのマニュアルだったらしい。

ログイン ユーザー登録
ようこそ ゲスト さん