  |
はてなキーワード: ユースケースとは
条件がぐちゃぐちゃしているのでユースケースを一つ作る。
「Aは親であるBと遠くはなれて住んでいる。様子を見に行くのも飛行機を使うため、気軽に帰省する訳には行かない。Bは高齢のためここ数年、急激に運転がおぼつかなくなってきた。軽い認知症が始まっている。車を降りることを薦めても『心配しなくていい』を繰り返すだけで、話を聞かない。後期高齢者保険の話をしても嫌な顔をするだけ。ヘルパーを入れることも拒む。説得を続けると『疲れた』といって引っ込む。高齢者の運転事故の話が話題になっており、心配だ」
多分日本中に掃いて捨てるほどあるユースケース。本当に掃いて捨てたら大阪の海が悲しい色に染まるどころか広大な埋立地ができるだろう。
さて、BはAの言うことをまったく聞かない。一方でBの運転能力は日増しに低下している。ここで何ができるか。現実的選択肢は以下のとおり。
最初の選択肢はAが逮捕される。2番目の選択肢を取る人は一定数いる。その後再就職できずに低所得層に転落する悲劇が量産されているが、報道はめったにされない。最後の選択肢を現実解として選択する人は多いだろう。
最後の選択肢を選んだ場合で、かつBが誰もひき殺さなかった場合、現実に起きるのは次のような事態になる。
Bは脳機能の衰えにより、自分の車がどうなったかを正常に判断できなくなる。車を捨てるのはこのときしかない。しかしながら、同時にBは徘徊等をはじめており、この時点で付きっきりの監視が必要になる。
Bはヘルパーを拒んでいたため、遠隔地からAがBの世話を頼める人はいない。「徘徊しているお父さんを保護しました」という警察からの電話に、予定をすべてキャンセルし、会社に頭を下げて（割安航空券を使わずに）あわてて帰省することになる。
長期休暇は取れない。ここでどうやって車を捨てればよいか。
普段意識していないが、会話で「廃車」というときには上の二つの意味を両方含んでいる。
この二つを短時間にできるだろうか。
スクラップ処分はできる。近所に業者がいるならば、自走していって車検証と自分の身分証を見せるだけで廃棄してくれる。所有者の同意書、委任状などは不要（業者に確認することを推奨）。
問題は法的な廃車のほうだ。
この二つがあればいい。さてここで問題。Aの言うことをまったく聞かなかったBは、Aに登録印の保管場所を教えてくれるだろうか。
教えてくれているなら幸い。とにもかくにもすぐに廃車処理すべきだ。（来年の納税までに捨てればいい）などというのは間違いだ。なにしろ、
Bが自活能力を失ったからAの元に引き取る。あるいはAの居住地の近所の施設に入れる場合、当然住民票を移動することになる。
ところが、印鑑登録の再登録には本人自筆の委任状が必要となる。委任状を書けるくらいなら運転の心配などあるわけないっつーの。そもそも、委任状を書ける状態ではBはAに同意しない。
この点に関して、役所は一切助けてくれない。結局、この状態になると選択肢は二つ。
偽造が発覚した場合、たぶん書類送検される。裁判で争うのも一興だろう。ツイッターで炎上させてメディアを巻き込む。うまくするとゴーストライターが適当な感動ポルノ本を書いてくれる。印税で買ったワインを飲みながら、すでに知的な話をできなくなったBの耳元に「あんたのおかげで大もうけできたよ」とささやくと、テレビドラマ的で素敵だと思う。
重量税を払わない方法もある。払わないと警察が来るので「この人が脱税しました」と、Bを突き出すのだ。嘘ではない。安全な運転と納税は所有者であるBの義務だ。うまくするとBはお上が面倒を見てくれる（ないない）。
成年後見人は一番まともな方法だ。成年後見人になれば、Bの代わりに印鑑を登録し、廃車することができる。が、認定されるまで数ヶ月かかるという、お役所仕事なので年明けにスクラップにしたなどという場合はあきらめるしかない。
かくのごとく、親の車を捨てるとは面倒な事である。
当然だが、ここに延々と書いた面倒な話とは別に「老いの準備を一切しなかった親を引き取る」という大変な事態が同時に発生する。
子供が憎い、子供を少しでも苦しめたい。そう思っている方には『心配しなくていい。俺は大丈夫だ』と言い続けることをお勧めする。効果は絶大である。
Javaを始めとするオブジェクト指向言語による開発になると、設計の手法も従来とは大きく変わる。
詳細設計のことだ。
ここでいう詳細設計とは、本来コードで記述する処理を、逐一日本語で書き下したものを指す。
てか、そんな物を読むくらいなら、現物のソース読めよって話だ。
だいたい、ソースに書くレベルの粒度の記述を、なんでいちいち日本語なんて表記揺れも甚だしいフォーマットで書かにゃならんのだ。
何よりソースに修正が入ると、遡って詳細設計も直さないと整合性が取れなくなるので、言うなれば二重に工数を掛けることになる。
「違うよ、設計を直して実装するんだよ」というが、合理性を重んじるSEやPGという人種が、実質同じ内容を何度も書きたがるわけがない。
それに、単体テストくらいまでの段階ならともかく、開発要員が縮小される結合テスト・システムテスト以降で、そんなことをしている余裕など現場にはない。
でも、そうなることが目に見えているにも関わらず、欲しがる客や元請が後を絶たない。
負担ばっかり増えて、尚且つ無意味な作業をやらせるなって感じ。
なんでそんなに「日本語訳」が欲しいの？
もし客がソースを読めないなら、その時に客が読みたい部分だけを元請が訳して説明すればいい(全部読みたがるヒマな客なんてそうそういないだろうし)。
そして元請はITのプロなんだから、ソースなんてスラスラ読めて当然なわけで。英語読めない英語の専門家が存在しないのと同じ理屈ね。
それこそ読み取り専用でリポジトリのアカウントの一つや二つくらいいつでも作れるので、ソース抜き打ちレビューどうぞって話だ。
とはいえ、別に何も「真実はソースただ一つ！」なんて言うつもりはない。
ソースに行き着くまでにも考えることは色々あって、その考えた結果は全て形に残さなければならない。
ソースもまた考えた結果の成果物の一形態であり、他の形態が、各フェーズで書くドキュメントなのだと思っている。
そしてドキュメントがあるお陰で、システムがトラブった時もいきなりソースの問題箇所を探し回る苦労から解放されるのだ。
ドキュメントを手がかりに「このクラスの、このメソッドが怪しい」まで行き着いてから、そこで初めてソースを確認すればいいと。
Javaだったら、ユースケース図、アクティビティ図、クラス図、シーケンス図、Javadocによるメソッド説明と読み込んでいってアタリを付け、それから当該メソッドのソースを読めばいい。
いわゆるExcel方眼紙でシステムの設計書を書いているのだが、これがどうにも上手くいかない。
問題は色々あるが、大きく分けて「必要な情報が見えにくい」「変化に追従するのが大変」に集約される。
そのメソッドを記述するのに必要な、他の設計書や仕様書を見つけにくい。
例えば、他の設計書(1ファイルで1クラス)に書かれているメソッド名や引数が合っていなくても、すぐに発見しづらい。
また、入出力情報が書かれたインターフェース仕様書を探しにくいなどなど。
そもそもどうユースケースを読んで、設計が必要なクラスを抽出するかもよくわからないし。
次に「変化に追従するのが大変」について。
上述の状態で設計書を書いた結果、製造するプログラマから「こんなんじゃ実装できない」と突っ返されて修正するパターンが多い。
更に要件定義レベルでの見落としによる手直しも、結構な頻度で起きる。
いずれもExcelファイル1個に留まらない、影響範囲の大きい修正になるケースが殆ど。
そんなことが相次いで発生した結果、修正対象の抽出・修正・確認作業で作業量が膨大化し、全く対応できない。
「1個ずつ解決していけばいずれ必ず終わる」を合言葉に、気合と努力と根性でやってきたけど、なんでこうも先が見えないのか意味がわからない。
「機会はある」ってなんなの(笑)
「チャットボット」というバズワードに騙されてウンコゴミカスな案件引っ提げて起業したいとかいうアホが大量にいるからのあの記事ちゃうの？
100案件中1しかヒットする可能性がないレッドオーシャンで「1ヒットするかもしれないから機会はある！」って言うのそれ無責任じゃない？
先日、はてなの匿名記事で大きくバズってる記事があったので、拝見したが、何とも言い難い気持ちになった。
匿名記事なので、あえて私についての説明を加える必要はないかと思うが、某記事と近い立ち位置であることはご理解頂きたい。
チャットボットに関する議論の方向性が見えないのは、チャットボットというワードによって、様々なものを一緒くたにしてしまっているからである。
現状は、切り分けると実に多様である。
チャットのUIそのものの「チャット」なのか、Facebook MessengerやLINEなどのプラットフォーム依存の「チャット」なのか。
人工知能を用いた「ボット」なのか、単純に応答を返す「ボット」なのか。
今回は、プラットフォーム依存の「チャット」、単純に応答を返す「ボット」という意味でのチャットボットの実用性についてお話したい。
そもそも、昨今のチャットボットブームというのは、Facebook MessengerやLINEなどがプラットフォームを公開したことに依るもので、そこに新規性があるはずで、今しなければいけない議論はここにある気がしている。
よく言われるのが、ユーザーは使うのかどうか、という話であるが、プラットフォームがβ版の最中で、今これを議論するのは時期尚早である。
だが、在米時代にUberのボットを使ってみたり、在中時代にWeChatで色々とボットを試してみると、これがかなり便利なのである。
私はそもそも電話が嫌いであるし、ウェブやアプリを横断するのも面倒くさい。
その中で友人などとメッセージをやり取りし、そこからアプリを動かずに予約をしたり、企業に問い合わせたり、というのは手間が省けて実に良い体験であった。
では日本ではどうだろう。
だが、若者世代含め、チャットアプリが生活の大きなパイを占める時代においては、当然求められても納得出来る。
であるからして、予約や定期的に購買するEC、デリバリーサービスやメディア諸々、チャットだけで完結するようなユースケースは必ず出てくると思う。
そういったケースが増えていくと、「これはなんでチャットで出来ないんだ」という時代が来てもおかしくはない。
いろんなものがネットで可能になった時に、「なんで今の時代にネットで出来ないんだ」と思われたと同様に、だ。
「チャットじゃなきゃダメなんですか？」ではなく、「チャットじゃダメなんですか？」という問が来る日もそう遠くはないかもしれない。
今回、人工知能型ではないものに重点を置いたのは、人工知能型には課題が多すぎるからである。
自然言語処理も精度は高くないし、無論、感情を読むなどはまだ先の話になるだろう。
そして、まるで人間ですよ、というものに対し、ユーザーが対人コミュニケーションを望むのは間違いない。
人間に話しているのに、およそ意味不明な回答が来たらユーザーは離脱するだろう。
一方で、そもそも人間ではなくただのシステムだと認識していたらどうだろう。
今は、ユーザーも企業も、雑談や人間らしさはさておき、ちゃんと言ったことをこなすコマンド型のボットに期待すべきだ。
いわば、アプリをチャットのUIにして、コモディティ化しているプラットフォームで公開する、ということだ。
今までユーザーもアプリに対して人間らしさ、などというものは微塵も期待していないはずで、そのようなボット像を目指すべきではないかと考える。
また、ユーザーに広く使われるためには、チャットボットと言えども、UXは非常に大切である。
この点においては、プラットフォームが解決しようと頑張っている。
FacebookがQuick Replyという機能を実装したことから見えるのは、
⑴そもそもユーザーの発言に揺れが出ないように、最初から選択肢を用意しよう
⑵ユーザーがテキストをタイプする手間を省いてタップだけで済むUIにしよう
ということであり、チャットボットが広く使われる上でのUIを見越していると思われる。
その上で、企業側も前述のようにプラットフォームが用意したUIをいかにフル活用して、いかにユーザーが使いやすいものを作れるか、が非常に重要だと考える。
多様なものが混合しているワードを漠然と差して、「これはない」というのは暴論だろう。
1VCさんが、この領域は絶対ない、というのは新規投資先スクリーニングに有用だと思うが、それならば実名にし、そのVCではチャットボットサービスには投資しません。
と言ってしまった方がコスト削減になるのではないだろうか。3割もの方がチャットボットサービスについて話し、毎回同じ議論をしているのだとすれば、それこそ無駄である。
なんなら、事業内容を聞いて、「チャットボット」というワードが入れば「事業内容を変えなさい」と返すチャットボットでも作ってみてはいかがだろうか。
こういった機会は、毎回必ず様々な議論を生み出すが、全員の意見が一致しないからこそ、投資の価値があり、それを見抜いたものが勝つ業界だと思っている。
だから、是非ともチャットボットサービスを考えている皆さんは、ちゃんと自身のサービスの価値を見極めた上で、頑張ってほしい。
なぜ両方使うという選択肢がない。真の技術者はウェブ標準だろうがFlashだろうがネイティブだろうが、その場その場でユーザーの体験を最善にし、クライアントの要求を最高に満たすベストの技術を使う。JavaScriptかFlashかなんて動きさえすればユーザーには関係ないんだから。実際、HTML5スゲＥＥＥＥＥ！！！ってページにFlashタグのブクマが間違ってつけられたりしてるよ？（笑） ウェブ標準の崇高さなんてパンピーにはわからんのです。
そもそも分からないんだけど、HTML5が「投資」するほどたいしたもの？ 誰もが基礎教養として身につけているはずの、これまでのHTML＋CSS＋JavaScriptの延長線上の技術でしょ。今まで普通にやってきたウェブ開発者ならすぐにキャッチアップできるはずだよ。
どうせHTML5の実装の普及には当分かかるし、その時点のブラウザ環境で使用可能なものをゆっくりまったりと導入していけばいいだけ。その意味ではいわゆる遅延評価学習で十分。あわてることはないです。どうせ皆使うことになるんだから。
一応言っておくと、いいものだと思いますよ、HTML5は。現段階で頑張って凝ったものを動かしておられるイノベーターの方々もたいしたものだと思います。敬意を。マリオやらグラディウスやらは著作権的にどーなのかと突っ込みたいが。
それはシナリオのひとつですよね。Googleの甲斐性次第では十分にあり得る。それと、ジョブズが翻意するというシナリオもありますよ。今までに散々あったことですが。どこかでそれをネタにしている記事があったと思いますが。
もしEdgeを見てそう思ったのなら、Flash CSを使って制作したことがありますか？ Edgeを実際に使ってみましたか？ と問いたい。
他にも、最低でも、
これらにきちんと答えられない人間にHTML5 vs Flashなど語る資格はないです。そもそも対立させる時点でわかってないなー ┐(´д｀)┌ って感じなのだけど。
あとFlashへの投資が無駄になると思ってるようですが、俺はFlashは投資判断「Buy」継続だと見てますよ。たとえこのままiOSで動かずともね。AIRもあるし、ブラウザのプラグインとしてのFlashだけ見ていると考えを誤るよ。ブラウザのほうにしても、GPUアクセラレーションつきの3Dが真っ先に使用可能になるのはFlash。プレイヤーの普及が速いから、WebGLと異なり、今後1～2年内に実案件で使用可能になるでしょう。そういった面ではなおカッティングエッジな技術だよ。
まあ、プラットフォームや言語の選択は投機だから、どの銘柄が買いか売りかで紛糾するのはわかる。ただ、それなら分散投資だとか、インデックス投資という考え方もあるのでね。HTML5に惚れ込んで一点買いなんて若いエンジニアがいたら、それはもう相当危なっかしいなと、視野も相当狭くなるだろうなと危惧するよ。
というか、JavaだろうがC++だろうがObjective-CだろうがLLだろうがアセンブリ言語だろうが関数型言語だろうが、一度全部触ってみなよ。いいから。HTML5で手一杯なんてのでは話にならんですよ。
俺は人をうんざりさせるのが好きなので、ちょっと書いてみる。非モテの主張に対する俺の分類的脊髄反射。
非モテというラベルとその主張には、どれも風が吹けば桶屋がもうかるてきな飛躍があるように思えるので、個々のユースケースを考えてみる。
人がもてないことについてあれこれ言うのは野暮なんだが、こんな憂さ晴らしでもしたくなるほど「非モテ非モテ」って目に付いて鬱陶しいんだよな。
