IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→起業)

組織・業界は如何にしてエンドユーザーを無視するか

そんなに難しい話ではないです。確認の意味を込めて。

 

例えば、個人・創業者が1人だと、見るべき相手はエンドユーザーしか居ません。
ここで多かれ少なかれ、エンドユーザーを見れなかった人は淘汰されます。

(※例外はあります。例えば趣味でやってる人など)

 

f:id:otihateten3510:20170928085720p:plain

 

創業者が会社を作って組織にしたら、下図のようになります。
ベンチャーのような状況です。まだエンドユーザーを見る余裕があります。

 

f:id:otihateten3510:20170928085728p:plain

 

組織がさらに成長しようと、外注を使うとします。 
すると、外注はエンドユーザーを見るとは限りません。より大事なのはお金をくれるクライアントです

もし外注が、ユーザーにとって大事な部分を担っているとすると、これは問題になります。(例えばユーザーインターフェースのような)

 

f:id:otihateten3510:20170928085736p:plain

 

組織の中が構造化すると、直接エンドユーザーを見ることが無くなる場合があります。
例えば従業員は、経営者や上司の方を見て仕事をするでしょう

 

f:id:otihateten3510:20170928085743p:plain

 

それでも経営者がエンドユーザーを見ていればよいですが、そうではないと以下のような状態になります。もはや誰もエンドユーザーを見ません。内へ篭もる状態です。

f:id:otihateten3510:20170928085638p:plain

 

実際はこれよりもっと複雑なはずです。多階層になっていたり、出世ゲームだったり、エンドユーザーも1人じゃなかったり。

 

外注や従業員はエンドユーザーを見る必要がある?

よく巷では「エンドユーザーを見ましょう」と言いますが、私は必ずしも従業員や外注そうする必要はないと思います。彼らにとって「お金をくれる人」はクライアントや上司・経営者です。お金をくれる人が大事なわけですから。あとは綺麗事でしかありません。

 

 

エンドユーザーを見てもらわないと困るのは組織側

図で言うところの組織、つまりエンドユーザーから直接利益を得る者にとっては、従業員や外注にエンドユーザーを見てもらわないといけません。
だから頑張って従業員・外注をコントロールして、エンドユーザーを見せようとします。
この状態が理想的な状態です。

 

経営者はエンドユーザーを気にする
従業員は経営者の評価を気にする
外注は従業員の評価を気にする

経営者はエンドユーザーを気にする
従業員はエンドユーザーを気にする
外注はエンドユーザーを気にする

 

視座を高く持つ」とはまさにこの状態ですね。
従業員が組織の目線を持っています。

 

しかし、この理想はまやかしだ

「一人一人が経営者目線でエンドユーザーのために」というのはよく聞く話ですが、実際の所まやかしだと思います。
別に直接の利害がないですから。どうしても限界があると思います。


もちろん、それで上手くいくこともありますが、上手くいかなくなる原因がいくつもあります。それに、上手く行きすぎると従業員から搾取している状態にもなります。

 

関連

otihateten.hatenablog.com

 

上手く行かない原因

問題はコントローラーで起きます。
(ManagerではなくController。MVCデザインパターンのCみたいな感じ)

事業を突き詰めていくと、部下や外注の視座を上げ、成功させる役割そのものが目的化していきます。すると、どうでしょうか。

  • 視線が内へ向く
  • コントローラー側の仕事量が増大する
  • コントローラーの権力が増大する

と言った弊害が出てきます。

そして何より、エンドユーザーをどれだけ見れているか採点するのはコントローラーです。お客さんではありません。
コントローラーの視線が、真にエンドユーザーを見ていれば問題ありませんが、そうでなくなった瞬間に全て崩壊し始めます。
やがて「エンドユーザーのため」が建て前・美辞麗句となり、いつの間にか出世ゲームや政治ゲームと化していくでしょう。
これは多かれ少なかれ、ほとんどの人が経験あるのではないでしょうか。

 

上手く行かなくても何とかなってしまう会社

通常ならエンドユーザーを見失った会社は淘汰されていきます。
しかしそうはならない時もあります。

  • 他にない技術力がある
  • 独占状態である
  • とにかく金を持っている
  • 会社の他の事業は好調である

そういった会社、事業部はマヤカシのまま突き進んでしまうわけです。 

 

特に会社を跨ぐと難しくなる

