プロジェクトアサイン者との期待値を揃えてみよう！ロールセッションについて徹底解説してみた | DevelopersIO
データアナリティクス事業本部＠札幌の佐藤です。 今回は私のプロジェクトで実際に活用している、各メンバーとの役割や期待値のすり合わせ方法について記載します。 当活用にあたっては株式会社コパイロツトの方にナレッジの共有や、推進方法など相談させていただいたうえで、ルールとして今整備、運用しているものとなります。 ※コパイロツト様に事前に掲載のご了承をいただいているものとなります。 ご協力いただきありがとうございます。 お話の前提 私の案件は小規模（メンバー10人未満）のプロジェクトが多いため、小規模案件での前提として記載します。 また、期間においても3ヶ月程度の短期間の開発プロジェクトを前提としております。 大規模案件・長期間案件・保守案件の場合は必ずしも該当しない観点がある可能性がありますので、あらかじめご認識いただければと思います。 プロジェクトでよくある問題 プロジェクトを実施していく中で
エンジニアが事業を動かすための成果定義とは - Speee DEVELOPER BLOG
※この記事は、2024 Speee Advent Calendar 22日目の記事です。 前日の記事はこちらになります。 tech.speee.jp はじめに 初めまして、2022年度新卒でSpeeeに入社し、現在Housii（ハウシー）という完全会員制の家探しマッチングプラットフォームの開発チームでエンジニアをしている大金と申します。 今回は、自分の実体験を元にした記事を書いてみました。 開発物を日々沢山リリースしているものの、イマイチ「事業の成果」に向き合えていないと感じるエンジニアの方々にとって、少しでも今後の動き方の参考となる記事になれば幸いです。 目次はこちら はじめに なぜか「事業成果」から遠ざかってしまう問題 「価値ある顧客体験」を軸にした成果定義へのアップデート 1. 事業の解像度の向上 2. 施策のプランニング周りの動きの改善 3. 「見るポイント」の変化 「事業成果」に
役割をお願いする時に伝えていること - Konifar's ZATSU
マネジメントを4年くらいやっている間に、何人かにEngineering managerや採用のリードなどの役割をお願いして担ってもらってきた。何か新しい役割をお願いする時に整理して伝えている項目を雑にまとめておきたい。 以下のようなGoogle docsを作って共有し、30分のミーティングで直接伝えて考えてもらうようにしている。タイトルは「◯◯さんにxxをお願いしたい」みたいな感じ。項目や内容は相手によって適宜変えてる。 これは何 「◯◯さんにxxをお願いして一緒にやっていきたいと考えています」みたいな感じでストレートにお願いしたい役割を書く 「命令ではなく、なぜお願いしたいか、何をお願いしたいかなど◯◯さんに意思決定する材料を渡すためのdocsです」のようにまだあくまで提案ですよということも書く なぜ今お願いしたいか プロダクトや組織の状況も踏まえて、"今"お願いしたい理由を書く その役
日本の従業員が｢世界一やる気がない｣本当の理由
各種の国際比較調査から、日本の従業員のモチベーションやワークエンゲージメントは世界最低であることが明らかになっています。しかし、本当に日本人は世界で最もやる気・熱意がないのでしょうか。今回は、この残念な定説の真偽について考えてみましょう（以下、モチベーション＝やる気、ワークエンゲージメント＝熱意とします）。 やる気・熱意が低下傾向にあるのは事実 オランダのランスタッド社の調査（2019年公表）によると、日本は「仕事に対して満足」と回答したのは42％で、34カの国と地域の中で最下位でした。アメリカのギャラップ社の調査（2023年公表）によると、「熱意あふれる従業員」と回答したのはわずか5％で、日本は125カ国中最低でした。他にも、日本のこうした状況を示す調査結果が多数あります。 では、当の従業員はどう受け止めているのでしょうか。大手・中堅企業に勤務する従業員にヒアリングしました。 「以前のよ
管理職とは？ 管理職の定義・役割・なりたくない人のキャリアパターン・メリットを5分で解説 - ミーツキャリアbyマイナビ転職
管理職とは、企業において、部門・チームをまとめ、部下の育成を担う役割。従来、多くのビジネスパーソンにとって、管理職になることは出世と成功への道であり、将来の目標でした。 しかし近年は、「苦労に見合った給与がもらえない」「責任が重くなる」「プライベートの時間が減る」といった理由から、「管理職はコスパが見合わない」「管理職になりたくない」と考える人が増えているようです。将来、今の職場で管理職になるかどうかを迷っている人もいるのではないでしょうか。 今回は、管理職の定義や役割、必要なスキル、管理職になるメリット・デメリットなどの基礎知識を確認したうえで、管理職にならないという選択肢についても考えてみましょう。 ＜INDEX＞ ・管理職の定義 ・管理職の役割と仕事内容 ・管理職に必要なスキル ・管理職に向いている人と向いていない人 ・管理職になるメリット ・管理職になるデメリット ・管理職になりた
何も決定しないクセに「失敗したらお前が責任を取れ！」という管理職は最悪の存在。
思い出すのも恥ずかしい黒歴史の塊なのに、今でもたまに見てしまうネットのページがある。 笑顔の大学生たち、楽しそうに練習する動画などありふれたコンテンツだが、このページを見るたびに恥ずかしくてどうしようもなくなる。 同志社大学のアルティメットチーム「Magic」のツイッターサイトだ。 そして、取り返しのつかない失敗をしたことや寂しさなどが入り混じった複雑な感情がよみがえり、胸の奥が痛くなる。 実はこのチーム。 1992年に私が、友人と2人で始めた小さなサークルだった。 相方の名前を、仙田とさせて頂く。 当時大学1年生だった仙田と私は、とにかく時間と情熱と体力を持て余していた。 大学に入ったはいいが、つまらない授業とバイトとメシを食べるだけで過ぎていく毎日は、退屈で仕方なかった。 大学生らしい無意味な野心や根拠のない自分への特別感もあり、何か大きなことをしたいとバカな妄想ばかりでいつも盛り上が
技術視点の時間軸を鑑みたCTOの役割定義 | F's Garage
最近、ずっと考えてることとして、CTOの役割定義は大切かなと。 IVS CTO Night & day 2018のイベント中で「CTOという肩書はラベルか？」という示唆的な話が出てきていました。 この指摘がイベント中になされたのは、なんどもこのイベントに参加している僕が知ってる限り初めてで、会社のステージの変化に対して、CTOという役割認識においてもフェーズが変化してきたのを感じています。これは言葉を返すと「ラベルだけの存在になるとCTOはいらないかもしれない」という指摘で、組織構造がどんどん変わっていく上で、どういう裁量、責任を持ち続けるのか？を設計しておくことが重要であると考えます。 CTOのイグジットマネジメントや、急に組織が拡大した時に歪を及ぼさない形で組織をスケールさせたい時、はたまたCTOの肩書に流動性をもたせるにあたっても、この辺の考え方をしっかり持っておくのは必要かなと。
命を救うだけが医療の役割じゃない｜守本 陽一
高２の夏に自宅で介護していた祖父が亡くなった。 僕の誕生日だった。 その日、僕はこれまで生きてきた人生の中で、一番泣いた日だった。 なぜ泣いていたのかは今は思い出せない。ただ覚えているのは、僕が朝起きたときにひっそりと自宅で息を引き取ってた祖父の生暖かい手の感触だ。 その感触に祖父がまだ生きているような感覚を覚えた。目の前から大切なものがなくなった喪失感と自分の無力感から泣いていたような気がする。 それから僕は医学部を目指し、医学部6年生になった今年、祖母が亡くなった。 心臓に持病を抱えていた祖母は、肺炎にかかって病院に入院し、２週間後に息を引き取った。僕は死に目には会えていないし、僕が医師になって主治医として診ることもできなかった。 でも祖父のときとは違って、泣くことなかった。 大切なものがなくなったという喪失感と無力感は確かにあった。 実家を離れて暮らしている分、祖父より何かしてあげる
「フロントエンド開発者」の終焉 | POSTD
元記事の著者より：この記事は主に北米文化で私が見たことを反映しています。 誰かに職業をきかれたら、私は「フロントエンド開発者です」と答えます（答えは相手によって変わることもあります）。10年か20年前は、自分の仕事に必然的に伴うものが何なのかは、かなり明瞭でした。インタラクション用にHTMLやCSSを書き、JavaScriptも多少は書いていました。駆け出しの頃、PHPやMySQLの作業に職務の大半を費やしていたとはいえ、フロントエンド開発者として見られる方が好きです（これに関しては、後に詳しく説明します）。この状況は、2010年の初頭に変わり始めました。JavaScriptが、重要で、非常に大きな存在になってきたのです。昨年の初め頃から、たくさんのフロントエンド開発者に会うようになり、あることに気付きました。フロントエンド開発者は、もはや、私が以前から知っているフロントエンド開発者ではな
Selfkleptomaniac — Rails3 + Sorceryで複数のモデル（管理者と一般ユーザとか）を扱う
Blogging is a disease: selfkleptomania, your normal condition. About GPG Public Key Deviseが魔術すぎるので一部のユーザには人気のあるシンプル指向のユーザ認証用プラグインSorceryですが、例えば「管理者」と「一般ユーザ」みたいに複数の種類があるアカウントをそれぞれ別のモデルとして扱うのはあまり得意ではありません。どのウェブアプリケーションでも普通はこれくらいのアカウント種別はあるでしょうし、もし一般ユーザに管理側の機能やアカウントが使えるようになってしまっては困るので、うっかりミスでとんでもないことにならないよう、それぞれ別のモデルで扱いたくなるのは当然です。これが出来ないのであれば、折角シンプルさが気に入ってSorceryを使い始めても、すぐに挫折してしまいます。大変残念です。 でも、まあ確かに得
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
