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

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

NTTを退職しました。

ついに来てしまった退職エントリ
人のをぼーっと見てるだけではと思ったので
自分でも書いてみる

私自身、NTT研究所と呼ばれるNTT持ち株会社に所属する研究員でした。
最近は一応武者修行ということで事業会社(東西とかドコモとかそういうところ)にいました。 そんな自分がなぜ辞めるのか頭の整理

なぜ辞めるのか

端的には二つのことから辞めるに至りました。

  • キャリアチェンジする基準を満たしたから
  • 違うキャリアの場合、他社の方が魅力的だから

ということです。
キャリアチェンジする基準は以下の二つを考えていました。

  1. アカデミアを目指せなくなった
  2. 研究者以外として一定の業績ができた

アカデミアを目指せなくなった

入社当時から、アカデミアを最終的に目指していることから商用化開発ではなく。
なるべく論文がかける研究よりのところを志望しておりました(細かい分野は割愛)。
内定時も研究能力を期待しているから、研究をしてほしいと言われていた
しかし、初期配属はガチガチの政府系システム開発のチームで、希望と1ミリもかすってないところでした。
まぁ、別に初期配属ガチャでカスを引いただけと考え意思を上に伝えながら3年間開発マネジメントを中心に様々学びました。
その間にも部署の解体を2回経験しその度にコア研究チームかと思ったが毎回開発チーム
このへんで薄々「アカデミックへの道は険しいな、別のことも考えないと」と思っておりました。
その間に行きたい部署へのロビー活動をしたりしていいとこまでいったところでいわゆる事業部門への異動がありました。
人事曰く「これを乗り越えれば次は前から希望していた研究できる部署にいけるよ」とのこと。
事業会社で2年強過ごし次にある程度希望を聞いてくれるなど配慮していただける人事を打診されました。
しかし、この時すでに「今から新たな分野の研究に挑戦しキャッチアップし、先を拓くにはキャリア的に無理がある」
と考えるに至りました。
そしてこの時に、今からアカデミアに行くという道はかなり険しすぎると考えたのです。
また、研究所においても実際に研究できる人や時間はひと握りの恵まれた人たちだけのものという実態も
かなり実感と経験としてあったので今後の人生をかけるにはリスクが高すぎると判断しました。

研究者以外として一定の業績ができた

研究所でありながら、研究以外のことに色々手を出していたこともあり
開発マネジメントやデザイン思考、イベント運営など色々な経験できたました。
そして事業では実際のサービスオーナグループにおいてサービス運営に関する様々な経験をすることができました。
サービス企画・プレスリリース
大規模実証実験の企画・遂行や開発チームのリーダーなどなど事業推進者としてそこそこの経験と成果を残すことができたのです。
この時点で事業推進者としてさらにキャリアを高めて行くという方向性が強くなってきました。

違うキャリアの場合、他社の方が魅力的だから

私の置かれた状況では、NTTグループ内で事業推進者として活躍を目指すということが有力な選択肢だと思います。
しかし、私の興味志向がWebサービスの要素を多分に含みNTT特有の計画経済ではことが進まない分野だったのです。
その志向の違いは意思決定構造・スピードや社内文化、社内環境などかなりWebサービスでスタンダードな考え方と
NTTとは違う要素が多くNTTでは今後この分野で成果をあげて行くにはあまりにも困難だと考えました。
私はあくまでも「意思決定が遅いのであったり、社内開発環境の制約が厳しい」ことが悪いことだとは思いません。
インフラやとして社会に果たすべき役割を考えたらその構造であることは理解できます。
ただ、webサービス業界のような変化が激しく一瞬で市場が蒸発したり淘汰される世界には対応できない。
とは考えております。
運よくオファーをもらった会社ではそのようなことへ対応できる環境があるように思えますし、その実績もあります。 全く正反対の環境であるがこれからのキャリアを考えた場合多くの経験と実績が必要になると考え次の会社に
移ることにしました。

他の理由

他にも色々な複合的な理由はありました。
かなりオトナ語に変換しますが

  • 給与水準が(求められるスキルの割に)あまり高く無い
  • 新規サービス/事業が軽んじられた評価体制
  • 技術を軽視する環境で有能なエンジニアがどんどん辞めてしまっている
  • 異動に伴い転居が発生するがそれを受容できるライフスタイルでは無い

次はどんなことをするのか

次の会社はWebサービス系の会社となります。
会社規模はそれなりに大きく、コミュニケーション事業やAIプラットフォーム事業、決済事業などなど手広く行なっております。
その中で私はAIプラットフォーム事業でテクノロジーの側面から事業を推進するポジションとのことです。

NTT(研究所)に対して思うところ

