自分が製品のユーザーであることは強い

自分がユーザーであれば、ユーザー調査をする必要がないし、自分がユーザーなのでユーザーファーストになりやすい。

人は欲しい答えが返ってきた時に感謝をする。

「自分が作りたいものを作る」に注力したい。

僕にとってそれは組織なのかもしれない。

優秀なエンジニアが行動できずにただ立ちすくんでいる。 その方達を有効活用すれば良いだけだと思う。 エンジニアは優秀である。 その人たちが燃える環境を作れば良いだけだと思う。

人の力をもっと有効活用したい

人はなかなか優秀である。 優秀な人に権限を委譲して、もっとやらせば良いだけな気がする。 経営者がやることは、環境作りや仕組み作りだと思う。

最終決定権を使って、従業員が一番モチベートを持てる環境を作れば良いだけだと思う

そういう会社を作りたい

とあるスクール生と会話した感想

良いとは思ったが機会の損失をしている気がした。 それがなければもっと強くなっていたのに、と思った。

コミュニケーションの活発な企業で働く得はありそう。 どういうメンバーと働くのか大事そう。

その人のおかげで周りのメンバーのモチベーションが上がったり、逆に下がる事は大いにありそう

アウトプットを頑張った日 ~自分を褒めたい

今日はアウトプットを結構頑張ったかな。 プログラムというより、組織づくりやコミュニケーション、心構えみたいなのを学んだ日だった。

開発者としてインクリメントを作るのも大事だけど、チームとして結果を出す、みたいなのも大事。

両方できるようになりたい

マネジメント論を読んで

部下に責任を負わせる

「xxの責任者はあなたです」みたいな感じで部下に責任意識を持たせるのが良い。

エンジニアに当てはめるなら

話の長いエンジニアがいるから、相手を傷つけずに話を抑えてもらう必要がある。

そして話を出してもらう土壌を作る必要がある。

aws系の本は買わなかった話

僕の今与えられている仕事 + 役割的にAWSインフラの知見はそこまでは求められていない。 けど大事なのは分かる。

なので買うという判断をする自分でいたかった気もする。

僕が買った本は心理的安全性や組織論の本だった。

確かに一人の技術者が出せるアウトプットには限りがあるからそういう領域も大事だ。

けど、そっちも勉強して欲しかったよ、自分

変わらない事を選んだ親戚を見て

今日は親戚と話をした。 親戚は変わらない事を選んだ。 成長を望んでいないように思えた。

正直話しても学ぶ所が少ないように思えた。 今は営業マンしてないかもしれないけど、昔は部下もいて営業部長をしていたのなら、その時の知見を話して欲しかった。

残念だった。

戦おうという姿勢がなかった。

市場は刻々と変わり続けている。 企業は常に変革を求められる。 強いチームを作らないといけない。

なのにそれができてない(求められていない)会社にいても微妙な気がする。

スピード感あるチーム開発とは

プロダクトはフィードバックを含めて、高速に改善していくのが理想。

アイディアを思いついたらそれを要検討し、市場に放つ。 それに伴うフィードバックを受け、また改善する。

IT企業において、webサービスがユーザーと接するインターフェイスであるならば、そのプロダクトは大事である。

サービスが使いにくかったり不具合があるからユーザーは問い合わせを行う。

0には出来ないし、それを気をつけ過ぎると市場に出すのが遅れて、会社の成長が遅れる可能性や、同業他社に市場を奪われる可能性がある。