nozayasu

仕事全般/マネージメントで考えたこと

チームの文化とは何なのか?

チームの文化は何を与えてくれるのでしょう。

ある文化のなかで働くということは、価値観や慣習を共有しながら働くことであり、チームにおける暗黙知を与えてくれる。 共通の暗黙知をメンバーがお互いに持っていることで、コミュニケーションの基礎となりチームの意思決定を早める。

つまりはチームを円滑に機能させるための必要条件十分条件ではない)なのではないかと思っています。

  • そもそも文化とはどんな概念なのか?
  • 意識的にチームの文化を作るとはどういうことなのか?
  • なぜチームの文化を良いものにする必要があるのか?

という3つでチームの文化を考えてみたいと思います。

そもそも文化とは?

文化(ぶんか、英語: culture、ラテン語: cultura)にはいくつかの定義が存在するが、総じていうと人間が社会の成員として獲得する振る舞いの複合された総体のことである。社会組織(年齢別グループ、地域社会、血縁組織などを含む)ごとに固有の文化があるとされ、組織の成員になるということは、その文化を身につける(身体化)ということでもある。人は同時に複数の組織に所属することが可能であり、異なる組織に共通する文化が存在することもある。もっとも文化は、次の意味で使われることも多い。
* ハイカルチャーのように洗練されたもの
* 象徴的な思考や学習による信念やふるまいのパターン
* ある社会組織に共有されている価値観

文化 - Wikipedia より引用

なにやらすっと入ってきにくい言葉が並べられていて、うっ…となるので自分の言葉に噛み砕いていきます。

チームを通して人と人が関わることで抱く想いや価値観、言葉や行動の積み重なりがそのチームにおける文化と呼ばれるようになる。

こう解釈すると悪しき文化も良き文化も、自分達で積み重ねた結果でしかありません。これは自分達の歴史とも言い表わせるのではないでしょうか。

過去の文化はある時点まで積み重ねた行動の結果
今の文化は現時点まで積み重ねた行動の結果
未来の文化はこれから積み重ねていく行動の結果

チームの文化というのは時間軸上のある断片のようなものとも捉えられます。 その断片は、チームが置かれた状況・チームを構成するメンバー・チームの積み重ねてきた歴史によって形作られる。

流動的な性質をもった概念であり、その時々の条件を受け止めて継続的なフィードバックをすべきものだと理解しました。

文化の輪郭が少しつかめた気がします。

この考え方をもとに、意識的にチームの文化を作るとはどういうことなのか?を考えていきたいと思います。

意識的にチームの文化を作る

組織的な取り組みの構造を理解する

チームの文化を作る上で、どのような組織的な取り組みが良い効果をあげているのかは、著名な方々や企業が数多くの事例を示してくれています。

数多ある取り組みのなかの1つに共感し、所属チームでも同じように取り組んで良い文化を作っていこう!と考えた時に、果たして同じような効果は得られるものでしょうか?

ここでチームの文化が、もう一度どんなものであったかを思い返します。

チームが置かれた状況・チームを構成するメンバー・チームの積み重ねてきた歴史によって形作られる。

これはつまり、チーム毎の構成要素には様々な違いがあることに他なりません。

違いがあることを前提に持つと、自分達が同じような効果を得るには、取り組みの構造を捉えることが大事になってきます。

その取り組みは、何をチームに与えるのだろうか?なぜ良い方向に働くのだろうか?結果として自分達の望むチームの文化形成に寄与するだろうか?

構造を理解することで、今のチームに与えるべきものだろうか?チームに落とし込む際に大事な観点はなんだろうか?という問いが明確になるからです。

「チームのあるべき姿を言葉にすること」という例を取り上げながら、組織的な取り組みの構造を考えることをやってみたいと思います。

チームのあるべき姿を言葉にすること

チームのあるべき姿・価値観を表すための取り組みとして、ミッション・ビジョン・バリューを設定しよう!というのをよく目や耳にします。

なぜこのような取り組みをするのでしょうか?

過去に一度考えたことのあるテーマで、その時の所感としては

日々の業務レベルにおいて判断基準の1つになり得るものである。

エンジニアが経営理念について考えた話 - nozayasu

というものでした。

チームのあるべき姿を設定することで、メンバーに行動の判断基準を与える
メンバーに行動の判断基準を与えることで、メンバーやメンバー間に健全なフィードバックを促す
一定の基準に基づいたフィードバックの積み重なりが、結果としてチームの文化を望むものへと緩やかに調整する

というような構造を自分のなかで解釈できました。

共通の理想像は、チームの継続的なフィードバックにおける指針となり、日々の積み重ねの方向を無意識下に調整してくれるのでしょう。

実際にチームのあるべき姿を言葉にする際には、チームにおける行動の判断基準になりえているか?フィードバックを生んでいるか?を観点として持つことができました。

ルールや慣習に向き合う

組織的な取り組みの構造を解釈し、チームに落とし込むために必要な観点を持つことをしてきました。

どんなに良い取り組みも、定着することなく中途半端で終わってしまってはチームの文化形成には繋がらないでしょう。次は定着させるために何ができるのか?ということを考えていきます。

イメージを湧かせるために「ユーザーファーストに徹すること」を例にしてみましょう。

ユーザーファーストを組織的な取り組みとして実現するために、職種の垣根を超えてユーザの声を日々の行動や施策に活かすことを推奨する。

この時、チームでは何が起きるでしょうか?

エンジニアが営業同行して直接ユーザーの声を聞きにいく、営業がSQLを駆使してユーザーの行動ログを分析する。ユーザの声をより深く知るために、職種や職能の垣根も超えてどんな向き合い方ができるのか?をメンバーは模索するかもしれません。

しかしこれはあくまで、メンバーの意欲に依存する形です。定着を目指す場合には、ある程度のルール化を検討する必要があると考えています。

