チームを率いてるなら、上の発言をブレークダウンして伝えてみてはいかがだろうか？
フリーランスエンジニアの @nabeemichi です。
組織のあり方はいろいろあって、フラットな組織で上下関係が基本的にない組織もありますが、 今回のお話は、トップダウン形式で社長や上層部から命令や方針が伝えられるパターンについて考えます。
上の方から方針が降りてきて、実行するチームまで内容が降りてくるのですが、 組織で働く場合、チームをまとめるマネージャーやリーダーと呼ばれる方々が存在します。
大きな組織の場合は、さらにマネージャーやリーダーをまとめるマネージャーがいたりもします。 実際に手を動かして実行する人々に上からの情報が伝わるまでに、何度か伝言ゲームが発生します。
伝言ゲームでは、正確に情報を伝えることは大切なことです。 嘘や、フィルタリングされた情報を入れると本来伝えたいことは異なる意味としてい伝えられては意味がありません。
伝言ゲームを尊重しているのかどうかは知りませんが、 社長が言ったことを一言一句間違えずにそのまま伝えるマネージャーを見ていると、 君の存在価値はなんなのでしょうか？ と疑問が発生すます。
え！？だってそうですよね？ 現代において、最も正確に社長が言ったことを伝える方法は、、、 人から人への伝言ゲームではないことは自明です。 社長が話してることをビデオに取るなり、ボイスレコーダーにでも取るほうがよっぽど正確に伝えることができます。 しかもiPhoneもってれば、簡単にビデオ撮って、共有だってすぐできる時代です。
さらに、方針なんかだったら社長みずから全社集会なんかして発表しちゃったりしますから、 実行するメンバーの方々なんかは、同じことを再び聞くわけです。 これって、なんの意味があるのでしょう。僕には時間の無駄にしか思えないわけですね。
組織が存在する理由
そもそもなぜ組織が存在するのか？を考えてみましょう。
サッカーみたいにスーパースター選手を活かすために組織を作る場合もありますが、 一般的には、役割で組織を分けるのがほとんどだと思います。 製品を売る役割は営業。製品を作る役割は開発。働く人たちをサポートするのは管理部門。 などと、必要な役割でチームを作っていきます。 役割が決まっているため、具体性があるのです。具体性があるから業務を遂行することができるわけです。
上からの方針は抽象的
なわけです。全体の方針ですから抽象的になります。 ざっくりしてるわけですね。 具体的な事例や、事実を元に全体が同じ方向を向くような方針や目標を立ててるわけですから、抽象的になってしまうのですからね。
実行するのに必要なこと
とにかく具体化したTODOリストが必要。 アプリ開発で積極的に取り入れられている、かんばん方式などは良い例だと思います。
具体化しないとどうなるか？というと、何をしていいのかよくわからない！ってことなのです。 例えば、上の人がジュース買ってきて！って言われても行動に起こせないわけです。
ジュースって意外と抽象的で、オレンジなのか？コーラなのか？缶がいいのか？ペットボトルがいいのか？500mlがいいのか2リットルがいいのか？
たったこれだけの抽象度なだけで、考えうることがこれだけ出てきます。
でも、2リットルのコーラ買ってきて！ だったらすぐ行動できます。超具体的だからです。
さて、そもそも組織がなぜ存在するかということを思い出してみます。 目標を達成するためのとある役割を担当するためにあるのです。
となると、絶対に、社長の言っていることよりも具体的な目標を掲げなければならないはずです。 だって、実行するためには必ず具体化が必要ですから。 つまり、社長がかかげた方針を、自分たちの役割と照らし合わせて、方針を達成するための具体的な目標を伝えないとチームは動きません。
ブレークダウンが必要なんです。
マネージャーは伝言ゲームをするのではなくて、自分のチームの役割を果たすためのブレークダウンした説明をする！
ってのが重要なんです。それを考える必要があるのです。
僕だったら、この順番でチームに伝えるでしょう。
上の方が言っていたことをまずはそのまま伝える → 正確な情報伝達と全体像把握のために。自分の理解が間違ってたときにチームメンバーに突っ込んでもらうために
それから自分のチームの役割と上からの方針を考えて、チームとして実行すべきことを落とし込み具体的な内容を伝える
2.に関しては自分がマネージャーの役割をしてなくてもします。 目標を達成するためには？って考えてトップダウン思考で行動できるレベルまで具体化してTODOリストを作成ですね。 一人で具体化できない場合は、チームメンバでブレストみたいなことしてだしたりします。 やっぱり行動して成果だしたいので、そして成功するとモチベーションも上がりますし、何より楽しいですから。
使ったことないプログラミング言語のお仕事を依頼されたけど、受け入れ要件みたせました。
フリーランスエンジニアの @nabeemichi です。
ちょいちょい、知り合いの方などから個別にお仕事をいただけるようになってきて、直接契約のお仕事が増えてきた。 直接お仕事依頼されるようになってくると、前提条件として言語が指定されたり、最も早く目的達成するためには使ったことない言語を利用しないといけないこともしばしば。
そんなこんなで、今回はGoogle App Scriptを利用するお仕事を依頼された。 一度も使ったことないし、使う必要性もなかったので初見の言語なんだけど、お仕事させていただくことにした。
もちろん納期どうりに要件もみたして、依頼主からはイメージ通り！といっていただけたので、仕事としてはトラブルもなく完了することができた。
仕事を受けるにあたって考慮したこと
全くやったことないことは完成までのプロセスをイメージすることが困難だ。 イメージできないと見積もりもたてれないし、実現可能かもわからないのだけど、それだとなにも進まない。 そのため、イメージするためにある程度考慮した。
似ている言語を知ってるか
Google App Scriptに似ている言語が何かを調べた。 ちょっとサンプルとかを見てみたかんじ、JavaScriptの劣化版みたいな雰囲気だったので、 JavaScriptは使ったことあるので、なんとかなりそうだな。と判断。
それに、Google App Scriptについて調べるとサンプルがたくさん出てくるし、公式ドキュメントもちゃんとあるので言語的な障害はなさそうだ。
実行環境についてすぐにキャッチアップできそうか
言語がどうにかなっても、実際にプログラムが実行される環境について知らないと、実装上の制約条件もわからないまま作ってしまって、実際にユーザー先で実行したら動きませんでしたー！という、終わってる結果になってしう。
そのため、自分のPC環境で、ユーザーが実行する環境と同様のものを用意できるかが判断軸になってくるのだが、Google App ScriptはGmailやスプレッドシートを操作したりするプログラミング言語である。 つまり、毎日自分も利用してるGmailアカウントがあれば、同じ状況が速攻つくれる。 さらに、スプレッドシート上で実行するプログラムだったとしたら、実際に利用するスプレッドシートをお客さんから共有だってしてもらえる。 開発環境問題と実行環境問題は特に障害はなさそうだった。
できなかったときのことを事前に決めておく
使ったことない言語、環境はやっぱり実現可能かどうかは、やってみないとわからない。 やったことある事例の組み合わせでの判断もできない。
だから、最終逃げ道として、要件を満たせないケースについて取り決めを引き受けるときにしておいた。
今回は、以下のように決めておいた ・マックス1日使って実現できないと判断した場合、料金は発生しない ・できないと判断した理由を報告 ・他の案で実現可能かを報告 ・やってみたことを報告
まぁ、できなかったら俺の1日が無になるのだがしょうがない。
実際引き受けてみて
言語については、実際にプログラミングしてみてJavaScriptの劣化版だからどうにかなるし、 実行環境についても特にハマることもない。 何より、Google App Scriptはぐぐるといっぱいネタがでてくるし、だいたいやりたいことみんな同じようなかんじ（Gmailを自動で返信するとか）だから参考になる記事たくさん。 やっぱググって情報でてくるって大事だな。
過去には、WPFとかいうググっても全く情報がでてこないフレームワーク指定でアプリ作らされたけど、それとは大違いだわ。
有名企業に入社しても、自分のブランド力が上がったわけではない！という話
フリーランスエンジニアの @nabeemichi です。
またまた、転職活動中の友達に話したら反応良かったので文字化します。
有名企業に入社しても、企業を有名にした人がすごいだけで、入社した人がすごいのではない。
何が言いたいかと言うと、人のブランドの上に乗っかっただけで、自分のブランド力が上がったわけではない！！ということです。
有名企業にはいるとブランド力を持った人になったと勘違いする人
っていると思うのです。実際に僕が就活したてたときも誰もが知るような企業に内定もらって、いきなりすげーだろ！オーラ出すやつはいました。 確かに人気企業は倍率も高いだろうし、優秀な人がたくさん受けると思うので受かることはすごいことだと思います。
転職活動でステップアップして有名企業に入社する人もいるでしょう。 中途採用でも有名企業を受ける人は優秀な人が多いと思うので、受かることはすごいことだと思います。
僕も一応IT系の仕事をしてますので、IT業界での有名企業に内定をもらったとします。 イメージしやすくするためにもう少し具体的にいきましょう。 どこでもいいのですが、誰もが知るIT企業とするとマイクロソフトあたりにしましょう。
マイクロソフトは世界的企業であり、どの国でもwindowsは使われているでしょうし、世界中のWEBアプリエンジニアを苦しめるIEも全世界で未だに使われているはずです。 創業者のビル・ゲイツも長者番付にランクインするくらい有名な方です。
そんなマイクロソフトに仮に僕が入社することになったとします。
マイクロソフトは世界で誰もが知る企業です。 こんな世界的に有名な企業に入社した僕は世界の誰もが知るほどの知名度になったでしょうか？
答えはノーですね。誰がどう考えても、いや考える間もなくノーです。 だって、マイクロソフトは知っていてもマイクロソフトの社員を知ってる人は少数です。
すごいのはマイクロソフトを作った人
マイクロソフトをイチから作って世界的に企業にしたビル・ゲイツや初期のメンバーはすごいと思います。 全く認知もされてない、できたてホヤホヤのなにもないところから作ったのはすごい。 これは、初期のメンバーが作り上げた世界ブランドでしょう。 初期のメンバーはものすごいブランド力があると思います。
でも、有名になった誰もが知る今のマイクロソフトに入社したら、 初期のメンバーが作り上げたブランドの上に乗った形になります。 そのため、入社した僕が作り上げたブランドではないのです。 ということは、入社しても僕のブランドが上がるわけでもなんいんですね。
だから、「俺マイクロソフト！」とかい言ってても、僕の場合「で！？」しかないわけで、自分のブランドってどの会社に所属してるとか関係ないんですよね。
会社が育ててやっただろ？というのは的外れであるという考え方
フリーランスエンジニアの @nabeemichi です。
タイトルのことを転職活動している友達に話したらウケがよかったので、文章にしてみることにしました。
転職のために退職交渉を行う際に、「会社が育ててやったんだぞ！」ということを言われることがあるらしいですが、 僕にはこのロジックが理解できません。
どんなに良いとされる環境にいようが、自分で成長することを選択し、行動を起こした人しか成長はしないのです。 そのため、会社が人を育ててやったなんてことは的外れというわけです。
どんなにすごい人が教えようが育たない
簡単な例として、大学受験を考えることにします。 大学受験における成長を、偏差値アップすることと定義します。 大学受験において、偏差値が上がれば上がるほど、合格する大学の数が多くなり、大学受験終了後に多くの選択肢を手にすることができるため選択肢を広げられるという点で成長と捉えます。
偏差値を上げるための手段としては、勉強をすることになるのですが、 この勉強の方法にも何種類かありますが、偏差値を上げるためには最も偏差値の高い東京大学への合格者数が多い予備校の有名な先生の授業にでることにします。
この場合、「会社が育ててやったんだぞ」というのは「予備校が育ててやったんだぞ！」と変換して考えることと同値です。 「予備校が育ててやったんだぞ！」ということが正しいとする場合、 有名な先生が教えてくれていることもあり、予備校へ通い、授業を受けていれば東大へ合格するほどの偏差値になる！ ということになります。
しかし、現実は違います。どんなに有名校出身であろうが、有名な先生に教えてもらおうが、全員が合格することはありません。 合格する人は、自分で勉強することを選択し、授業を受けて己の問題点に気づき、それを埋める勉強をした人です。
つまり、予備校がなにかしたのではなく、予備校という環境を利用して問題点や課題を洗い出して、解決する作業を自分で行ったため偏差値が上がり選択肢を増やすことができた。というわけです。
自分で成長したということです。
これを会社に当てはめてみましょう。
社会人としての成長を、仕事ができるようになり給料が高くなるとします。
新人で入社した場合、先輩社員がメンターとなってOJTなどを行い、新人教育するとしましょう。 僕も新卒で入社した会社ではメンターがつきましたし、その後メンターもしましたので実際に存在する教育方法なのではないでしょうか。
もし、「会社が育ててやったんだぞ」ということが正しいとすると、仕事のできる先輩社員がメンターとして仕事を教えてくれるので、 仕事ができるようになり、評価もされて給料が上がるはずです。
しかし、現実は違います。仕事ができるようになって給料が上がる人もいれば、そうでない人もいます。 どんなに仕事ができるメンターが付こうが、本人が成長することを選択しなければ成長しないわけです。
仕事ができて給料が上がる人は、仕事ができる先輩社員を見て自分の課題を把握して、課題を解決する作業を自分で行ったため給料が上がったのです。
ロールモデルを見て、自分で成長したということです。
以上のことから、「会社が育ててやったんだぞ」ということは正しくないということが導き出されたのです。
そもそもなのですが、
人が人を成長させることはできない
はずなのです。 きっかけや気付きの元になるとはできます。プロ野球選手などを見て憧れて目指すきっかけを与えるのは人です。 これと同じで、社会人でも同じ原理は働くでしょう。
しかし、育ててやることはできない。 そもそも、育っているのか退化しているのかを決めるのも人ですから、正解がどの方向なのかを決めるのも人次第。 だから育ててると思ってるのは、他の人から見たら育ってない！なのかもしれない。
会社はきっかけと環境しかあたえられない
自ら成長することを選択したときに、成長を加速させるためのツールや気づきをもらえるような人がいたりすること。 これしかないんじゃないのかな。 だって、人は自分で成長を選択して、自分で行動をしないと成長しないですからね。
会社が育ててやっただろ！ってのは的外れ！
フレームワークを理解しないでプログラミングしてるエンジニアっているんだね
@nabeemichi です。
アプリケーションをつくるときにフレームワークを必ずといっていいほど利用する。 最近のエンジニアにとっては、フレームワークをうまく利用して効率的に開発することが重要になってくる。
フリーランスエンジニアとして働いていると、いろいろな経歴のエンジニアと働くのだが、 フレームワークを理解しないでプログラミングしているエンジニアが一定数いることに気づいた。
フレームワークを理解するとは
フレームワークや技術を理解するということは、理論と動作の2つを確認して初めて理解したということになる。
理論はフレームワークのドキュメントから論理てきに頭で理解する。 オープンソースのフレームワークでソースコードが公開されている場合は、ソースコードを読んで論理的に動作を頭の中でイメージできる状態にしてもいい。 とにかく、文字列を読んで頭で動きを予想できる状態になることが理論的にわかっている！という状態なのだ。
しかし、これだけではフレームワークを理解している状態だということができない。 文字列を読んでイメージできても、所詮は人間である。勘違いしてる場合だってあるのだ。 そこで重要なのは、実際に動かして目で見て確かめることだ。 頭でイメージした状態が、目の前で動いてイメージと一致する状態を確認しなければ、理解しているとは言えないのだ。
理解してないで使ってるとは
上記で述べたことの一方しか確認してない状態で作っている。 特に、動きだけ見て作っている。 動きの確認は、ドキュメントみてサンプルを見て、コピペして自分のやりたい動作になるように改造している。
たしかにこれでもアプリケーションは作れるし、つくる速度もは一旦は早い。 ここでの問題は、理解しないで作ってるから、つじつま合わせの実装が増えて、何をしたいのか理解できないソースコードが出来上がることだ。 そう！実現したいことに対して最短のアプローチを取れていない状態を作り上げている。 こうなってくると、フレームワークを利用して効率的に開発を行いたいのに、非効率を作り出している。
さらにつじつま合わせの実装を行うということは、不具合や問題が起こったときに何をしていいのかわからない状態になっているのだ。 不具合に蓋をするためにさらにつじつま合わせのの実装で回避する。 こうなったら、もう何も問題が発生しないでくれ！と念じるしかない。 （いや、問題起きても時間かければ一つづつ紐解いていけばいいのですがね。泣きたくなります）
プログラミングのソースコードってね、書けば書くほど不具合の発生確立も高くなるし、負債にもなるんですよね。 書かなくていいものは書かないで、違うとこにパワー使おうよ。 そのためには、理解して使ったほうが、なにかと早いと思うけどね。
アプリケーションを企画するならば、理想の状態を定義しないと不具合かどうかすら判断できません。
@nabeemichi です。
アプリケーション開発をしていると、テストを行います。 リリース前に評価チームがテストを行い、仕様があっているかや不具合がないのかについてテストを行い、 不具合がある場合は、開発に不具合の修正依頼がきます。
不具合がないアプリケーションなんてものは存在しませんので、テスト段階で不具合修正依頼は必ずきます。 エラーが起こる場合は技術的に間違っているので修正方針もはっきりしていますし、不具合だと特定することができます。 しかし、動作的におかしい場合は話が変わってきます。
動作的におかしい場合は、
アプリケーションとしての理想の状態
を定義していないと、おかしいと判断できないはずなのです。
特定の条件のときに、動作が意図してない状態なので修正してください！
と、依頼されても何が意図していないのかは特定できない。 仕様書を見ても全く記載がない。 僕に決定権がないようなチーム体制で仕事をする場合は、どうしようもなくなってくるわけです。
だってその不具合、開発時に発生したものではなく、企画が仕様書を作った時点で発生している、仕様バグですから。 仕様が不具合なのです。
もし仮に、僕が決定権もっていたら
僕が理想の状態を考えて仕様から修正してしまうのですが、 そもそも、どんな課題を解決するための機能なのかが理解できないと、こっちとしても独断的修正どころか、 仕様の修正方針の提案すらできないのです。
もうこうなると、企画者に理想の状態の定義をしてから、不具合であるかを決めてください！
と、エンジニアは言うしかないのですよ。
仕様書に課題が明記されてたとしよう
この場合は、エンジニアが対応方法を考えて提案できる。 課題から解決方法として、機能を考えられる。 そして、課題が解決された状態が理想の状態であると考えることができるので、 現時点とのギャップがわかる。
ここまでくると、不具合が何であるのか？を定義することができるのです。 これをしないと、対応方針もきまらないし、そもそもユーザーが何したいのかわからないんじゃないの？
なぜやるのか？
なぜつくるのか？
なぜこの機能なのか？
ココらへんを説明してない仕様書やチームと働くと、プログラミングを淡々としてくれるロボット作った方が効率的ではないでしょうかね？
vuetify.jsのautocompleteを利用して、よみがな検索した結果を表示する方法
個人の時代と呼ばれるようになったので、WEBアプリくらいも個人で開発運用する時代だと思って、一人でWEBアプリ開発中の @nabeemichi です。
一人で開発、運用するにはできるだけコーディングする量を減らしてWEBアプリを作らないと、いつまでたっても完成しないので、 nuxt.jsを使い、CSSフレームワークとしてはvuetify.jsを利用して開発しているのですが、 ちょっとハマったので、トライアンドエラーした記録をしておきます。
nuxt.jsやvuetify.jsとはなんぞや？と思う方もいると思いますが、今回は完全にプログラミングの内容になっておりますので、 エンジニア界ではお決まりのフレーズである、ググレカスを前提に攻めていきます。 ググっても出てこないことを主に書いていこうと思います。
課題となる事象
まずは何が課題となったかについてです。 グーグルの検索などでは、ユーザーが入力した内容で、検索したそうなワードをオートコンプリートで候補を出してくれます。
例えば、「て」と入力したら、オートコンプリートとして「天気、天気東京、、、、、」などと検索したそうな単語を表示してくれるやつです。
これと同じようなことを実現しようとした場合、サーバサイドではelasticsearchを利用して検索した結果をフロントエンドでオートコンプリートとして表示させるのが一般的だと思われます。
今回はvuetify.jsのAutocompleteコンポーネントを利用して、これを実現しようとしましたが、オートコンプリートが表示されないケースがありハマりました。 具体的には、
Autocompleteコンポーネントで「て」と入力したら、「天気、天気東京、手」などが出てきてほしいケースを実現するのにハマったのです。 でも「天」と入力すると「天気、天気東京」は出現するという現象。
オートコンプリートを表示するまでの一連の流れ
vuetify.jsのAutocompleteにユーザーが入力（例：「て」と入力）
ユーザーがインプットするたびに入力内容をelasticsearchで検索（例：検索結果として["天気", "天気東京", "手"]がヒットする）
elasticsearchの検索結果をvuetify.jsのAutocomplete側のオートコンプリート用のitemsと連動させる
課題となる事象の原因
vuetify.jsのAutocompleteコンポーネントにデフォルトで「:filter」が指定してあるため、インプットした文字でフィルタリングがされる仕様になっているため。
今回のケースでは、オートコンプリートのitemとしてelasticsarchの検索結果をAutocompleteコンポーネントitemsで管理できているのだが、さらに「て」でfilterをしているので、漢字の「天気」などは表示されない
ということであります。
解決策
Autocompleteの no-filterプロパティがあるので、これを有効にしてあげましょう。
<template>
<v-autocomplete
:loading="loading"
:items="items"
:search-input.sync="search"
v-model="select"
no-filter // ☆これをつけないと、インプットした文字でフィルタされて、読み仮名検索とかできない☆
></v-autocomplete>
</template>
<script>
import elasticsearchClient from '~/plugins/elasticsearchClient'; // ここはelasticsearchのドキュメントを読んでelasticsearchのJS用ライブラリを頑張って入れる
export default {
data() {
return {
loading: false,
items: [],
search: null,
select: null,
}
},
watch: {
search(val) {
val && val !== this.select && this.querySelections(val)
}
},
methods: {
querySelections(v) {
const me = this;
this.loading = true
elasticsearchClient.search(
{
index: 'hoge',
type: 'doc',
body: {
// 検索はいい感じにオートコンプリートされるリストがとれるようにelasticsearchの設定とqueryを頑張る。
"query": {
"match_phrase_prefix":
{"fuga": v}
}
}
}
).then(
function (resp) {
const hits = resp.hits.hits;
// 検索結果をitemsに打ち込むことでオートコンプリートとして表示される。
me.items = hits.map((hit) => {
return hit._source;
});
}, function (err) {
console.trace(err.message);
}
).finally(
() => {
this.loading = false
}
)
}
}
}
</script>
解決策に対する根拠
vuetifyjsのAutocompleteコンポーネントのソースコードを見てみると、赤枠で書いてあるところにfilterのデフォルト関数が定義されており、 ユーザーが入力した文字（queryText）がオートコンプリートとして表示する文字（itemText）に含まれているかを判定しているので、ほぼ間違いなし。 no-filterをつけると、このfilter関数が実行されなくなるので解決