一つの会社なら、まだ経営陣が統制を頑張ってみたり、やりがいを与えられるようにあれこれ調整することはできるでしょう。しかし会社を跨ぐと非常に難しくなります。

現代では、エンドユーザーに対して一つの価値を複数の会社で提供していることが珍しくありません。そうなると、一つ一つの会社がエンドユーザーを見たくても、全体としては業界内を見てしまい内にこもることになると思います。

 

 

真の課題は、理想的な利害設計

エンドユーザーを無視してしまう現象を回避するには、全関係者を当事者にする必要があります。当事者意識ではありません、当事者そのものです。

そのためには、全関係者が影響するKPIを設定し、それに全ての立場を絡める必要があると思います。よくwin-winの関係なんていいますが、全立場のwin/loseを合わせるという状態です。利害一致・利害設計と言ってもいいですね。

ここで気をつけたいのは、そのKPIを売上などの業績にしないことです。エンドユーザーを無視しても業績は上がります(これは社会全体の課題でもあると思いますが)
もう一捻りした何かが必要です。
しかし満足度だけでもダメです。儲からないと個々は頑張れません。
この両方が上手く成り立つように設計するのが非常に難しいです。

あるKPIを上げれば上がるほど、全員が儲かってエンドユーザーも嬉しい」という設計が必要です。

 

ちなみに、この利害一致するように組織を改変するのは、プログラミングの設計に少し似ていると感じています。

 

誰が利害設計できるのか

上記のようなことは結構前に考えたのですが、じゃあ一体誰がその設計をできるのでしょうか?
最初は「社長しか居ない」と感じましたが、最近は社長ですら足りないと感じています。大抵は会社単体の話を越えるからです。

となると、案外サービス設計そのものなのではないかと考えています。サービスというのは利害関係を一致させないと成功しづらいものです。サービスにおいて利害設計をしっかりして、それを用いて業界全体を巻き込んでいくのが近道なのでは?と思います。

って、つまりビジネスそのものなのかもしれませんが。

ベンチャープロダクトのパラドックス

最近、マッチング系サービスを作っています。マッチングサービスは人が居ないと始まらないので、著名な方へB側の方に参加していただけるようアプローチしています。
ただ私は動いていなくて、事業の相方が頑張っている状況です。相方が何とかビジョンを説明して「いいよ、やるよ」と言っていただいている。という話を開発側である私がミーティングで聞くわけです。

 

まだリリースしてないどころか、会社すら建てていないサービスに参加していただくというのはどういうことでしょう。もうビジョンに共感いただいたか、多少なり信頼していただいたかくらいしかありません。
そう考えると、プロダクトをもっと素晴らしいものにしなければ。と思うのですが、シード期はスピードが命。スピードを追い求めると品質・機能はまだまだ足りない状態でリリースすることになります。
ひょっとしたら失望されてしまうかもしれない。などと不安な気持ちを消えながら開発を続けています。

 

この矛盾は非常にツライものがあります。
マッチング系サービスなので、人が居ないと成り立ちません。だから人を誘わなければならないのですが、その時点でプロダクトがありません。
プロダクトがないのに、あるいはプロダクトの品質がまだよくないのに、誘わなければならないというのは非常に難しいことです。
いっそ、全て完成してから売り込みたくなってしまいますが、それは悪手だとよく言われます。スピードが足りませんし、受けなかった時のリスクが大きすぎます。

 

もちろん、提供者と同じくらいにプロダクト戦略を理解していただくとか、ビジョンの重要さを理解していただければ話が早いのですが。最近やっていて感じるのは、地頭がかなり良い方でも、サービス好きなタイプでなければ、予想以上にサービスというものを理解していただくのが難しいのかもしれません。これはサービス設計がそもそも難しいのと、説明の難しさ、そしてそもそも机上の空論であるというのがあると思います。

そうなってくると、想像する以上に信頼や情熱みたいな部分が重要になってくるのかもしれませんね。

 

作っているのはサービス・プログラムなんですが、相手にするのは人間です。人間は理屈だけで動く生き物ではありません。そこら辺が大きな課題でもあり、逆にパラドックスを突破する鍵でもあるのだと感じています。

 

 

つまり要約すると

プレッシャーつらい😇

エンジニア兼PM兼責任者な私が「先生方」にプロダクトがイケてるか評価されてしまうわけです……

誰も教えてくれない会話方法

anond.hatelabo.jp

 

そう言えば前に似たこと書いたなぁと思って漁ったらありました。

 

otihateten.hatenablog.com

 