ルールにするということ

具体的なルールとは「月一回エンジニアは営業同行をすること」といったものです。強制力を持つルールは、メンバーを行動させることに直結するため、取り組みを定着させることに強い影響力を持つと思います。

行動を起こさせるではなく、行動をさせるという言葉を使いました。ルールというものは個人が納得感を持っているかは関係なく、行動という結果を引き出すような力も持ち合わせるため、それが苦痛であると受け取られた場合強い反感を買うことでしょう。

メリットとデメリットを考えた上で、どのような場合にルールにすべきなのでしょうか?自分のなかの基準を考えておこうと思います。

  1. チームの理想とする価値観を共有するため、それが望ましい強制である場合
  2. 立場・職種・職能を超えたフィードバックや指摘をしやすくなるよう、メンバーに公平性を与えたい場合

1について

たとえルールの設定者側が望ましいと思っても、最悪の場合それを理由に辞められるかもしれない。ということはあり得るだろうと思っています。

なので、なぜそのルールが望ましいと思っているのか?をチームやメンバーに繰り返し言葉にすることを、合わせて行うべきと考えています。

2について

チームに取り組みを定着させるためには、メンバー間での監視が機能することが必要です。人間は忘れる生き物であり、ミスをする生き物だと捉えています。だからこそ、フィードバックを日常的に行えることが定着に強い意味を持ちます。

しかしフィードバックというのは、職種や立場を超えて行うことに心理的障壁が伴うものであるというのが一般的です。 そこでルールです。ルールという共通の基準を逸脱したか?で判断できる状態を与えることは、フィードバックをするという行為の心理的障壁を和らげるだろうと考えています。

慣習の扱いを決めるということ

チームにはルールのように明言されていないが、メンバーが同じようにとる行動である慣習と呼ばれるものが存在します。

ある行動を他者が真似する形で生まれたもの、メンバー特性によって生まれたもの、ルールの副作用で生まれたものといったような自然発生するものです。

慣習は自然発生したものであるがゆえに、チームの文化にとって望ましいものであるとは限りません。扱いとして、認める・認めない・黙認するという3つの選択肢が考えられます。

価値観にマッチしているか?メンバーの自由度を妨げないか?何か問題が起きているか?という観点で、いかに扱うべきかを判断する必要があると考えます。

特に黙認する選択肢をいれることが大事だと思っていて、慣習を認める・認めないと明言することはルールを作ることと同義であり、メンバーに前述したようなストレスをもたらす可能性のある行為です。直近問題がないのであれば、あえて黙認することにも意味があると感じています。

なぜチームの文化を良いものにするのか?

チームの文化というものは、良くしたことで事業の利益に直接影響するものではないかもしれません。

また事業がうまくいってるときには、得てしてチームの雰囲気も自然といいものです。 逆に言えば、事業が苦難と対峙したときほどチームの雰囲気が悪くなります。

ここで考えなければいけないことは、チームの雰囲気が良いこととチームの文化が良いことは別であるということ。チームの雰囲気が良くても組織的負債は貯まっていく可能性があるということ。

なぜチームの文化を良くするのかと言われれば、それは事業を継続させより発展させたいから。

事業が苦難と対峙した時にどう切り抜けるか、チームが苦難にきちんと対峙できるようにしておく必要がある。

そのために普段からチームの文化のことを考えていなければいけない。組織的負債を溜め込み過ぎないようにしなければならない。

たとえ事業がうまくいかず雰囲気が悪くとも、それでも必死にチームとして事業に向き合っていれてるのであれば、そこには良いチームの文化があるのだと。そんな風に僕は思うのです。

Japan Product Manager Conferenceから感じ取った、プロダクトマネージャー19の職責と11の心構え

pmconf.jp

全体的な所感

今回参加したJapan Product Manager Conferenceは、プロダクトマネージャーという言葉が表すものはなんであるのか?という問いかけに尽きるなと思いました。

実務経験から得た知見や結果の考察、思考法やフレームワークをどのように取り入れているか、理想とする姿と現場としての課題感。様々な観点でのセッションがあった中で、会全体を通してプロダクトマネージャーの職責を言語化する、心構えを共有するという熱意みたいなものを感じ取れたからです。

以上の様な全体的な所感を前置きとしつつ、僕が感じ取ったプロダクトマネージャーの職責と心構えを整理します。さらにプロダクトマネージメントというものに対して、二日間何を考えたのかという構成で話をしたいと思います。

僕は前提としてプロダクトマネージメントというものは、事業領域や構成メンバー等によって独自文化を持つものである。それ踏まえて抽象化できるものや、一般論として話せるものもあるという考えを持っています。なので今回は、事業領域等を超えて一般化できることと感じたものを整理します。

プロダクトマネージャーの職責

http://3.bp.blogspot.com/-Lre98PlTKKM/Vf-aHNlsDXI/AAAAAAAAyDQ/erI62bdTvds/s800/businessman_workaholic.png

課題探索

  • プロダクトに懐疑的であり続けることが職責である
  • プロダクトが解決する本質を探索することが職責である
  • プロダクトの課題設定をすることが職責である

戦略立案

  • プロダクトの理想像を言語化するのが職責である
  • プロダクトの定性的な目的設定をすることが職責である
  • プロダクトの定量的なゴール設定をすることが職責である
  • プロダクトの成果を出すことが職責である
  • プロダクトの好意・認知・配荷を向上をさせることが職責である
  • プロダクトのリスク・阻害要因を取り除くことが職責である

構造化

  • プロダクトの課題・目的・ゴール設定を理解・実行できる単位に細分化することが職責である
  • プロダクトタスクの優先度付けすることが職責である
  • プロダクトタスクを継続実施するための必要情報全てを整理することが職責である
  • プロダクトの成果を理解できる単位に分解・翻訳することが職責である

