安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド｜面川泰明
みなさん、コードを書く前に設計書を書きますか？ 書くか書かないかは人それぞれだと思いますが、「設計」というプロセス自体は意識的であれ無意識的であれエンジニアであれば全員やっていることだと思います。 今回は設計プロセスの改善という文脈で私たちがDesign Docという仕組みを導入したことについて共有しようと思います。もし同じような状況を経験している人がいたら参考になれば幸いです。 導入の背景まずは導入するに至った状況からお話します。 私たちのサービスは、利用していただくユーザーの数が増加しています。それに伴って品質のハードルも上がってきました。サービスに障害が発生するとユーザーさんに大きな損害を出してしまうことになるからです。そこで今まで以上に安全にサービスを開発できる仕組みづくりが必要になりました。ですが、実現のためには大きく2つの課題がありました。 課題1. 開発スピードが徐々に鈍化し
なぜモダンなプロダクトチームによるリーンなプロダクト開発が必要なのか｜川嶋一矢@メルペイPM
はじめにメルカリUK版の立ち上げを終え2018年3月に帰国しました@tsumujikazeです。今は東京でメルペイのProduct Managerをしています。 イギリスではいわゆるモダンなプロダクトチームでのLeanなプロダクト開発を経験しました。得るものが多かったので、なるべく多くの人に知ってもらいたいと思いこのポストを書きました。 PMF →リーンプロダクトのプロセス →モダンなプロダクトチーム（組織論）という流れになっています。 はじめに 本編 ・何のためにプロダクトを作るのか ・プロダクトマーケットフィット ・PMFピラミッド ・要件定義フェーズのリーン化 ・モダンなプロダクトチームでのリーン開発とは おまけ ・Problem Space vs. Solution Space ・Problem Solution Fitとは ・エンジニア組織とPM組織の特性について ・バリュープロ
GitHub のプルリクで blame する ghpr-blame.vim つくった - はやくプログラムになりたい
先日 kazuho さんが git blame でプルリクを表示するスクリプトをつくってらっしゃって，便利そうだったので Vim プラグインをつくってみました． ファイルの各行がどのプルリクで変更されたかを確認し，気になるプルリクはその場で詳細を確認することもできます． github.com 使い方 インストールはお好みの Vim プラグインマネージャを使うなどしてください． 1. ファイルを開いて :GHPRBlame を実行 :GHPRBlame を実行すると裏で git-blame が走り，カレントバッファのファイルの各行のプルリク情報を git blame --line-porcelain で引っ張ってきます． 引っ張ってきた情報を元にカレントバッファの左に細長い一時バッファが開き，そこに各行に紐付いたプルリク番号が表示されます（プルリクに紐付いていない行は何も表示されません）．
Dangerで始めるPull Requestチェック自動化 - コネヒト開発者ブログ
こんにちはー！こねひとちほーのえんじにあのフレンズ@Utmrerだよー！ 今回はPull Requestを自動でチェックしてくれるDangerについて紹介します。 Pull Requestでのコミュニケーション Pull Requestのレビューは不具合の指摘やコーディングスタイルの統一、より良いコードのための提案などのために行われます。 ですが、次のようなコミュニケーションをしたことはありませんか…？ タイトルにIssue Idを含めてもらえますか？ WIPみたいなんですがレビューして大丈夫ですか？ Base branchが間違ってます、変更してください。 変更履歴のdocsを更新してください。 このような「実装とは関係のない指摘」はできるだけ減らし、自動化したいものです。それを実現するのがDangerです。 Dangerとは DangerのGitHubには次のように書かれています。 F
Let's Dev: A Package Manager
For Yarn 2+ docs and migration guide, see yarnpkg.com. Posted Jul 11, 2017 by Maël Nison Hello everyone! Today, we’re gonna write a new package manager, even better than Yarn! Ok, maybe not, but at least we’re gonna have some fun, learn how package managers work, and think about what could come next on Yarn. The devil is in the details This article omits small details and environment quirks, and f
社内横断の技術組織を終わらせました - nottegra’s blog
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
ビジネス貢献するためのエンジニアリングの話をデブサミでしてきた #devsumi - @i2key のBlog
Nintendo switchの初期不良を引き当てたので、ゼルダをやるために開けておいた予定がなにもすることなくなってしまったのでブログを書いた。私のswitchは今頃京都にあるでしょう。 Developers Summit 2017 でコンテンツ委員しつつ登壇もしてきた もともとは、デブサミオーガナイザの鍋島さんからコンテンツ委員としてお声がけ頂き、今回はコンテンツ委員という立場でデブサミに関わっていました。 そのため、コンテンツ委員が登壇とか自作自演感甚だしいので自分が登壇するつもりはまったくなかったのですが、GuildWorks -ギルドワークス-の市谷さんから越境をテーマに株式会社ヴァル研究所の新井さんと自分の3人でやりませんかとお誘いを受け、以下で登壇することに。 「新規事業が対峙する現実からエンジニアリングを俯瞰する」 新規事業が対峙する現実からエンジニアリングを俯瞰する #d
若手エンジニアを不幸にしないための開発の「べからず」集 - Qiita
若手エンジニアを不幸にしないための開発の「べからず」集を書いてみました。 「若手エンジニアを不幸にしないため」とは書いていますが、若手に限った内容ではありません。 いろんな開発の「べからず」のために不幸になるのは、とりわけ若手が多いということを意識したためだと思ったからです。 ・若手には、方針の決定権がない。 ・若手は、組織の中で道具のように扱われてしまう場合がある。 ・(今の）若手は、将来も働き続けるための力を付けるための組織内での教育が、（昔ほど）なされなくなってきている。 ・コスト意識が乏しいので必要性が乏しいことについてまで残業前提の仕事のスケジュールを組織がたてることが多い。（その分野の理論を知っていれば自明のことを実験で証明することを要求されるのは苦痛である。） 設計指針の「べからず」 何ができれば十分かを明確にしない 開発目標は、何ができれば十分なのかを明確にしないまま、追加
開発基盤チームが目指す事 #pixiv_night - Qiita
（当日はesaのプレゼンテーションモードで発表しました） （pixiv night in Fukuoka #02 - ピクシブを取り巻く技術がわかる一夜！ - connpass の発表資料です） 自己紹介 各種SNSをcatatsuyでやっている かたついと呼ばれることが多い ピクシブ株式会社で開発基盤チームと広告チームの兼任 2014年度新卒（2013/10入社） pixivの技術的な改善が主な業務（後で詳しく） 単著『pixivエンジニアが教えるプログラミング入門（星海社新書） ピクシブ社内の非エンジニア向けのプログラミング研修の書籍化 pixiv社内ISUCONやISUCON6本選の問題作成 pixivのチーム分け pixivというサービスは巨大 www.pixiv.net/touch.pixiv.net/スマートフォン用APIなどなど 提供しているサービスも多い pixivという1
モブプログラミング - Woody Zuill氏とのインタビュー
ソフトウェア業界におけるクレイジーなアイデアの歴史の中で、XP（ペアプログラミングとテスト駆動開発を用いる）が初めて登場したときの影響は、かなり大きなものだった。モブプログラミング（Mob Programming）は、それをもう一歩進めたように見える。モブプログラミングとは、チーム全員が同じ時に、同じ場所で、同じコンピュータ上で仕事をするソフトウェア開発手法だ。 2016年5月1日と2日にマサチューセッツ州ケンブリッジで開催された最初のMob Programming Conferenceで、Woody Zuill氏がモブプログラミングについてのキーノートを行った。そこで彼は、モビングをやってきた4年間に、誰もが尋ねる質問について語った。InfoQではQ&Aと記事で紹介する。 本記事は、キーノートのふりかえりと、モブプログラミングの導入方法、IT業界における主な問題、モビングに合った他の活動
HTTPLab - Go言語で作られたインタラクティブなHTTPサーバー | ソフトアンテナ
インタラクティブなHTTPサーバー「HTTPLab」。 Go言語で作られたオープンソースソフトで、任意のHTTPリクエストに対するレスポンスを自由に作成することができる特徴を持ちます。 レスポンスのステータスコードのほか、遅延時間や、ヘッダー、ボディなどレスポンスの各データを変更することができるため、HTTPクライアントの作成やテストに便利なツールです。 以下使用法を説明します。 HTTPLabはマルチプラットフォーム対応のGo言語で作られています。macOS、FreeBSD、Linux環境の場合GitHubのリリースページから実行ファイルをダウンロードして利用するのが簡単です。 Macの場合「httplab_darwin_amd64」をダウンロードし、以下のようにして実行します。 mv httplab_darwin_amd64 httplab ./httplab デフォルトポートは100
コマンド一発でソースコード検索＆表示できる「peco」改が凄い！
lestrratさんがやってくれました。 ずいぶん前から、ソースコードを検索して読みやすいコマンドはないかなーと思っていました。個人的にはackで検索して見つかったファイルをlessで開いて再びキーワードを入れて当該行までジャンプしていたのですが、毎回毎回めんどくさい感じでした。コマンド一発でインクリメンタル検索してキーワード周辺のソースコードを読めるツールが欲しいなぁって思ってたんです。 とあるslackでお昼時に、mattnさんと「ほしいですよねー」という話から始まって、vimにあるgrepとかも物色しながら「いいのないねー」とか言ってたらkanさんが「@lestrrat 案件だ」って言い出して牧さんが召喚されてついさっきpecoに必要な機能が追加されてました。速いw ためしにpicotlsの開発ディレクトリでpecoの一行ラッパーperoを起動し、「EVP_Digest」を検索してみ
4+3+2+1 Team Success Factors - Crisp's Blog
I’ve now published a new YouTube video where I present 4+3+2+1 Team Success Factors, a model that captures and describes what you can do to help make your team become strong and successful. These 10 factors are split into four groups. * The first group describes four dialogs we need to have as a team. * Next we have three aspects of hard work. * Then there are two dialogs I need to have with mysel
低レイヤーの歩き方 - るくすの日記 ~ Out_Of_Range ~
この記事は Kobe University Advent Calendar25日目の記事です。 低レイヤー技術(後述)をこれから学びたい人向けの入門記事です。 自身の経験を踏まえ、より多くの人達にこのレイヤーに興味を持ってほしくて書きました。 決して卒論がやばくてAdvent calendarのネタが作れなかったわけでは(ry なぜこんな記事を書いたか いわゆるシステムプログラミングのような低レイヤー(と言って差し支えない)ジャンルって一体何から始めれば良いのかいまいちピンと来ないし、何が面白いのかも分からないと思われている事が多いと思います。 にもかかわらず低レイヤーの魅力や学び方の指針みたいな物を示した、いわゆる入門記事ってかなり少ないんですよね。 本記事はこれからシステムプログラミングを始めたい方や、既にかじってみたが中々先が見えてこない、将来何の役に立つのか不安という方達に読んでい
エンジニア立ち居振舞い: ルーズボールを拾う - @kyanny's blog
お題「エンジニア立ち居振舞い」 チャットや課題管理システムを使って非同期コミュニケーションをしていると、誰かに向けて発せられたけど誰も応答していない、ルーズボールのようなメッセージができてしまう。こういうのを見かけたら、できるだけ拾うようにしている。 Quipper の Slack には #development という公開チャンネルがある。開発者が開発にまつわる話をする場で、開発者向けの #general チャンネルといった位置づけだ（なお、開発者向けの #random に相当する #slackoverflow というチャンネルもある） #development は公開チャンネルなので、開発者だけでなく、営業・マーケティング・カスタマーサポートなどの部門で働く人たちも参加している。時折、彼らがシステムのことで何か困っていて、開発者の手助けが必要なことがある。そういうとき、誰でも構わないか
Visual Studio Development – Introducing Visual Studio for Mac
This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support. Connect(); 2016 Volume 31 Number 12 [Visual Studio Development] Introducing Visual Studio for Mac By Mikayla Hutchinson; 2016 At Connect(); in November, Microsoft is launching a preview of Visual Studio for Mac. This is an exciting development, evolving
ピクトリーの開発で大切にしていること - ピクトリー運営ブログ
2度目のブログです！ みなさんお元気ですか？ id:amachang です 僕は元気です！お米おいしいです（〃）＾ω＾（〃） TechCrunch さんに紹介されました ありがたいことに弊社のアプリ「ピクトリー」が好調です！ 先日、TechCrunch さんでも、ピクトリーについて取り上げていただきましたので、もし興味があればご覧ください 匿名画像投稿サイトから画像SNSにピボットした「Pictory」、中高生人気を集めて月間1億PVを突破 | TechCrunch Japan もっともっとスピード感が欲しい！ 今までは、 id:mizzusano と二人で開発してきたのですが もっともっとスピード感欲しい！ 人材募集しています！ というわけで、このピクトリーをより発展させていくために採用を始めることにいたしました！ Wantedly のページも作ってみたので、もし良かったら見てみてくださ
QA to AQ: Quality Assurance から Agile Quality へ - Qiita
伝統的な品質保証(QA)からアジャイル品質(AQ)へと変わっていこう 2016/9/30、Hillside Group(後述)の代表Joseph Yoderさんが来日され、鷲崎先生と特別セミナーが開催されたとのこと。 そこで紹介された、「QA to AQ: 品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ」というパターンが秀逸で、かつ、日本のアジャイルオーディエンスに興味がある方が多いであろう、と思い、紹介します。 アジャイル開発は徐々に日本の開発現場にも浸透しています。特に、Webサービスを事業としている会社、スタートアップ企業、などでは普通になる一方で、ITを利用する側と開発を請け負う会社が分かれている場合、また、組み込みの製品開発などでも、まだまだアジャイルは浸透が足りないようです。開発部隊と別に、品質保証部がある組織も、組み込みでは珍
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Backlog UI リニューアルの舞台裏 / Backlog Renewal UI
物理サーバを選定する際のポイント – Eureka Engineering – Medium