otihateten.hatenablog.com

 

でもこれは議論についてですね。
会話に広げるともう少しパターンがあると思います。

 

正常な会話は正常な議論から

以下は前に書いた図です。
相手の発話に対し、どう切り返すかに関して書いたものですが、これはほとんど発話に対してきちんと意見をいう際のツッコミどころ一覧です。ラストだけ議題変更です。

 

f:id:otihateten3510:20160816210833p:plain

はてな匿名ダイアリーの件では、Aさんはあの手この手で「議題の変更」を行っています。これこそ増田がイラつく原因ではないでしょうか。
つまり増田が提示した議題について、Aさんと議論状態になれないのです。

※ちなみに、議題とは上図でいうところの全体、あるいは一つ一つのツッコミどころという認識です。話題は「カモノハシについて」といったもっと広い話と考えています。話題はそれてないけど議題はそれてることってありますよね。 

 

肯定だけ、否定だけ、議題変更だけはツライ

これは人に依りますが、私は議論が健全に行われている状態の会話が、会話者にとって幸福度が高い状態だと思っています。
これは自分と相手の意見の差異を楽しんでいるのだと思います。

例えば、どんな事を言っても肯定だけ。どんな事を言っても否定だけ。どんなことを言っても議題変更されたらどうでしょうか。非常にツライ会話となり、これ以上話しても無益だとなることでしょう。
特にツライと言われるのが否定だけパターン。逆に肯定だけパターンはあまり槍玉には上がらない印象ですが、人によってはそれも嫌うでしょう。議題変更だけパターンは、両者の中間くらいのツラさでしょうか?

 

人によって会話ゲームが違う

会話してる人たち全てにとっての幸福度(場の幸福度)は、大抵の場合上で言った通りだと思います。しかし、話者一人ひとりで言えば、目指すゴールが違っていたりしますね。

  • 共感してもらうことがゴール
  • 批判することがゴール
  • 場の幸福を追求することがゴール
  • 自分のしたい話を如何に聞いてもらうかがゴール
  • 如何に相手の話を聞くかがゴール
  • 如何にイニシアチブや、マウントをとるかがゴール

etc

これらが上手く噛み合わないと、場としては不幸な会話になってしまいます。

 

議題変更・話題変更

一旦、今ここで話す議題と話題の整理をすると。
こんなイメージです。

 

マルゲリータって美味しいよね」
議題:マルゲリータは美味しいかどうか
話題:マルゲリータについて。美味しい食べ物の話

 

議題変更は何も悪いことではありません。
正常な会話だと

議題が決まる → 肯定・否定が出る → 議題変更・あるいは話題変更 → 

というループで進みます。
いつまでも同じ議題、話題について話していても飽きるだけです。
これらを上手く組み合わせて、ようやく普通に会話になります。

 

感嘆、意見など、その他の選択肢

これらの他にも、感嘆、意見などの選択肢があると思います。
どちらも特徴的なのは、個人が主体になっていることです。

感嘆は分かりやすいですよね。肯定に近いですが、より感情に寄っています。
意見は、主語を広く取れば議題になるところを、個人に紐付けることで事実にしてしまうパターンです。

例:
議題:この服は可愛い
意見:私はこの服が可愛いと思う

主語の選択は、安易な否定を防ぎ、会話を円滑にするためのテクニックでもあります。
主観的なことはどうあがいても議論が収束しないものなので、会話が上手い人はここらへんをうまく使い分けている印象があります。
(逆に主語を無視するとブログでも荒れたりしますね)

主語を自分にしなくても良いと思います。
第三者を持ち出すことで会話の流れにアクセントが付くでしょう。

例:あいつがこの前「この服がすごく可愛いから俺も着たい」って言ってた。

 

議題変更・話題変更のパターン

一つの発話には、ツッコミどころが複数入っているようにみえると思います。
つまり1つの議題は大抵複数の議題に分割することができます。
ツッコミをすることで、議題の再提起がされます。

発話がそれまでの議題と直接的に紐付かない場合には話題変更と言えます。

 

まとめ

  • 発話には、議題に対するツッコミ(肯定、否定、意見)、議題の変更、話題の変更、意見、感嘆、その他がある
  • 会話が上手い人は無意識的にそれらを組み合わせている(恐ろしい!)
  • どれかに偏ると会話の質が下がる
  • いい会話のためには、これらを意識的にバランス良く組み合わせるのが良いんじゃないでしょうか

 

