"組織/チーム体制"投稿一覧

大橋桃太郎

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

PMです！最近導入をはじめたばかりなのですが、ストーリーポイントの意識はあまりしていないです。もっぱら推進サイクルに乗せられるように頑張るぞというところで、担うタスクが多すぎる弊害かもしれません。が、デザインに関しては手を動かす作業の比率が多い役割でもあり、スクラムに添える自分達のスキームをみつていったほうがいいかなあと課題にかんじはじめています

大橋桃太郎

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

（前提とされているように程度問題はあると思うのですが）例にあげられているようなケースであれば、 "未知に触れる機会" と捉えて糧にできるか、が重要に思います。不確実性を楽しめる能力といったところでしょうか。まずそう思ってみるところからしか拡がらない可能性がありますよね！

和田健太郎

エンジニア

世の中あらゆる場所で同じような疑問を持っている方がいるんだなと思い若輩ながら回答させていただきます。

個人的な見解としては、価値観のすり合わせ、というのは組織のマネージャーと現場との間のコミュニケーションの深さで解決するしかないだろうなというところです。

カルチャーマッチはそうなんですが、組織の価値観にピタリ一致する人を全世界から必要人数かき集めてくる、... 続きを見る

大井竹昭

データ分析

データの利活用を中心としたコンサルをやっております。

マイクロマネジメントにならないようにするには、信用することです。

指示としては、アウトプット像、その為のアウトカム例を明示することです。
それだけで不穏な顔をする人には、実現方法をアウトカム例を実演してみせるになります。

アウトカムの実現方法は同じやり方をなぞっても良い... 続きを見る

大井竹昭

データ分析

データ利活用を中心としたコンサルをやっています。

「ITの知識がない人に、業務システムの開発」は難しいと記載いただいています。まさにその通りです。

ですが、『業務を知らない人に、システムを作ってもらう』のも正直手戻りが大量に発生します。予算や開発期間がかなり余裕を持たれている場合にはそれも良いでしょうが、実際のプロジェクトでは責任を問われて外されるのがオ... 続きを見る

Miyashita

エンジニア

まずはChatGPTの有用性や可能性を話して、ChatGPT賛同派を増やす活動をしています 笑
ちょびっとだけ触っただけだと「こんなもんか」と否定的に捉える人も多いので、味方を増やしています。

ABEChan@iOS/Android Developer

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

とりわけ「エンジニアチーム」という所に絞られた話かもしれませんが、「開発チームの「コンポーネント」として機能し、特定の職能にのみ寄与した働き方をしている」に近い話で、それぞれのチームやプロダクトに共通コンポーネントと言われるものがエンジニアリング観点でも含まれる場合があります。
例えばプロダクトAとプロダクトBの認証基盤はおおよそ同じ仕組みを利用しているため、開発者は両方のチーム自体に所... 続きを見る

北野勝久

エンジニア

私たちの会社でも10%ルールとしてゴキゲンチャレンジという制度を運用しています！金曜日午後の時間を開発本部全体でおさえる運用をしているので、普段関わりがないチームの人といっしょに仕事する機会なんかにもつながっています。

「新しいことをみんなに気軽に試してほしい」という文化をつくりたいと思った場合に、「そういう方針・標語をどこかに打ち立てる」という選択肢もありますが、まずはみん... 続きを見る

杉田大樹

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

マネジメントする組織のメンバーがある程度自律して任せられる状況であれば、おおまかな目指しどころと推進イメージをインプットして任せてしまいます。（何かあったら責任はこちらで取るので思うままにやってみてほしいと伝えます。）
一方メンバーの構成要素の中でまだ未熟なメンバーの割合が多い場合はある程度マイクロマネジメントにならざるを得ないなと感じております。（タスク化を一緒にやる、悩み相談などのフ... 続きを見る

Taketo Yoshida

エンジニア

私の所属している会社にもあります。だいたいはe-learning（最近だとML）のビデオ見たりしてますね。自分の仕事では使わないところを勉強してます。

