"コミュニケーション/チームビルディング"投稿一覧

kentaro haneda（jumbo）

エンジニア

何を解決する・実行することを期待役割とするかだと思います。
例えば「現場課題をテックリード的に解決する・ソリューションを一緒に考える」「経営に入り課題の言語化や議論に参加する」などで報酬体系や契約は大きく違ってくると思います。

佐々木多生

エンジニア

相場とか特に無いと思います。月数百万取る人もいれば、数万でやる人もいます。
要はクライアント企業にとってどれだけの価値を感じれるか？だと思います。

kentaro haneda（jumbo）

エンジニア

チームの習熟度や設計、再利用可能なコンポーネントの量次第かと思います。
コンポーネント思考な仕組みを使わないよりはUIの再利用性を高く実装できるというメリットがあり、作りやすいとは個人的に思いますが、大きくコスト削減ができるイメージはないです。
むしろケースによっては冗長に実装しないといけないケースもあるので、実際に担当するフロントエンジニアと効果についてしっかり詰めて議論した...

KAWASHIMA Yoshiyuki

エンジニア

レビュワーの認知負荷を軽くするのが優しさだと考えています。
認知負荷を軽くするには、コード変更量よりも、コードの変更理由が一つであることが望ましいと思っています。
既存の設計上の課題のため、変更理由が一つであってもたくさんの差分が発生するケースはあり得ますが、それは1つのプルリクエストである方が認知負荷は軽いと判断しています。

またどんなに少ない変更量であ... 続きを見る

tamura naoki

エンジニア

私も未経験独学でエンジニアに転職しました。
五年以上も前なので参考になるかわかりませんが、、、。

フロントで受託開発の案件があったので以下のようなことをしていました。

スマホアプリ開発案件
・テストをメインに実施
・バグがあれば修正→PR

WEBサービス開発案件
・軽微な修正
・追加...

kentaro haneda（jumbo）

エンジニア

いろいろやってみましたが愚直に直接話すしかないかなと。
1on1やランチ、飲み会などをしてオンライン・オフラインでもカジュアルに話せる場所を設けるのは大事だと思っています。定量や定性でも成果や効果を出しにくいところではありますが、だからこそある程度コミュニケーション施策はやっておいて損はなと思います。

小西裕真

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

ドラッガー風エクササイズをするのはおすすめです。
https://www.agile-studio.jp/post/apm-drucker-excersize...

櫻井隆太郎

エンジニア

NodeJs歴5年以上です。

結論から言うと、両方あると思います。
ただ、NodeJsはバックエンドが主戦場の言語であるため、バックエンド開発が多いかと思います。
フロントサイドはNode以外にJavascritpベースのFWである、ReactやVue、古い環境ですとjQueryを採用した事が多いです。なので、フロントは別の言語、もしくはJSベースのFWで... 続きを見る

Shun

エンジニア

フリーランス2年ほどやっていたものです。
このOffersにも機能としてありますが、各社サービスの時給診断をしてみて、仮に「5000円/時間」となった場合はあなたの「希望時給」として伝えてみるのはいかがでしょう？？
決定するのはクライアントになりますし、クライアント側のお財布状況をフリーランサーが把握するのは難しいです。（資金調達後だけど、採用戦略やリソース分配の計画まではグロ... 続きを見る

kentaro haneda（jumbo）

エンジニア

なりたての頃は「自分がマネージャー1年生であること」というのを日々意識していました。
故に

・学ばないといけないことは当然多い
・失敗も見越してリスクとして取り扱い、相談・共有をたくさんする
・マネジメントもタスクとして向き合いスループットを上げる

ことを意識していました。
期待値が高い役職ですが、自身の目線や水準...

セーヤン

エンジニア

働きやすさに加えて働きがいのある環境を作ることに意識を向けています。
メンバーとのコミュニケーション（近況や今後のキャリアの話）や実際の業務での活躍を観察して、それを基に個人、チーム、そして会社全体の成長を加速させるための施策を検討し実行するようにしています。

新田智啓

エンジニア

課題解決だけでなく、チームがどのような状態になると良いかというビジョンを持つことです。

タスク管理や人の感想ばかりを伺っていては理想の状態に辿り着くことは難しいです。
チームとしての理想を定義し、半年先、１年先のチームの良い状態に向けて日々の活動をしていくことです。

EMが管理する必要のなく、自分たちで自分たちを管理して、より良い状態を探し続け... 続きを見る

飯野博勝

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

抽象的ですが、
毎日のルーチンを決める。
週次のルーチンを決める。
声がけコミュニケーションを意識する。
メンバーが何をしているのか？知る。
進捗確認は、当然ですが、課題解決に意識する。
ですかね。

北野勝久

エンジニア

スクラムにおけるプロダクトオーナーだと理解して回答をしますが、プロダクトオーナーの役割は「プロダクトの価値を最⼤化」することで、スクラムにおけるイベントは、スクラムが重視する「検査」「適応」「透明性」の3つの価値観を体現する場です。
この2つの視点から考えていくと、私なら、以下のようにプロダクトマネージャーに提案すると思います。

## スプリント内で実施するもので必... 続きを見る

Kono Naoko

デザイナー

客先との会議はONにしていますが、社内MTGはOFFでOKです。
オフショア開発の場合は、回線が重くなって、画面共有が厳しいです。

Dai Fujihara

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

こんにちは。最大50人のチームを見た経験がもとになりますが、地味ですが1on1が一番よかったきがします。ただ、1on1をはじめるときに、オリエンテーションとして

1. 1on1をやる意味や期待
2. メンバーに期待すること
3. 私に期待したいこと

を行い、第1回目はお互いにわかり合う目的もあって必ず「あなたの好きなものと嫌いなものは... 続きを見る

Shinichi Kogiso

デザイナー

スクラムでの例ですが、雑談が少ないとなったときに同期で「雑談時間」というMTGを開催する例がありました。ただ、基本的にオンラインではあまり良質なコミュニケーションが取りにくいので、数ヶ月に1回ぐらい同期的に飲み会などのイベントを設けることでコミュニケーションを活性化しています。

大橋桃太郎

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

テキストでコミュニケーションをとる場合、高度な構造化が求められると思っています。
得意な人は、構造化能力が高いかどうかだと思うのですが、得意不得意以上に、テキストでよい状況と、会話が良い状況があるかなと。（会話と違って、受け手が受け取っているとも限らない）

特に、共有レベルのコミュニケーションならまだしも、意思決定が必要な会話は非常に困難ですよね。
続きを見る

Shun

エンジニア

チームメンバーとの人間関係構築の状態問わず、まずは「なぜ導入するのか、導入することでどういった嬉しいことが起きるのか」をまず共有し納得してもらうことだと思っています。現状のプロジェクト進行やスループットに対する課題も添えるとメンバーも課題感を持ってくれると思います。

納得されたのであれば、「ではどんなことに気をつけ、どう動くべきなのか？」と言うフェーズになるのでそこでアジャイ... 続きを見る

横江 亮佑

エンジニア

たしかに Git を学びたてだと、
GitHub や GitLab が Git の派生バージョンなのかと感じてしまいますよね。

GitHub や GitLab は Git の派生というわけではなく、
Git を使ったチーム開発をよりおこないやすくするための Web サービスのお名前ですね！

Git のようなバージョン管理システムは、手... 続きを見る