でももうちょいシンプルなモデルにしたいですねこれ。ていうかどこかにまとまってると思うんですが(自然言語の文脈理解か、認知心理学か、言語学あたり?)
あと、本当はもう少し色んなパターンがありますよね。面白いこと言ってみたり、叱ってみたり。

週末開発の課題

とりあえず、課題だけです。
解決策はそのうち(そもそも見つかっていない説)

 

  • 休日が丸ごと空いていない。誰にだって生活がある
  • 休日ずっと開発に当ててると、精神を病んでいく
  • とにかく進まない。エタる
  • モチベーションの維持がキツイ
  • 何やってるんだろう? と我に返る
  • (↑仕事と割り切れない、趣味とも割り切れない、勉強とも割り切れない)
  • 休日ベースだと大人数は回せない、逆に1人だとやること多すぎ
  • 勝てるモデルにするほどMVPが大きくなる
  • 得意領域である開発以外のタスクが多く、しんどい
  • 動くまでが長い
  • データや人を用意しないと動かないサービスだと、リリースまでに壁がいくつかある
  • 何か忙しいことが有り、2週間くらい期間が開くと忘れてしまう
  • 1機能、1チケットも消化できないことが多い。その割に期間があく
  • 時間が経ちすぎてアイディアとして腐る
  • 勉強もしなきゃならない、手も動かさなきゃならない
  • 自由に言語や環境を選びすぎてしまうと、勉強だけで何も進まなくなる(目的が分散)
  • 知識不足で詰む

 

まだまだありそう。

たぶん追記します。

積み記事リスト

年内3割は消化したい

 

・なぜ見積もりが外れるのか
・フロー効率(速度重視)の実運用を考える
・年収を上げる方法 その2(主にIT向け)
自然言語理解にもう一度チャレンジしたい
・IT業界で「基礎」はどれだけ大事なのか?
・リーダブルコード TIPS
・日本の経営者はサイコパスか? 日本のITベンチャーの社長像
・IT業界(Web系)はコンテンツ化する
・ITにおけるチームはデザインパターンで考える
・現実的に、アプリサービスを作る際にかかる費用
・ベテランがベンチャー企業で能力を発揮しきれない理由
・プロジェクトの手詰まりと、その先へのアプローチ
・グロースハック、リーンスタートアップのウソ(やらかしパターン)
・大人数でプロダクトを作るという愚行
・優秀な人が「無能な働き者」になる瞬間
・隣の人を理解するには? その2 ~経営者目線って何さ~
・受託企業ラビリンス なぜ日本のIT企業は儲からないのか

 

けものフレンズ問題=アジャイル・外注問題??


nlab.itmedia.co.jp

 

この発表が全て正しいとは到底思えませんが。

たつき監督、ヤオヨロズの制作体制は、IT業界で言うところのアジャイルでした。
ちなみに「アジャイル」というワードは使っていなく、独自で考えた体制らしいのですが。これはガイドブックや、フレンズの会で語られていました。

 

アジャイル導入の際に起こりがちなこととして

  • クオリティを上げるため進捗が見えづらくなる
  • 承認フローが重くなるのを嫌う

などがありますが、これはけものフレンズでも起きていたようです。
具体的には、テレ東細田Pが「福Pがのらりくらりして教えてくれない」みたいなことがあります。事前共有にも消極的だったそうです。
つまりヤオヨロズのやり方は、アニメ業界内では画期的なのですが、アジャイルとしてはまだまだ成長途上という印象を受けました(やれるだけすごいんですが)

こういった状況の会社はIT業界内にもたくさんあります。
それが問題になって、契約更新しないとか、ウォーターフォールに戻すみたいな話も聞きます。
ヤオヨロズの場合は、制作体制に自負を持っていた節があるので、ウォーターフォールには相当難色を示すと思います。 ※通常の会社なら、外注先プロマネ的な立ち位置の福Pが、外注先プロダクトマネージャーであるたつき監督をなだめるところですが、福Pがたつき監督に絶大な信頼を置いているので、通常のチームとは少し状況が違うと思います。

 

しかし、今回の状況はもう数点考えなければならないことが有ります。

  • 1期はそれでヒットしている
  • ヤオヨロズに技術的優位性がある
  • モデリングなどのデータはヤオヨロズが持っている

※最後の項目は予想ですが、「PC内のどっかにある」とか「設定資料はあまりない」のような発言があったので十中八九、納品物には入っていないでしょう。

