ただの事業担当者から見た世界

某私立大学理工学部→生体工学研究室→通信系研究所→通信インフラ会社(←いまここ)思ったことを徒然に書いていこう。

絶望的なデザインのサービスをデザインしている

デザインシンキングがようやく市民権を得てきて

下記のようなブログもtwitterで話題になってきている

(追記あり) 日本の家電の「絶望的な使いづらさ」について | coardware

 

かく言う自分は、現在事業担当者として

いくつかのサービスのシステム主管をしており絶望的に使いにくいサービス(UIは当然のこと)を世に出している一人である。

とはいっても、自分自身はサービスデザインの学習やコミュニティに参加したりとデザインに対して無頓着とかではない。

むしろ、自社の中ではかなりUIもとよりUXに関心がある自負はある。

社内でも使いやすいUIにしろとかいうオーダはよくくる。

 

では、なぜそれでも使いにくいUIができてしまうのか。

弊社においては原因は3つあると考えいる

 

1.サービスデザインの思想・プロセスの未浸透

2.プロダクトマネージャの不在

3.専門家・専門技術者の不在

 

ひとつづつ書いていくと

1.サービスデザインプロセスの未浸透

弊社においては、これまで”売れる”自社サービスを作った経験が無い。

しかし、計画通りのインフラを整えた実績だけはある。

弊社の文化として、綿密な調査と計画そして計画から狂いなき実行が重要というのが根ずいている。

ここで、ユーザの介入する機会もなければトライ&エラーをする機会もない。

なぜならばユーザの介入やトライ&エラーには計画の不確実性を増し計画通りの実行ができないリスクを高めている。

#担当レベルではよいものを作るのではなく、計画通りの実行が目的となってしまっている

弊社の場合は基本的にはインフラのような機能で定義される大規模開発しか社内の会議体では想定されていない。

(”機能で定義できる”システムを”ウォーターフォール”で開発することしか想定されていない。)

それは、サービスを作るとはなんであるのかという思想が全く入っていない。

その思想がないことが環境、制度、組織においてサービスを作るうえの大きな足かせになっていると考えられる。

 

2.プロダクトマネージャの不在

弊社において一つのサービス・プロダクトにマネージャがいない。

じゃ誰がそのサービスのおける決定を下しているのか。

それはサービスごとではなくサービスの営業面ならば営業主管のマネージャ。システム面ならばシステム主管・・・それ以外は?謎である(未定義である)

往々にして未定義部分において責任の擦り付け合いが発生しプロダクトの改善は迷宮入りすることが多い(そしてそのまま出てこないか、間違った出口にいきつく)

つまりプロダクトの改善においては今後の営業・マーケティング戦略とシステム投資が密接に関係しているはずでありながら有意義な連携ができているとは言えない。

この問題はUXのようなサービスをトータルで考えなければいけない時にはクリティカルに効いてきて問題が解決されない(棚上げ状態)のままプロジェクトは進行していった結果、残念なUXが完成する。

プロダクトを持つならばせめてプロダクトを管理するマネージャが必要であり、そのマネージャの考えで業務を分解し権限と共に責任を果たすようにしていくことが必要と思う。

 

3.専門家・専門技術者の不在

サービスをトータルで考える場合、サービスコンセプトからビジネスモデル、マーケットリサーチ、UXデザイン、実装・・・等々