組織作り

  • チームメンバーの特性を理解することが職責である
  • チームメンバーの課題や経験を引き出し、チームとして循環・還元させることが職責である
  • チームメンバーのオーナーシップを支援するのが職責である
  • エンジニア、セールス、マーケティング、デザイン、サポート、あらゆる部門と健全なコミュニケーションをとることが職責である

成果分析

  • プロダクトが課題を解決できているかを分析するのが職責である
  • プロダクトの成功/失敗を判断することが職責である

プロダクトマネージャーの心構え

http://1.bp.blogspot.com/-BcUJyoZPQns/Vt_t2lfEDUI/AAAAAAAA4pc/t9i1I_hoCXA/s800/business_tayoreru_man.png

  • 権限ではなく戦略やビジョンを振りかざすべきである
  • 自分やチームにゆとりをもたらす仕組みを整備すべきである
  • 考えを徹底的に言語化して伝えるべきである
  • 建設的な議論や問いかけをするための言葉を選んで使うべきである
  • コミュニケーションのハブであろうとすべきである
  • 公平性があるプロダクトより愛されるプロダクトを考えるべきである
  • 面倒なことほど取り組むべき課題だと考えるべきである
  • ルーチンワークは仕組みに置き換えれないかを考えるべきである
  • 追加開発は、追加スケジュールとセットになるものだと考えるべきである
  • エンジニア目線とユーザ目線は、対立するものではなく補完し合うものだと捉えるべきである
  • 世界を見据えたプロダクトを考えるべきである

プロダクトマネージメントというものと二日間向き合って

カンファレンスの内容は、とても刺激をもらえ影響を受けるものが多かったです。

また開催期間中の伊藤直也さん言葉にとても考えさせられました。

改めて、プロダクトマネージャーに担ってほしいことはなんでしょうか?

思想家でしょうか?戦略家でしょうか?評論家でしょうか?プロダクトに関わる全てでしょうか? 僕はプロダクトを通して責任を負っていく役割だと考えるようになりました。 責任を負う過程というのは、人に足りないものを埋める動きをさせ、把握する範囲が広がっていき、思慮深くある必然性をもたらすのだろうと感じています。

加えて、数多ある職責の中でも個人的には物事を構造化できるスキルや経験値が重要視されると考えるようになりました。 難しい課題や大きな目標に対して、自分達が理解・実行可能な単位に分解できるかどうかが日々の成果に影響する。
売り上げ目標1億に対する成果10万をいかにして生むのか、予実をとれる単位が細かいほど大きな目標の予測値信頼度があがる。
大きな目標を達成するべくして達成することが、プロダクトマネージャーの責任を果たすと言うことなのかもしれない。
といったことが二日間を通して自分の中に残りました。

最後に少し話を変えて本を読む行為というものを考えてみます。本を読み続けていると書籍毎に点で理解してきたことに対して、一気につながって物事の流れや構造体をぐっとイメージできる瞬間があります。
経験される方も多い感覚かもしれません、あっこれは別の書籍でも近しい内容に触れたことがあるぞ共通解なのかな?だとするとあっちの矛盾はこっちで解決になるのかもしれない。のような体験です。

本質を探る行為というのは、例にあげた本で体験できる様な感覚。多角的な視点を用いて、もやもやしていた物事の構造体をイメージできるようにする行為であると考えています。

責任を負い、思慮深くなり、把握する範囲が広がる。副次的に物事を多角的な捉えかたをできるようになり、結果として構造体をより深く理解・説明をできるようになる。この流れをイメージできたことが、僕の中で一番の収穫でした。

運営の皆様、登壇者の皆様、会場でお話しをさせてもらった皆様、ありがとうございました。

工数見積もりとはラブレターである

前置き

システムを実装する上での工数見積もりで、どんなことを把握したいですか?
僕は個人にできるかぎり依存しない、事業価値を届けるために必要なコストを把握したいと思っています。

工数見積もりとは誰が行うものでしょうか?担当するエンジニア個人でしょうか?それともチームに属するエンジニア全員でしょうか?
僕はデザイナーや企画も巻き込んでチーム全員と関わりながら行うものであると考えています。

関係者全員で、絶対的な時間の見積もりではなく、相対的な規模感での見積もりをしていく。この辺りは所謂アジャイルな開発の思想に影響を受けているように思っています。

このような考えのもと、工数見積もりというものを通して

  • 何がしたくて何がしたくないのか
  • 各ポジションとどんな風に関わっていくのか
  • 一番考えるべきことは何だと思っているのか

みたいなポイントで自分の考えをまとめていこうと思います

何がしたくて何がしたくないのか?

工数見積もりでしたいことはなにか?

  • ユーザーにとって必要なものであることがイメージできること
  • イメージ通りの機能を作りあげるために必要なものを整理すること
  • 規模感の把握

工数見積もりでしたくないことはなにか?

  • 実際にできあがったものが意図していないものになること
  • 作業に入ろうとしたときにまだ動きだせない状態であること
  • 未確定要素によって規模感すらだせないこと

こうやって改めて考えてみると、情報の整理からくるタスク分解と規模感を把握だけでなく、タスクの完了状態が与える影響がどんなものかもこの段階で意識したいのだなと思いました。
また着手時にすぐ動き出せるように、未確定要素を極力なくす調整もこの段階で一番とっていきたいと思えました。

各ポジションとどんな風に関わっていくのか

デザイナーや企画側に対して

デザイナーや企画側に対してはフィードバックをする、レビューの面もあると思っています

  • どんなことをしたいのか伝わってくるか?
  • 自分がユーザとしたら価値があると思えるか?
  • タスク分解をイメージできるだけの情報があるか?
  • やりたいことへのシステム的な解決はもっと良い方針がないか?
  • これをやらないで別のことやったほうがよかったりしないか?

実装する側だから気づける点と想い、実装前段階ですり合わせていくことで出戻りを少なくしていければと思っています。

