[B! チーム開発] kyokomiのブックマーク

スピード感のために品質を落とすということはチームの成長を諦めるということ - ネットの海の片隅で

サービスを開発していると、スピードが重視される。そのこと自体にはまったく問題はなくて正当なことだと思っている。ユーザーに対して一刻も早く価値を届けるためには必要なことだ。そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。逆に、技術力が高くない人が時間をかけて作ったとして

kyokomi 2017/06/02

チーム開発

リンク

クソゲーを作る組織とそうでない組織 2012 05-12

2014/09/03(水) に行った講演です【CEDEC2014】ニコニコ動画の「ゲーム実況」はなぜ人気？ゲーム売上への貢献、使いこなすための注意点、人気実況者になるためのコツも…！ http://www.gpara.com/infos/view/15977 「CEDEC 2014」生中継２日目（基調講演＋メインホール） - 2014/09/03 09:45開始 - ニコニコ生放送 http://live.nicovideo.jp/watch/lv191086165

kyokomi 2015/02/24

リンク

クソコードと呼ばない - ppworks.jp

新しい現場にはいったときに心がけていること、クソコードと呼ばないこと。誰かのコードを読んでいるとそりゃまあクソコードを見つけることがある。その時どう立ち向かうかという精神論の話。例えソレがそうであってもソレを口にするとネガティブが蔓延する。思ってもイイ、でも言ってしまってはならない。あるフェーズに置いては必要だったし、現に動いていて価値を提供しているのだ。あるべき姿を叫ぶの簡単だ。あるべき姿を見ているなら行動しないといけない。見つけたらリファクタだ。出来るところからやるんだ。 Shut the fuck up and write some code & 許可を求めるな Pull Request せよ— 🌈KOSHIKAWA (@ppworks) 2014年5月23日クソはクソと言える空気や文化は大事。良くないものを指摘できるようにはしたい。口の前に手を動かそう。プログラマーなら

kyokomi 2015/01/17

チーム開発

リンク

ゲーム開発を知らずにゲームが作れるか　島国大和のド畜生

・2023年03月 (1) ・2023年02月 (1) ・2023年01月 (2) ・2022年12月 (1) ・2022年11月 (3) ・2022年10月 (1) ・2022年09月 (1) ・2022年08月 (1) ・2022年07月 (1) ・2022年05月 (2) ・2022年04月 (1) ・2022年03月 (1) ・2022年02月 (1) ・2022年01月 (1) ・2021年10月 (1) ・2021年08月 (1) ・2021年07月 (2) ・2021年05月 (1) ・2021年04月 (1) ・2021年03月 (1) ・2021年02月 (1) ・2021年01月 (1) ・2020年12月 (1) ・2020年11月 (1) ・2020年10月 (1) ・2020年09月 (1) ・2020年08月 (2) ・2020年06月 (2) ・2020年04

kyokomi 2014/10/30

　"「攻撃が当たったら２０ダメージ」"最近こんなのばっかりでグッタリしてる

チーム開発

リンク

プライベートで3年間チーム開発した話 YAPC::Asia Tokyo 2014 前夜祭欲しいものは作ればいい！〜Webアプリ10連発〜土谷光 (@hika69) | Stobo

このスライドは Markdown でプレゼンテーションが作成できるサービス Stobo で公開されています。

kyokomi 2014/08/28

リンク

会社に Github導入した話

パターン QA to AQ: 伝統的品質保証（Quality Assurance）からアジャイル品質（Agile Quality）へHironori Washizaki

kyokomi 2014/07/16

いい話だった！！

リンク

伊藤直也が語る「仕事の流儀」第3回──OSSプロジェクトのように組織をつくる｜CodeIQ MAGAZINE

伊藤直也氏が語る「仕事の流儀」の第3回は、暗黙知を作らない組織の作り方。オープンソースのスタイルで組織を作ればいいという直也氏は、KAIZEN platform Inc.において、どのような行動をとっていたのか。ある取り組みによって、KAIZEN流の行動哲学が生まれたという事例をもとに語っていただいた。 by 馬場美由紀（CodeIQ中の人）暗黙知を作るな、すべてを形式知に変えよ前回は、Sqwiggleを活用したリモートワークやGitHubを活用した開発について述べました。開発プロセスは、まあアジャイル開発っぽいですね。アジャイル開発というか、スクラムで求められている他のプラクティスについて、KAIZENのリモートワークではどのようにやっているかをもう少し説明すると、まずデイリースタンドアップ、いわゆる朝会です。リモートでやってるので、スタンドアップといいつつ立ってはいないんです

kyokomi 2014/07/15

リンク

暮らしの情報サイトnanapiはサービスを終了いたしました | nanapi [ナナピ]

