チーム力向上のためのエトセトラ - Qiita
この半年間、久しぶりに開発チームのマネージャ的な立場もやることになったので、「ふつうの受託開発チームのつくりかた」以来、工夫したことをまとめておきます。「ふつうの受託開発チームのつくりかた」未見のかたはぜひそちらも見てみてください! チームに名前を付ける 私の受け持つチームは伝統的に「ラスカル」の名を付けるようにし、チームのアイデンティティを保つようにしています。チームメンバも本当は出来るだけ長く担当してもらいたいのですが、大きなSIerだとそれが難しいこともあります。 通常のプロジェクトチームだと、サブシステム名くらいで呼ばれることでしょう。これは、そのプロジェクトが終わったらチームも終わり、で帰る場所も無くなることを意味しますし、愛着をもって働くことは難しくなります。 メンバが多少入れ替わっても、チームは継続する"モーニング娘。方式"であれば、またいつか戻ってくることもできるし、OBと
良いProduct Managerと良いTech Lead - ワザノバ | wazanova
http://engineering.foursquare.com/2014/01/30/good-tech-lead-bad-tech-lead/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 A16ZのBen Horowitzが、1996年にNetscapeのDirector of Product Managementだったころに、「Good Product Manager, Bad Product Manager」という名エントリーを残しています。また、これに倣って、FoursquareのJason Liszkaが、「Good Tech Lead, Bad Tech Lead」をまとめています。 自分達のあるべき姿を律するため、かつ、悪い手本にならないようにという自戒の意味をこめて、気に入った
WEBエンジニアがプロダクト開発を通じて学んだチームビルディングに関する5つのTIPS
インタ ーネットの世紀のプロダクト ・マネジャーの役割は 、最高のプロダクトの設計、エンジニアリング、開発を担う人々とともに働くことだ — 『How Google Works』 本記事は Livesenseその3 Advent Calendar 2016 の24日目の記事です。いきなり格好つけた言葉から入ってしまいましたが、クリスマスイブなので。同様に以下ポエミーかつエモ目の記事となります、ご容赦ください。 私は転職会議というWEBサービスの開発に携わっており、2年ほど前から開発チーム（エンジニア/デザイナ/ディレクタの混成チーム）のマネージャーとしてプロダクトオーナー（PLは持たない）兼エンジニアマネージャーのような仕事をしてきました（最近では二足のワラジに限界を感じてプロダクトマネージメントのみに集中していますが）。 本記事では、プロダクト開発に携わってきた中で、グロースに繋がったと思
効率的で課題解決的な態度にひそむ罠について - 下林のエンジニアブログ
この記事は「はてなディレクターアドベントカレンダー」の18日目の記事として書かれました。 id:shimobayashiと申します。数年前からはてなという会社でディレクターという肩書で働いています。コードも書いてますけどね。 今回はディレクターアドベントカレンダーということで、マネージャー的な側面から表題の件について書いてみることにしました。 さて、一般的に効率的であることと課題解決的であることは良い態度とされていると思います。 実際にはこの2つが重なると、現在の課題についてのみ話すようになりがちです。なぜなら、効率的であろうとするほど話題を絞りがちですし、課題解決的であるほど課題について考えがちだからです。会議の場なんかでは顕著ですね。 そうなると「ここがうまくいってないよね」という会話しかせずに「ここはうまくいってるね」という会話はしなくなりがちです。そうした会話が続くと段々と自己肯定
エンジニアが自由研究に時間をかけるべき理由
ここ数年でWebエンジニアを取り巻く環境は劇的に変わったと思う。 具体的に言うと、知的好奇心とやりがいを求めて仕事を選ぶことが当然になったように感じる。 Webエンジニアを取り巻く変化 5年半前、私が新卒で就職した時はまだ、エンジニアでも長時間労働はあたりまえで、エンジニアはビジネスサイドが考えた要件に従ってサービスを実装する人だ、という認識が強かったように思う。 一緒に大学院を卒業した優秀な友人たちはみんなメーカーか大手SIerに就職し、それこそWeb企業を就職の選択肢に入れている人はめずらしかった。 その後、リーンスタートアップやアジャイルの導入によって、エンジニアがサービスを考えて、実装・リリースし、データを取り、そのデータを元にまたサービスを改善していくことが当然となり、エンジニアという仕事はよりクリエイティブなものとなった。 また、オープンソースのプロダクトは当然のように色々なサ
「ボトムアップの見かけはとても重要」 - ninjinkun's diary
この記事はProduct Manager Advent Calendar 2日目の記事です。 先日Japan Product Manger Conferenceに参加して、ポケモンGOの開発元であるNianticでPMをされている河合さんのセッションの中で印象的な言葉があったので書き留めておく（セッションの詳細はプロダクトマネージャーに必要な資質って何ですか？ 元グーグルのPM対談 | HRナビ by リクルートで読める）。 会場からの質問で、「開発者に仕事を任せる際に、上からやることをお願いするトップダウン型と、開発者が自発的にアイデアを出してくるボトムアップ型があると思うが、どちらがいいと思うか」（うろ覚えだけど、だいたいこんなニュアンスだったはず）という質問に対し、河合さんは一呼吸置いてから「ボトムアップの見かけはとても重要」と回答されていた。 これはPMの中では既に実現方法（おそら
わたしのバイモーダル戦略 : 小野和俊のブログ
このところ知人からよく、「小野さんはプログラマーから経営者になった」と言われる。これはまさにその通りで、かつてソースコードを美しくリファクタリングすることに情熱を燃やした私は、いまは組織をより良いものにしていくことに情熱を燃やしている。つまりリファクタリング対象がソースコードから会社に変わったのだ。 そんな私が今やや苦戦しつつもやりがいを感じて取り組んでいるのが、「2つの異なる文化の共存協調」だ。具体的には、大企業的な文化とベンチャー的な文化を共存させ、かつ協調させようにしようとしている。ウォーターフォール的な文化とアジャイル的な文化の共存協調、と言い換えることもできるだろう。 アプレッソでかなり自由にやってきた私にとって、当初、セゾン情報の動き方は不慣れであり、また動きが遅く感じることもあった。だが少しすると、こうした動き方や文化にも相応の合理性があり、アプレッソで取り入れることが望まし
セルフマネジメントの必須スキル「タスクばらし」そのポイント | Social Change!
私たちソニックガーデンでは、指示命令のマネジメントを捨て、メンバーそれぞれが自分で考え自律的に行動することで、高い生産性を発揮しつつ様々な変化に対して柔軟に対応できる組織づくりに努めている。 そんなメンバーたちに求めるのはセルフマネジメントができることだ。セルフマネジメントができるために身に付ける素養は少なくない。しかし、セルフマネジメントを身につける最初の一歩は何かを聞かれたら「タスクばらし」だと答えるだろう。 本記事では、セルフマネジメントをマスターするための最初の必須のスキル「タスクばらし」について紹介する。 「タスクばらし」とは 「タスクばらし」とは、読んで字のごとく、仕事をタスクにバラすことである。仕事に取り掛かる前に、その仕事の要素を分解し、どのように進めるか道筋を立てることで、どれくらい時間がかかるか、リスクは何か、見通しを得ることができる。 当たり前のことだと思っていたが、
ペロリ流 開発要件のまとめ方 - peroli Developer's Blog
2016 - 07 - 22 ペロリ流 開発要件のまとめ方 開発プロセス list Tweet こんにちは。開発部のマネージャーをやっている mizushimac です。 今回は開発するモノの要件のまとめ方についてペロリ開発部が実践している内容を少しご紹介したいと思います。みなさんの会社やプロジェクトではどうやって開発するモノの要件をまとめていますか？ パワポ ですか？ spreadsheet ですか？ 流れ行く slack や github issue で議論しながらコメントに埋もれていき誰かが箇条書きでまとめますか？ きっとカオスなことが多いかなと思いますのでこのエントリーが少しでもご参考になればと思います。 ちなみに、ペロリはカオスを楽しめる人を求めていますw 開発要件のまとめ方って色々あって難しい 私が学生の時に所属していた ベンチャー企業 では、数十MBもある パワポ に画面イメ
プロジェクト・マネジメントの目的とは何か | タイム・コンサルタントの日誌から
中堅エンジニアが壁を破って成長するには、何を学ぶべきか。そういう問いに関連して、ここ何回か書いている。初級の仕事を一通りおえて、とりあえず一人前のことはできるようになっても、その先にしばしば壁がある。そこを乗りこえて面白い仕事をしていくためには、もう少しマクロにものを見て、人を動かせるようになっていく必要がある。 今年の1月に、静岡大学と浜松ソフト産業協会の共催によるプロジェクト・マネジメント講座に呼ばれて、初日の講師を務めさせていただいたときも、その話から始めた。集まった方はほぼ全員がIT技術者だった。IT分野は勉強会も盛んで、知識欲に燃えた熱心なエンジニアも少なくない。わたしはたずねた。 「この中で、現在プロマネの仕事をされている方はいらっしゃいますか？」 手を上げた方は全体の1/3もいなかった。ある意味、予想通りではある。プロマネの仕事をばりばりこなしている人は、こうした講座を聴きに
GitHub のプロジェクトなどから学ぶ、サイドプロジェクト成功のパターン
ビジネス上のプロジェクトの成功法則やマネジメント方法は様々な形で語られています。一方で、主に余暇の時間で行われる技術的なサイドプロジェクト（ソフトウェア、ハードウェア含む）に成功パターンはあるのでしょうか。 最近では定量的なプロジェクトの分析を行うために GitHub のプロジェクトのデータを使おうとしている動きがあります。もちろん GitHub を使った研究はあくまでソーシャルコーディングのプロジェクトをスコープとするものですし、一部は因果関係というよりも相関関係でしかありませんが、知見として活用できる部分もあると思うので、GitHub の研究や私個人の経験を通して見てきたサイドプロジェクトの成功パターンをまとめてみたいと思います。 以下では大きく 3 つに分けて解説します。 チームアイデアとテーマプロセス 1. チーム最初に残念なお知らせです。どうやらプロジェクト内部の仕事の多くは少人
Flyspray : Flyspray: The bug killer!
Flyspray is a lightweight, web-based bug tracking system written in PHP for assisting with software development and project managements. Originally developed for the Psi XMPP client project it has been made available to everyone under the LGPL 2.1 licence. Flyspray aims to cut out the unnecessary complexity of other bug trackers focusing on a very intuitive design making it very easy to effectivel
ソフトウェアエンジニアリングにおける認知バイアス5つ | POSTD
人間の論理は、私たちがプログラミングして毎日使っているマシンの論理とは違って完璧ではありません。人間は間違えますし、悪い精神的習慣を確立してしまいますし、エンジニアとして成功するための能力に悪影響を及ぼす認知バイアスをたくさん持っています。ソフトウェアエンジニアとして定期的に目にする一般的なバイアスのうち5つを見ていきたいと思います。 1. 根本的な帰属の誤り 根本的な帰属の誤りは、個人の行動を説明するにあたって、気質的または個性的な面を重視しすぎて、状況的な面を軽視しすぎる傾向を言う。対応バイアスとも。 （参照） これは私のお気に入りの認知バイアスです。”至る所で”見られるからです。道で誰かに行く手を遮られると、その人を完全に嫌なヤツだと思ってしまいますが、自分が同じことをしてしまう時は、相手が見えていなかったとか、会議があって遅刻できなくて急いでいたといった理由があります。誰かがバグを
マネジメントで意識していたことを書いた - tehepero note(・ω<)
2014-02-07 マネジメントで意識していたことを書いた エンジニア 考え方 ここ半年くらいはAmebaで一兵卒としてチョロチョロしてる自分ですが、最近色んなプロジェクトのアレコレを見ていて色々と思うところがあります。 半年くらい前までは自分もサービスを持ってたので、マネジメント・ディレクション周りで意識していたことを書きます。 教育と裁量 自分のチームには12新卒が2名いたんですが、全てを与えず、とにかく課題を与えて常に思考する癖をつけさせるようにしました。一人にはリリースコントロール（機能開発の主導、ブランチの運用、リリース作業）を、もう一人にはサービス間連携（関係者との調整含む）をと、割と重要なミッションを課しました。とにかく自己学習ではなかなか経験できない仕事は任せた方が良いかなと。 健康管理 風邪ひいてる、その兆候があるメンバーは基本的にさっさと帰らせました。あと、ちゃんとマ
どうすれば小さなチームでも大きな成果を出せるのか
スクーの授業で使った資料です。 ソフトウェア開発をしていく中で、沢山のリソースやお金をつぎ込んで開発するのではなく、どうすれば少人数のチームで低コストな中で開発を続けていくことで、大きな成果を出す為の考えかたについて説明しています。Read less
プロジェクトがスムーズに進むために心がけている7つこと - ヴェルク - IT起業の記録
個人的には、「こうすればうまくいく」的な方法論は好きではなく、プロジェクトはそんなに単純な話ではないと思っています。もちろん、最低限の知識としての方法論は必要ですが、それが解ではないかなと。 そこで、今回、僕が気をつけているポイントを書いてみたいと思います。 プロジェクト開始時の整地 ヴェルクでは、僕がプロマネに入っているプロジェクトにおいて、事細かに進捗を管理したりメンバに報告してもらったりはしていません。そんな時間がないという事情もありますが。お客さんとの窓口以外は基本的にメンバーに任せています。 ただ、任せる前に必ず「整地」をするようにしています。 お客さんとの関係や意思疎通、技術的な課題や難易度が高いもの、要件がぶれそうなところや膨らみそうな点を整理しておきます。もちろんメンバーに任せる時点で全て解決していれば良いのですが、そうもいかないので、これらの懸念を共有しておきます。 これ
Redmineを全員で使ったらカオスになった話
タスク管理のツールとしてオープンソースのRedmineを使っていた。エンジニアだけで使っているうちは特に問題はなかった。エンジニアが10数名、全員でも40人規模の会社なので全員の作業を見える化したいよねという話が上がって全員でRedmineを使い始めることになった。そして何が起きたか。 プロジェクトが乱立した エンジニアであれば「プロジェクト」は単位は大体想像がつくと思う。しかしながらツール上ではその単位でプロジェクトは作られなかった。「正規のプロジェクト」の小規模な機能追加であっても「○○対応プロジェクト」と銘打たれツール上にプロジェクトが作成された。 「〜対応プロジェクト」「〜導入プロジェクト」「〜検討プロジェクト」「〜プロジェクト」・・・どんな言葉にもプロジェクトを付ければ”プロジェクト”にできるんだということは新鮮ではあったし、勉強にもなった。（そもそも”プロジェクト”って何だ？）
インクリメンタル開発のメンタル面の効用
私はソフトウェアの開発においては、インクリメンタルに進めることを重視しています。インクリメンタル開発の重要性については多くの方が既に指摘しています。曰く、 プロジェクトを部分に分けることによりリスク管理がしやすくなる 同じくスケジュール管理がしやすくなる。 設計の妥当性を早期に確認でき、アーキテクチャ変更の見通しが立てやすい などなど。 いずれも妥当な意見だと思いますが、メンタルな要件も上記と同じくらい重要ではないかと考えています。つまり、インクリメンタル開発では具体的な成果を小出しに出して評価していきますが、これにより開発意欲が湧き、維持するという側面が重要だと考えています。 その説明のために仕事における実例は紹介できませんので、その代わりに、私が手がけた「最初のインクリメンタル開発」の事例を紹介することにしましょう。 私が小学校５年生の時でした。私の父がオートバイの大きなプラモデルの箱
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Taiga.io
