はじめに こんにちは。食べログ飲食店システム開発部でエンジニアリングマネージャーをしている井本です。 今回は私の所属している予約サービスチームをサンプルにし、以下のような内容を紹介します。 食べログのエンジニア組織、所属チームで起きていた課題 食べログエンジニア組織と予約サービスチームについて 予約サービスチームの組織編成の工夫について チームで行なっている情報共有の工夫 この記事が組織編成や仕組みを考えるヒントになれば幸いです。 食べログのエンジニア組織、所属チームで起きていた課題 複数の開発チームにまたがる開発の課題について 我々が所属している食べログは、年々ネット予約の利用人数が増加しております。 大変喜ばしい状況ですが、ビジネスの拡大に追いつくため、組織も対応していく必要が出てきています。 特に近年ではエンジニア組織も拡大し、複数の開発チームにまたがり開発する機会が増えました。 複
チームのキャパシティを超える要求を抱えたプロジェクトが、なんの問題もなく完了するはずがありません。なんとか作り上げられた機能は、表面上は要求通りでも、どこかぎこちなさを感じます。ユーザー体験が悪く、それがユーザー価値を押し下げ、ビジネス価値を削り取ります。触るたびに新しい欠陥も見つかるかもしれません。内部品質も最低です。それが今後の追加開発の足を引っ張ることにもなるでしょう。そして、ただ消費するような働き方によって、チームは成長も達成感も感じられず、疲弊します。 詰め込み型のプロジェクトは、誰にとっても利点がなく、そのうえ持続不可能なやり方なのです。 「詰め込んでもなんとかなる」という楽観主義詰め込み型のアプローチは、組織内でプラクティス化しやすいプロジェクト計画手法です。この手法で完了したプロジェクトは、一見すると、上手くいったように見えます。多少の遅延があったとしても、概ね一通りの機能
不確実さが増す世界のプロジェクトマネジメントとはとういうものか倉貫義人氏：そんな不確実さが増す世界のプロジェクトマネジメントはどういうものなのか。（スライドを示して）プロジェクトがうまくいかない（理由）というのは、このあたりを見てもらうと胃が痛くなりそうな言葉がいっぱい書いてあると思います。想定よりコストがかかるとか、作ったものを直せないとか。 （スライドを示して）これに対してどうすればいいかというと、「こうすればうまくいくのかな？」と考えがちですよね。「遅いからプレッシャーをかけようか」とか「少し遅れているので人を増やそうかな」とか「一気に作ったほうがいいんじゃないの？」とか「属人性を排除しましょう」とかと言いがちですよね。 これらはけっこう言いがちですが、全部失敗するやつです。これを全部やってみたら困ったことにプロジェクトが大変なことになるので、ぜひやってみたらいいと思います。 （会場
AIに適した知的労働 森一真氏（以下、森）：データの分析も知的労働ですし、チームビルディングもある意味知的労働かなと思いますが、特に情報処理的で、かつ問題が曖昧ではなく、ちゃんと定義できるものほどAIに向いています。いわゆるリサーチや分析はどんどん優先的にAIに置き換わっていきます。 新規事業アイデアは（スライドの）真ん中にあるんですが、若干情緒的なところや文脈的なところもありつつ、リサーチ等の情報処理的な業務負荷が著しく高いので、うまくプログラムを組むことでかなりAI化が進みやすいと思います。 逆にリーダーシップやチームビルディング、組織文化などは、AIにはまだちょっと難しいと思います。この（スライドの）右上にいけばいくほど、AI化が進みやすいと考えてください。 その中で新規事業のアイデアを作る場合、どう活用できるか。これ（スライド）は新規事業プロセスの事業仮説を作るまでを簡便化した図で
宿泊開発チームでエンジニアをしている @itinao です。 昨年の10月に入社しました。 今回は GitHub Projects を利用したタスク管理について記載します。 なんとなーく GitHub Projects 使うと、KANBANにしてみたり リストにして使ってみたり で終わってしまいます。 もっと色々できるんだよってことが伝えられればと思います。 背景 どんな機能があるか Custom Fields Views Group by Slice by Workflows ISSUEと Pull requestの紐づけ Insights タスクの進め方 タスクの洗い出し 見積もり 現状の課題と今後の展望 まとめ さいごに 背景 一休ではチームごとにタスクの管理方法が違い、 Google Spreadsheet・GitHub Projects・Jiraなど、チームごとにタスク管理の方法
前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳
近年のソフトウェアプロダクト開発組織の活動単位としてよく言われるのは、「少人数で安定したチーム」であろう。表現は違えど、どの文献でもそのように述べられる。 それでは、「少人数」と「安定」の2つの要件を満たせば高パフォーマンスなチームが設計できるかと言えば、そんなはずもない。他にも要件があるはずだ。 そこで、チームに共通して必要だと考える要件を、設計に関わったこれまでの組織から抽出して言語化し、原則としてまとめてみた。それが、「安定」「アトミック」「非兼務」「少人数」「流動性」「イテレーティブ」の6つだ。 初期に携わった組織には欠けていた要素もあるが、何度も失敗を重ねるうちに見いだしたものだ。組織設計のプラクティスとしてよく聞くものもあるが、いずれも実体験を経て必要だと感じたものばかりである。 なお、本記事で取り上げる6つのチーム設計原則だけでは、組織設計として不十分だ。チームにどういった機
SIerの人手不足が深刻だ。旺盛なDX（デジタル変革）需要に対応するため、人材獲得競争が激化している。 人手不足への対処策の1つとして各社はサービス型への事業モデルの転換を進めている。事業モデルの転換とは別にもう1つの重要な取り組みがある。開発生産性の向上だ。技術者1人当たりの生産性を高めることで、より少ない人数で多くのシステムを開発できるようにする。 開発生産性向上への取り組みは今に始まったことではない。数々の開発手法や開発ツールが生まれてきたのはそのためだ。SIerも独自の開発標準や開発環境などを整え、効率のよい開発を進めてきた。 その中でもクラウドやコンテナといった最新技術を活用することで成果を上げたのが野村総合研究所（NRI）である。複数の企業で共通して使えるソフトをつくり、別のプロジェクトでも利用する。つくらない部分をなるべく増やすことで生産性を向上させる。実施した事業本部内での
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
導入 どうやら新卒2年目社員のAさんが上司のZさんにプロジェクトにおいてテストコード導入を打診してるようです。少し内容を見てみましょうか。 Aさん(新卒2年目社員)「最近テスト自動化やテストコード、TDDなどの単語をよく聞きます。うちはテストコード書いてないですし、実装後の簡単な動作確認、最終の結合テストしかしていません。開発体験と品質を上げるために、テストコードを導入したいです。」 Zさん(上司)「そうは言うがね、君。今のうちの状況を見てごらんよ。みんな複数のプロジェクトに関わっていて、常に多忙。残業時間もぎりぎりで何とかプロジェクトが回っている状態だよ。そんなみんなにさらに作業を増やすようなことを提案するというのかね？しかも、テストコードはお客様からしたら作っても作らなくても関係ない、いわば直接利益に関係ないような作業じゃないか。もちろん、世の中で認知されているということは知ってるよ？
概要 Word や Excel でのドキュメント作成を回避し、なるべく生産性高く、かつ、OS 環境依存なく、すべて基本無料で構成できるツールで、Markdown ベースで設計書を作成することを考えてみます。 GitHub 上で閲覧できる形でドキュメントを作成することを前提に、VSCode（＋プラグイン）を用いて、テキスト文書、表（テーブル）、図（構成図など）、キャプチャ、などをスピーディに作成し、PullRequest ベースで運用していけるように、プラグインを構成および、レギュレーションを作成してみました。 GitHub の README.md や Wiki に書いて使えるかと思いますので、併せて markdown 形式および、vscode のプラグイン推奨設定ファイル形式でも載せておきます。 もし、もっとこのプラグインを使うと良い、などアイデアなどありましたら教えていただけると幸いです
人月の神話 をひさしぶりに読んでみた。 人月の神話は、フレデリック・ブルックスの超有名古典的エッセイ集で、ソフトウェアエンジニアリングに関する多岐にわたるトピック取り扱っている。その中でもとくに有名で、よく世間で言及されるのは、表題にもなってる「人月の神話」と「銀の弾などない」、それから「セカンドシステム症候群」あたりだろうか。 はじめて読んだのは20年くらい前。社会人になったばかりのころ、満員電車にゆられながら、「へー人を増やしても開発ってうまくいかないのねー」などとわかったような顔をしながら読んでいたのを覚えている。当時は職業プログラマとしての経験を積む前で、本を読んでも鵜呑みにすることしかできなかった。でも、熟練のプログラマとして経験を積んだいま読んだら、またなにか違った洞察を得られたりするかもしれない。読み返してみた動機はそんな感じ。 目次 現代のプログラマにとって有益か やっぱり
まずはじめに、2022/01/28のfreee Tech Nightを楽しみにお待ちいただいていた皆様、当日直前にLiveを延期してしまいまして、運営にかわりまして申し訳ございませんでした。この記事はLiveで話す予定の内容の一部を深堀りした内容になっておりますので、文字でもお楽しみいただければと思います。 Abstract 期日を決めることには様々な利点があるが、期日通りに終わらせるにはとてもじゃないが避けづらい問題が多すぎる。 特に期日を先々まで決めてしまうことで直近の期日さえ守れなくなる状態になる。 期日を決めず、優先順位を決め、短い間隔で機能や価値を出すことで、方針の柔軟さを確保し、ランダムに発生する事象に対応しやすくなる。 現在地と予測地点を確認するためにまずは「バーンダウンチャート」をつくって運用してみよう。 はじめに なにか目指したい姿があると、その姿に対して何かしらの案を考
数年前、私はこんな絵を書いて、アジャイル開発やリーン開発のついての様々なプレゼンで用いた。 そこから、この絵は急速に広まっていった！記事、プレゼン、さらには本（Jeff Pattonの”User Story Mapping”という素晴らしい読み物なのだが）にまで至る所で姿を見せた。多くの人がこの絵は反復型開発、リーンスタートアップ、MVP(minimum viable product)の本質をよく捉えていると伝えてくれた。しかし、元の文脈から切り離して物事を捉える際にはごく自然なことであるのだが、この絵を誤解している人がいる。簡素化しすぎだと非難する人もいる。（正しい指摘である） この絵はあくまで比喩である。実際の車の開発の話ではなく、車を比喩とした一般的なプロダクトの開発の話なのである。 とにかく、これらのバズからこの考えの背景を話す時だと判断したのだ。 １つ目の例：not like
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