同じエンジニアに対して

同じエンジニアに対しては、いかに思いを伝えて共通のイメージを持つかが大事だと思っています。

  • 他人がこの作業をするのならどんな情報が必要か?
  • 新たに配属された人でもイメージできるだけの情報になっているか?
  • 作業の実現アプローチは妥当なものか?
  • 実現するための不明点はないか?

同じエンジニアだからこそ、スムーズに開発がスタートできるよう負担を軽減することになればと思っています。

一番考えるべきことは何だと思っているのか

やることの見積もりをするのはもちろんなのですが、僕は加えて一部やらない判断を提案していくことや、既にあるもの削除していくための見積もりこそ大事ではないかと考えています。

それは事業に対してエンジニアが一番主張できるポイントが、何を作らないのか?だと思っているからです。
やらないことが増えると、保守するコードが減ることになります。運用時のフットワークが軽くなります。

全ての企画を作るとこれくらいかかるけど、同等のこんな機能ならこれだけでできるよ?
企画のやりたいイメージをいかに、シンプルな機能だけで実現できるのか?そこを考えるのも面白いとこなんじゃないかなと思っています。

そういう意味で工数見積もりとは、事業を企画することに大きく関わる作業だと言えるだろうと考えています。

まとめ

作業担当する誰かに送る、精一杯の想い。色んな下準備をして、受け取る人に気に入ってもらえるように作る。さながらラブレターなんじゃないかと思っています(今回これがいいたかっただけかも)。

愛を持って工数見積もりをしてみませんか?きっと愛は届く!きっと。

おしまい。

チームのUXをマネージメントする

チームで仕事をすると言うのはどの様なことでしょうか?
メンバーはチームを通して何を感じ、他のメンバーに何を感じさせるのでしょうか?

今回はチームにおけるUXという視点で、何をマネージメントをすることができるだろうか?を考えます。

チームで仕事をする際のUXとは?

まずは僕の考えるチームのUXは何かを定義します。
チームを通して何を考え、どんな行動をして、どれだけの対価を得たり払ったりしたか。と言うことだと考えていて

  • アドバイスをして、信頼を得ること。
  • 成果が出て、自信を得ること。
  • 失敗して、信頼や自信を失うこと。

例えばこのようなことがチームで仕事をする際のUXだと捉えます。

チームのUXをマネージメントするとは?

チームと言う体裁があったとしても、メンバーはあくまで利己的に行動を決定するものだろうなと考えています。
もう少し噛み砕くと共通の目標があってチームは結成されるわけですが、漠然と走っていくとメンバーは個人の利益を最大化させる行動を無意識に優先するだろうと思っています。

チームとしての利益という視点での行動をメンバーから引き出すこと、これがチームのUXをマネージメントするということだと考えています。

引き出すために何をするのか?

books.google.co.jp

この本であげられている様な心理的安全をチームにもたらせるように先導していくことで、チーム利益のための行動が、個人利益のための行動と同等の価値を持つようにしていきたい。そのために何をするか?ということを考えていきます。

  1. どんなチームが理想なのか、どんなチームにしたいのかを伝える
  2. チームがメンバーに何を期待しているのかを理解できるようにする
  3. 実際に行動に起こすという体験をできるように手助けしてあげる

それぞれを見ていこうと思います。

どんなチームが理想なのか、どんなチームにしたいのかを伝える

僕の大好きなスライドを紹介して、まずイメージを持ってもらえればと思います。

speakerdeck.com

ここで伝えたいことは、スライドの中に書いてある内容が正だ、これが僕の理想だということではありません。(個人的には好きで影響うけてます)

チームとしてどんなメンバー同士の関係性でありたいのか、どうあることがいいことだと考えているのか。それをメンバーに伝え、示すことが大事だと考えています。

もちろん理想を話すことはメンバー間で折り合えない部分もあると思っていて、それはそれで良いと思います。折り合えないよということがわかることで、対応できる余地が作れると考えるからです。苦手なら苦手なりの、付き合いかたを考えましょうか?となれれば僕としては儲け物です。

今後のチームとしての行動指針を一緒に考えていこう?という意思表示と、実現するためになにができるか考える、自分だったらもっとこうだと考える体験をメンバーとすることを狙いにしています。

チームがメンバーに何を期待しているのかを理解できるようにする

最近見て考えることが多かったワークショップの資料を紹介しつつ、こちらもまずイメージを持ってもらえればと思います。

speakerdeck.com

「知っているだけで解決できる問題が世の中にはたくさんある」この言葉をなるほどな、そうだなーと思いました。僕個人としてチームメンバーに期待すること、思っていても正直あんまり言葉にしたことなかったです。

僕はこのスライドをみて、これって開発フェーズ毎と役職や職種って視点で分けて考えると、もっと具体的な業務レベルでの期待感の共有になるかもなと思っています。

企画立案時には、エンジニアは企画者にどんなことを期待してるのか。その逆はどうなのか。実装時には企画立案時とは別の期待がメンバーに生まれるのか。ユーザエクペリエンスマップのペルソナをチームメンバー、フェーズを開発のフローに当てはめてみてワークショップ等企画してみることで、チームの相互理解が深まるのではないかと思っています。

チームメンバーがお互いに期待していることを把握することで、今のタイミングではこんな行動してほしいのかな?と考える体験をすること、プラスの対価を得る行動はこうなのかもな?と感じてもらうことを狙いにしています。

実際に行動に起こすという体験をできるように導いてあげる

これは最近よく感じていることで、不安や困ってることを言える雰囲気作る、心理障壁を減らすってことを実践していくには、メンバー個々人が実際に想いを口に出す体験を何度したかが大事だと考えています。

やはり自分にとっての印象を悪く捉えられそうなことを口に出すのは、抵抗感があるものです。新規参入したメンバー等であればなおさら。

