リモートでむしろ生産性が上がったエンジニア組織の作り方を一休 CTOの伊藤さんに聞いてみた
宿泊予約事業やレストラン予約事業などを手掛ける、株式会社一休。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Teams」を活用いただいています。 今回は、執行役員CTOを務める伊藤直也さんにインタビュー。実際に「Findy Teams」上のデータを参照しながら、エンジニア組織における生産性についての考え方などを伺っていきます。 ■プロフィール 伊藤 直也 株式会社 一休 執行役員 CTO コロナ禍における開発を、Findy Teamsで振り返る ──こちらが御社の2020年1月から直近までのデータになります。プルリク作成数はだいたい平均値を超えていて、件数としては2020年7月と2020年10月に大きな山があります。今年は5月頃から全体的に伸びている傾向にありますが、これらの要因として考えられる部分はありますか？ Findy Teamsのチ
プロジェクトが大変になってきたときは大変とちゃんと言うのが重要 - hitode909の日記
このままのペースには締め切りに間に合わない、とか、作ろうとしていたものが思っていたより難しかった、みたいなときに、普段よりペースを上げたり、時間をのばしたり、一部の仕事を他の人にお願いしたりして、がんばって進めることがある。 そういうときに、チームメンバーの中で一人だけ突然ギアを上げていると、周りの人からは、なんで突然に急いでるのか？と奇異の目で見られるかもしれない。 プロジェクトの進捗が悪いです、とか、このままでは危うい、危機的状況です、みたいなことを言うのは、なかなか言いづらい、言うのに躊躇するようなことかもしれない。未来のことだからわかりませんし、楽観的に見ると後半の伸びで追いつけるでしょう、みたいに、大丈夫、と言ってしまうこともできなくはないだろうと思う。 でも、プロジェクトの現状は悪い状況です、ということはちゃんと言って、共通認識として持ってしまったほうが、いまは非常時なのでちょ
Git のユーザー名を複数使い分ける時は global の設定を消す
2016/09/13 この記事は書かれてから1年以上が経過しており、最新の情報とは異なる可能性があります techGitgitconfig 会社用のアカウントと個人用とで分けたいときなどに。 正攻法じゃないけど、間違えずに済むので一応メモ。 （以下いろいろ編集追記） これでしばらくやってみてほぼ困らなくなりましたのでオススメです。 ライブラリはオープンに個人用アカウントで作っておき、 それを会社用アカウントから利用するみたいなことも想定できるので、 user.name, user.email を複数使い分けられるようにしておいて損はないと思います。 global の .gitconfig の user.name をあえて空にするホームディレクトリに置いてある .gitconfig 内の [user] name = foobar email = foobar@example.com みたいな
道の真ん中をきれいにするプロジェクトマネジメント～イケてるチームになるための10原則～ - Qiita
はじめに 私が好きな江戸の小話的なものに、こういったものがあります。 江戸下町では、道向かいのそれぞれが軒先を掃くときに、道の真ん中よりもちょっと向こうまで掃くのがならわしだったそうです。両側の人がそれぞれ真ん中よりも向こうまで掃くので、道の真ん中が一番きれいになる、というお話です。 近年こうした「江戸しぐさ」のようなお話は、真偽のほどが定かではないとして、流布することに批判もあるようです。実際この話も正直事実かどうかは全くわかりません。 ただお互い完璧ではない他人同士が肩寄せ合って共に生きる知恵といいますか、プロジェクトへの参画姿勢について良い示唆を与えてくれる話だと思い、その前提で使っています。 実際私が関わる案件のキックオフでもお客様や関係者によくこの話をするのですが、「キックオフでの『道の真ん中の話』、他の現場でも最近してるんですよ」とお客様やパートナー様から言っていただけたことが
プロジェクト管理を自動化してみたけど思うようにはいかなかった話 - dely Tech Blog
こんにちは。delyでAndroidエンジニアをしているkenzoです。 今回はAndroidの話ではなく、担当している別のプロジェクトの管理をいい感じにしようと思っていろいろやったけど、そんなにうまくいかなかった。という感じの内容です。 どんな話 「他部署の依頼でコンテンツを作成するプロジェクト」の管理を自動化した結果、うまくいったこと、失敗したことについてのお話です。 なんで自動化したの 今回のお話の背景 弊社では開発部が他の部署から依頼を受けてLP等のWebページを作成しています。 私は他の部署と開発部内の実装者とのやりとりの間に入って管理する取りまとめのようなことをしてきました。 やっていたことをざっくり言うと、依頼を受け、実装者に依頼して、配信の準備をする。という簡単なお仕事で、元々はスプレッドシートで管理をしていました。 発生した問題 新たに高い頻度でコンテンツを作る施策の開始
Web制作会社から事業会社に転職してチームリーダーになるまで - Qiita
この記事はCrowdWorks Advent Calendar 2016の14日目の記事です。 クラウドワークスにはWeb制作会社出身のエンジニアが二人（私と@takeru0757さん）います。@takeru0757さんは6日目の記事で デザイナーと一緒に仕事をする上で気をつけていること というタイトルでデザイン観点で素晴らしい経験談を書いていましたが、今日はマネジメント観点でWeb制作会社出身のエンジニアがどういうチャレンジをしてきたかをポエムでお送りいたします。 バックグラウンド 私がクラウドワークスに参画したのは2015年5月で、以前はGitHubをメインで使った開発もしたことなければテストなんて書いたこともない、自動テスト？自動デプロイ？何それおいしいの？なんならRuby自体ほぼやったことないよ、みたいな残念なステータスでした。 でもエンジニアとして通用するスキルを身につけたいとい
はてなインターンの振り返りをYWTを使ってやってみた - だいくしー(@daiksy)のはてなブログ
今年は、はてなインターンの実行委員長という仕事をしている。 hatenacorp.jp 8月15日から9月9日までのインターンを終え、今年の教科書も公開ができた。 developer.hatenastaff.com まだもう少し委員長としての仕事が残っているが、ここで一度今年の振り返りをしようということで、実施した。 振り返り手法としてのKPTとYWT ぼくは普段、Mackerel というプロダクトの開発にかかわっている。Mackerelでは開発手法にスクラムを採用していて、2週間のスプリントごとに毎回振り返りを行っている。ここで使っているのはKPTという手法だ。 KPTはKeep, Problem, Tryの略で、2週間を振り返って、その期間でKeepしておくべき良かったこと、Problemとして議論すべき問題となること、そしてそれらを受けて次のスプリントですべきTryを決める。 K,
開発速度を上げるための Pull-Request のつくり方 - クックパッド開発者ブログ
こんにちは、投稿開発部の森川 (@morishin127) です。クックパッド、お料理アルバム、みんなのお弁当の iOS アプリの開発等に携わっています。 クックパッドでの開発は GitHub Enterprise 上で行われており、書いたコードをプロダクトに取り込む前には基本的に第三者のコードレビューが必須です。コードレビューはプロダクトの品質向上に貢献していますが、往々にして結構な時間と労力がかかるものです。Pull-Request を出してレビューをしてもらい指摘の修正を繰り返していると、場合によってはマージに数日〜1週間ほどかかってしまうこともあります。自分の開発速度を速めるため、また周りのエンジニアの開発速度を下げないためにレビューしやすい Pull-Request を出すことは重要です。この記事ではレビューしやすい Pull-Request のために心がけていることを紹介したい
チーム作りやモチベーションをどうする？CROSSで先達の濃い話を聞いた (1/3)
2月5日、横浜市の大さん橋ホールにて「エンジニアサポート CROSS 2016」が行なわれた。「先達に聞くこれからのエンジニア像」と題されたパネルディスカションでは、Web業界を牽引してきた3人のエンジニアが自身の経験を元にした深みのあるトークを繰り広げた。 エンジニアは自身で条件を決めるようになれ 昨年も行なわれた人気パネルに登壇したのは、元テコラスの伊勢幸一氏、元Googleで現在Qiitaを展開するIncrementsに籍を置く及川卓也氏、楽天 技術理事のよしおかひろたか氏の3人。エンジニア業界では知らない人がいないベテラン3人から含蓄のある話を聞き出そうと、CROSSのメインステージには多くのエンジニアが詰めかけた。 冒頭、モデレーターのニフティ森藤大地氏が出したテーマは「与えられた条件で最高のパフォーマンスを出すために」。若い頃にエンジニアとして、どのような研鑽や取り組みをしてき
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
泥沼プロジェクト振り返り
はじめに ちょっと前まで結構激しく泥沼化したプロジェクトにいた。 その頃はプロジェクトも僕も相当疲弊していて、何も考える時間がなかった。 ある程度、月日が経って今なら もう少し客観的にあの頃のことが考えられるかなと思い書いてみることにする。 振り返りをし、自分としてもプロジェクトとしてもどうあるべきであったかとか そういう立派なことが考えられればいいのだが。 とかく、Slide Shareとか世の中は成功事例は多く発信される。 けど、失敗事例のほうが共通して当てはまったりする。 前提 ・古典的なウォータフォール ・古典的なStruts1系ベース内製フレームワーク ・Java SE 6 ・QAとかいない ・デザイナーとかいない ・フロントエンドエンジニアとかいない アンチパターン 当時のプロジェクトを振り返って、明らかにこれは駄目だっただろというところ。 ◆プロジェクト全体 ・決定者がいない
開発モデルの作り方(守破離の破)
Regional Scrum Gathering Tokyo 2015 で発表したスライドです。 「[1C-2] 開発モデルの作り方 ～守破離の破！～」Read less
サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック (1/3)：プロジェクト成功確率向上の近道とは？（2） - ＠IT
サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック：プロジェクト成功確率向上の近道とは？（2）（1/3 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、Joelの機能仕様書を日本人向けにカスタマイズされたものを例に、機能仕様書の基本的な書き方、読みやすくする7つのテクニック、仕様書作成ツールは何を使うべきか、誰が書くべきかなども解説します。 連載目次 連載の第1回の前回「ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門」では、ITシステム開発がビジネスに貢献していくためには、まずは開発の成功が出発点になること、そしてITシステム開発におけるコミュニケーションの重要性、そしてコミュニケーションにおけるドキュメントの重要性について説
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
機械学習プロジェクトはなぜ失敗するのか | AI専門ニュースメディア AINOW