NTTの研究所は優秀な人たちが非常に多くおり
仕事の難易度も高いものも多くてそれなりに楽しかったです。
辛いこともたくさんありました
しかし、今の世の中では中央研究所モデルは困難なことが多くありすぎているように思えます。
研究内容・分野によって違いますが現在、NTTは法律により事業会社を分社化されそれの"基盤的"研究開発を
行うことがミッションでありながらその基盤とは2社以上の事業会社に利用されることになっており
サービス系の研究においては研究をやりにくくしてしまっているように感じました。
サービスというある程度目的ドリブンの研究開発において"2社以上"となるとある程度、似た目的を持ったサービスを
2社以上検討していることが求められさらに研究成果を事業に転化するには長い(社内調整)期間が必要になってしまいます。
そのため、基礎研究のように事業応用が強く期待されていない分野であったり
ネットワーク研究のような制御可能な計画経済としての応用研究や事業会社との長期的パートナーシップを持った研究以外は
かなりハードルが高いように感じました。そして、それを越えるためにパワーポイントを多用した長い長い社内調整政治が必要になってきてしまいます。
しかし、社会人生活をスタートする上で様々なことを学ばさせていただけれました。
ただやはり、内定時の殺し文句を反故にした配属は今後の不幸の再生産をしないためにもやって欲しくないです。

Cairns旅行(準備編)

ちょっと遅い夏休みということで一人Cairnsに旅行行って来ました。
そこでちょっとだけ旅のまとめ。

旅の前準備

何気に一人海外は何回かあるのですが初めてだときっと数週間前から荷物のパッキングをするのかな
と思ったりします。

持ち物

この中からいくつか気になったのをPick Up

ETA

勝手にVISA無しだと思っていのですが、オーストラリア入国にはETAというものが必要でした。
オーストラリア 政府のサイトからもできる様ですが、代行業者に頼んだ方が安いということがあるみたいです。
ちなみに自分は下記のサイトから840円で取得しました。
ETAS|イータス等海外ビザ申請代行【株式会社ビューグラント】

日焼け止め&サングラス

ケアンズはめちゃめちゃ紫外線強い(みたいです)
もともと肌は強い方なのでよくわからなかったですが
目に関してはサングラス無しでは私はとてもきつかったです。

スリッパ

飛行機の中やホテル(私はMOTELでしたが)で使います。
無いと窮屈な足で寝ないといけなかったり、ホテル客室に無い場合があります。

