組織のサイロを打破する！エンジニアがオーナーシップを持って共創する開発プロセス「インナーソース」
このセッションでは、組織のサイロを打破してエンジニアが幸せにコラボレーションするための考え方である "インナーソース" について紹介します。 サイロ化した組織においてはコラボレーションが困難となり車輪の再発明が繰り返されることになってしまいます。そんな組織ではソースコードの共有やオーナーシップ確立が不十分であるため、コードの管理やメンテナンスに関する情報が不透明になっていることでしょう。 これらの課題に対処するため、アメリカやヨーロッパの大手企業が2015年から取り組み始めた活動が インナーソース です。この取り組みは、オープンソースのコラボレーションモデルを企業内に導入することで、エンジニアたちが風通しの良い環境で働けるようにし、エンジニア文化や組織の改善を促すものです。 インナーソースが実践されているのは Microsoft や Adobe などの Tech企業だけにとどまらず、ボッシ
GitHub PR毎に独立環境を構築することにより開発効率を向上させました！ - JMDC TECH BLOG
株式会社JMDCに6月に入社しました @dtaniwakiこと谷脇です。 github.com 現在、Pep Up for WORKという企業向けヘルスケアプロダクトをフルスタックで開発しており、今回は開発プロセス改善の取り組みについて紹介させていただきます。 info.jmdc.co.jp Pep Up for WORKではtoBサービスとしての品質を担保するため、PdMによる動作確認を行っています。一方で、非同期で開発に参加しているメンバーが多いため、この動作確認の効率化が非常に重要となっています。 以前の動作確認フローと仕組み 私が入社する前は、ステージング環境とは別にdev環境というPdM確認用環境を１つ用意して、以下のようなフローでデプロイを行い、PdMが動作確認をしていました。 以前の動作確認環境の仕組み このフローでは以下の２通りのパターンのデプロイが行われます。 複数のGi
エンジニアの活動情報からFour Keysを集計、可視化した話 - Pepabo Tech Portal
データ基盤チームの @udzura です。今回は、昨年の後半にかけてデータ基盤チームで取り組んできた、開発者の生産指標である Four Keys の可視化についてお話をします。 Four Keysとは何か 生産性ダッシュボードプロジェクトの全体図 開発活動のExtractとLoadパイプライン 取得したデータのTransform ビュー部分 まとめと今後 画像について Four Keysとは何か 始めに、Four Keysについての説明をします。 Four Keysとは、GoogleのDevOps Research and Assessmentチームが6年間の研究の結果割り出した、ソフトウェア開発チームのパフォーマンスを示す4つの指標のことです。 詳細はGoogle Cloudのブログ記事「エリート DevOps チームであることを Four Keys プロジェクトで確認する」などをご確認
Pull Requestから社内全チームの開発パフォーマンス指標を可視化し、開発チーム改善に活かそう - Hatena Developer Blog
こんにちは。id:shiba_yu36です。MackerelチームでWebアプリケーションエンジニアをしています。最近の開発合宿で、id:syou6162やid:polamjagと一緒に、社内の全チームの開発パフォーマンスを表す指標をGitHubのPull Requestから可視化し、開発チームの改善に活かせるようにしました。今回はその紹介をします。 説明するサンプルコードは、次のレポジトリで公開しているので参考にしてください。ここではGitHubのhatenaオーガニゼーションで集計していますが、forkして少し手直しすれば、別のオーガニゼーションの集計も可能になっています。 hatena/pull-request-analysis-sample 開発チームの改善におけるいくつかの課題感 開発チームのパフォーマンス指標に何を使うか 4つの指標のうち何からまず集計するか 変更のリードタイム
GitHubをフル活用してカンバン(Kanban)方式による開発体制を構築したノウハウを惜しみなく公開する - Qiita
簡単な自己紹介 渋谷のとあるプログラミングスクールを経営する会社でCTOを担当しています。 昨年、2019年3月にこの会社にジョインしてから開発から新商品企画まで幅広く担当してます。 背景 2019年3月に私が入社した時、システム開発の案件管理に色々と問題がありました。 それらの問題を各ステークホルダーにヒヤリングして問題点と解決案をまとめて社長に提案し、社長の賛同を得て開発体制の構築を進めてきました。 この度、ようやく開発体制の構築ができて順調に開発案件の管理、運用できるようになってきたので、今回、他の会社の参考になればと思ってまとめてみました。 弊社の組織体制 組織としては、CEO（社長）をトップとして、以下チームが下にある形です。 私は、CTOとして開発チームのマネージャーを担当しています。 開発体制の問題点をステークホルダーの声を聞いて整理した 問題の解決にあたって、まずは各ステー
【GitHub】少人数のチームで開発するときのGitHubのブランチ運用Flow - Qiita
概要 少人数のチームでGitHubを用いてプロダクト開発するときのブランチ運用フローについて． GitHub Flowを参考にシンプルさと運用のしやすさを重視している． チームの全員が6つのルールを守るだけで，masterが綺麗な状態で保たれる． 全体像 6つのシンプルなルール 1. master は本番環境にデプロイされているバージョン 2. develop はテスト環境にデプロイされているバージョン 3. feature ブランチ（作業ブランチ）は develop から分岐する 4. feature ブランチは頻繁に push する 5. pull-request（PR）で develop にマージする 6. マージされた feature ブランチは削除する 実際の作業例 1. develop からある機能を実装する作業ブランチを作る
高速で無駄のない開発をするチームのための"７つ道具"（2014/03/08 - Websig）
パーソナルなアイディア出し会における、ブレインストーミングメモ。コンテンツサービスのアイディア"MogMog"。ユーザーは手元のローカル音楽を再生しつつ、地理的な移動によってコンテンツを獲得できるフリーミアムサービス。感想・チョイ足しアイディア募集。また、アイディアを使いたい方は一報の上、ご自由にどうぞ。 Written in Japanese. Idea brainstorming notes about a new Content Service "MogMog". Music on Geograph. The user can listen the songs he/she has already had, and also he/she can get new content by walking around some geographical spot. Freemium Mo
GitHub実践入門が3/20発売 現場で使える実用的なガイド | Act as Professional - hiroki.jp
3/20(木)に日本語で初のGitHubに関する書籍（雑誌を除く）である「GitHub実践入門 ~Pull Requestによる開発の変革」が発売されます。304ページにわたる現場で使える実用的なガイドを目指して執筆しました。 本書は、世界中の開発者が行っているGitHubを利用した開発方法を、みなさんが現場で使えるようになるためのガイドとして執筆しました。よって、GitHubの解説だけにとどまらず、開発ワークフローやそれを支えるほかのツールにも踏み込んで解説しています。 現場で使えるノウハウが凝縮されたGitHubのガイド本書は現場でGitHubを徹底的に活用するために、UIの解説、Gitの操作、実際に手を動かしながら試せるPull Request、開発ワークフロー（GitHub Flow, Git Flow）の解説、Jenkinsなど開発を支えるツールのGitHubとの連携について丁寧
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デプロイ頻度を10倍にした、ブランチ戦略とGitHub Actions on AWS ECS
Mini Tokyo 3D 開発日誌
@vvakame氏によるGitHubで簡単！コントリビューション！