30人が参加するプロジェクトで桁違いのパフォーマンスを発揮するためのチームデザイン - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。シニアスクラムマスター（初めて名乗った！）の天野 @ama_ch です。開発本部に所属するアジャイルコーチとして、組織内を横断的に支援しています。最近は、 kintone フロントエンドリアーキテクチャ（フロリア）プロジェクトの支援に注力しています。 フロリアプロジェクトの概要はこちらの記事をご覧ください。 blog.cybozu.io 現在、フロリアには約30人のメンバーが参加して日々活動しています。チームの規模が大きくなると、コミュニケーションが難しくなり、効果的なチームワークを発揮するのがどんどん難しくなっていきます。フロリアでは、昨年後半頃からだいぶチームの規模が膨らんできたため、今年からチームを再編し4チーム体制に切り替えました。 今回は、フロリアが数十人規模でもチームワークを発揮するために、チームの設計や運用で意識しているポイントを紹介します。 目指している状態 最
エンジニアの"有害な振る舞い"への対処法 - Qiita
本記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニアや上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40％低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz
チームにいると頼りになるソフトウェアエンジニア
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
Webディレクター解体アドベントカレンダー - 二宮日記
Webサービスのディレクションの仕事を始めてもうすぐ20年経ちます。デザインとコーディングを行う傍ら、自分で企画や進行も担うようになり始めた20年前を振り返ってみると、Webディレクターを取り巻く環境や求められる仕事の内容は大きく様変わりしました。 tableタグを入れ子にして無理くりレイアウトしたHTMLを1ページずつ紙芝居みたいに繋ぎあわせていた時代から、スマートフォンアプリのリッチな体験が当たり前の時代へ。数名のチームで1人が複数の役割をこなしながら素朴にサービスを作ってはリリースを繰り返していた時代から、高度な専門性を持つメンバーで組織化されたチームが開発のフェーズごとに価値の検証を繰り返しながらサービスを作り上げていく時代へ。サービスに求められる品質も、開発者に求められる専門性も、比較にならないほど高度になりました。 ディレクションという言葉で一括りにされていた仕事も同様です。担
共創の前にまず独創 - 西尾泰和のScrapbox
2017年から私たちの会話の中心となったテーマ、それは「コンテストへの応募」についての話です。Twitterで「～に応募したいので仲間を募集！」と書いている人々を目にしたことがきっかけで、この問題について考えを巡らせるようになりました。しかし、その後5年を経て考えるに、この問題はコンテストへの応募に限らず、より一般的な視点で捉えるべきかもしれません。 古いアフリカの諺に、「速く行きたければ一人で進め、遠くまで行きたければ皆で進め」という言葉があります。しかし、この言葉に込められた教訓を適用するには注意が必要です。人数が増えれば必ずしも成功確率が上がるわけではない。チームの一員として一緒に歩む人々を選ぶという行為は、目指す方向性が一致しなければ逆効果になり得ます。そして、それは特にSNSであいまいに「仲間募集」する場合に真実となります。 一人で進むことが困難な場合、その困難さを克服するために
周りが自分より優秀なのは当たり前。「僕なんか」って考えるよりチャレンジングで楽しそうなチャンスを選ぶ - Findy Engineer Lab
オープンソースのCI/CDツールとして広く知られているJenkinsを開発した川口耕介（@kohsukekawa）さんが新たに友人と立ち上げたLaunchable（ローンチャブル）は、データサイエンスの技術を利用したテスト自動化のプラットフォームを提供すると表明しており、開発プロセスの改善をさらに推し進めるスタートアップとして注目されています。 このLaunchableにプリンシパル・ソフトウエア・エンジニアとして参画したのが、庄司嘉織（@yoshiori）さん。ソフトウェア開発者のキャリアを25歳でスタートし、Javaエンジニアとしてさまざまな経験を積む傍ら、若手エンジニアによるjava-jaというコミュニティも取りまとめてきました。 未経験のRubyにチャレンジしようと転職したクックパッドでエンジニアリングマネージャーや人事部長まで務めるなど、複数の領域で多様なキャリアを歩んできた庄司
とある人事部長の後悔を聞いてほしい１（追記あり）
かつて、大手企業で人事部長をしていた。 人事部長という役職名ではないが、似たような名称のポジションだった。 人事の機能のひとつに『処分をつける』というのがある。 問題のある社員への指導教育だったり、人間関係のトラブルに決着をつけたり、罪を犯した人間を罰したりする機能だ。 それに比べれば、勤怠管理だの、給与の支払いだの、社会保険の手続きなどは子どもの遊びに思えてくる。 そんな、面倒くさい問題に10年近く携わってきた。 今でも夢に見る。 後悔がある。どうしてあの時、もっとやれなかったんだろう、やらなかったんだろう。 どうして、あの人の心に寄り添うことができなかったんだろう。どうして、自分の思う正しさを貫くために上位の役職者を説得しなかったのだろう。 そんな後悔を吐き出したくて、はてな匿名ダイアリーに投稿することにした。 事案は４つある。そこまでぼかしてはいない。私自身と向き合うためには、真実を
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
エンジニアアルバイト氏受け入れテクニック - hitode909の日記
いま社員エンジニアが何人かに加えてエンジニアアルバイト2人、くらいのチームで働いていて、その中でアルバイト氏のメンターもやっている。 前のチームでも何年かアルバイトの面倒を見たり、何回かインターンのメンターをやったりしていた。 手癖でいろんなことをやってしまっていて、属人性が高まってしまっていると感じたので、どんなことをやっているか書いておく。 1日に何回か口頭で会話する 実装ができててから方針がまずかった、となると時間がもったいない 方針書いたくらいでレビュー依頼に出してね、とお願いしてもやってもらうの難しいので、こちらから聞きに行くほうがうまくいきやすい レビュー依頼になったらすぐに見る 社員は明日も要るけど、アルバイト氏は週に数回しか来ないので、その日帰るまでにレビュー完了して打ち返しもしてもらえるように動けると良い レビュー依頼になってなくてもPull Request見に行く 方針
エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
