タグ

チームとエンジニアに関するbraitomのブックマーク (16)

  • 早くチームにマッチするために気をつけてる事 - そーだいなるらくがき帳

    新入社員として1週間が過ぎた。 ブルックスの法則的に考えても私はまだチームにとって生産性をマイナスさせる存在でしかない。 ブルックスの法則 - Wikipedia だからいち早くチームにとって必要な存在になる必要があるし、そのために気をつけてる事をメモする。 これを見て「もっとコレした方がいいよ」ってアドバイス、逆に「それは不要だよ」ってアドバイスを期待してる。 チームやプロダクトを好きになる これはとても大切なことだ。 嫌いな人とは仲良くできないし、嫌いなプロダクトは育てれない。 もし、コレを読んでる人が職場のチームもプロダクトも嫌いなら転職した方がいい。 ただ好きの反対は無関心なので無関心の場合は条件付きでやっていけると思う。 この辺の話は主旨が変わるのでまた別の機会があれば話したい。 コミュニケーションについて 新しいチームに合流してまず一番大事なのはコミュニケーションコスト。 自分

    早くチームにマッチするために気をつけてる事 - そーだいなるらくがき帳
  • フロントエンドエンジニアがサーバーサイドエンジニアとペアを組む話 - Qiita

    この記事は freee Engineers Advent Calendar の1日目です。 こんにちは。freee株式会社でフロントエンドエンジニアをしている @ymrl です。freeeでは給与計算freeeの開発をしています。 僕はフロントエンドエンジニアを名乗っていますが、実際はサーバーサイドの開発もしています(freeeではフロントエンドとサーバーサイドの担当に線引きをしていません)。しかし自分としてはフロントエンドのほうが得意だし、UIを作るのが心底楽しいし、サーバーサイドに比較的苦手意識を持っています。 今日はそういう状態の僕が、どういうふうに開発しているかという話をします。 技術に自信がないのでペアを組んだ 給与計算freeeの開発チームでは、ひとつの機能を開発するときに エンジニアのペア制 というのをとっています。 かつて僕が給与計算freeeのチームに異動してすぐの頃、僕

    フロントエンドエンジニアがサーバーサイドエンジニアとペアを組む話 - Qiita
    braitom
    braitom 2016/12/03
    “フロントエンド開発中心の人とサーバーサイド開発中心の人がペアになってひとつの機能を開発することで、お互いが得意な部分を担当しつつコードレビューをし合う体制”
  • はてなの技術組織2016 - Hatena Developer Blog

    この記事は、はてなエンジニアアドベントカレンダー2016の1日目の記事です。 8月よりCTOになりましたid:motemenです。たいそうな肩書きがつきましたが、引き続きチーフエンジニアという役職も兼任しており、これまでどおりアプリケーションを書きつつ、技術組織の開発・改善をおこなっています。 せっかくの機会なので、このエントリでは現時点でのはてなエンジニア組織の概観と取り組みを紹介しようと思います。 技術グループ はてなにおいてエンジニアと呼ばれる職種の人は、それぞれが提供するサービス(ウェブサービス、スマートフォンアプリ、インフラなど)を軸とする開発部に属しつつ、職能を軸とした横串の組織である「技術グループ」に所属する、という形態を採っています。現時点で、ここに属するのは40名強になっています。 会社を駆動させていくお金を生み出すのは造られたシステムであったり、営業活動であったりす

    はてなの技術組織2016 - Hatena Developer Blog
    braitom
    braitom 2016/12/02
    専門職10%ルールいいな。
  • チームで仕事をすることについて

    こんにちは、 Kaizen Platform, Inc. に入職して 1 年 3 ヶ月の Hitoshi Nakashima と申します。普段は福岡市で生活しており、遠隔にて就労しております。小社ではウェブアプリケーションエンジニアとして勤務しており、主に Ruby on Rails で構築されたウェブアプリケーションの開発・保守を行っています。最近では Kaizen Chat と呼ばれる Kaizen Platform ユーザー向けの Chat ソフトの開発に関与しました(小社製品をご利用の皆様でまだ Kaizen Chat をお試しいただいたことがないという方がおられましたら是非一度お試しください)。 個人では年に一度(主に年末)、失敗談や暗い話をブログに投稿してソーシャルネットワークの耳目を集めることを主な活動内容としております。 今日は最近のチームで仕事をすることについて話したいと

    チームで仕事をすることについて
  • Nuxt.jsとFirebase/Firestoreで動的コンテンツをPWAする | SCOUTER_Engineer

    At Wantedly, we connect talents with companies that believe in your passion and values. See a company you're interested in? You can make a casual visit to to the office to find out more!

    Nuxt.jsとFirebase/Firestoreで動的コンテンツをPWAする | SCOUTER_Engineer
    braitom
    braitom 2016/10/03
    モチベーションとアウトプットを最大化するための方法。「Will Can Must」の3つをコントロールするのを意識することが大事。自由研究の時間はこの3つのバランスを調整する時間とのこと。
  • 僕が考えるチーム開発の効率化 | srockstyle

    フリーランス時代は時間単位でのコミットで、かつ短期集中型で半年続くかどうか、場合によっては1ヶ月で終わるみたいな感じだったので、総合的にチームの開発の最適化みたいなところは考えることはあまりなかった。 一方で「こここうすればもっと楽なのになあ」というところはたくさん発見できて、それはそれでとてもポジティブなだった。 現職では当にチーム開発で、僕はSREという立場でみんなのイテレーションをサポートしていく立場。長期的にみて「こうじゃないと僕が過労死する」みたいな個人的な気持ちと「これこうしないとマジでプロダクトやべーじゃん」みたいな危機感が同時に沸く事が多い。そうなると改善に時間をかけたくなる。 具体的に何やったかは現職のエンジニアブログに書いたし、11月に登壇が決まっているPHPcon2016で話す予定なのでここでは省いとく。どちらかというと僕がいろいろ考えてて見出した質みたいなの書き

    braitom
    braitom 2016/10/02
    なるほど。 “僕が考えたチーム開発効率化の本質は以下の三つだ。 素早くリリースできて Pull Requestが増えても少ない時と時間は変わらず 自分たちの負荷をさげることができるか”
  • 自走するチームづくりをサポートするときのパターンぽいもの - Mitsuyuki.Shiiba

    プロジェクトデザインパターンを読んだ。内容は企画に携わる人向けなんだけど、ちょっと言葉を変えると、エンジニアとしても「わかる!」って感じで読んでてワクワクした。良かった。 ということで「そういえば、チームづくりのサポートをするときに、ある程度パターン化してるものが僕の中にもあるなー」と思ったので、それっぽく書いてみる。 立ち止まる時間 やることが多すぎてチームが疲れている。 その状況において 少しでもタスクを早く終わらせてチームに余裕を作りたい!と、手が空いたメンバーに対して五月雨式にタスクをアサインしていると、メンバーは終わりが見えなくて疲弊してしまう。そして、効率良く作業をするほうが損をしているように感じてしまう。 そこで 5または10営業日の短い期間で区切り、その期間で終わらせるタスクを前もって共有しておく。その期間の終わりにはチームで時間を取って、何を終わらせることができたかを振り

    自走するチームづくりをサポートするときのパターンぽいもの - Mitsuyuki.Shiiba
    braitom
    braitom 2016/09/22
    「指示を受けて動くチーム」から「ビジネス視点を持って自走できるチーム」になるためのポイントがまとめられている。
  • 世界各国から91名30チームが参加! メルカリ初の大型ハッカソン「Mercari Euro Hack 2018」 - mercan(メルカン)

    昨年エンジニア界隈で好評を博した伊藤直也氏(現一休CTO @naoya_ito)がホスト役を務める #naoya_sushi にメルカリCTOの柄沢聡太郎(@sotarok)が登場してから約一年。 mercan.mercari.com 後編では遂におsushiが。二人の話は盛り上がり、両社のプロダクトチームの話に話題が移っていきます。 両社のプロダクトチームの違いとは? sotarok 一休はどういうプロダクトチームなんですか? エンジニアが結構役割を兼ねてるって話がありましたけど。 naoya 基はあまりロールは分かれないです。チームごとに見てる領域が分かれている程度。企画とかプロダクトマネージャーといったロールがないっていう方がわかりやすいかな。 sotarok それはメルカリとすごく違うところですね。 メルカリはまず一つのプロジェクトの中にプロジェクトオーナーがいて、それがエンジニ

    braitom
    braitom 2016/09/22
    "コミュニケーションのためのオフィス内導線には個人的にこだわってて、僕の中で信念があるんですよね。会社づくりの中で最も大事だと思うことのひとつ。"
  • Qiitaのスライドモードは、mizchiが勝手に作った!?─Incrementsの縛られない開発スタイルを聞いてみた

    Qiitaのスライドモードは、mizchiが勝手に作った!?─Incrementsの縛られない開発スタイルを聞いてみた 馬場 美由紀(HTML5 Experts.jp編集部) 及川卓也さんや田中洋一郎さんをはじめ、著名なエンジニアが次々と入社していることで話題のIncrements。8月にはさらにCSSのコードフォーマッターであるStylefmtの作者・morishitterこと森下雅章さんを迎えるなど、さらに開発陣営を強化しています。 今回はさっそく森下さんにも加わっていただき、白石俊平編集長を聞き手に、CTOの髙橋侑久さん、フロントエンドエンジニアmizchiさん、デザイナーの東峰裕之さんに、「Qiita」の開発環境や開発スタイルなどについて聞いてみました。 特定領域でとんがってるスペシャリストが増えてきた 白石:まずは、自己紹介とQiitaの開発チームでの役割についてお聞かせください

    Qiitaのスライドモードは、mizchiが勝手に作った!?─Incrementsの縛られない開発スタイルを聞いてみた
    braitom
    braitom 2016/09/07
    “新しいことにはどんどんチャレンジしていって、あまり保守的になりたくないと思っています。”
  • 伊藤直也さんの一人CTO Nightに一人で行ってきた - comix

    巷で話題?のnaoya さんの一人CTO Nightに行ってきましたので、超雑ですがメモを公開しておきます。 イベント詳細: https://doda.jp/event/seminar/20160830.html オレオレメモなので多少ニュアンス違うところあるかもです。特に二部のパネルディスカッションの部分はかなり文脈を端折っているので雰囲気知るくらいに読んでもらえれば。 もし大きく間違っていることあったらご指摘くださいm(__)m ちなみにアニメの話はあんまりなかったよ。 では、早速。 第一部【プレゼンテーション】最速で最高のアウトプットを生み出すチーム作りとは? 【プレゼンテーション内容】 CTO・技術顧問を複数社経験した伊藤直也氏が、過去の実際の事例をもとに、最高のアウトプットを生み出すチーム作りを解説します。 前提として、、、 50〜300人くらいの規模の組織が対象 CTOのマネジ

    伊藤直也さんの一人CTO Nightに一人で行ってきた - comix
    braitom
    braitom 2016/09/03
    “問題があるとき人ではなく構造に原因を求めるべき”
  • iOSDCでハッピーについて話したよ

    ノハナの中の様子を時に真面目に時にゆるゆるとお伝えします こんにちは。iOSエンジニアの原です。 8/19-20に開催された国内最大級のiOSアプリ開発のカンファレンス iOSDC 2016 で「ハッピーな開発チームを築くためにiOSエンジニアがしたこと」というタイトルでLTさせていただきました。 LT内容の補足 せっかくのカンファレンスなので、普段できないエモい話をしたいと思い、このタイトルにしました。 開発しているサービスがグロースするためにしたこと ドッグフーディングランチと競合調査ランチについて話しました。 ドッグフーディングランチは、楽しくかつ強制的に ドッグフーディングするために始めました。ドッグフーディング自体は、絶対に実施したほうが良いと思いますが、なによりサービスに合った形で、ユーザと似たような環境で実施することが大事です。また、エンジニアだけでやると、内部実装の話になっ

    iOSDCでハッピーについて話したよ
    braitom
    braitom 2016/08/28
    ドッグフーディングランチ、競合調査ランチいいな。あと病気のことをちゃんと知るってのはすごい大事だと思う。
  • 2015〜2016年で開発組織を作るためにやってみたこと - FLINTERS Engineer's Blog

    こんにちは、杉谷と申します。 GANMA!を開発しつつ、社内環境を整えたりとかしています。 この会社に入社してから3年(+1ヶ月)経ちました。あっという間! いろいろやってきた結果、組織がますます良い感じになってきたので、会社ぐるみで試みてきたことをご紹介します。 2013〜2014でやってみたこと 入社1〜2年目は以下のことを行いました Chatwork / Stash(現BitBucket) / Confluence / JIRAの導入 開発ポリシーの制定 TDD研修・スクラム研修 システムリーダー定例 裁量労働制の導入 評価制度の改善 会社標準PCMacBookPro 15インチ(松)に ゲーム部を立ち上げてみた 詳しくは前回のエントリ 2014年。開発組織を作るためにやってみた事 をご参照ください。 Slackの導入 2013〜2014の段階ではChatworkを利用していました

    2015〜2016年で開発組織を作るためにやってみたこと - FLINTERS Engineer's Blog
    braitom
    braitom 2016/08/22
    社内の組織の体制作りをどのようにやってきたかについて。社内全レビューの仕組みいいな。社外レビュアーもCool。
  • 初めての技術力評価会を終えたので感想を書いた - CARTA TECH BLOG

    こんにちは、fluct SSP開発部の@saxsirです。 今年の4月に入社した新人ですが、職場ではgolangとかAWSとかを使って社内向けのプロダクトをゴリゴリと開発しています。 さて、VOYAGE GROUPでは人事評価制度の一つとして技術力評価会という相互評価の仕組みがあります。 これは年に2回ほど開催されており、直近半年くらいの仕事から何かテーマをピックアップし、別チームのエンジニア2名(評価者)に「私はこんなすごいことをやったんだよ、どやっ」とお話しながら自分の技術力を評価してもらうという場になります。 もちろん、新卒も例外なく技術力評価会を行います。 今回は初めての技術力評価会を終えて私が学んだこと、を社外の方向けに書こうと思います。(言うまでもなく、私は被評価者です) ※以下、「技術力評価会」を「評価会」と略して表記する場合があります TL;DR 「なぜやったのか」を説明

    初めての技術力評価会を終えたので感想を書いた - CARTA TECH BLOG
    braitom
    braitom 2016/08/21
    自分できちんとなぜ?を考えて説明する機会を与えるのはとても良さそう。「言われたからやりました」とか言ってくる人が減るだろうし。
  • 開発会社におけるエンジニアスキル向上施策の過去と今|TechRacho by BPS株式会社

    morimorihoge@Webチーム部長です。ご無沙汰しています。ゴ魔乙はギルド戦が実装されてから拘束時間が多くなり、そろそろ見切りを付けようかとも思い始めた今日この頃です。とりあえずポケモンGOは始めました。 しばらくTechRachoに投稿できていなかったわけですが、別に遊んでいたわけではなく、むしろ開発会社としての業の方で一杯一杯でなかなか記事を書く気合を充填できていませんでした。 今回は、最近社内で(というか主に僕のいるWebチームで)取り組んでいる社内エンジニアのスキルアップへの取り組みについて、これまでの経過と近況を書こうと思います。長いです。 ※今年に入ってから弊社は事業拡大を目指して採用活動を強化しており、現在進行形でメンバの増強を行っています。新しい人が入ってくる中で古くからの人もいるという当たり前のことではありますが、過去にこういう取り組みをしていたんだよという記録

    開発会社におけるエンジニアスキル向上施策の過去と今|TechRacho by BPS株式会社
    braitom
    braitom 2016/07/31
    全部は真似できないけどできるところは真似してみたい。あと、「現在動いている案件 > 新人教育」が結構すべてな気がする。
  • “エンジニア35才定年説に挑戦する” 開発チームのマネジメント

    Scala/Scrum/DDD 困ったこと50連発ガトリングトーク!! のLTで話させていただいた、エンジニアチームのマネジメントについて取り組んでいることを紹介します。

    “エンジニア35才定年説に挑戦する” 開発チームのマネジメント
  • エンジニアを疲弊させる、「やりません」「できません」を言わせない開発チームとは - paiza times

    Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ!』 こんにちは、谷口です。 開発をしていて、「いま当にこの機能が必要か?」「この納期でその機能作るのは無理だろ」などと思った経験はありませんか? 新人の頃は何も考えずに上に言われたものを作っていた、もしくは作ろうとしたけど無理だった案件があったという人も多いでしょう。上の立場の相手に「この機能、当に必要ですか?」なんて、言いたくてもなかなか言えないものです。 しかし、現場の開発者が「これ要らなくない?」「これはできません」と思っているのにそれを口にできないようなチームって、よい開発チームとは言えないのではないでしょうか。 今回は、エンジニアが「やりません」「できません」と言うことについて考えてみました。 ■それ、当にいま必須の機能ですか? ユーザー「あー顧客情報を一覧で見れたら便利なのになー」

    エンジニアを疲弊させる、「やりません」「できません」を言わせない開発チームとは - paiza times
  • 1