なので最初は聞き出す努力がいる

丁寧に自分で口に出すって行動までを引き出してあげることが、何でも言える雰囲気を育てていくことに繋がるだろうと考えています。開発してて困ってることある?といった聞き方ではなく、この開発だったらこんなとこ困りそうに思うんだけど大丈夫?
と言った様な少しつっこんだ聞き方をすることで、個人としてマイナスの対価を得ると思われがちで嫌厭される行動を、起こしやすくしてあげられないかを狙いにしています。

まとめ

チームとしての利益という視点での行動をメンバーから引き出すために、心理的安全をチームに熟成させたい。それをこんなアプローチでやっていきたいと思っています。どうしてそうしたいと考えてるのか?と言う観点で書いてきました。どこか参考になるところがあれば幸いです。

おしまい。

エンジニアが経営理念について考えた話

前置き

経営理念ってなんでしょう?ミッション・ビジョン・バリューってなんでしょう?様々な会社が掲げています。社内に浸透させようとしています。
僕は今まで5社ほど勤めてきたなかで、正直一度もキチンと意識して働いたことはありませんでした。それは僕自身が必要としてなかったからなのか、会社としての伝え方の問題なのか、最近ふと考えてみたという話です。

経営理念って何?

経営理念とは、組織の存在意義や使命を、普遍的な形で表した基本的価値観の表明。

平たく言えば、「会社や組織は何のために存在するのか、経営をどういう目的で、どのような形で行うことができるのか」ということを明文化したものである。

これによって経営者は、基本的な考え方を内外に伝えて共有化したり、社員に対して行動や判断の指針を与えたりすることができる。理念自体に社員が共鳴すれば、働くインセンティブにもなり、企業における求心力にもつながる。すなわち経営理念は企業文化を形成する主要な要素である。

経営理念の内容は、行動規範的なもの、経営の成功のための鍵や経営姿勢を示すもの、企業の存在意義を示すものなどいろいろな形で表現される。一般的には、社会、顧客、および社員の三者に関する理念が設定されることが多い。

経営理念が難しいのは、適切な設定をしても時代とともに形骸化し、現実と乖離してくることである。どれだけ優れた経営理念やビジョンであっても、その変更のタイミングを見極め、時代に合わせて方向を再設定、再定義して、新たな道を踏み出さなくてはならない。

経営理念とは | ビジネススクールならグロービス・マネジメント・スクール より引用

なるほどなるほど。
とても大事なことなんだな、ということは理解できました。
と同時に僕はこうなんじゃないか?と思う点がいくつかあったので、章に分解して整理してみたいと思います。

理念自体に社員が共鳴すれば、働くインセンティブにもなり、企業における求心力にもつながる

理念自体に共鳴できる人はどれだけいるのだろう?単純な疑問をこの一文から持ちました。 というのも今まで理念に共鳴するからここで働きたい、と思えたことが僕自身なかったからです。

それはなぜなのか、というのを自分の中で解釈すると「自己の会社や組織は何のために存在するのか」という視点で普段想像や仕事の一端を見ていなかったからだろう。と言うところに落ち着きました。自分が普段考えていないことに対して、共鳴するということは起こりにくい。

ではそんな僕が経営理念として共鳴しえるものはなんだろうか?と改めて考えてみると、自分の考える1個人としての社会的な存在理由にぴたりと合致するケース。もしくは内容自体が重要ではなくだれが言葉にしたのか、魅力をもった人物が作った言葉には自分から寄せていって共鳴したいと思えるかもしれないなと考えます。

実際僕はどこで働きたいかよりも誰と働きたいかで職場を選択してきたので、自分が働く上で大事にしているものが改めてそういうことなんだろうなと再認識しました。

とこんな流れで考えた結果、理念自体に魅力を感じる人はいないことはない。けれど組織にいる理由の大半は個人レベルでの魅力、プロダクトに対する魅力に共鳴したからなのかもしれない。相対的にみて理念自体に共鳴する人は少ないんじゃないだろうかという考察に至りました。じゃあ僕の考える経営理念の必要性って?というところは別の章やまとめにて。

考え方を内外に伝えて共有化

僕はここを重要な一文だと捉えました。内外っていったい何を指すのでしょうか?
僕は内が組織や社員、外が社会や株主といったものを指しているだろうとそれぞれ考えています。

ここでさらに踏み込んで考えなければいけいないことは何でしょう?僕は内と外で期待するものが違うだろうという点を考えなければいけないのではないかと思っています。内外をひとくくりにできるような言葉ってどんなもの?むしろそれぞれに向けた言葉を別で用意すべきものなのではないか?

そもそも経営理念ってどんな風に考え始めるのか?と想像してみると、経営理念には創業メンバーの強い起業動機、社会に向けた意思表示の面がやはり大きいと感じています。つまり外向きに寄せた言葉を設定することが多いなと思っていて、そもそも内向きにも響くようにとするのは難しいのではないか?という疑問を持ちました。

その解釈持って、経営理念を表す際にミッション・ビジョン・バリューと複数用意されているのはどうしてか想いを巡らせると、なるほど向き先の違う言葉を定義してるのかな?という見方をすることができました。

また最近知った言葉でインナーブランディングというのがあるので取り上げるのですが、こういう内向きに対しての明示的な言葉が存在することからも、向き先に合わせた言葉の作り方が意味を持っている。内外に伝えるというのは単に同じ言葉で表すことではないな、と考えるようになりました。

インナーブランディングは、インターナルブランディングやインターナルマーケティングとも呼ばれ、社員に企業ブランドの価値や目指す姿を理解させる啓蒙活動が起源です。消費者などに対して自社のブランド価値を啓蒙するアウターブランディング(エクスターナルブランディング)と共に、ブランド構築活動を構成する重要な要素のひとつです。

インナーブランディングとは|KAINOSHO より引用

