リモートでむしろ生産性が上がったエンジニア組織の作り方を一休 CTOの伊藤さんに聞いてみた
宿泊予約事業やレストラン予約事業などを手掛ける、株式会社一休。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Teams」を活用いただいています。 今回は、執行役員CTOを務める伊藤直也さんにインタビュー。実際に「Findy Teams」上のデータを参照しながら、エンジニア組織における生産性についての考え方などを伺っていきます。 ■プロフィール 伊藤 直也 株式会社 一休 執行役員 CTO コロナ禍における開発を、Findy Teamsで振り返る ──こちらが御社の2020年1月から直近までのデータになります。プルリク作成数はだいたい平均値を超えていて、件数としては2020年7月と2020年10月に大きな山があります。今年は5月頃から全体的に伸びている傾向にありますが、これらの要因として考えられる部分はありますか？ Findy Teamsのチ
余計な「念のため」でプロジェクトが死に至る「オーバーエンジニアリング」の問題とは？
日本に「過ぎたるは及ばざるがごとし」ということわざがあるように、海外のソフトウェア開発現場でも製品が必要以上に複雑化してしまう「オーバーエンジニアリング」という現象がしばしば問題になります。そんなオーバーエンジニアリングの原因や影響、防止方法について、ボイスチェンジャーアプリの開発会社・Voicemodで主任プロダクトマネージャーを務めるシモン・ムニョス氏が解説しました。 Overengineering can kill your product - Mind the Product https://www.mindtheproduct.com/overengineering-can-kill-your-product/ ソフトウェアエンジニアとしての経験を持つプロダクトマネージャーのムニョス氏によると、「ありもしない問題を解決するためのコードやデザイン」と形容されることもあるオーバーエン
プロジェクトが大変になってきたときは大変とちゃんと言うのが重要 - hitode909の日記
このままのペースには締め切りに間に合わない、とか、作ろうとしていたものが思っていたより難しかった、みたいなときに、普段よりペースを上げたり、時間をのばしたり、一部の仕事を他の人にお願いしたりして、がんばって進めることがある。 そういうときに、チームメンバーの中で一人だけ突然ギアを上げていると、周りの人からは、なんで突然に急いでるのか？と奇異の目で見られるかもしれない。 プロジェクトの進捗が悪いです、とか、このままでは危うい、危機的状況です、みたいなことを言うのは、なかなか言いづらい、言うのに躊躇するようなことかもしれない。未来のことだからわかりませんし、楽観的に見ると後半の伸びで追いつけるでしょう、みたいに、大丈夫、と言ってしまうこともできなくはないだろうと思う。 でも、プロジェクトの現状は悪い状況です、ということはちゃんと言って、共通認識として持ってしまったほうが、いまは非常時なのでちょ
Trello、Asana、GitHub、Jira。チームによって管理ツールがバラバラな理由 - エス・エム・エス エンジニア テックブログ
タスク管理は、チームで仕事をしていく上で欠かせない一方で、永遠にカイゼンし続ける必要があるものです。チームごとに、どんなツールを選んでいるのか、それをどう利用しているのでしょうか。 エス・エム・エスでは、タスク管理の仕方もチームごとに裁量が与えられています。どのようなツールを利用してタスク管理をしているのか。「カイポケ」「カイゴジョブ」「ハピすむ」など、各サービスの開発チームに聞いてみました！ ツールの選定基準、利用の仕方、利用ツールのメリット・デメリットなど、開発チームによってどのような違いがあるのかを紹介していきます。 エンジニアチームごとに異なるタスク管理ツール 今回、話を聞いたのは、カイゴジョブ、ハピすむ、カイポケGengar、カイポケ障害、カイポケKSEE、カイポケSRE、カイポケ訪看など7つの開発チームのエンジニアメンバー。 それぞれのチームで使っているツールやチームのメンバー
1年を超える長期プロジェクトを30人超でふりかえりした話（前編） 〜プラクティスの選択〜
新規プロダクトや大きな機能のリリース、大規模リニューアルなど、長い時間かけて行うプロジェクトは少なからず発生します。 みなさんは、そのようなプロジェクトのふりかえりは上手く行えていますか？また、オンラインでのふりかえりはどのように行っていますか？この記事では、長期間のプロジェクトに対するふりかえりの方法を、どのように準備して行なっていったかをご紹介します。 今回のふりかえり会の全体像 今回のふりかえりではmiroを用いて下記の流れで行いました。それぞれのプラクティスの内容については、本記事で説明します。 ふりかえり事前会アジェンダ 参画時期の共有（プラクティス1） 起こったことの共有（プラクティス1） ふりかえり本会アジェンダ 本日のチャレンジ宣言（アイスブレイク） 良かったこと、気になったことを共有（プラクティス1） インタビュー×3（プラクティス2） 課題の狙いを定める（プラクティス3
BASEの長期間プロジェクトでのチーム開発について - BASEプロダクトチームブログ
ServiceDev所属、サーバサイドエンジニアの栗田です。 現在私は、ServiceDevのチームに所属し、ネットショップ作成サービス「BASE」及びショッピングアプリ「BASE」の機能開発を担当しています。 BASEでは主にQ毎にプロジェクトチームを編成し、チームで主体となって機能開発を行っていきます。 チームメンバー構成はプロジェクトの特性や規模により様々ですが、多くの場合、同じグループから1〜2名がプロジェクトにアサインされます。 今回はとある長期間プロジェクトで感じた事や・実際にこのように進めたよというところをサーバサイドエンジニアの視点から紹介したいと思います。 どんなプロジェクトだったか 今回紹介するプロジェクトは「BASE」の拡張機能である「BASE Apps」の1つである「商品オプション App」を開発するプロジェクトでした。 「商品オプション App」は商品にギフトラッ
プロダクト企画にエンジニアを早めに巻き込む（嫌がられずに協力を得る方法） - ykmc09 blog
TL;DR : ひとことでいうと 決定事項になる前に早めに巻き込もう 巻き込むときは、 その意図や相手に期待することを伝えよう 特性を理解して、ちょっとした工夫（最初の一声はチャットなどの非同期コミュニケーションを使う、etc）をしよう たまに遭遇するシーン ソフトウェアプロダクトの企画（プロダクトデザイン、プロダクト設計）を行う人や組織が、 企画の要件や仕様をかっちりと固めてから、エンジニアに渡したほうがいい 、と思っているシーンを見聞きすることがあります。 「重厚なウォーターフォールプロセスを採用しているから」という場合もあると思いますが、 軽量なプロセス下にある Web サービス企業でも、企画と開発で役割分担をしている場合は（程度の大小はあれど）起こってしまう と思っていて、今回はそういったケースを想定しています。 特に、以下のような思いがあるからそうしている、というケースを話題に上
約9カ月でリリース、目標の2倍の成果――“品質”と“納期”を両立させる新規プロダクト開発でチームを崩壊させない方法
約9カ月でリリース、目標の2倍の成果――“品質”と“納期”を両立させる新規プロダクト開発でチームを崩壊させない方法：リクルート事例に見るエンジニアとしての価値の高め方（1） 変化が速くなる一方の市場環境において、エンジニアとしてビジネスに貢献するにはどうすればいいのか。本連載では、リクルートでの新規プロダクト開発事例からエンジニアとしての価値の高め方を明かす。初回は、本連載で事例として扱うプロダクトの概要やスケジュール、開発の進め方について。 エンジニアとしてビジネスに貢献するにはどういうアプローチをしていけばよいか 近年、ビジネス市場の変化は速くなる一方です。FinTech、MaaS（Mobility as a Service）、HRTechなどに代表されるように、ほぼ全てのビジネスにデジタル技術が欠かせなくなっているため、エンジニアである私たちにも、市場変化の速さは“脅威”といえると思
実装を引き受ける前に詰めておくべきWebフロントエンドの想定漏れチェックシート - Qiita
リキッドレイアウトのように幅が常に変動するレイアウトのデザインは、動かないカンプからは実際の挙動が読み取れず、デザイナーの意図が汲み取りきれないことが多い。また、複雑化するアニメーションの実装においても、カンプだけではコミュニケーションに不備が生まれてしまう。ほかにも、CMSを使った案件ではデザインカンプと実際のデータの間に齟齬がある可能性もある。 実装効率を高めてスケジュール通りに仕事を終わらせるには、とにかく事前に仕様を固めることが大事だ。ワイヤーフレームやデザインの途中の段階からなるべくデザイナーとコミュニケーションを重ね、想定外の要件が発生しないように気をつけるべきだろう。 この記事では、デザイナーやフロントエンドエンジニアが見落としがちなWebフロントエンドの課題について列挙していく。 ホバー表現を後から指示される ツッコミ 後から仕様追加されると困るから先に決めて! メモ 最近
開発速度を上げるための Pull-Request のつくり方 - クックパッド開発者ブログ
こんにちは、投稿開発部の森川 (@morishin127) です。クックパッド、お料理アルバム、みんなのお弁当の iOS アプリの開発等に携わっています。 クックパッドでの開発は GitHub Enterprise 上で行われており、書いたコードをプロダクトに取り込む前には基本的に第三者のコードレビューが必須です。コードレビューはプロダクトの品質向上に貢献していますが、往々にして結構な時間と労力がかかるものです。Pull-Request を出してレビューをしてもらい指摘の修正を繰り返していると、場合によってはマージに数日〜1週間ほどかかってしまうこともあります。自分の開発速度を速めるため、また周りのエンジニアの開発速度を下げないためにレビューしやすい Pull-Request を出すことは重要です。この記事ではレビューしやすい Pull-Request のために心がけていることを紹介したい
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita
ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレクターから適切な人に指示を出すことにし、メンバー同士でのダイレクトなコミュニケーションをいったん、原則禁止した。 （ディレクターがAさんとBさんで直接やって、と指示を出すときもあるが、それもやりとりの結果をAさんから必ずフィードバックさせるようにした。） ただ
プロジェクト管理や共同作業をより効率的に--生産性向上ウェブツール10選
Jack Wallen （Special to TechRepublic） 翻訳校正： 石橋啓一郎 2015-04-09 06:30 生産性を向上するためのツールは、この5年間で劇的に変わった。かつてよく使われていたスタンドアロンのアプリやクライアント・サーバ型のアプリの多くは使われなくなった。今では、ビジネスのスピードはウェブで決まる。ウェブは、企業が抱えるタスクのほとんどを支えられるようになっている。ローカルにインストールされたクライアントアプリからウェブベースのアプリに移行するには、IT部門が抱えるユーザーの仕事のやり方を一新する必要がある。そのため、選択するウェブベースの生産性向上ツールについては十分な検討が必要だ。 信じられないかもしれないが、これらのツールの多くは、従来使われていたものよりもはるかに費用対効果が高い。さらに、信頼性も高く、従業員がはるかに高い生産性を発揮できるよ
［2］「FUJI HACK」体験記（後編）――「つながりマップ」開発にチーム力を結集した結果
［前編から読む］ （前回までのあらすじ）徳田恒司氏は、富士通の社会基盤システム事業本部第二システム事業部に所属するSE。上司の指示で、富士通の社内ハッカソン「FUJI HACK」に参加することになった。当初、普段の職場環境と違う会場の雰囲気に気圧されていたが、次第に自分のアイデアを形にしたいと思うようになる。ハッカソン1日目の後半に実施したチーム分けの際、本来リーダー候補に選ばれていなかったものの、自ら立候補してリーダーを買って出た。 富士通の徳田恒司氏（写真1）は立候補によってリーダーになり、チームを率いることになった。今回のハッカソンでは、プログラマー、デザイナー、ビジネス担当を混ぜてチーム編成する決まりだった。ハッカソンに参加する際、自分はどのスキルを持っているかを名札で色付けされていた。プログラマーは青、デザイナーは黄色、ビジネス担当は緑だ。 徳田氏の下に集まったメンバーには当初、
ZOZO Technologies TECH BLOG
2020-07-01 ZOZOTOWNのインハウス広告運用を支援するデータと仕組みの話 BigQuery データ マーケティング 広告 本記事では、ZOZOのマーケティング部門の広告運用のインハウス化に伴って、これまで取り組んできた広告データの収集と活用、その仕組みにフォーカスして事例をご紹介します。 ZOZOTOWNのインハウス広告運用を支援するデータと仕組みの話 2020-06-29 【オンラインMeetup イベントレポート】ZOZOテクノロジーズの大規模データ活用 イベントレポート GCP Elasticsearch 検索 機械学習 こんにちは、ZOZOテクノロジーズ CTO室の池田（@ikenyal）です。 ZOZOテクノロジーズでは、6/22にZOZO Technologies Meetup -ZOZOテクノロジーズの大規模データ活用-を開催しました。 zozotech-inc
複数人でのプロジェクトマネジメントに速攻で同期できる「かんばん」を使えるサービス「Taiga」
トヨタが考案した「かんばん方式」は、生産計画に応じて必要なものを必要なときに必要なだけ供給でき生産効率が向上するため自動車の製造に限らず製造業一般に普及し、現在ではプログラムマネジメントの手法の一つとして広く採り入れられています。そのかんばん方式を使って複数人で取り組むプロジェクトをオンライン上でマネジメントできるサービスが「Taiga」です。 Taiga.Io | Agile, Open Source, Free Project Management System https://taiga.io/ ◆アカウント登録 上記サイトページの下にある「SIGN UP」をクリック。 TAIGAのアカウント登録画面になるので、ユーザーネーム・公開ネーム・メールアドレス・パスワードを入力したら「SIGN UP」をクリック。 無事、サインアップが終わるとこのようなサインイン画面になります。なお、複数の
「一人でもコードレビューはできる！」Sendagaya.rbでコードレビューについてディスカッションしました | mah365
先日デキるプログラマだけが知っているコードレビュー7つの秘訣というテーマでSonicGarden Studyというオンライン放送にてお話をさせていただきました。参加者が500人とかなり大盛況の放送だったのですが、その分流れる質問量も激しく、十分に質問にお答えできなかったなーという感がありました。そこでその放送の翌週にあたる8/18（月）にSendagaya.rbの場をお借りして（thanks @tkawa！）コードレビューについてディスカッションする機会を設けさせていただいたのでした＠ソニックガーデンオフィスにて。 スライド 前半はこのスライドを元にざっくり15分ほどでSonicGarden Studyでどんなお話をさせていただいたかを紹介しました。3分ぐらいでざっくり、と前置きしたのに15分ぐらい話してた・・・。 話に上がった内容 いろいろと面白い話が上がっていたので、覚えている範囲でつ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
たった1人でスマホゲームを作りヒットさせた男 - 日本経済新聞