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

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

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

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

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

要件

  • お盆に家を空けるとき(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件携わることができた

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

 

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

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

開発を行ってきた。

 

----

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

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

みたいなものだ

----

 

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

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

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

 

過去の屍と死因を示して

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

と言っても

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

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

 

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

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

ということだと思う

 

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

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

 

社会は厳しい

誰のための仕事か

7月に突然辞令が出て

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

 

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

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

 

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

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

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

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

 

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

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

 

その結果とても内向きで

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

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

 

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

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

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

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

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

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

 

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

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

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

 

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

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

思うこの頃

何もない日に休む

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

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

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

 

そんなことで

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

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

 

土日に休むのと違って

とても新鮮。

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

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

 

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

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

そうすると

 

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

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

 

という具合

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

 

・休む必要がない

・やることもない

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

 

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

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

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

と実感する

 

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

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

 

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

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