まきやま

エンジニア

まさに20%を採用しています。
時間を取って取り組むべき負債解消や、エンジニア個人のWillを実現する仕組みという位置づけになっています。

私が取り組んだものではありませんが、アプリのウィジェット対応などもこの仕組みから生まれていたりします！

厳密に20%という計測などはしておらず、プロジェクトのチケットと自身のベロシティを踏まえて自主的にやる... 続きを見る

山本隼汰

エンジニア

現在、検証中のものになりますが、以下の様なデザインをしてます。
弊社は小規模のスタートアップのため、個々人が余計なことを考えず、最大限ポテンシャルを発揮できる様にデザインしてます。

【ざっくりいえば】
入社半年後のOKR決めて、入社３ヶ月後、１ヶ月後のOKR決めて本人と合意する
1on1 や個別の会議で、OKR 実現のための振り返りとアクションア... 続きを見る

山本隼汰

エンジニア

あまり積極的に活用できてる感はないのですが、以下の様なことはすでにやってます

・copilot 導入
・ChatGPT でドラフト版の記事作成（ブログ等）

山本隼汰

エンジニア

マネジメントしようとしないことでしょうか。変に力が入ってしまうとマイクロマネジメントになってしまうし、ぼーっとしてると放置・放任してるだけになってしまうため、ある程度、細部については無関心になりつつ、自分が相手に期待するゴールイメージを明確に持っておくことが重要かなぁと思ってます。（「うまく行った時のビジョンが見えているか」を自問自答しています）

そうするために、「最悪ここま... 続きを見る

tomo

エンジニア

20%ルールとはちょっと違うのですが、似たような感じで、チームが直接業務以外のことに時間を使って、
新しい学びを得るなど、自己・チームの成長や未来への投資になるようなアクティビティは他にも色々あります。

- ハッカソン
- ボランティア コーディング
- 自己学習の日
- 修正タイム(バグ、リファクタなど)
- ハックアワー(... 続きを見る

Dai Fujihara

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

僕の場合は、マネージャになって、なんでもかんでも自分がやるには限界を感じたので、チームが自律して動ける方法を考えるようになりました。社会人であれば自立しているはずなので、個人やチームでの自律を目指します。

自律を促すためにポイントのひとつが、インプットとアウトプットです。

たとえば、インプットとして、こちらが相手に期待するものを伝えます。それはふるまいか... 続きを見る

大橋桃太郎

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

本当に難しすぎるんですが、一つの論点に対してスライド5枚くらいでまとめとにかく簡単にわかりやすくすること、詳しくするのは階層深くするイメージで、最初の5枚のうちの１つをさらに5枚にわけて細分化する、のような感じで情報を絞ることを意識しています。

口頭でも何度も何度も繰り返し必要だと思いますし、徹底的にわかりやすくすることと何度も繰り返す前提でいること、ですかね、、！(難しいで...

makoto tanaka

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

こちらでも回答してるのですが、ドキュメントと動画をベースとし、全社・事業部・メンターのような形で進めていきます。

https://of... 続きを見る

Dai Fujihara

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

自分は3ヶ月に1回、会社のOKRなどがでてくるタイミングで、チームレベルのAll handsをやっていました。

・どんな資料にまとめているか
会社の方向性がでたりアップデートされた時点で、チームレベルの方向性をさだめる資料を作っていました。

・どうやってまとめて伝えやすくしているか
ビジネス ＞ プロダクト ＞ 開発・・・というような... 続きを見る

Dai Fujihara

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

一番成果が出た方法を思い出してみるとこんな流れでやってました。

1. 今のオンボーディングにかかっている時間を計測する（チームに入ってタスク完了できるようになるまでの時間）
2. 今かかっている時間の半分以下を目標に立てる
3. 半分以下にするための施策を打ち出して実行する
4. 定期的に振り返る

とくに、2が重要で、10％... 続きを見る