社員に対して行動や判断の指針を与えたりすることができる

エンジニア目線で見た場合、経営理念に一番重要なのはここだろうと思ってます。組織としての正解はなにか?現場での判断に困ったときに基準となるものはどんな想いなのか?それが明確であることは、最も会社が社員に浸透させる意味を感じれます。
経営理念の元、僕はこの企画や実装を採用することが正解だと判断しました。なんてことを社員が言うことを願っているのかな?と想像することもできます。

このへんの解釈で、僕の中にすっと入ってきた言葉を引用しておきます。

大事なのは、 その企業が目指しているものを従業員に理解してもらうことで、 従業員の仕事に方向性と目的を与え、さらに従業員が意思決定をするときの ”判断基準”になるように落とし込み、それによって企業を成長させることなんですね。

As I Am. | 有名企業から学ぶ;ミッションとビジョンの違い より引用

判断基準になるレベルまで落とし込むことを目標にし、結果として企業としての成長を得たいのだな。なるほどなーと腹落ちしました。

まとめ

自分の考えをまとめると経営理念というのは、経営者や企業としての内外にむけた意思表示である。
社員目線でみると、日々の業務レベルにおいて判断基準の1つになり得るものである。
外向きには企業としての存在理由、内向きには組織の行動指針として必要なものである。

各社想いや狙いがあって作るものであるとは思うけれど、僕個人としては誰に向けた意思表示なのかという観点を明確にして設定されていたほうが、浸透しやすくなるのではないだろうかという考察になりました。

経営理念なんて理解しなくても、仕事はできるのかもしれないし僕はできてきました。
けれど判断基準になりうるものだというのを解釈できると、理解する必要性があると考え方を変えることになったのはよかったです。
チームで働く上で、同じ価値観・判断基準というかが皆で共有されていると、スムーズな連携がしやすくなることを実感しています。

経営理念ってくくりで受け取ると大層なことに感じますが、このことって事業単位、数人のチームにおいても共通に言えることだと思ってます。一緒に集まってなにかを作っていくって時には、チームとしてそれをどんなものにしたいかって意思表示を明確にしておき、個々人の判断基準になるくらい浸透させること。考え方の粒度や視点の違いはありますが、大事にいきたいですね。

ということで経営理念に共鳴して働きたい!となる人は考えた後も稀だろうと思ってますが、経営理念を社員に浸透させる意味は理解できました。
経営理念の理解は大事、理解してきましょう。

おわりに

組織論とか、チームが機能する仕組みづくりとは?
みたいなのが最近の勉強のテーマなのでそういうの好きな人とか、マネージメント層・経営層の方で話聞いてあげてもいいよってかたは是非機会を作らせて下さい。

エンジニアがデザインと向き合うために思考する

前置き

良いデザインに出会ったことはありますか?デザインと括られるものを通して、感情を動かされたことはありますか?世の中には多くのデザインされた物で満ちていて、人の感情を引き起こしてくれる素敵なプロダクトがあります。

漠然と疑問に思っていたことがあって、人はデザインの良さを何を見て判断をしているのだろう?作り手は何を思い描いているのだろう?僕は感覚的な部分、表面的な部分でしかデザインを感じることができてないんじゃないか?

僕はデザインの内側にあるものを知ることで、エンジニアとして、サービスを作る人として、デザインへの理解、価値の判断基準を自分の中に持ちたい。と考えるようになりました。

そんなデザインを深く考えたことのなかった僕が、デザインの何に興味持ち、何を理解し、どんな風に考えるようになったかを整理していきたいと思います。

そもそもデザインって?どんな風に成り立ってきたもの?

物・事の成り立ちを知りたくなる性分なためか、多少遠回りな出発点です。とは言え分厚い参考書は頭に入りにくかったので、全体の流れを知れるものとしてこの本を手に取りました。

www.mdn.co.jp

権力・荘厳さといった絶対的な存在を誇示するための表現方法から始まり、知性や緻密さといった豊かさを示すような表現方法が必要とされてくる。工業発展による大量生産の時代が訪れると、デザインを必要とする人が特権階級だけでなく民衆全体となり、必要とされる表現方法はより機能美や合理主義に傾いていく。

このようなデザイン史の変遷を知って思うのは、デザインには時代背景が色濃く反映されているのだなと言うことです。何を表したいものか、誰が最も必要としているものかによって、デザイン形態が出来上がるのだと解釈しました。

デザインとは何を表現するものなのか?

デザインは対象に自己同一性を与えるものである。
デザインは対象が人に与える感覚を科学的に拡張させるものである。

現段階の僕が考える、デザインはなにを表現するものだろうか?はこの2つに集約されています。

デザインは対象に自己同一性を与える。とは?

僕がデザインの与える自己同一性をどの様に捉えるかにあたって、職場で紹介してもらって参考になった記事があります。

medium.com

この記事自体はデザインそのものについてではなく、オリンピックのビジュアルデザインとして求められているものはなんであるか?について書かれているものとして読みました。その上で僕はこの記事内容からデザインは対象を、何時、どこで、部分として捉えても、全体として捉えても、等しく対象であると認識させるようにできる。自己同一性を表現するものでもあると解釈しました。

デザインの局所的な部分や表層の部分ばかり見ていた側からすると、こんなにも緻密に考えをまとめ、人の感覚を導いているのかと気付かされ、部分と全体が一体となるための細かなシステム設計、秩序をあたえること。デザインとは単に装飾を施したりビジュアルのことだけを指すものではない。感覚値ではない、論理からなるデザインの一端を知れたように思います。

デザインは対象が人に与える感覚を科学的に拡張させる。とは?

デザインとは本来、テクノロジーを人間的なものにする営みであり、人間の精神に訴える力を持っている

デザインイノベーション デザイン戦略の次の一手より引用

books.google.co.jp

