"マネジメント"投稿一覧

Suzuki Yutaro

エンジニア

まず、terraform-docs自体について調べてみましょう。
https://terraform-docs.io/
続きを見る

北野勝久

エンジニア

https://offers.jp/qa/question/Uh1yvtNXky/Uw54nCm7VA にも書いたのですが、求められるスキルはとくに組織規模の大きさや周辺機能組織がどの... 続きを見る

大橋桃太郎

プロジェクトマネジメント

一般論としてですが、責任範囲が経営なのか技術組織が最大の違いかと思います。
CTOの場合、技術的専門性に責任をもった経営参画であり、技術だけでなく経営に関する様々な知識や理解（事業成長, 会計, 採用, 資本政策, 未来への投資, etc..）が求められ、経営として全体最適な意思決定をする責任があります。
一方で、VPoEの場合、責任範囲は技術であり、技術への高い専門性は同様で... 続きを見る

北山 淳也

エンジニア

逆に、なぜ週5勤務であれば生産性と収益性が担保されているのでしょうか。
これはヒトを成果物を生み出す機械と捉えた時に24時間/365日稼働させた方が成果物が多くなるに決まっているという発想からきています。

しかし、それではヒトは壊れてしまうので日本においては労働基準法というもので労働時間の取り決めがなされています。（ただ、これも労働時間と成果物が正比例するような行為... 続きを見る

大橋桃太郎

プロジェクトマネジメント

「プロジェクトリーダーの教科書」おすすめです！

大橋桃太郎

プロジェクトマネジメント

ある種の企業や事業での仕事は、長距離走ではなくインターバル（短距離走×たくさん）だとこないだ感じました。その認識に立つと、休むタイミングが細切れにあったほうが一定期間を全力疾走できるのでよい、んですかね？(笑)

なんにせよ、実験期間を設けてパッと試せる状況をつくりたいですよね

Dai Fujihara

プロジェクトマネジメント

アジャイルコーチとして現場支援をするときに、立ち上がり始めたチームや、まだスクラムが安定していないチームの場合は、まずはベロシティを扱うことが多いです。その場合は、以下のようにしています。

・スプリントごとにベロシティを出すアクションを行う。とりえあず出そうぜ！です。
・次に、ベロシティをグラフにしてトレンドを出し、トレンドをスクラムマスターに解説してもらう。ベロシ... 続きを見る

mizzusano

プロジェクトマネジメント

一人でゼロから何かを作り、リリースして、ユーザに使ってもらうまでやってみるのがお勧めです。
基本的にコードレベルのエンジニアリングの詳細は、エンジニアに任せればよいと思います。しかし、コンポーネントとして何を作る必要があるのか、情報を構造化できてないと何に困るのか、モデルは何を扱うべきなのか、などのシステムの構造や、自分は何をしたくなるのか、という扱いたい情報の概念は大きく変わるものでは... 続きを見る

Masaya Hayashi

エンジニア

ここでいう「観測する内容」にあたるメトリクスの存在は、当日のLTで話した3つの原則のうちの1つであり、重要なポイントの1つです。
メトリクスを利用する際に最も注意すべきなのは、それらを人事評価に直接使用しないことです。

また、エンジニアリングマネージャーの視点から言えば、課題の発見と解決をサポートすることを意識し、EMとしての役割を果たすことが重要です。
... 続きを見る

Offers(オファーズ) 公式

※本投稿は、2023年6月13日に開催されたイベント「開発生産性を高める〜SmartHR、SODAによるチーム起点の取り組み〜（https://offers.connpass.com/event... 続きを見る

pospome

エンジニア

"まず技術を使ってもらうという0→1の部分に関しては比較的トップダウンでやらせているので、特に苦労はないです。

使ってもらった後に学習コストをどう下げるのかという点は、私自身がとにかく手を動かして進めていくタイプなので、他のメンバーも同様に手を動かして、触って覚えてもらうという形を取っていて、ある程度の学習コストはかけてもらう形にしています。

ただ、技術... 続きを見る

嶋田印刷

デザイナー

この質問はよくあり今も昔も多くの人がかかえる、悩みかもしれません。そして中々解決できる問題ではないので、自分の特性と照らし合わせて考えた方が良いです。

シビアですが、状況が変わったら儲かる方に自分を変化させないと、人生は厳しいので成功できないと思います。過去の成功法則というのは、ヒットした好きな事をすると多くの人が既にやっているので在庫損します。

価値観... 続きを見る

tshion

エンジニア

普段Android アプリエンジニアをやっているので、ずれた回答をしたらすいません。

さて本題ですが、この夏に「デザインシステム」を改めて学んでみるのはどうでしょうか？

デザインは、配色ルールやタイポグラフィなどを通じて、統一的な世界観を構築しているかと思われます。
それらを体系的にまとめたものがあれば、個人的にはどうアプリUI として実装して... 続きを見る

和田健太郎

エンジニア

当然ケースバイケースで中身は変化しますが、1on1は月1でやっているので、「長期の成長イメージの具体化」と「そのための今月の動き」をよくテーマにしています。
もう少し具体的に述べると

１．長期（再来年ぐらいまで）の成長イメージの言語化
２．年内の組織成長と個人の役割の言語化
３．今月の役割と目標の設定
４．アクションプランの設定 続きを見る

大橋桃太郎

プロジェクトマネジメント

スキルや他社サービスに関連した興味軸の話題について話しあうことで、目標やスキルに転用できる気づきを得ることが多いなと感じています。そのために興味ある話を、というわけではないですが、なんにせよ話題を楽しんで何かに気づこうとする姿勢が重要かなと思います。、

横江 亮佑

エンジニア

触れたことある分野はまだ、アウトプットからフィードバックのしようがあるのですが、
機械学習エンジニアやQAエンジニアなどになってくると経験がなく難しいですね！
機械学習は短期的なアウトプットが出るものではないのでなおさら、専門外の人が評価しにくいですね。

基本的には、機械学習チームやQAチームを作って、チームマネージャーが評価する、という仕組みを作り上げる... 続きを見る

横江 亮佑

エンジニア

自分の中ではあまり「これ１つ！」というのはなくて、
いろんな本から部分部分を吸収していくといいと思います。

もう１つ大事なのが、他社でマネージャーをやっている方に話を聞くことで、
本からは抽象的なことが学べ、人からは具体的なことを学べるので、両方をおこなうといいでしょう。

個人的なオススメは『人事の超プロが明かす評価基準』という本で、... 続きを見る

横江 亮佑

エンジニア

ネガティブフィードバックを受けたかたが、悪気があっておこなっているケースは0%と言っていいくらいほぼないので、
まずは「○○のときに、○○と感じた人がいるらしい」ということを伝えて、
本人がどういう意図でその発言や行動をおこなったのか伺います。

その上で、○○と感じた人がいることに改めて立ち直り、
どうするとよりグッドだったのか、という話をするこ... 続きを見る

横江 亮佑

エンジニア

評価するのは人間なので、ある程度主観的なのは仕方ないと思います。

https://offers.jp/qa/question/U9EcRZ83wi
での回答のように、職種の職...

横江 亮佑

エンジニア

今回のイベントではフィードバックがテーマでしたので、
1on1の場で評価の話がメインになっているように感じられたかもしれませんが、
実際のところ、将来のことだったり最近元気？だったりの評価以外の雑談も話しています。

とはいえそんな雑談の中でも、フィードバックにつながる発見があったりします。
例えば「最近趣味でWebアプリ作ってるんですよねー」みた... 続きを見る