工数見積もりとはラブレターである
前置き
システムを実装する上での工数見積もりで、どんなことを把握したいですか？
僕は個人にできるかぎり依存しない、事業価値を届けるために必要なコストを把握したいと思っています。
工数見積もりとは誰が行うものでしょうか？担当するエンジニア個人でしょうか？それともチームに属するエンジニア全員でしょうか？
僕はデザイナーや企画も巻き込んでチーム全員と関わりながら行うものであると考えています。
関係者全員で、絶対的な時間の見積もりではなく、相対的な規模感での見積もりをしていく。この辺りは所謂アジャイルな開発の思想に影響を受けているように思っています。
このような考えのもと、工数見積もりというものを通して
- 何がしたくて何がしたくないのか
- 各ポジションとどんな風に関わっていくのか
- 一番考えるべきことは何だと思っているのか
みたいなポイントで自分の考えをまとめていこうと思います
何がしたくて何がしたくないのか？
工数見積もりでしたいことはなにか？
- ユーザーにとって必要なものであることがイメージできること
- イメージ通りの機能を作りあげるために必要なものを整理すること
- 規模感の把握
工数見積もりでしたくないことはなにか？
- 実際にできあがったものが意図していないものになること
- 作業に入ろうとしたときにまだ動きだせない状態であること
- 未確定要素によって規模感すらだせないこと
こうやって改めて考えてみると、情報の整理からくるタスク分解と規模感を把握だけでなく、タスクの完了状態が与える影響がどんなものかもこの段階で意識したいのだなと思いました。
また着手時にすぐ動き出せるように、未確定要素を極力なくす調整もこの段階で一番とっていきたいと思えました。
各ポジションとどんな風に関わっていくのか
デザイナーや企画側に対して
デザイナーや企画側に対してはフィードバックをする、レビューの面もあると思っています
- どんなことをしたいのか伝わってくるか？
- 自分がユーザとしたら価値があると思えるか？
- タスク分解をイメージできるだけの情報があるか？
- やりたいことへのシステム的な解決はもっと良い方針がないか？
- これをやらないで別のことやったほうがよかったりしないか？
実装する側だから気づける点と想い、実装前段階ですり合わせていくことで出戻りを少なくしていければと思っています。
同じエンジニアに対して
同じエンジニアに対しては、いかに思いを伝えて共通のイメージを持つかが大事だと思っています。
- 他人がこの作業をするのならどんな情報が必要か？
- 新たに配属された人でもイメージできるだけの情報になっているか？
- 作業の実現アプローチは妥当なものか？
- 実現するための不明点はないか？
同じエンジニアだからこそ、スムーズに開発がスタートできるよう負担を軽減することになればと思っています。
一番考えるべきことは何だと思っているのか
やることの見積もりをするのはもちろんなのですが、僕は加えて一部やらない判断を提案していくことや、既にあるもの削除していくための見積もりこそ大事ではないかと考えています。
それは事業に対してエンジニアが一番主張できるポイントが、何を作らないのか？だと思っているからです。
やらないことが増えると、保守するコードが減ることになります。運用時のフットワークが軽くなります。
全ての企画を作るとこれくらいかかるけど、同等のこんな機能ならこれだけでできるよ？
企画のやりたいイメージをいかに、シンプルな機能だけで実現できるのか？そこを考えるのも面白いとこなんじゃないかなと思っています。
そういう意味で工数見積もりとは、事業を企画することに大きく関わる作業だと言えるだろうと考えています。
まとめ
作業担当する誰かに送る、精一杯の想い。色んな下準備をして、受け取る人に気に入ってもらえるように作る。さながらラブレターなんじゃないかと思っています(今回これがいいたかっただけかも)。
愛を持って工数見積もりをしてみませんか？きっと愛は届く！きっと。
おしまい。
チームのUXをマネージメントする
チームで仕事をすると言うのはどの様なことでしょうか？
メンバーはチームを通して何を感じ、他のメンバーに何を感じさせるのでしょうか？
今回はチームにおけるUXという視点で、何をマネージメントをすることができるだろうか？を考えます。
チームで仕事をする際のUXとは？
まずは僕の考えるチームのUXは何かを定義します。
チームを通して何を考え、どんな行動をして、どれだけの対価を得たり払ったりしたか。と言うことだと考えていて
- アドバイスをして、信頼を得ること。
- 成果が出て、自信を得ること。
- 失敗して、信頼や自信を失うこと。
例えばこのようなことがチームで仕事をする際のUXだと捉えます。
チームのUXをマネージメントするとは？
チームと言う体裁があったとしても、メンバーはあくまで利己的に行動を決定するものだろうなと考えています。
もう少し噛み砕くと共通の目標があってチームは結成されるわけですが、漠然と走っていくとメンバーは個人の利益を最大化させる行動を無意識に優先するだろうと思っています。
チームとしての利益という視点での行動をメンバーから引き出すこと、これがチームのUXをマネージメントするということだと考えています。
引き出すために何をするのか？
この本であげられている様な心理的安全をチームにもたらせるように先導していくことで、チーム利益のための行動が、個人利益のための行動と同等の価値を持つようにしていきたい。そのために何をするか？ということを考えていきます。
- どんなチームが理想なのか、どんなチームにしたいのかを伝える
- チームがメンバーに何を期待しているのかを理解できるようにする
- 実際に行動に起こすという体験をできるように手助けしてあげる
それぞれを見ていこうと思います。
どんなチームが理想なのか、どんなチームにしたいのかを伝える
僕の大好きなスライドを紹介して、まずイメージを持ってもらえればと思います。
ここで伝えたいことは、スライドの中に書いてある内容が正だ、これが僕の理想だということではありません。(個人的には好きで影響うけてます)
チームとしてどんなメンバー同士の関係性でありたいのか、どうあることがいいことだと考えているのか。それをメンバーに伝え、示すことが大事だと考えています。
もちろん理想を話すことはメンバー間で折り合えない部分もあると思っていて、それはそれで良いと思います。折り合えないよということがわかることで、対応できる余地が作れると考えるからです。苦手なら苦手なりの、付き合いかたを考えましょうか？となれれば僕としては儲け物です。
今後のチームとしての行動指針を一緒に考えていこう？という意思表示と、実現するためになにができるか考える、自分だったらもっとこうだと考える体験をメンバーとすることを狙いにしています。
チームがメンバーに何を期待しているのかを理解できるようにする
最近見て考えることが多かったワークショップの資料を紹介しつつ、こちらもまずイメージを持ってもらえればと思います。
「知っているだけで解決できる問題が世の中にはたくさんある」この言葉をなるほどな、そうだなーと思いました。僕個人としてチームメンバーに期待すること、思っていても正直あんまり言葉にしたことなかったです。
僕はこのスライドをみて、これって開発フェーズ毎と役職や職種って視点で分けて考えると、もっと具体的な業務レベルでの期待感の共有になるかもなと思っています。
企画立案時には、エンジニアは企画者にどんなことを期待してるのか。その逆はどうなのか。実装時には企画立案時とは別の期待がメンバーに生まれるのか。ユーザエクペリエンスマップのペルソナをチームメンバー、フェーズを開発のフローに当てはめてみてワークショップ等企画してみることで、チームの相互理解が深まるのではないかと思っています。
チームメンバーがお互いに期待していることを把握することで、今のタイミングではこんな行動してほしいのかな？と考える体験をすること、プラスの対価を得る行動はこうなのかもな？と感じてもらうことを狙いにしています。
実際に行動に起こすという体験をできるように導いてあげる
これは最近よく感じていることで、不安や困ってることを言える雰囲気作る、心理障壁を減らすってことを実践していくには、メンバー個々人が実際に想いを口に出す体験を何度したかが大事だと考えています。
やはり自分にとっての印象を悪く捉えられそうなことを口に出すのは、抵抗感があるものです。新規参入したメンバー等であればなおさら。
なので最初は聞き出す努力がいる。
丁寧に自分で口に出すって行動までを引き出してあげることが、何でも言える雰囲気を育てていくことに繋がるだろうと考えています。開発してて困ってることある？といった聞き方ではなく、この開発だったらこんなとこ困りそうに思うんだけど大丈夫？
と言った様な少しつっこんだ聞き方をすることで、個人としてマイナスの対価を得ると思われがちで嫌厭される行動を、起こしやすくしてあげられないかを狙いにしています。
まとめ
チームとしての利益という視点での行動をメンバーから引き出すために、心理的安全をチームに熟成させたい。それをこんなアプローチでやっていきたいと思っています。どうしてそうしたいと考えてるのか？と言う観点で書いてきました。どこか参考になるところがあれば幸いです。
おしまい。
エンジニアが経営理念について考えた話
前置き
経営理念ってなんでしょう？ミッション・ビジョン・バリューってなんでしょう？様々な会社が掲げています。社内に浸透させようとしています。
僕は今まで5社ほど勤めてきたなかで、正直一度もキチンと意識して働いたことはありませんでした。それは僕自身が必要としてなかったからなのか、会社としての伝え方の問題なのか、最近ふと考えてみたという話です。
経営理念って何？
経営理念とは、組織の存在意義や使命を、普遍的な形で表した基本的価値観の表明。
平たく言えば、「会社や組織は何のために存在するのか、経営をどういう目的で、どのような形で行うことができるのか」ということを明文化したものである。
これによって経営者は、基本的な考え方を内外に伝えて共有化したり、社員に対して行動や判断の指針を与えたりすることができる。理念自体に社員が共鳴すれば、働くインセンティブにもなり、企業における求心力にもつながる。すなわち経営理念は企業文化を形成する主要な要素である。
経営理念の内容は、行動規範的なもの、経営の成功のための鍵や経営姿勢を示すもの、企業の存在意義を示すものなどいろいろな形で表現される。一般的には、社会、顧客、および社員の三者に関する理念が設定されることが多い。
経営理念が難しいのは、適切な設定をしても時代とともに形骸化し、現実と乖離してくることである。どれだけ優れた経営理念やビジョンであっても、その変更のタイミングを見極め、時代に合わせて方向を再設定、再定義して、新たな道を踏み出さなくてはならない。
経営理念とは | ビジネススクールならグロービス・マネジメント・スクール より引用
なるほどなるほど。
とても大事なことなんだな、ということは理解できました。
と同時に僕はこうなんじゃないか？と思う点がいくつかあったので、章に分解して整理してみたいと思います。
理念自体に社員が共鳴すれば、働くインセンティブにもなり、企業における求心力にもつながる
理念自体に共鳴できる人はどれだけいるのだろう？単純な疑問をこの一文から持ちました。 というのも今まで理念に共鳴するからここで働きたい、と思えたことが僕自身なかったからです。
それはなぜなのか、というのを自分の中で解釈すると「自己の会社や組織は何のために存在するのか」という視点で普段想像や仕事の一端を見ていなかったからだろう。と言うところに落ち着きました。自分が普段考えていないことに対して、共鳴するということは起こりにくい。
ではそんな僕が経営理念として共鳴しえるものはなんだろうか？と改めて考えてみると、自分の考える1個人としての社会的な存在理由にぴたりと合致するケース。もしくは内容自体が重要ではなくだれが言葉にしたのか、魅力をもった人物が作った言葉には自分から寄せていって共鳴したいと思えるかもしれないなと考えます。
実際僕はどこで働きたいかよりも誰と働きたいかで職場を選択してきたので、自分が働く上で大事にしているものが改めてそういうことなんだろうなと再認識しました。
とこんな流れで考えた結果、理念自体に魅力を感じる人はいないことはない。けれど組織にいる理由の大半は個人レベルでの魅力、プロダクトに対する魅力に共鳴したからなのかもしれない。相対的にみて理念自体に共鳴する人は少ないんじゃないだろうかという考察に至りました。じゃあ僕の考える経営理念の必要性って？というところは別の章やまとめにて。
考え方を内外に伝えて共有化
僕はここを重要な一文だと捉えました。内外っていったい何を指すのでしょうか？
僕は内が組織や社員、外が社会や株主といったものを指しているだろうとそれぞれ考えています。
ここでさらに踏み込んで考えなければいけいないことは何でしょう？僕は内と外で期待するものが違うだろうという点を考えなければいけないのではないかと思っています。内外をひとくくりにできるような言葉ってどんなもの？むしろそれぞれに向けた言葉を別で用意すべきものなのではないか？
そもそも経営理念ってどんな風に考え始めるのか？と想像してみると、経営理念には創業メンバーの強い起業動機、社会に向けた意思表示の面がやはり大きいと感じています。つまり外向きに寄せた言葉を設定することが多いなと思っていて、そもそも内向きにも響くようにとするのは難しいのではないか？という疑問を持ちました。
その解釈持って、経営理念を表す際にミッション・ビジョン・バリューと複数用意されているのはどうしてか想いを巡らせると、なるほど向き先の違う言葉を定義してるのかな？という見方をすることができました。
また最近知った言葉でインナーブランディングというのがあるので取り上げるのですが、こういう内向きに対しての明示的な言葉が存在することからも、向き先に合わせた言葉の作り方が意味を持っている。内外に伝えるというのは単に同じ言葉で表すことではないな、と考えるようになりました。
インナーブランディングは、インターナルブランディングやインターナルマーケティングとも呼ばれ、社員に企業ブランドの価値や目指す姿を理解させる啓蒙活動が起源です。消費者などに対して自社のブランド価値を啓蒙するアウターブランディング（エクスターナルブランディング）と共に、ブランド構築活動を構成する重要な要素のひとつです。
社員に対して行動や判断の指針を与えたりすることができる
エンジニア目線で見た場合、経営理念に一番重要なのはここだろうと思ってます。組織としての正解はなにか？現場での判断に困ったときに基準となるものはどんな想いなのか？それが明確であることは、最も会社が社員に浸透させる意味を感じれます。
経営理念の元、僕はこの企画や実装を採用することが正解だと判断しました。なんてことを社員が言うことを願っているのかな？と想像することもできます。
このへんの解釈で、僕の中にすっと入ってきた言葉を引用しておきます。
大事なのは、 その企業が目指しているものを従業員に理解してもらうことで、 従業員の仕事に方向性と目的を与え、さらに従業員が意思決定をするときの ”判断基準”になるように落とし込み、それによって企業を成長させることなんですね。
As I Am. | 有名企業から学ぶ；ミッションとビジョンの違い より引用
判断基準になるレベルまで落とし込むことを目標にし、結果として企業としての成長を得たいのだな。なるほどなーと腹落ちしました。
まとめ
自分の考えをまとめると経営理念というのは、経営者や企業としての内外にむけた意思表示である。
社員目線でみると、日々の業務レベルにおいて判断基準の1つになり得るものである。
外向きには企業としての存在理由、内向きには組織の行動指針として必要なものである。
各社想いや狙いがあって作るものであるとは思うけれど、僕個人としては誰に向けた意思表示なのかという観点を明確にして設定されていたほうが、浸透しやすくなるのではないだろうかという考察になりました。
経営理念なんて理解しなくても、仕事はできるのかもしれないし僕はできてきました。
けれど判断基準になりうるものだというのを解釈できると、理解する必要性があると考え方を変えることになったのはよかったです。
チームで働く上で、同じ価値観・判断基準というかが皆で共有されていると、スムーズな連携がしやすくなることを実感しています。
経営理念ってくくりで受け取ると大層なことに感じますが、このことって事業単位、数人のチームにおいても共通に言えることだと思ってます。一緒に集まってなにかを作っていくって時には、チームとしてそれをどんなものにしたいかって意思表示を明確にしておき、個々人の判断基準になるくらい浸透させること。考え方の粒度や視点の違いはありますが、大事にいきたいですね。
ということで経営理念に共鳴して働きたい！となる人は考えた後も稀だろうと思ってますが、経営理念を社員に浸透させる意味は理解できました。
経営理念の理解は大事、理解してきましょう。
おわりに
組織論とか、チームが機能する仕組みづくりとは？
みたいなのが最近の勉強のテーマなのでそういうの好きな人とか、マネージメント層・経営層の方で話聞いてあげてもいいよってかたは是非機会を作らせて下さい。
エンジニアがデザインと向き合うために思考する
前置き
良いデザインに出会ったことはありますか？デザインと括られるものを通して、感情を動かされたことはありますか？世の中には多くのデザインされた物で満ちていて、人の感情を引き起こしてくれる素敵なプロダクトがあります。
漠然と疑問に思っていたことがあって、人はデザインの良さを何を見て判断をしているのだろう？作り手は何を思い描いているのだろう？僕は感覚的な部分、表面的な部分でしかデザインを感じることができてないんじゃないか？
僕はデザインの内側にあるものを知ることで、エンジニアとして、サービスを作る人として、デザインへの理解、価値の判断基準を自分の中に持ちたい。と考えるようになりました。
そんなデザインを深く考えたことのなかった僕が、デザインの何に興味持ち、何を理解し、どんな風に考えるようになったかを整理していきたいと思います。
そもそもデザインって？どんな風に成り立ってきたもの？
物・事の成り立ちを知りたくなる性分なためか、多少遠回りな出発点です。とは言え分厚い参考書は頭に入りにくかったので、全体の流れを知れるものとしてこの本を手に取りました。
権力・荘厳さといった絶対的な存在を誇示するための表現方法から始まり、知性や緻密さといった豊かさを示すような表現方法が必要とされてくる。工業発展による大量生産の時代が訪れると、デザインを必要とする人が特権階級だけでなく民衆全体となり、必要とされる表現方法はより機能美や合理主義に傾いていく。
このようなデザイン史の変遷を知って思うのは、デザインには時代背景が色濃く反映されているのだなと言うことです。何を表したいものか、誰が最も必要としているものかによって、デザイン形態が出来上がるのだと解釈しました。
デザインとは何を表現するものなのか？
デザインは対象に自己同一性を与えるものである。
デザインは対象が人に与える感覚を科学的に拡張させるものである。
現段階の僕が考える、デザインはなにを表現するものだろうか？はこの2つに集約されています。
デザインは対象に自己同一性を与える。とは？
僕がデザインの与える自己同一性をどの様に捉えるかにあたって、職場で紹介してもらって参考になった記事があります。
この記事自体はデザインそのものについてではなく、オリンピックのビジュアルデザインとして求められているものはなんであるか？について書かれているものとして読みました。その上で僕はこの記事内容からデザインは対象を、何時、どこで、部分として捉えても、全体として捉えても、等しく対象であると認識させるようにできる。自己同一性を表現するものでもあると解釈しました。
デザインの局所的な部分や表層の部分ばかり見ていた側からすると、こんなにも緻密に考えをまとめ、人の感覚を導いているのかと気付かされ、部分と全体が一体となるための細かなシステム設計、秩序をあたえること。デザインとは単に装飾を施したりビジュアルのことだけを指すものではない。感覚値ではない、論理からなるデザインの一端を知れたように思います。
デザインは対象が人に与える感覚を科学的に拡張させる。とは？
デザインとは本来、テクノロジーを人間的なものにする営みであり、人間の精神に訴える力を持っている
デザインイノベーション デザイン戦略の次の一手より引用
人が生きて環境をなす、そこに蓄積された叡智がデザインです。デザインは人間にとって本質的な何かを覚醒させるための営みなのだということに、ぴしっと焦点を合わせて考えるか考えないかで、デザインのとらえ方はまったく違ってきます。
なぜデザインなのか。より引用
デザインの内側にあるものを知ろうと思い立ってから、本読む、ブログ見る、プロダクトデザイナーと話すと言ったことをしてきた中で、上記の引用した2つ言葉がとても理解の助けになりました。
引用した言葉を自分の中で整理すると、デザインは視覚だけではない人の感覚に訴えかけるものであること。人の感覚を分析し、理解し、より豊かな感覚へと昇華させる行為に近いのだと解釈しました。
デザインは論理なのか？
学んでいくにつれて、デザインは論理で説明できてしまうのか？という問いが僕の中で湧き上がりました。
似た問を持った人の起こした議論。とても興味深いやりとりで、僕の欲しかった解にも出会えました。
論理は根底に存在しても、感覚や感情があって初めて決定できる。善し悪しを判断するのは制作者の経験や感覚です。
デザインは全て論理ではないですか？(½) - クリエイティブ | 【OKWAVE】より引用
デザインを考える上で論理は不可欠である、感覚値も同じように不可欠であるのだと解釈しました。
判断基準をもてたか
今まで対象と抽象的呼んでいたものをサービスの事業価値として捉え直してまとめます。デザインが事業価値に自己同一性と、感覚の拡張を与えられているか？と言う判断基準を持ってみたいと思えました。 さらにその上で論理で説明しきれない部分、最適解が絞り込みきれない場合には感覚値を拠り所にする。
これでしばらくデザインを捉えていこう。という所まできたので一旦区切りです。
最後に
デザインの内側にあるものを知ろうとすることで、自分なりの良さを判断する為の土台が作れてきました。デザインの世界の考え方は、単純に興味深くてとても面白いテーマです。エンジニアリングに近い部分もあり、共感しやすかったのが興味を継続できた要因なのかな？と感じます。
この先はWEBのデザインとして、どう思想を成立させるのか？と言う具体的な方法論のところにも理解を深めていけたらと考えています。
おしまい。
CROSS2016にいって、組織について一日考えてきた話
CROSS2016とは
Webエンジニアとその付近の人1,000人集合！ 国内最大級のWeb系勉強会 通算5回目となる「エンジニアサポートCROSS 2016」は、 Webテクノロジーに関わる人たちが「Webの未来」を語る勉強会です
なんで参加したの？
同僚に紹介してもらったのがきっかけで、今回初めて参加してきました。僕自身はWebテクノロジーより、チームや組織作り方が興味があって、 あまりテクノロジーを聞きにいった感じではなかったです。
率直に言って、とても満足しました。
著名な方々の話だからという理由ではなく、内容が有意義だと感じれたことに満足感を得たのだと思います。
参加したセッション毎の内容と雑感
エンジニアとしてどう働きたいか？経営者としてどう働いてもらいたいか？労使の本音バトル！
概要
経営者も労働者も根本では同じ目的・目標をもっていて、それを達成するために会社という組織を作っているけれどお互いの考えが折り合わず、対立する構造になりがちだけどそれってなんでなの？という内容でした。
仕事に対する両者の思想
労働者側（エンジニア）
基本的には楽しく働きたい
エンジニアからみた楽しくって何？
エンジニアリングを突き詰めたい
モダンなシステム検討を継続的にする
理想論的なシステム作りに挑戦する
経営者側
基本的には楽しく働きたい、働いてほしい
経営者側からみた楽しくって何？
ステークホルダー、経営者、社員、顧客全ての関係者が満たされる状態
お金や、仕事、発言に対して責任をもつ
全体最適に気を配る
価値があることを実行していく
なにが対立してるの？
責任に対する意識の違いとそこからくる相手に見える不満
労：製品に責任を持ちたいから時間をかけてでも良いもの提供したいのに、期日達成に対する要求が強すぎるように見える。
経：仕事を完了することへの責任を常に持っているので、理想論を追い求めすぎることは自分本位な働きかたをしているように見える。
一歩引いて考えてみると？
労：個々人のタスクが全体としてどういう位置づけで、目的と納得感を保てる形で落とし込んでもらうと理解が進む。
経：サービスは実際作ってみてわかることも多いから、ある程度納期や品質という責任について妥協できるポイントもある。
歩みよるにはどうしていくのがいい？
お互いを知る為の時間が足りてない、対話の時間を増やすことが必要。
雑感
全体としてはよくある話だなと感じました。経営層だからとかはあんまり関係なくて、他者を知るために対話の時間は必要だよね？という落としどころだったかなと解釈しました。
もう少し時間があったら、その先のどう対話の時間を確保するか？単純に確保したら解決できそうなのか？みたいなところも聞きたかった。
次に個人的に腑に落ちない点を少々
製品が売れるかどうかは正直興味があまりないとおっしゃってた方がいたけれど、僕個人としては理解できない。もし売れないってことになったとしたら、自分が作ったものに価値がないと言うことになると思っています。
端的な話にしてしまうと製品に価値がないかもしれないけど、エンジアリングを突き詰められたら楽しいよと言うことに捉えられる意見だった。
それって本当にエンジアリングを考えているだろうか？挑戦してるということの有能感があるだけじゃないだろうか？
モダンなシステムを取り入れたいのはなぜか、エンジニアリングを突き詰めたいのはなぜか。それをすることで提供できる価値の幅が広がるとイメージできるからであってほしい。なぜ、エンジニアリングを突き詰める必要性があるのか、その意義を考えていけるようにしたいと改めて思った。
最近一般化してきたCIが必要な理由とか、色々な作業の自動化を促進することの本質はシステム化できるところを徹底して、その分空いた時間をもっと価値を提供するための作業にあてようってことだと思っています。
ビジネスを考えた結果、モダンなシステムにしていく必要があると提案できるようにありたい。
CTOが現場に言えない本音
概要
評価・採用・育成といったCTOが、日々業務範囲にしていることの裏側ではこんなことを思っているよという内容でした。
評価について
軸は大きく二つあって、成果と成長。
成果と成長で分けて良し悪しを伝えるようにしている。
成果だけだと点でしかない。成長は積み重ねとしてキャリアをどう伸ばせたかをみる。
成果
目標に対する達成度、事前期待値に対する達成度を個人ごとに絶対評価としてみる。
成長
新しい技術という観点では、取り組んでいるかではなく使いこなしているか。理解度はどれくらいに変わったか、業務に使えるイメージができるのか。
個人の成長が会社の成長とも方向が合っているか、会社として評価できない成長もある。
個人だけで完結してどう頑張ったかよりも、外に向けてどれだけ影響を与えたかの方が評価として判断しやすい。
採用について
技術云々はもちろんあるが、一番重要なのは勉強する意欲がある人かどうか。
採用は素質、評価は成果でみることが多い。
自分が働きたいと思える人かどうか。
働きたい人とは自分よりなにかすごいと思う部分がある人。人間として興味がわく人。
地頭の良し悪しは、何かの説明してもらって説得することをができるかを見ていたりする。
CTOってなに？
単なる役割でしかないと思っている。
どんなことを意識しているのか？
エンジニアのブランディング。
露出をいかにつくり、外への影響を与える機会を増やし、組織としてそれをどう支えられるかを考えて、実行すること求められてると感じる。
ビジネス面も考えるからこそ、価値提供のスピードをあげるためにエンジニアリングはなにができるのか？組織のパフォーマンスをどうやって維持できるのか？ということを意識している。
雑感
中身の濃い刺激を受けるセッションでした。書きたいこといっぱいあるけど、オフレコにしてくれってとこも多かったのでつらいw
評価とか採用はそんな風に考えてるのかーってくらいで、CTO像の部分が面白いと感じました。
最近GMOペパボCTOのあんちぽちゃんさんの話でも似たようなこと思いを持った。世のCTOは技術からみた経営戦略の策定・実行だけじゃなくて、組織として個々人が成長を感じれるには何ができるのか？その環境を用意するためにどう実行していくかを考えてるんだなと。
個人的にどうやって変化に強い組織を作っていくかにすごく興味を持っているけど、どうやって成長を感じれるようにしていくか？の視点からの話はやっぱり勉強になりました。
自分の成長を考える時も、組織での成長視点をいれて考えるのも良いなと思いました。
先達に聞くこれからのエンジニア像 2016
概要
いかにして人を巻き込み、組織を作りあげるのかという内容でした。
リーダー像とは？
人員・資金・権限といった多様な制限がある環境で、想像力で解を求める人。
普通に考えると解決する見込みがないなかで、それでもどう解決するかを考える人。
大きな旗を降りかざして、人を巻き込んで実現する人。
10倍の成果を得るためには？
そもそも一人の時にあげていた成果を10倍にするためには、人を巻き込まないと達成できない。
人を継続的に巻き込んでいく方法を考える。
いかに動機付けできるかが大事で、他者がこれをやりたいと言わせるように個々人の状況を作ってあげる。
自分の口で言うことは、モチベーションを持って取り組むことに繋がる。
メンバーを巻き込んで、考える頭を増やしていくことで成果に繋げる。
巻き込むために何をしていくのか？
思想を伝えきるために、発言力と影響力を高めるために、信頼を勝ち得るための努力をする。
組織として世界観をプロダクトに持てるよう思想を共有する。
ゴールを意識し続けるために、細かいコミュニケーションを継続的にやる。
組織を継続していく上での気をつけることは？
プロダクトから何を削っていいか？何を足していいか？を判断するため、皆を同じ意識を保てるようにする。
失敗を叱る組織は、失敗しないように動く組織になっていくので、叱るのではなくどう改善するかを常に考えていく。
自由度を優先してリスクが伴うような場合には、その分綿密にリカバリー方法を考える。
メンバーに苦手意識がある場合は、正直に苦手なことを伝えて仕事上だけでも上手くやれる方法がないかを話し合うようにする。
役職や職種を越えて全てが一つのチームとして考えて、俯瞰した見方に近づける。
モチベーションが高い人を増やす努力と同じくらい、モチベーションが低い人が他者に悪影響とならないように配慮する。
その他参考になった話し
勉強会やカンファレンスでは質問をしようと思って聞くと理解度が増す。
ロールモデルを持つことは、自分がどのようなキャリアパスを進みたいかを考える助けとなる。
雑感
特に感じたことが二つあって、一つは信頼を勝ち取るために努力をすること。
丁寧に仕事をすること、丁寧に人と接していくことを改めて意識しようと考える良いきっかけとなりました。
もう一つは最近仕事における動機付けを自分でも考察したこともあって、やりたいと言わせるように状況を作ってあげるって言葉がとても考えさせられました。
組織として同じ想いをどうやって共有し続けていくか、そのために僕は末端タスクこそ丁寧に情報を詰め込むべきと考えています。会社として、事業として、チームとして、色んな粒度があるけれど、個人として組織や事業と接点となるのは日々のタスクだから。接点となる部分こそ手を抜かないで、上流からの想いをイメージできるだけの情報を落とし込みたい。イメージできることが個人レベルの動機付けに良い影響を与えるのでは？と考えているからです。
考えさせられることが多く、一番心に響いたセッションでした。
終わりに
組織作りのセッションがこんなにも多くあることは少し驚きでした。
良いプロダクトを作っていくための組織作り、興味はこれからも続きそうです。
社内外問わず、考えたり想いをぶつける機会を増やしていけたらいいな。
おわり。
仕事の納得感とは？
仕事の納得感はどんな時に得られるでしょうか？
行動の選択権があり、意志が尊重され、行動を決断できるだけの情報を引き出せる時に、納得感というものが得られるのではないかと考えています。
自分の例をあげながら、なぜそう考えたのかを整理していきます。
現在、10名規模の会社で仕事をしています。
この内容はマネージメントする立場からではなく、マネージメントされる立場から考えたものです。
この作業は誰かに価値を与えるのだろうか？
この作業は今やる必要があるのだろうか？
僕は作業の価値や必要性を想像できない場合に、不安を感じることが多いです。
他者からの指示や依頼に対して、常に共感して不安を抱かない。これは理想ではありますが、おそらく実現させることは難しいのでしょう。
であれば不安はある程度存在することを受け入れ、それをいかに取り除くか？という方向で、自分を保ちたいと考えるようになりました。 作業の価値や必要性を想像できないという不安を和らげるためには、「なぜやるのか？をもっと理解したいです。教えてもらえないでしょうか？」と意志を表明します。
ここで大事だと思っていることは、なぜの部分を深く理解できることだけではありません。
- 意志表明が行動の選択肢として認められている
- 個人が尊重されて健全なフィードバックが返ってくる
- 決断に至るまでの適切な情報が開示される
この3つが満たされることで、自分の意志で行動を決定した感覚に繋がることが大事だと考えています。
実際には、依頼者が受託者の行動を決定していることには変わりない。ではなぜ自己決定感が高まると納得感に寄与するのか？という点を探っていきましょう。
納得感の定義づけ
納得感と言って話を進めた時に、人によって受け取り方が違うと思います。
そこで、まず自分のなかにおける納得感の定義を行います。
納得感がある状態というのは、自分の動機づけの1要素と捉えています。 今回は納得感を、動機づけの観点からみていきます。
動機づけとはなにか？
まずはそもそも動機づけとはなにか？という概念の部分をざっくりと把握してみたいと思います。
動機づけ（どうきづけ、motivation、モチベーション）とは、行動を始発させ、目標に向かって維持・調整する過程・機能である。
動機付けを大きく分けると「外発的動機づけ」と「内発的動機づけ」という2つのタイプに分類されています。
内発的動機づけとは好奇心や関心によってもたらされる動機づけであり、賞罰に依存しない行動である。
外発的動機づけとは義務、賞罰、強制などによってもたらされる動機づけである。
内発的動機づけと外発的動機づけの主な違いは、活動の質や継続性への影響度合いと言われています。
内発的動機づけによる活動は、外発的動機づけによる活動よりも、楽しく、質が高く、持続すると言われています。 たとえば、試験のために（外発的に動機づけられて）勉強しているときには、試験が終われば、勉強しなくなるでしょう。試験のためだけに勉強したことは、試験が終われば、忘れてしまいます。
内発的動機づけに寄与する要素はなにか？
まず、内発的な動機づけを支えているものがある。それは、「自己決定感」「有能感」「他者受容感」という3つの要素だ。自己決定感とは「自分のことは自分で決めている」という気持ちであり、有能感とは「自分なら頑張ればできる」という本人の気持ちである。他者受容感とは「自分は周りの大切な人から受容されている」という気持ちである。この3つの要素が自ら学ぶ意欲をもたらし、楽しさや満足感が生まれる
本当の「やる気」はどこから生まれるのか?(Part.2) | コラム-TMW CONSULTANT EYE | トッパンマインドウェルネス より引用
これらの動機づけの概念を踏まえ、自分の仕事に納得感のある状態とはなにか？を考えてみます。
自分の仕事に納得感のある状態
内発的動機によって仕事をしている状態であると考えています。
さらに掘り下げて、仕事における内発的動機の元になるものはなにか？
自分で意思決定して行動（作業）していることであると捉えています。
これを満たしていることが、納得感に寄与するのだと解釈しました。
しかし仕事や組織において、皆が自由に作業を決定できるとは限りません。それぞれが自由に決定することができない時点で、全員の100%を満たすことは無理なのでしょう。
では、100%に近づけるためにはなにができるでしょうか？
自己決定感をどう満たすのか？
自分の仮説を話していきます。
人の行動には目的が存在します、それが前述した行動の動機付けになるからです。
自分自身で行動を決定する際には、目的である「なぜやる必要があるか？」「やることにどんな価値があるか？」を無意識に考えているのではないかと僕は考えています。
これを自己決定のプロセスだと仮定すると、他者が自分の行動を決定する際にも、自己決定と同等なプロセスを持たせられれば、自己決定感を高められるのではないか？という仮説を持つことができます。
仮定とそこからくる仮説を元にすると、他者に行動を指示・依頼した際に、対象となる実行者の納得感を保つためには、目的である「なぜやろうと思ったのか？」「どんな価値があると思ったのか？」指示者目線の決断に至った経緯の情報を伝えることが、重要な要素であると考えられます。
とはいえ常に頭のなかを見せれるわけではないので、完璧に決断に至った経緯の情報を伝えることは難しいです。
伝え切りたいけど伝えきれないものでもあると受け止め、他者が違和感を覚えて言葉にしたという行動を尊重する。
違和感をなくすためならば、何度でも伝えるよという姿勢を合わせもつことが、実際に運用するためには必要なのだろうと考えます。
まとめ
仕事の納得感を保つためには
- 自分が行動（作業や方針等）を決定するに至った情報を、他者が同程度に得られるようにする
- 自己決定ブロセスの過程を妨げないように、行動の選択肢の提供や他者の意志を尊重する
それがあることで、受け取った側は決定者と同じ価値を想像しやすくなる。
もう少し言い換えると、他者の考えた価値を自分が考えたものと擬似的に捉えて行動をとれる。
自分のものとして考えて行動できるのであれば、内発的動機に近い行動となっていくのではないでしょうか。
おしまい。
プロダクトオーナー祭りに参加してきた。
なんで参加したの？
僕は単なるプログラマーで、今現在明確にプロダクトオーナーとしての役割で仕事していません。
ましてやエンジニアチームでリーダーの役割すらしてません。本当に単なるプログラマーです。
がしかし、僕が所属する会社の人数規模(10名程度)では全員が多かれ少なかれ、
プロダクトオーナーの役割とされる分野に関与しながらサービスを作っていると感じています。
なのでやっぱり関わるなら理解をしてやりたいな！楽しくやりたいな！と思うようになりました。
現状はこの手の本を読んで、自分の解釈を同僚に話してみたりするくらいです。（良き同僚が多く、色んな影響をうけて幸せです）
知識を増やすことというのは不思議で、今まで関心がなかった分野（僕はマネジメントとかあんまり興味なかった）にとっかかりをつくると、どんどん欲求でてきます。もっと多方面の意見に触れたい。これが一番大きかった。
といったまぁよくあるモチベーションの元、マネジメント関連の外部イベントに参加してきたよって話です。
プロダクトオーナー祭りって？
こんなイベントでした。 postudy.doorkeeper.jp
togetterはこちら togetter.com
どうだった？
正直世界を変えるのは俺たちだ！とまではまだ思えませんが、内容良かったです。（月並みな感想！笑）
セッションについてでもうちょっと感じたことまとめます。
セッションについて（覚えてるとこだけ）
新カゴプロジェクトのプロダクトオーナーとしてやってきたこと
GMOペパボ株式会社 カラーミーショップ
10年続いているサービス運用上の話、すでに顧客を確保しているサービスで改善を進める時にこんな風にやった、やってるよ。
という話だったと理解しました。
登壇者様のスライド公開されたので引用
www.slideshare.netこのセッションで頭に残ったこと（僕の解釈の結果です、100%登壇者様の言葉ではないです。）
- 優先順位を決める時、根拠となるデータがあると判断が早い
- プロトタイプを早く触ってもらえるフローを整備する
- 動画のように、実際動くものによる表現が一番伝わりやすい
- 視覚からの情報が8割と言われてる
- 哲学駆動開発wwwww（なぜ作るのかってのをまず詩で表した？ちょっと聞き逃した。深く内容聞きたい）
- ユーザビリティテストで、実際の社内テスト時にユーザ操作を全て動画にとってチームで議論の種にした
- 完了条件は明確であればあるほど判断しやすい
- 誰に確認をとるか？を迷う状況はいいことない
僕はこう思ったです
プロトタイプとして早く共有する、動画での共有をするとか誰がみても共通の理解度持てるように工夫してるんだなと思った。
言葉やワイヤーフレームだけみても、共通理解とならないで各々頭の中で補完する内容が違うこと実感してる。
誰が見ても近しい理解度を得るために、想像や感覚で補完させてしまう部分を少なくする努力大事だ。
僕の会社にて不具合報告の方法として、GIFアニ入れて報告をやった場合にチームの理解度があがる効果あったし納得感ある。
GIFアニ作る時に使ってるやつ blog.scimpr.com
あとPivotal使ってるって話の時に、◯◯APIを作ります。みたいな粒度で登録してる風に受け取れた話があったけど、Pivotalは依存関係把握しにくいと思っていて、それだと何かがブロックしてるのかとか見えにくくないか？◯◯APIが必要なことわかるけどそれができると要件ベースでは何が完了となってるの？という疑問がわいた。というかそういう壁を僕のチームで感じたことがあった。
そこで僕のチームでは要求ベースでのストーリーをPivotalに登録して、受け入れ条件として細かな粒度のタスクをいれることを試してる。
依存関係のない単位で登録と、見積もりをする方がわかりやすいと感じてるので、ここを登壇者さんと話してみたかったけど質疑の時間なかったのが悲しかったー。
僕のチームのPivotal登録例
メトリクスによる「見える化」のススメ：No 見える化, No 改善
抱えている課題に対して、その要因の深堀と現状の分類・数値化をすることで定量的な変化を捉えられるようにする。
要因と思われることの変化を捉えられるように数値を設定すると、解決するためのアクションをイメージしやすくなるよね。
ということを実体験するワークショップだったと理解しました。
登壇者様のスライド公開されたので引用
www.slideshare.netこのワークショップで頭に残ったこと
- 人の感覚は正解がそれぞれあることを理解する
- 計画外追加作業が、質の改善要求？仕様の誤認？不具合？何要因による追加作業か正しく把握する
- コミュニケーション時間量と消化ストーリーに相関関係はあるかという疑問
このセッションで頭に残ったこと（僕の解釈の結果です、100%登壇者様の言葉ではないです。）
- 追うべき数値は自分で作ることもできる。新しいものは提案者の思想がアンカリングになって提案者主導になる
- 数値変化を見れるようにするというのはコミュニケーションの促進剤
僕はこう思ったです
仕事への納得感の保ち方、進捗管理の効率化、見積もり精度の向上、チームメンバーの些細な悩みを上手く引き出す。
似たような課題を皆感じているんだなというのがわかるのは妙な安堵感がある。
同じ課題を持つ第三者だと、つっこんだ話も関係性とか無視して気軽にできるのよかった。
僕はチームの課題に対して、定量的にみるための機能を整備するコストを払うには、結構厳格なする理由を持たないといけないかなぁって考えてしまっていた。 なので勝手に敷居を高く感じて提案するのが億劫になってた部分がある。
単にチームのコミュニケーションの促進剤だよって意味の解釈をできると、役立つと思うからこれ把握できるようにしましょうよ！って提案への心持ちが軽くなっていい。
とはいえ業務効率やらなんやらの改善専門部署を用意できるほど、規模感があるわけではないので地道に個人が片手間で扱える範囲でまず頑張ろうと思います。
最後に
余談として僕の友人が「祭」とかかれた半被を着て門番的に待ち構えていたので、心強かったです。
（来るとこ間違ったかな？と少しなったし遠くで見て、ふいた）
頑張ってたね、お疲れ様。また似たようなの何かあったら教えてね。
おしまい。