クレジットカード(デビットカード

ハワイだとJCBなど使えると思いますが、ケアンズは思ったよりJCBは使えないです。
見た感じMasterかVISAが多い様です。
クレジットカードとかだと付帯の保険などもあるのであると便利だと思います。
現地で必要な現金を現地のATMで調達するとレートがいいらしいです。

電源の変換プラグ

オーストラリア は0型というハの字のプラグなので日本から充電器など持ってく時は
それを変換できるアダプタが必要です。

ちなみにオーストラリア は220Vが定格電圧なので
100Vのみに対応している日本の電化製品使う場合は変圧器も必要になります。
しかし、最近の電化製品は日本で売られていても220Vに対応していたりするので
電化製品を持っていく場合は一度確認してみるといいかと思います。
ちなみに私が持っていったUSB充電機などは220V対応しておりました。

ケアンズの季節にもよりますが、男性ならば半袖半ズボンでいいと思います。
朝晩に冷え込むことや山の中にいったりする時の羽織用パーカなどもあるといいでしょう。
また、ホテルにはパジャマなども無いのでパジャマようの装いも必要です。
あって便利だったものはラッシュガードです。
ちょっと海に出たりした時に羽織ったり、UVカットの効果もあります。

アクティビティ予約

ケアンズは街自体も大きくなく、アクティビティがメインになるかなと思います。
私は、時々海外行くときに使うVeltraを使っております。(ポイントとかもあったので)
旅行会社によったらオプションツアーであったり、他にもアクティビティの仲介業者を使うのもいいかもしれません。

www.veltra.com

ちなみに私は

  • キュランダ
  • 4WDでの森散策
  • ミカエルマスケイへのクルーズ&ダイビング
  • スカイダイビング
    をしました。

現地についたら

現金の確保

私の場合はSONY Bankに豪ドルの預金があったのでそれを使いたいという事情がありました。
他に使う機会が無いので
そこで、空港の到着ロビーにあるATMで豪ドルを引き出し現地で現金調達することとしました。
ちなみに、現地ではかなりカードで払えるので100豪ドルあれば十分かなという感覚です。

moneykit.net

通信環境

旅行先の通信環境は結構大事です。
私は、日本国内にいる間にSIMロックを解除して現地のSIMカードを刺しました。
Optusの5日間5GBで10$プランを使いました。
下のサイトに詳しいです。
greenisland-cairns.com 設定はケアンズ空港で到着ロビー内にOptusのカウンターがあり
そこにいるスタッフにSIMカード欲しいといえば買えます。
親切にも設定までしてくれるので絶対にSIMフリーの携帯を持っていたら
現地SIMを使うのがいいと思います。

ケアンズ空港と市街地との移動

旅行会社によっては、送迎がついていたりオプションになっていたりすると思います。
送迎がついていたらいいのですが、もしオプションでそこそこ高いならばタクシーで移動すると便利です。
タクシーでケアンズ市街と空港は時間で10分ぐらいの距離でだいたい20-25豪ドルの料金になります。
これが2人以上になれば割り算でできるのでかなり安いかなと思います。
一人でも旅行会社オプションより安い感覚でした。
ちなみに市街地から空港に来るときは流しのタクシーはほとんどいないので
ホテルのフロントで読んでもらうのがいいと思います。

自動水やりきを作ってみた

ちょっと前の話になるが自動水やりきを作ってみた。

嫁氏にかけかけと言われて書いております。

要件

  • お盆に家を空けるとき(4日間)は最適限持つ
  • 1日二回水やりをする
  • 家の窓はちゃんと閉まるようにする
  • 家に眠るRaspberryPi 3を使う そのぐらいです。

使ったもの

  • RaspberryPi 3B
  • リレー回路
  • 灯油用ポンプ
  • ポリタンク(水よう)
  • ホース
  • 他細々したもの(適当)

作る方針

  1. RaspberryPiで定期的にGPIOのスイッチを一定時間ONにする
  2. ONになったらSlackに投稿する
  3. GPIOの状態をリレースイッチを通して灯油ポンプのスイッチに入れる
  4. ポンプから引き上げた水をホースを通してプランターに水やりをする

作り方

1.RasoberryPiで定期的にGPIOのスイッチを一定時間ONにする and 2. ONになったらSlackに投稿する

今回は、さくっと作って試すためにNode-REDで中身を作ります。
RaspberryPiにはRaspbianOSをインストールしておきます。
ググるといっぱい出てきますが初心者のかたはここら辺を参考に
RaspbianOSをインストールすればおそらくNode-REDは元から入っているでしょう。 そしたらこんな感じにNodeをつなげていきましょう。

f:id:tadanonanika:20180911221324p:plain

簡単に解説すると、毎日6時、19時になるとGPIOの16番PINのスイッチを入れて60秒後にスイッチを切りSlackに投稿するというものです。 それほど難しいところはないでしょう。

3. GPIOの状態をリレースイッチを通して灯油ポンプのスイッチに入れる

ここら辺から、電子工作が入ってきます。
まず、回路を設計していきましょう。
今回、の回路は以下のようになってます。

f:id:tadanonanika:20180910231913p:plain
回路図

RaspberryPiのGPIOスイッチは3.3Vの50mAが最大値となります。
この、電流では石油ポンプが動作しません。
そこで、3.3Vで駆動するリレースイッチを用意して、それを経由して石油ポンプの電源をONにします。
実はここで少しだけつまりました。
リレースイッチでなんとかするという方針があったのですが、適当に買ったリレースイッチが50mAで駆動しなかったのです。
むしろ3.3V 50mAで駆動するリレースイッチが ズボラな私では 見つかりませんでした。
そこでRaspberryPIの5V給電PINからサポートをしながらリレーを駆動させる方法を考え 回路を考えるのがめんどくさいので 小型リレーボードキットLK-RB1を使いました。
f:id:tadanonanika:20180911215649j:plain:w400

あとはハンダコテなどで配線したり、ブレッドボードで適当に作ったりしました。
ポンプの電池端子にはんだづけし回路側に持ってきたりしてます f:id:tadanonanika:20180911215712j:plain:w400

4. ポンプから引き上げた水をホースを通してプランターに水やりをする

ここからは結局は物理の世界です。
ポリタンクから水を引き上げ、ペットボトルに水を入れる。
ペットボトルの底に穴をあけプランターに向けたホースを設置する。 f:id:tadanonanika:20180911215718j:plain:w400

このホースのプランターに差し掛かる部分に穴をあけそこから水を出すようにしました。 f:id:tadanonanika:20180911221845j:plain:w600

このとき、何度か試行錯誤をしております。
まず、ペットボトルの位置を高くしなければホースに水は流れていきません。
高校物理のお話ですがこの高さを稼ぐことに若干苦労しました。
脚立の上にバケツを載せるという荒業

ホースから各プランターに出て行く水の量もホースに空けた穴の大きさに依存します。
大きすぎると水が出過ぎたり、小さすぎると張力から外に水が出なかったりします。
なにせ、水圧はペットボトルの高さの高低差ぐらいしかないので・・・

本当は、水道蛇口から給水しある程度の水力を持って
電磁弁で制御したかったのですが、ベランダに蛇口がないので断念。

しかし、ちゃんとお盆の役目は果たしてくれたのでした。

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

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

下記のようなブログも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件携わることができた

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

 

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

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

開発を行ってきた。

 

----

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

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

みたいなものだ

----

 

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

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

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

 

過去の屍と死因を示して

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

と言っても

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

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

 

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

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

ということだと思う

 

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

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

 

社会は厳しい