この3点で明らかなのは、引き継ぎができる会社が無いということです。

 

引き継げる会社がない状況で、大人気案件の契約を打ち切る

という状況ですね。ITでも有りますが、極稀レベルです。

これは

  • 引き継げると思っている
  • 同等でなくて良いと思っている
  • 事業自体どうでもよく、プライドや会社の力関係の問題

など色々考えられますが、外側から見ると発注側がコントロールできていないと見えるのではないでしょうか。

 

問題の一般化

今回の件は続報を待たなくてはいけませんが、少し一般的な視点で考えたいです。

アジャイル外注は、たとえ成功したとしても色んな特徴を持っているようです。

  • 外注先の替えが効かない、引き継げない
  • 成果物の範囲が難しい
  • 進捗はやはり見えづらい
  • 結果的に、コントロールができない(たつきを信じるしかない) 

これらは時として外注先に有利に働きます。
であれば、本当に成功したい一部の企業を除き、成功するつもりのない大企業はそもそもアジャイル外注を嫌うという未来しか無いのではないでしょうか

受託産業の闇、アニメ業界で言えば製作委員会方式の闇。良いものを作り続けられる環境への模索はまだまだ課題が多そうです。
※アニメ産業でも、それが嫌で受託脱却をしているところがあるそうです

 

ファンの心情

とか、そういう業界の課題はどうでもいいから「たつきを返して」

これがファンの心情だと思います。
業界・仕事のロジックだけ見て、ユーザーやファンを見ないとしっぺ返しを食らうのではないでしょうか。エンドユーザーをよく見ましょう。
ブランドになってる企業なら尚更。

 

※一応念押しですが、この発表が全て正しいとは到底思えません。
 が、発表が全て前提で書いてみました。

※これ、SMAP問題と似てますね

AIと自然言語の不確かさ

最近話題になったお話

 

togetter.com

 

リーディングスキルテストで測る読解力とは 大学共同利用機関法人 情報・システム研究機構 国立情報学研究所 社会共有知研究センター センター長・新井紀子

http://www.nii.ac.jp/userimg/press_20160726-1.pdf

リーディングスキルテストの実例と結果

http://www.nii.ac.jp/userimg/press_20160726-2.pdf

 

一応、私も大学院で自然言語理解を専攻していたので、ここらへんはよく考えます。

割りと多くの人が、自然言語を「正常に読めて当たり前」としていると思います。しかしよくよく自然言語を紐解いていくと、読めなくて当たり前な構造をしています。

一体どうやって読んでいるのか、文法というもので捉えると限界が来るのです。
英語を理解できないのも、翻訳機が未だに完成しないのも、結局は言葉が完璧ではないからにほかなりません。

 

完全にルール化できないのに、何故か読める

こういった現象、最近ディープラーニングでよく見かけます。
結果は出るが、過程が分からない

曖昧なルールで、ある程度何となく読めるようにできています。
そんなだから、当然ながら読解力の低い子も出てきます。

だって、その子は一度だって母国語について教えてもらっていませんから。むしろ読めるほうが不思議なんです。

 

AI研究を元にした読解力テスト

新井紀子さん、東大ロボの方だったんですね。
この研究は非常に有意義だと思います。これまで、不確かな国語文法という50年以上も前の仕組みでしかテストできなかったものを、AI研究の過程をなぞることでより「読解」にフォーカスしてテストすることが可能になっています。

 

でも、読解力には限界がある

この研究は教育にフォーカスされていますが、私が以前より気にしているのは、AIのゴールについてです。

もしAIが吐き出した文章を読み解ける割合が5割だった場合、AIの出した正しい言葉は5割の確率で勘違いされます。ならその言葉はゴール足り得るでしょうか?

システムに喩えるなら、APIの通信失敗です。これはもちろん間違った方に重い責任がありますが、システムとしては両方に責任が生じます。
あくまで受信側が理解できる言葉を、送信側は送り出さなければなりません。
「正しい言葉を送ったから俺は悪くない」は社会では通用しません。

そうなると、AIは人間の間違いを予測し、間違われたことを判別しなければなりません。そしてそれは、AIが真に人間に近づかなければ成し得ません
更に言えば、そんな状況で100%間違わない言葉など吐けないのです

 

AIと聞くと、どうしても完璧で正しいというイメージをしてしまいますが
本当に人間社会に入っていくには、より人間らしく振る舞う必要が出てきそうです。
(しかしそれはあまりにも難しいことです)