年末だから熱い想いをポエムしてみたものが下書きに埋もれていたので拾って公開してみる
全然別件でブログを書く気持ちになったものの
管理画面を開いたら下書きのまま放置されている謎のブログを発見しました。
たぶんこの時と同じ気持ちで続きを書く事は出来ないので
中途半端なようなむずがゆい気持ちもありつつとりあえず公開しておきます。
新年をこれから迎えようとする厳かな気持ちで読んでいただければ幸いです。
-------- ｲｲﾜｹ ｺｺﾏﾃﾞ --------
年末ですね。
師匠も走る師走もいよいよ大詰めです。
そんな中でとても良い記事を見つけました。
https://qiita.com/hirokidaichi/items/d12fcce80ee593bcf34d
せっかくの年末なので
エンジニア組織作りやシステム構築の上でとても大切にしている事を
きちんと言語化してブログに残してみたりしようかなと思います。
ここからの内容はほぼポエムであり
一緒に働く人向けのメッセージです。
「世の中にはそんな事を考えているエンジニアもいるんだなぁ」ぐらいに捉えてもらえれば幸いです。
どんなエンジニアと一緒に働きたいか
組織を作っていく上でどうしても避けて通れないのが
採用、育成、文化共有
みたいなところかと思います。
チームの性格と個人の指向をきちんとすり合わせて一致させていく必要があると思いますし
それがきちんと出来ている組織は高いパフォーマンスが発揮出来るはずだからです。
もちろんエンジニア組織における採用では
```
どんな言語が扱えるか
どんなフレームワークを使ってきたか
どんなチーム規模やサービス規模を経験してきたか
```
みたいな事を軸に採用をかける事が多いですが
実際の面接の場面ではこの辺りは深く確認しない事が多いです。
それよりも
チームに入った時にどういう状況が想定されるか
がお互いに想像出来るように話し合いを持つ事が多いと感じています。
自分自身がたくさん経験しているので特に感じる事ですが
チームにおける個人のパフォーマンスはそのチームでしか発揮できず
別の組織に属すればその組織でのパフォーマンスになると思います。
極端に言えば新しい環境に身を投じる時に過去の実績はあまり重要ではない
ということです。
それよりも
新しい環境に順応していく能力を強く求める事になります。
もちろん過去を捨ててきてほしいわけではなく
過去の実績を抽象化、汎用化して活用して欲しいとも思っています。
普段扱っている開発言語やフレームワークも
数年経てば様変わりしてしまうのがテクノロジーの世界です。
常に新しい情報を取り入れ続け挑戦し続け成果を出し続けられないと
エンジニアとしての未来は無いと考えています。
マインドセットとして常に次のステップを見据えて
アクションし続けられる人と一緒に仕事をしたいと思っています。
目標設定と評価の話
今所属している組織では明確な評価基準はまだありません。
目標設定は走り始めましたが
四半期毎の開発スコープや注力課題を明文化したもの、というレベルに留めており
個人のキャリアに関わるような目標設定は行っていません。
これは経営側とのすり合わせを今後していく必要があると感じていますし
会社の見解としてはまだ明確なものは無いのですが
個人的には評価基準の設定と目標設定が非常に苦手ですｗ
というのも
特にスタートアップの組織では会社の目標自体が朝令暮改で移り変わっていく事が多く
手段としてのエンジニアリングについてもそのスピードについていく必要があります。
そこに個人のキャリアの話が挟まってくると混乱が生じやすいです。
もちろん企業として従業員のキャリアパスに寄りそう必用はありますし
成長をサポートする必要もあると思いますが
強制されるべきでも会社の意志で振り回されるべきでも無いと思っています。
短くても四半期、半期、通年などで設定される目標設定は
悪い捉え方をすると「状況が変わっても設定された目標値をクリアすれば評価が上がる約束」
と受け取られかねない、という懸念が非常に重たいです。
状況が刻々と変わる中で常にその時の最良の判断と最良の行動を続けて欲しいですし
その組織貢献が最終的に評価と給与に結びついて欲しいと切に願っています。
なので企業に属していたとしても常にメンバーや後輩に話をするのは
利益を上げて給与を上げてもらうための組織貢献をし続けよう
という話と
どこに行っても通用する力をつけられる習慣、学習方法を見に付けて実践していこう
という話をします。
普遍的な物を体現できる人が最後には求められると思うのです。
また目標設定と並んで議論される事の多い評価についてですが
基本的には「人が人を評価できると考える事自体がおこがましい」と思っています。
給与テーブルは企業の営利活動に大きく左右されますし
市場評価と社内のポジションによって多少の調整はあれど
基本は業績によって決めてしまって良いのではないかと思っています。
責任の所在を明確にすることとしないことの大切さ
人間というのは脆いもので
人が作り上げた仕組みのある一点においての責任を全部任せると簡単に壊れます。
その責任の重圧というのは周囲の人の生活を脅かしたり
場合によっては生死の行く末すら左右するものです。
普通に考えれば誰もそんな重たい責任は負いたくないですし
ごく当たり前の事です。
人には心があり感情があるからです。
逆にプログラミングにおいては
責任の所在を明確にしておくことで可読性、メンテナンス性の向上など
良い作用が多分に発揮されるところです。
「処理」というものをいかに標準化し
特定の範囲における責任を集中させ明確にするかということは
プログラマーの技量に関わる重要な点であると考えられます。
組織におけるリードエンジニアとして活動する中で
「責任の所在」という話を繰り返しするようになりましたが
逆に組織論の中では一切こういう話をしないなとふと気がつきました。
人が関わる部分に関しては責任を分散し冗長化していく事で
特定の人の離職や休みの場合のリスクを低減させられるからです。
自分も含めて誰かがいなくても回るように仕組みを作る事が組織として目指すべき姿だと思っていますし
この考え方はインフラ設計に似ているなと思ったりします。
プログラミングにおける責任の所在の明確化は
どちらかというと軍隊のような階級組織に似ていると思います。
ソフトウェアに寄った方がハードな軍隊式で
ハードウェアに近い方がよりソフトな現代的な組織論なのは面白いところです。
最近コンウェイの法則についての考察のブログを読みましたが
エンジニア組織を作っていく上では
相反する組織論を同時に考えて行く必要があるのではないか
ということに想い至ったので酔っぱらいながら書き記したまでです。
まだまだ言いたい事はたくさんありますが
組織論みたいなものは誰しも一言があり
語り始めるとケンカになるか酔っぱらうかなので
どうかアルコールの場でじっくりと語りたいものです。
今日のところは以上です。
どうもありがとうございました。
「技術のこと教えてください」って言っている人に教えることなんて何もない
表題の通り
本日もポエムです。
友人との会話の中で出てきた話で
当たり前なのに当たり前にならないとても不思議な話だと思います。
何かの情報をインプットしようとした時に知識のある人から情報をもらおうとすること自体はとても良いことだと思います。
ただ、何も行動を起こしていない、自分で調べもしていない事に対して「教えてください」では、何を教えれば良いのかわからないわけです。
何を知りたいのかもどこまで知っているのかもわかりませんし、少なくとも検索エンジンがそういう場合に非常に有用な手段だという事を知らないということぐらいしかわかりません。
その場合に返す言葉は結局「ggrks」になってしまうのです。
これは冷たい返答ではなく、まず自分で調べるところから始めましょうという小学生にもよくわかる丁寧な返答です。
調べてみてわからなければ改めて訊いてみてください。
相対的に見てエンジニアの多くは技術の話が好きで教えたがりの人が多いです。
きっと必要の無い部分までたくさんのインプットを授けてくれるでしょう。
ここから蛇足です。
この話にはふたつの重要な要素があります。
ひとつは「能動的であるかどうか」
もうひとつは「初めの一歩を踏み出しているか」です。
「能動的であるかどうか」は知識の獲得の上で非常に重要です。
教育論を語る上でどうしても教える側のスキルに目がいきがちで
社内教育の多くは講師側の人間の技量を上げる事でうまくいくと思われている傾向があるように感じます。
しかし本当に重要なのは教育を受ける側のモチベーションだったりします。
人間の脳みそは興味のあることに対しての吸収は早いですし定着もしやすいですが
興味の無い事はほぼ覚えられないようにできているそうです。
能動的に知識を獲得しようとしている人は時間対効率が良く
受動的な人は非常に効率が悪いということです。
日本語で言い直せば
「教育を受けている人」は成長せず
「学習を行う人」はすぐに成長する、ということです。
本当に知識を獲得したいのであれば「教育を受けに行く」という行動ではなく
「調べて飲み込む」というステップの方が圧倒的に量も質も良い、ということになります。
もうひとつの「初めの一歩を踏み出しているか」の話は
ひと昔前に投資や融資の話で聞いた事がある話です。
事業の構想を持っている人が複数いる中で
素晴らしい事業を考えたけど無一文の人で5万円融資して欲しい人と
事業計画には多少穴があって100万円の貯金がある5000万円欲しい人であれば
後者の方が融資を受けやすいという話です。
これは「100万円を貯める」というステップに到達している人の方が
何もしていない人よりも信頼できる、ということらしいです。
また、綿密に練り上げられたサービスのプレゼンを上手にするよりも
プロトタイプを持っている人の方が投資を受けやすい、というのも同じ話かと思います。
何かを始める事にはとても労力がいりますが
何かを始める事ができない人には対価を与える事も応援することも難しいのです。
行動をして初めて得られるものがあるという事はビジネスの世界では常識です。
何も行動を起こしていないのに「知識をください」は当然通らない主張だとすぐにわかりますね。
不思議な話ですが
IT企業に勤めている人でエンジニアと業務上直接関わるエンジニア以外の職種の人で
平然と「技術のこと教えてください」と言うだけで何かを教えてもらえると思っている人が少なからずいるようです。
業務がスムーズにいくようにweb技術の基礎の話やプログラミングのワークショップなどは行う事もありますが
事業に関わる技術の領域は広く全てを伝える事は到底できません。
入口を提示してとっかかりを作ること
技術に触れる機会を増やすことが出来る精一杯だと感じています。
技術に限らず知識の獲得は、これだけ情報が氾濫している時代ですから容易なはずです。
その中で、正しい知識を精査し取り込む工程で知識のある人に教えを求めるのであれば理解できますが
能動的に動けない人には誰も手を差し伸べなくなるのは仕方ないことだと思います。
早く人間が働かなくても成立する世の中にならないかなと思っている末端のエンジニアのポエムでした。
