エトウソウヘイ

関西のwebエンジニア。 趣味は、情報収集(技術、ビジネス、ゲーム) あだ名はロボット…

エトウソウヘイ

関西のwebエンジニア。 趣味は、情報収集(技術、ビジネス、ゲーム) あだ名はロボット ほのぼのと感じたことを書いていきます。 どうぞよしなに

成果評価のための責務とルール

どーも、関西でエンジニアをしている江藤です。 皆さんは会社で他人を評価する時に、何を指標に判断していますか？ 色々辛い思いをした人も多いのではないですか？ 個人的に一番辛かったのは以下です。 [僕] :どうやったら僕の給与上がりますか？ [上司]: ミッションを体現できたらあげるよ。 [僕]: 具体的にどういった成果を出せばいいですか？ [上司]: そんなんだからミッションを体現できなくて、給与が低いんだよ。考えろよ。 [僕] : (結局何をやればいいんだ？？) どの会

エトウソウヘイ

    • リモートワークの情報流通の向き合い方

      どーも。関西でエンジニアをしている江藤です マネジメントをやるようになって、`情報をよこせ`と色々言われますが、具体的にどうすればよくわからんと感じることが増えました。 仕事をは報連相が大事と習うのですが、具体的なアクションを提示してくれることは少ない気がします。 なので、本記事では僕が学んだ情報の共有や同期についてまとめていきます。 情報はなぜ大事？早く意思決定ができるからです。 大抵の問題は早期に対処すれば、傷は小さく済みますが、放置すれば雪だるま式に破壊力が増大

      エトウソウヘイ

      • 「有った方がいい」という言葉が現実を潰す

        プロダクトや新規機能を企画したり要件を詰める際に頻繁に出てくる「有った方がいい」という言葉。僕も何度もを要件を詰める時に聞くのですが、この言葉を鵜呑みすることは危ないと、つくづく感じているので言語化したと思います 足し算が現実を潰す機能開発を行う場合、目的を整理し必要な機能を洗い出していくことが必要であり、そのために色々な判断材料をもとに取捨選択をしていく必要があります。 例えば、実験的な機能をローンチして、市場の反応を見たい場合は、最低限の機能とユーザーに届けられる最低限

        エトウソウヘイ

        • エンジニアがコードを書く前に気をつけるべきこと

          どーも大阪でエンジニアをしている人です。会社でエンジニアが事業に貢献するために、ツールや機能の実装はままあることかと思います。ただし、注意しないと当初はよかったものが数ヶ月後に皆の首を絞めていることが発生しかねません。個人的にそういった勘所をまとめたいと思います。 機能の背景を理解しよう機能開発には必ず解決したい課題と期待する成果があります。これらを把握しておくと、今後の追加開発を見据えてソースコードの設計ができるほか、もし開発が間に合わない場合に代替案や折衷案を出し、bi

          エトウソウヘイ

        成果評価のための責務とルール

        エトウソウヘイ

          往復を減らすテキスト術

          リモートワークが普及してメインのコミュニケーションがテキストになってきました。ただ会話ベースでテキストを書くと無駄な往復が発生してストレスが溜まるので、そこらへんで気をつけていることを紹介していきます。 スケジュール調整は仮決定事項を伝える個人的にテキストで面倒なのがMTGとかの日程調整です。 複数人の予定をチェックするために何回もテキストで伝えないといけないです。 非常に面倒なので、自分の観測できる範囲(google カレンダーなど)でMTGに一番適切な日程を仮決定して

          エトウソウヘイ

          往復を減らすテキスト術

          エトウソウヘイ

          エンジニアによる事業ヒアリングのすすめ

          以前にエンジニアは自分が開発している事業やプロダクトを知るためにやったことをnoteに書いたのですが、今のスタイルややり方が違っている部分があり、より良い方法も見つかったので改めて書き起こしておこうと思います。 誰にヒアリングするの？PdMや事業責任者の方と一対一で必ず話すようにしましょう。なぜならその人は事業に対することをの全容を把握しているので時間や労力から考えて効率が良いからです。 現場の人からボトムアップでヒアリングをしていくと部分的に情報が揃っていくので最初の情

          エトウソウヘイ

          エンジニアによる事業ヒアリングのすすめ

          エトウソウヘイ

          新しい技術とどう付き合っていくべきか？

          この世の中、常に新しい製品やツール、サービス(以下技術と呼称)が生まれては陳腐化して消えていきます。そして、それらは何かしらの形で利用され、私たちのくらしを支えています。 昔は馬車が主な移動手段だったものが、自動車が発明され、今では自動運転の実験がなされています。こういった技術の変遷の流れは私たちの暮らしでも身近に感じ取ることができます。 では、なぜそういった進化が発生し、それらは私たちに何をもたらしているのか。 新しい技術はなぜ生み出されるのか？既存の問題や不満を解決

          エトウソウヘイ

          新しい技術とどう付き合っていくべきか？

          エトウソウヘイ

          価値あるKPT(振り返り)の育て方

          組織の成長にとって失敗を分析して次に繋げることってすごい重要だよね。 とはよく言われますが、他社事例やネットの記事通りに振り返りをやっても、空中分解や成果がでないと感じる場面は多いです。ただ、お手伝いしているスタートアップでKPTを提案して、実際にファシリテーターなどを含め先導した結果、うまくいかない原因について心当たりがついたのでまとめてみたいと思います。 KPTとは？まず前提となるKPT(振り返り)の解説をします。 一定の周期で、みんなで集まり、KEEPとPROBRE

          エトウソウヘイ

          価値あるKPT(振り返り)の育て方

          エトウソウヘイ

          成果は環境とフェーズで変わる

          よく「前職では力を発揮できていたのに、転職したら力を発揮できなくなった」という話を聞きます。新しいチームの人間関係や意思疎通に失敗したという考え方もあるんですが、自身の経験からそれだけではないのでは？と思ったので言語化してみたいと思います。 転職で力が発揮できなくなる原因は？結論だけ言うと、その会社が考える成果とのミスマッチが起きていることが原因だと思います。 肌感覚として、会社が考える成果は風土やフェーズ、自分の役職で結構変わったりします。なので、知識や技術などのスキル

          エトウソウヘイ

          成果は環境とフェーズで変わる

          エトウソウヘイ

          リモートワーク下での情報集積の仕組みを色々作ってみた話

          リモートワークになってから、業務委託としてある案件にジョインしたのですが、フルタイムの人や同じ業務委託の人と時間が合わず誰が何してるのかわからず、その情報の差異で仕事に支障が出てきたました。 具体的には、 ・同僚が受け持っているタスクが何かわからないから相談されても、背景から聞くことなる。 ・MTGをする際に、 `毎回zoomのURLどこっだっけ？` と無断に探す時間が必要になる。 ・プロジェクトのゴールがわかりずらいから、進捗がわからない。 と多種多様なのですが、放置し

          エトウソウヘイ

          リモートワーク下での情報集積の仕組みを色々作ってみた話

          エトウソウヘイ

          信用は行動に必要なリソース

          有名な言葉で「許可を求めるな謝罪せよ」という、行動の大切さと説いた言葉があるのですが、現実的なところは前提条件があると感じたので書いていきたいと思います。 信用なき行動は周りを破壊する結論からいうと前提条件として、周りのメンバーに信用されていることが最低条件だと感じています。 信頼がない状態で突っ走ると、上司やメンバーから見れば不安と迷惑としか感じないので、必要な情報や権限がどんどん隠されていき最悪の場合は干されます。 結果、自分がやりたいことや、経験したいことを行うことが

          エトウソウヘイ

          信用は行動に必要なリソース

          エトウソウヘイ

          仕組み導入のアンチパターンの話

          仕事でKPTやペア作業などのチームとしての仕組みを導入してみて、うまく機能せず悩んだ時期があったのですが、自分がやっていたアンチパターンを認識できるようになってきたので訓戒として残したいと思います。 先人のベストプラクティスを探さない厳密にはベストプラクティス(流れや準備)をちゃんと調べず、ふんわりしたイメージで仕組みを運用していこうとすることです。 そもそも、フレームワークや仕組みは先人の失敗と成功の繰り返しの中で洗練されていった、エッセンスが非常に詰まっています。それ

          エトウソウヘイ

          仕組み導入のアンチパターンの話

          エトウソウヘイ

          1on1はサポートとコーチングのバランスが重要

          色々な事情が重なり、直属の上司ではないが、他プロジェクトのメンバーの1on1をやる機会があり、実際に色々学びを得ることができたので、メモがてら残しておきたいと思います。 1on1とは?上司と部下が適切なスパンで30分ほど面談を行うことで、部下の行動を後押し、自発的な活動を促すことを目的とした仕組みです。 ここで重要なことは上司は部下の自発的な活動を期待するため、命令したり、圧をかけてはいけません。あくまでも主導権は部下にあり、上司はサポートに徹する裏方なのです。 今回僕

          エトウソウヘイ

          1on1はサポートとコーチングのバランスが重要

          エトウソウヘイ

          調整は見えにくいけど重要なスキル

          最近エンジニアとして、要件定義やスケジュールの策定などいわゆる、調整事を色々してきました。そうした中で、会社のなかでの調整の大事さなどを感じる機会があったので話したいと思います。 調整スキルとは何か？「ステークホルダーからの意向や背景を理解した上で、コミュニケーションを取り物事を推し進めるスキル」 と考えています。大袈裟な書き方をしていますが、物事を進めるために、関係者から情報を集めたり、プランを策定したり、提案してみたりなどの諸々のことですね。 例えば、「このツールが

          エトウソウヘイ

          調整は見えにくいけど重要なスキル

          エトウソウヘイ

          エンジニアが事業構造を知ってると得だと思った話

          ちょっと前に本業の仕事で事業構造を把握するために色々やったのですが、その時の経験から開発しているツールの仕様の変更や要件の定義の時に非常に有用だったため、その時の経験を色々話したいと思います。 事業構造を知るとなんで得になるのか？エンジニアが日々頑張って作るサービスは結局のところ事業を回すためのツールでしかありません。そして、その事業は市場や内部のフロー、ユーザー、競合など、様々な要素を鑑みながら意思決定がなされ運用されています。なので、それらの要素や力学を理解しておくと、

          エトウソウヘイ

          エンジニアが事業構造を知ってると得だと思った話

          エトウソウヘイ

          続けることの質は改善の質に大きく比例する

          現在働いている会社で振り返りや開発の仕方などの色々な枠組みを提案したりして、実際にKPT(チーム内での振り返り)主導したりとした結果、仕組みを運用するにあたって考えないといけないことを少し学べた気がするので書きたいと思います。 仕組みを作ることは難しい最初に仕組みを自分で作ることは難しいです。振り返りのような軽めの題材であってもファシリテーションのスキルや議論の方向性をコントロールする力も同様に求められます。その上で現在のチームにあった方向性の形へと具現化していかなくてはい

          エトウソウヘイ

          続けることの質は改善の質に大きく比例する

          エトウソウヘイ