様々な業務がある。しかしながら弊社の中には営業・管理・保守運用の管理者および管理者候補しかいない。(#私は出向者でイレギュラーなのだが)

基本的には2,3年のジョブローテーションでグルグルする総合職の集団であり業務に必要なスキルを持った人たちが集まっているわけではない。

しかし、上記のようなサービスを作る過程においては高い専門的スキルが代わる代わる必要であるはず。その結果、なんとなくのサービスを作るプロセスを踏むだけである。

一応、社の方針としては専門的スキルが必要な業務は外部に委託することになっているがそのような状態ではそもそもの業務定義すらおぼつかなく外部に委託することができない。できたとしても的を得た委託ができなく成果物が活用できない。その結果のひとつとして残念なUXをもつサービス・プロダクトができてしまうと考える。

では、海外の優れたサービスを作る企業(Amazon,GE,Philips,Sumsung等々)においてはどうか考えると。ジョブローテーション自体があまり存在せず、ある程度各々の専門分野ができる。その中でサービスを考える専門家やそれを実行する専門術者も育成されていると考える。

 

考えれば考えるほど根深い問題であり、いち担当レベルではどうにもならない

サービスデザインの手法が様々出てきてもそれは文化をつくるところから始まるものであるため

長い取り組みと強い指導力が必要なことであると思う

#担当ではなく幹部クラスにこの危機感が欲しい

 

そんなことをかんがえる連休最終日

あしたからも残念なサービスに少しでもならないため奮闘します。

「やったほうがいい」悪魔

時流の流れによって漏れなく弊社においても

名前だけの働き方改革が流行っている

 

異動してから非常に気になることがある。

 

「やったほうがいい」

 

この単語の意味だ。

 

様々な業務において、何をすべきかを定義することが必要であると思う

なぜならば質を求めればいくらでも業務は増やすことができるからだ。

しかし、業務するための時間は有限である。

いままでは時間いっぱいやればそれなりのクオリティが満たすことができた。

ただ、そのクオリティが本当に必要かどうかはおいて置いてだ。

(無駄な、パワポの絵や無駄な書き起こしなどなど)

しかし、昨今はそうはいかない残業規制もある。人員は減る。

業務所掌は広がり続ける。

 

そのなかで、これまでと同じ業務の仕方はしていては回らないことが見えている。

そうなれば目的を意識したうえで(そもそもこれができていないことが多い)クオリティをコントロールしながら業務を定義する必要がある。

つまり、クオリティコントロール上不要なものはガンガン削っていくべきである。

 

そこで気を付けるのは「やったほうがいい」という言葉だと思う。

弊社のなかでは、上から下まで「やったほうがいい」という業務が多い。

そして「やったほうがいい」というのは担当レベルに落ちてくるときには

「やらなければならない」ことになっている。

上に意見することをしない弊社ではデスマーチが始まる

 

「やったほうがいい」業務の発生は

施策について深くを知らない幹部が、思い付きで発した言葉であることが

8割占めていると感じる。

そして大体内容としては本来の目的とクオリティを考えれば

「やらなくてもいい」ことである。

(時々、クリティカルに「やるべきこと」の指摘もある)

 

 

結局のところ「目的」を意識して仕事をし

おかしいことをおかしいといえる「組織」ならば問題にすらならないし

そこにいきついてしまうが

「やったほうがいい」で生まれた業務は

一度、立ち止まって「本当にやるべきか」一考したほうがいいと感じた。

デザインってなんだろう

結構、重大な局面で

「君の思うデザインてなに?」

という問いがかけられたことからデザインについて半日考えていた。

 

その場では

「コンセプトを具現化する設計図」

と回答した。

 

でも、今になったらそれは本当にそうなんだろうかと考える。

デザインという言葉は「De」+「Sign」から来ていて

なんとか記号を作るってイメージがある。

おそらく、その記号というのが大切なんだろなぁと考える。

 

その記号というものは見えるものは表層的だけど

「機能」を持っていて、それが何かしらの「課題を解決」しているのだと

そしてその「課題を解決」する方針が「コンセプト」だったり

するのではなるかと

 

ここで頭で考えていたデザインに関するキーワードとして

・機能

・課題を解決

・コンセプト

 

そう考えたとき自分の中では

”デザイン=あるコンセプトに従い課題を解決するための機能”

ということで結局は機能に帰着するのではと思うようになってきた

 

でもここでいう機能は

システム開発でよく使われる機能という意味とは違う

自身の頭の中で最もしっくりくものは

Functionという意味の機能で数学でよく使われる

        y=f(x)

のfにあたるものと考える

 

上記の数式を概念的に示せば

x(いまの対象の姿)にf(機能)が作用してy(あるべき対象の姿)

 

そう考えたときさっきのキーワードは

・課題:x(いまの対象の姿)とy(あるべき対象の姿)の差分

・機能:xに作用してyにする能力

・コンセプト:fを作成する方針

なのかなぁと考えた。

 

まとめると

デザインはy=f(x)のfということになる。

うん、個人的にはすっきりしたけどこれ読んだ人は

きっとなんのこっちゃなんだろなぁ・・・

 

まだまだ思考が浅いんだろうなぁと思いながら

これからも時間があったら考えていきたい

 

巨人の肩に乗れない人たち

研究所時代にいくつかの開発案件に携わった

幸運なことに所謂大規模開発にも2件携わることができた

両方とも開発規模も大きく、さらに先進的技術を盛り込むという意味で難易度も高かった

 

その時はソフトウエア工学を駆使した開発管理手法や

リスク管理、経験からくる知恵というものを頼りに

開発を行ってきた。

 

----

ソフトウェア工学はこれまで様々な開発を失敗してきた人たちの

屍を集めて死因をつきとめし同じ過ちを繰り返さないためのまとめ

みたいなものだ

----

 

そこそこ自分が知っているからこそ

違う環境に移り思ったのは

半世紀前に大勢が死んでいった作戦で特攻しようとしている

 

過去の屍と死因を示して

「俺らもこのままじゃ、死ぬぜ」

と言っても

「俺には理解できない。大将が突っ込め言っているから突っ込むんだ」

という返事がくるような感じ

 

「巨人の肩に乗る」という言葉は研究していくうえでかなり意識していた言葉だが

いま思うのは「巨人の肩にのれない」人たちもたくさんいる

ということだと思う

 

きっとそんな人たち、そんな組織をどうマネジメントするかという

巨人もいるだろうがまだ自分はその肩に乗れていない

 

社会は厳しい

誰のための仕事か

7月に突然辞令が出て

研究所から事業部門へ異動し新規事業系の業務を行っています。

 

新規事業系は人が少なく体系化されていないため

裁量が解釈の仕方で大きく(権限があいまい)そこそこ面白い

 

だが、その新規事業であったり特にサービスを考える部分は

まだまだ弱いと感じる。特に、新サービス系は部長級以上の人の評価のために

行っていうように思えるためコンセプトなどの検討が詰まっていない段階で

から枝葉(機能やUI)について詰められるように見受けられている

 

社内の強い意見を飲み込むあまり「誰のためのサービスか」「誰のためのデザインか」

すべてがぼんやりしてしまう

 

その結果とても内向きで

現場に近い担当レベルでは「売れない」と思うサービスができあがる

当然、それを売り歩かなければならないが「売れない」

 

ここまでかかわってきた人たちは一体だれのために仕事をしてるのか

担当レベルはほとんど「幹部の満足感を満たすため」と応えているのが現状だ

それは「幹部を満足させる」=「自分の生活を維持する」というつながりなんだろう

今の会社では大きなインフラというキャッシュマシーンがあるため

実際のところ幹部から担当まで本当にサービスと作りそして売るということを

重視していないのではないかとすら思えてくる

 

せっかく、人生のなかで貴重な時間という資源を提供しているのならば

せめて私自身は意味ある価値を人と社会に提供していきたいと思う

その価値に対する正当な対価を得ることで生活を成り立たせたい

 

幸運なことにプロパーよりも比較的やりたいことできる境遇であるものの

それを少しでもできそうな環境に移るのは現実的手段としては濃厚ではないかと

思うこの頃

何もない日に休む

働きすぎて休むのを忘れていた人です。

嘘です働きすぎてはいません

ただ、休むのを忘れていただけです

 

そんなことで

今日は、年休消化を兼ねて

特に何もないけど会社を休みました

 

土日に休むのと違って

とても新鮮。

なんでかな?って思って考えてみた

(そんなことができるのも休みだけ)

 

今まで用事があって休む平日か

土日祝日しか休んでいませんでした

そうすると

 

用事のある平日→用事をこなす

土日→1日遊んで、1日休むことに専念

 

という具合

けど、何もない日に休むと

 

・休む必要がない

・やることもない

(本当はいろいろあるけど・・・)

 

ことから、いろいろ考えることができる

いわゆる想像的で創造的なこと

やはり自分はこういうことを考えることが好きなんだな

と実感する

 

これからは積極的に休んでいこう

というか、休まないと怒られる

 

そういえばセキュリティの話を

忙しさにかまけて続きを書いてなかったな

 

セキュリティは儲からないか(1)

昨今、マイナンバー制度を始め様々なICTが制度に取り込まれつつあるなか

情報セキュリティーが注目されている。

筆者自身、セキュリティの研究者という側面もあるので雑感

 

弊社は情報セキュリティに対して活発に研究開発の投資を行っている

一方、現場からすると現状の方針では情報セキュリティは儲からないという感覚がある。

その理由を3つにまとめてみた

 

1.情報セキュリティー自身はお金を生まない

情報セキュリティーは言葉はいいが、情報システムで言えば非機能要件である

(非機能要件:システムで実現したい主目的を達成するための以外の要件)

つまり、極論非機能要件は無くてもシステムはできる

そうなれば情報セキュリティーは差別化できる要素であるが、それ自体でお金を生み出すことができる性質の機能ではない。

多くの場合、その性質に対して多大なコストをかけようとする経営判断がされないことが多い。

 

2.費用対効果が低い(ように見える)

セキュリティは何かしらの「リスク」に対しての対応策として考えることができる。

何かしらのリスクが存在する場合、4つの対応策がある

   ⒈リスクの低減(発生確率を下げる:セキュリティ対策ソフト)

   ⒉リスクの保有(発生するリスクを許容する:何もしない)

   ⒊リスクの回避(発生しないようにする:ネットを使わない)

   ⒋リスクの移転(リスクを他人に負担してもらう:保険)

このようにした場合、多くの場合セキュリティ系企業の商材は1に偏る

この時、1を使い実際にセキュリティを担保する場合莫大なコストがかかってしまうため (追加のソフトウェア、アプライアンス等が必要)

クライアントが4つのうちどれを取るのか考えた場合

第1選択肢として1を考えるが、その値段に驚き2〜3に流れる場合多くあるため

意外と1の手段になる時は多くない。

(本当は1~4をミックスしてリスクとコストで効果が一番大きくなるところを考える)

個人的な感覚としては、日本人はリスクへの認識と対処があまりうまくないと思いますが・・・・

 

3.効果がわかりにくいためコモディティ化する

クライアントがめでたく「リスクの低減」をとった場合

実際にそのための製品を導入する。

セキュリティ商材はそれぞれたくさんの特徴がある。

しかし、その効果はクライアントには非常にわかりにくいうえに製品毎の効果の差もわかりにくい

例えば、トレンドマイクロカスペルスキーが店頭に並んでいてどちらを買うか

パッケージ後ろに書いてある意味はあまり理解できないので値段で決めることが多いと思います。

つまり、セキュリティ機能がコモディティ化してしまっている部分があります。

そうなった場合利益を削って価格を下げる戦略を取ることになってしまいます。

 

以上から、理解が難しいうえに一般的な商材は消耗戦になってしまいます。

そのため利益を生みにくい構造になっているのではと思います。

このような場合、どのようにして利益を上げていくかは

既存の経営学の範疇になるかと思います。

そのため戦略によったら利益が出る可能性がありますが

セキュリティだから儲かるという構造ではない。

 

しかし、本当にセキュリティは儲からないのか?

ということを次に考えていこうと思います。