ただのプロダクトマネージャから見た世界

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

ジョブチェンジして2ヶ月が経ちまして

年の瀬に入り新しい職場にもうそろそろ2ヶ月となります。 転職に至った経緯は下にまとめてあります

tadanonanika.hatenablog.com

環境が大きく変わったということもあり自分のメンタルなどもコロコロ変わったりしていてそれを日々なるべく客観的に見ることを心がけていたので
ジョブチェンジして2ヶ月の心境の変化を書いていきたいです。

入社1週間目

新しい気持ちで入社し、まだまだなれる段階でみんな優しい。
まだ社内のことがよくわからないので新しい情報を咀嚼するのに精一杯。
業務になれるためのドキュメントの読み漁りやいろいろな打ち合わせに出席。

入社2週間目

少しづつ役割を与えられ、会議のファシリテーションや議事録を通して
自身に関連する業務全体の掴みにかかる。 最初の自分の役割としての業務を引き継ぎにかかる。 新たなプロジェクトのプランニング担当をやるかどうか打診される。
当然二つ返事。少しづつ仕事している感覚で楽しくなってくる。

入社3-4週目

海外出張者の受け入れ業務など若干の雑務を依頼されるも
ここで受け入れ業務が思って以上の多岐に渡っており色々とびっくりする。
前職以上に仕事の振られ方が 抽象的であることを再確認。
新たなリリースの緊急対応などで入社初めてのバタバタ。
エスカレーションする案件にてそのやり方がわからないことがあり時間が取られてしまったりなど、業務をするのに知識なども足らないなか進めることが多くなり少し気持ちはダウンしてくる。

入社 5-6週目

引き継いだ業務の責任者として本格的に振舞うことが多くなってくる。
判断を仰がれることが増えてくるが、自分ではまだわからないことが多く情報の調査などを収集して行うのだが時間がかかってしまい方々に迷惑をかけてしますことがあった。
自分の役割のロールにおいてオペレーションミスもあったりこのあたりで自分の仕事に自信がなくなることが多く前職のぬるい環境が懐かしく思うことが多くなる。
しかし、その中でも周囲のフォローや言葉なので救われたりした。

入社 7-8週目

前週のミスと(慣れ)から、周りをさらによく見ること。
周りにわからなかったら聞くことを強く意識して行動をする。
少しづつまわっていなかった業務も周り始める。
(仕事の概要を掴むためにやっていた)オペレーション業務の改善・効率化PJをリードとして始動し自身の余裕を作るべくと体制構築やポリシーの制定などを行う。
少しづつ何をしないといけないのか、どうやってやるのかが見えてくるようになる。
完全ではないが、自身が回復したりする。
若干の息切れを起こしながら年末年始休暇に突入。

感情の起伏

少し、だらだら書いてしまったが入社して2ヶ月の中でももともとないほうである感情の起伏がそこそこあり以下のような感じだった。

  1. キラキラ期 (1 week)
    • 入社ばっかりの気持ちで新しい環境と不安でいっぱい
  2. 頑張ろう期 ( 2 week)
    • 少し、業務が始まりやっていけそうで成果を出してやろうと意欲に満ち溢れている
  3. これでいいのかな期 ( 3-4 week)
    • 業務が本格的に始まってきてうまくいかないことなどネガティブなこともありやる気がからまわるなど、ちょっとづつ辛くなってくる
  4. 本当にこれでよかったのかな期 ( 5-6 week)
    • 業務上の失敗などで一気に自信が損失し、過去の会社の方がよかったのではないか残っていればよかったのではないかという気持ちが出てくる(でも、帰る場所はもうないんだよ)
  5. やっていけるかも期 (7-8 week)
    • うまく行かなかったことを反省し、混乱していた気持ちを落ち着け焦らずもう少し落ちつていこうという気持ちと一個づつ仕事をまわるようになってきてやっていけそうだなという気持ちになる。

転職してよかったか

今のところよかったと思える
うまく行かない時に前職を思い出すことや、戻りたいと思うことな無いかと言われればある。
それでも、残っていたら本当はどうだったのかであったり社内環境・給与・業務内容は今の方が良い。
また、自分の人生や家族のことを今以上に真剣に考えることになる。
というのも、これまでは会社に縛られ会社の枠内でしか動けないという見えない鎖があったが一度転職を経験することで自分の力で人生を切り開いていかなければならないという強い自覚、自由な選択肢があるのかという事実、自分でなんとかしないといけない自分の人生に対する責任などを再確認することになった。
それはこれからの長い人生を考えた場合、今このことを強く意識できたことはそれだけで転職してよかったと思える。

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ということになる。

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

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

 

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

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