人が生きて環境をなす、そこに蓄積された叡智がデザインです。デザインは人間にとって本質的な何かを覚醒させるための営みなのだということに、ぴしっと焦点を合わせて考えるか考えないかで、デザインのとらえ方はまったく違ってきます。

なぜデザインなのか。より引用

www.heibonsha.co.jp

デザインの内側にあるものを知ろうと思い立ってから、本読む、ブログ見る、プロダクトデザイナーと話すと言ったことをしてきた中で、上記の引用した2つ言葉がとても理解の助けになりました。

引用した言葉を自分の中で整理すると、デザインは視覚だけではない人の感覚に訴えかけるものであること。人の感覚を分析し、理解し、より豊かな感覚へと昇華させる行為に近いのだと解釈しました。

デザインは論理なのか?

学んでいくにつれて、デザインは論理で説明できてしまうのか?という問いが僕の中で湧き上がりました。

okwave.jp

似た問を持った人の起こした議論。とても興味深いやりとりで、僕の欲しかった解にも出会えました。

論理は根底に存在しても、感覚や感情があって初めて決定できる。善し悪しを判断するのは制作者の経験や感覚です。

デザインは全て論理ではないですか?(½) - クリエイティブ | 【OKWAVE】より引用

デザインを考える上で論理は不可欠である、感覚値も同じように不可欠であるのだと解釈しました。

判断基準をもてたか

今まで対象と抽象的呼んでいたものをサービスの事業価値として捉え直してまとめます。デザインが事業価値に自己同一性と、感覚の拡張を与えられているか?と言う判断基準を持ってみたいと思えました。 さらにその上で論理で説明しきれない部分、最適解が絞り込みきれない場合には感覚値を拠り所にする。

これでしばらくデザインを捉えていこう。という所まできたので一旦区切りです。

最後に

デザインの内側にあるものを知ろうとすることで、自分なりの良さを判断する為の土台が作れてきました。デザインの世界の考え方は、単純に興味深くてとても面白いテーマです。エンジニアリングに近い部分もあり、共感しやすかったのが興味を継続できた要因なのかな?と感じます。

この先はWEBのデザインとして、どう思想を成立させるのか?と言う具体的な方法論のところにも理解を深めていけたらと考えています。

おしまい。

CROSS2016にいって、組織について一日考えてきた話

CROSS2016とは

2016.cross-party.com

Webエンジニアとその付近の人1,000人集合! 国内最大級のWeb系勉強会 通算5回目となる「エンジニアサポートCROSS 2016」は、 Webテクノロジーに関わる人たちが「Webの未来」を語る勉強会です

なんで参加したの?

同僚に紹介してもらったのがきっかけで、今回初めて参加してきました。僕自身はWebテクノロジーより、チームや組織作り方が興味があって、 あまりテクノロジーを聞きにいった感じではなかったです。

率直に言って、とても満足しました。
著名な方々の話だからという理由ではなく、内容が有意義だと感じれたことに満足感を得たのだと思います。

参加したセッション毎の内容と雑感

エンジニアとしてどう働きたいか?経営者としてどう働いてもらいたいか?労使の本音バトル!

概要

経営者も労働者も根本では同じ目的・目標をもっていて、それを達成するために会社という組織を作っているけれどお互いの考えが折り合わず、対立する構造になりがちだけどそれってなんでなの?という内容でした。

仕事に対する両者の思想

労働者側(エンジニア)

基本的には楽しく働きたい
エンジニアからみた楽しくって何?

エンジニアリングを突き詰めたい
モダンなシステム検討を継続的にする
理想論的なシステム作りに挑戦する

経営者側

基本的には楽しく働きたい、働いてほしい
経営者側からみた楽しくって何?

ステークホルダー、経営者、社員、顧客全ての関係者が満たされる状態
お金や、仕事、発言に対して責任をもつ
全体最適に気を配る
価値があることを実行していく

なにが対立してるの?

責任に対する意識の違いとそこからくる相手に見える不満

:製品に責任を持ちたいから時間をかけてでも良いもの提供したいのに、期日達成に対する要求が強すぎるように見える。

:仕事を完了することへの責任を常に持っているので、理想論を追い求めすぎることは自分本位な働きかたをしているように見える。

一歩引いて考えてみると?

:個々人のタスクが全体としてどういう位置づけで、目的と納得感を保てる形で落とし込んでもらうと理解が進む。

:サービスは実際作ってみてわかることも多いから、ある程度納期や品質という責任について妥協できるポイントもある。

歩みよるにはどうしていくのがいい?

お互いを知る為の時間が足りてない、対話の時間を増やすことが必要。

雑感

全体としてはよくある話だなと感じました。経営層だからとかはあんまり関係なくて、他者を知るために対話の時間は必要だよね?という落としどころだったかなと解釈しました。
もう少し時間があったら、その先のどう対話の時間を確保するか?単純に確保したら解決できそうなのか?みたいなところも聞きたかった。

次に個人的に腑に落ちない点を少々

製品が売れるかどうかは正直興味があまりないとおっしゃってた方がいたけれど、僕個人としては理解できない。もし売れないってことになったとしたら、自分が作ったものに価値がないと言うことになると思っています。

端的な話にしてしまうと製品に価値がないかもしれないけど、エンジアリングを突き詰められたら楽しいよと言うことに捉えられる意見だった。

それって本当にエンジアリングを考えているだろうか?挑戦してるということの有能感があるだけじゃないだろうか?

モダンなシステムを取り入れたいのはなぜか、エンジニアリングを突き詰めたいのはなぜか。それをすることで提供できる価値の幅が広がるとイメージできるからであってほしい。なぜ、エンジニアリングを突き詰める必要性があるのか、その意義を考えていけるようにしたいと改めて思った。

最近一般化してきたCIが必要な理由とか、色々な作業の自動化を促進することの本質はシステム化できるところを徹底して、その分空いた時間をもっと価値を提供するための作業にあてようってことだと思っています。