2020年8月31日(月)をもちまして、nanapiに関わるすべてのサービスは終了いたしました。 nanapiは、2009年のサービス開始より「みんなで作る暮らしのレシピ」という考えのもと、ユーザーの皆さまに生活に関する様々な「ハウツー」を投稿していただく投稿型ハウツーサービスとして運営してまいりました。約11年間にわたって皆さまからご支援をいただきサービスを継続できたこと、nanapi編集部一同、心より御礼申し上げます。掲載されていたコンテンツなどのnanapiについてのお問い合わせは、nanapi@supership.jp までお願いいたします。長きに渡りnanapiを応援してくださり、本当にありがとうございました。

kyokomi 2014/07/15

チーム開発

リンク

チームの想いをなんでも共有する「ゆるふわ」「ポエム」タグが議論のきっかけに - freee株式会社 Qiita Teamインタビュー - Qiita Blog

チームの想いをなんでも共有する「ゆるふわ」「ポエム」タグが議論のきっかけに – freee株式会社 Qiita Teamインタビューこんにちは！ htomineです。みなさんのチームには「気兼ねなく情報発信できる場所」はありますか？今回は、Qiita Teamをそんな場所としてご活用いただいている、freee株式会社さんの事例をご紹介します。サマリーポイントをまとめると使い方の指針になるような記事をはじめに投稿してから徐々に広めた開発ドキュメントにかぎらず、仕事のフローの改善案、自分の想いやライフハック的な記事など、メンバーに伝えたい様々な情報を投稿してよい場所として使っている目次freee株式会社Qiita Team導入の経緯導入前の課題使い始めてみてどうだったか―どんな記事が投稿されていますか？―社内に広まるきっかけは何だったのでしょうか？今までのツールではこういった投稿はでき

kyokomi 2014/07/09

ポエムいいなー！

リンク

nanapiの開発現場をどのようにして回しているか

よいチームをよい雰囲気を保ったままよい組織にスケールさせていくためにできること / What you can do to scale a good team into a good organization

kyokomi 2014/07/08

リンク

[※削除しました] 無料でイントラネット内にナレッジ/ノウハウの共有ができる「Lodge」 - Qiita

という記事でしたが、コミュニティガイドライン - Qiita:Support に反しているようでしたので、大変残念ですが削除させていただきました。他のテクニック系の記事なども、「プログラミングに直接関係するか」と聞かれると怪しいものが多いのですが、消すかどうかはまだ迷ってます。 Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

kyokomi 2014/06/24

リンク

はてなブログチームの開発フローとGitHub

6/1 github kaigi

kyokomi 2014/06/01

リンク

開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;

最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。小さく導入する短く導入する振り返る小さく導入するなんか導入する時は出来るだけ小さく導入してる。理由はいきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊するいきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続けるみたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。小さく導入する方法はいくつかあってスクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくするチーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく

kyokomi 2014/05/14

チーム開発

リンク

「チーム開発実践入門」勉強会

忙しい人のための Rocky Linux 入門〜Rocky LinuxはCentOSの後継者たり得るか？〜

kyokomi 2014/05/10

リンク

LINE iOSアプリ開発についてのご紹介 LINE Engineers' Blog

[English version] はじめまして、LINE 技術戦略室のhayaishiです。趣味は自転車と言っていますが最近は全く乗っていません。この記事では、LINEのiOSアプリ開発に関することをいくつかご紹介させていただこうと思います。 LINEのiOSアプリ開発環境ソースコード管理ソースコードはgitで管理しています。gitのリポジトリブラウザとしてGithub Enterpriseを利用しており、Githubでお馴染みのPull Requestなどを活用して開発を進めています。また、LINEのiOSアプリのタスクについてはGithub Enterpriseとは別のチケット管理システムを利用しておりそちらのステータスと連携して開発者、QA、プランナー間の開発状況の共有を行っています。 Gitでの開発フローについて LINEのiOSアプリはgithub-flowの様に

kyokomi 2014/04/22

タイトル見てLINEゲームの話かと思ってスルーしかけた^^;

リンク

『チーム開発実践入門』という本を書きました - ikeike443のブログ

2年くらい前に技術評論社さんから「チーム開発に役立つツールや方法論をまとめた本を書かないか」とお声がけいただきました。それから構想1年（ぼんやりしてた）、執筆に1年かけて（週末がなくなった）、ようやく4月16日に発売できそうなところまで来ました。今印刷所でゴインゴイン刷っていると思います。技術評論社さんのページを見てもらうと、表紙画像もアップされてますね。 http://gihyo.jp/book/2014/978-4-7741-6428-1 Amazonさんにもページができていますが、まだ表画像はアップされてません。チーム開発実践入門 ~コラボレートを円滑に行うツール・方法論 (WEB+DB PRESS plus) 作者: 池田尚史,藤倉和明,井上史彰出版社/メーカー: 技術評論社発売日: 2014/04/16メディア: 単行本（ソフトカバー）この商品を含むブログを見る目次もま