ビジネスを考えた結果、モダンなシステムにしていく必要があると提案できるようにありたい。

CTOが現場に言えない本音

概要

評価・採用・育成といったCTOが、日々業務範囲にしていることの裏側ではこんなことを思っているよという内容でした。

評価について

軸は大きく二つあって、成果と成長。
成果と成長で分けて良し悪しを伝えるようにしている。
成果だけだと点でしかない。成長は積み重ねとしてキャリアをどう伸ばせたかをみる。

成果

目標に対する達成度、事前期待値に対する達成度を個人ごとに絶対評価としてみる。

成長

新しい技術という観点では、取り組んでいるかではなく使いこなしているか。理解度はどれくらいに変わったか、業務に使えるイメージができるのか。
個人の成長が会社の成長とも方向が合っているか、会社として評価できない成長もある。
個人だけで完結してどう頑張ったかよりも、外に向けてどれだけ影響を与えたかの方が評価として判断しやすい。

採用について

技術云々はもちろんあるが、一番重要なのは勉強する意欲がある人かどうか。
採用は素質、評価は成果でみることが多い。
自分が働きたいと思える人かどうか。
働きたい人とは自分よりなにかすごいと思う部分がある人。人間として興味がわく人。
地頭の良し悪しは、何かの説明してもらって説得することをができるかを見ていたりする。

CTOってなに?

単なる役割でしかないと思っている。

どんなことを意識しているのか?

エンジニアのブランディング

露出をいかにつくり、外への影響を与える機会を増やし、組織としてそれをどう支えられるかを考えて、実行すること求められてると感じる。

ビジネス面も考えるからこそ、価値提供のスピードをあげるためにエンジニアリングはなにができるのか?組織のパフォーマンスをどうやって維持できるのか?ということを意識している。

雑感

中身の濃い刺激を受けるセッションでした。書きたいこといっぱいあるけど、オフレコにしてくれってとこも多かったのでつらいw

評価とか採用はそんな風に考えてるのかーってくらいで、CTO像の部分が面白いと感じました。

最近GMOペパボCTOのあんちぽちゃんさんの話でも似たようなこと思いを持った。世のCTOは技術からみた経営戦略の策定・実行だけじゃなくて、組織として個々人が成長を感じれるには何ができるのか?その環境を用意するためにどう実行していくかを考えてるんだなと。

個人的にどうやって変化に強い組織を作っていくかにすごく興味を持っているけど、どうやって成長を感じれるようにしていくか?の視点からの話はやっぱり勉強になりました。
自分の成長を考える時も、組織での成長視点をいれて考えるのも良いなと思いました。

先達に聞くこれからのエンジニア像 2016

概要

いかにして人を巻き込み、組織を作りあげるのかという内容でした。

リーダー像とは?

人員・資金・権限といった多様な制限がある環境で、想像力で解を求める人。
普通に考えると解決する見込みがないなかで、それでもどう解決するかを考える人。
大きな旗を降りかざして、人を巻き込んで実現する人。

10倍の成果を得るためには?

そもそも一人の時にあげていた成果を10倍にするためには、人を巻き込まないと達成できない。
人を継続的に巻き込んでいく方法を考える。
いかに動機付けできるかが大事で、他者がこれをやりたいと言わせるように個々人の状況を作ってあげる。
自分の口で言うことは、モチベーションを持って取り組むことに繋がる。
メンバーを巻き込んで、考える頭を増やしていくことで成果に繋げる。

巻き込むために何をしていくのか?

思想を伝えきるために、発言力と影響力を高めるために、信頼を勝ち得るための努力をする。 組織として世界観をプロダクトに持てるよう思想を共有する。
ゴールを意識し続けるために、細かいコミュニケーションを継続的にやる。

組織を継続していく上での気をつけることは?

プロダクトから何を削っていいか?何を足していいか?を判断するため、皆を同じ意識を保てるようにする。
失敗を叱る組織は、失敗しないように動く組織になっていくので、叱るのではなくどう改善するかを常に考えていく。
自由度を優先してリスクが伴うような場合には、その分綿密にリカバリー方法を考える。
メンバーに苦手意識がある場合は、正直に苦手なことを伝えて仕事上だけでも上手くやれる方法がないかを話し合うようにする。
役職や職種を越えて全てが一つのチームとして考えて、俯瞰した見方に近づける。
モチベーションが高い人を増やす努力と同じくらい、モチベーションが低い人が他者に悪影響とならないように配慮する。

その他参考になった話し

勉強会やカンファレンスでは質問をしようと思って聞くと理解度が増す。
ロールモデルを持つことは、自分がどのようなキャリアパスを進みたいかを考える助けとなる。

雑感

特に感じたことが二つあって、一つは信頼を勝ち取るために努力をすること。
丁寧に仕事をすること、丁寧に人と接していくことを改めて意識しようと考える良いきっかけとなりました。

もう一つは最近仕事における動機付けを自分でも考察したこともあって、やりたいと言わせるように状況を作ってあげるって言葉がとても考えさせられました。

組織として同じ想いをどうやって共有し続けていくか、そのために僕は末端タスクこそ丁寧に情報を詰め込むべきと考えています。会社として、事業として、チームとして、色んな粒度があるけれど、個人として組織や事業と接点となるのは日々のタスクだから。接点となる部分こそ手を抜かないで、上流からの想いをイメージできるだけの情報を落とし込みたい。イメージできることが個人レベルの動機付けに良い影響を与えるのでは?と考えているからです。

考えさせられることが多く、一番心に響いたセッションでした。

終わりに

組織作りのセッションがこんなにも多くあることは少し驚きでした。
良いプロダクトを作っていくための組織作り、興味はこれからも続きそうです。
社内外問わず、考えたり想いをぶつける機会を増やしていけたらいいな。

おわり。