なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集していま
情シスの仕事こそ、クリエイティブでおもしろい！ 12000人以上が利用するヤフーの社内システムづくり【デブサミ2018】
やや保守的とも思われがちな情報システム（情シス）部門。ビジネスの根幹を支える重要な役割にも関わらず、控えめな印象を持たれる傾向にあるようだ。しかし、入社以来、ヤフーの内製社内システムの企画・開発・運用に携わってきた伊藤康太氏は「情シスほど面白い仕事はない」と断言する。その熱い思いと共に、ヤフーの社内システムの詳細と、あえて「内製」にこだわる理由が語られた。 講演資料：ヤフーを支える社内システム 講演の模様（動画） ヤフーの社内システムを紹介します（Yahoo! JAPAN Tech Blog） ヤフー株式会社 システム統括本部 プラットフォーム開発本部 クリエイターエバンジェリスト 伊藤康太氏 情シスの役割はコミュニケーションの効果を最大化すること 「情シス部門」と聞いた時、そこに携わる人についてどのようなイメージを持つだろうか。「販売されている業務システムを導入する購買・調達的な仕事」「
コードレビューの高まった言葉 - 職質アンチパターン
ブログ間違った，普段こういう事はこっちに書いてます． http://moznion.hatenadiary.com 最近自分がコードレビューで使いがち，あるいは表立って使ってないんだけど内心評す時に使う言葉が色々とあり，まとめてみることとした．参考にしない方が良いと思う． 左は言葉，右は説明． 屈強 - コードが力強い時に使う．例えば長い一枚スクリプトとか，コメントが一切ないバッチ処理とか．やや批判的な意味合いで使うことが多い． マッチョ - 屈強と同じ文脈で使いがち 屈強だけどしなやか - 屈強だけどしなやかな時に使う．好意的な屈強さと言える． モノリス - 長大なトランザクションスクリプト見た時とかに使う．やや批判的． 言い訳ないですか - 後で直していくぞ！ というメンタルの時に書かれたコードのコメントが案外少ない時に使う言葉．言い訳は無いよりあった方が良い．実際には「もうちょっと言
2人で楽しくサービスやアプリを作る話
YAP(achimon)C::Asia Hachioji 2016mid in Shinagawa Talk 7/3 10:00- スライド資料です 子供のころは、秘密基地作ってる最中が一番楽しかったりしました。小さいサービスやアプリを2人で作るときに、企画・設計・開発を「2人で」楽しく進められるように、いくつかのサービスで行ってきた具体的な事例をベースに、簡単にできる方法を話します。 - アイスブレイク - ものづくりのフローを楽しく - ものづくりのフロー - ブレストの基本 - ホワイトボードの基本的な使い方 - スケジュール調整の基本 - イメージをすり合わせて一緒に形にしていく - リード・ファーストフォロワーを2人で使い分ける - アドホックペルソナと簡易シナリオ - リアルの時間を楽しく過ごす - メッセージやりとり - 開発合宿
Mackerelチームのリモートワーク体制における日報とデイリースクラム - Hatena Developer Blog
日報を継続する方法があったら教えて欲しい、id:Songmu です。最近はMackerelチームのディレクター兼デベロッパーをやっています。 リモートワークと情報共有 Mackerelは、8名程度で開発しており、開発メンバーは京都・東京・愛知の3拠点に散らばっており、リモート勤務も各自の裁量で行えるようになっています。 リモートワークにおいては細かい情報共有をなるべく労力をかけずに行うことが必要になりますが、そのために以下のようなツールを利用しています。 開発手法としてスクラムを採用 Hatena::Groupによる情報共有 Github/Zenhubを用いたプロジェクト管理 Slackでのチャットコミュニケーション Zoomによるオンラインミーティング Mackerelチームでは、Hatena::Group上で日報を書くことを推奨しており、今回はその話です。 Mackerelチームの一日
雑な発想を活かすチーム作り - クックパッド開発者ブログ
インフラストラクチャー部の成田（@mirakui）です。インフラストラクチャー部は、クックパッドで扱っている全サービスのサーバを設計・構築し、運用しているチームです。2015年3月現在、6人のメンバーで運用をしています。 さて、この運用というのは外から見ていると保守的な仕事に思えるかもしれませんが、その実、とてもクリエイティブな仕事です。クックパッドのサービスは一日平均で10回以上デプロイされており、アクセスも日々増え続け、状況は刻一刻と変化しています。今日動いているサーバ構成が、一年後に通用するとは限らないわけです。そんな変化に追従するためには、サーバを常に改善していかなければなりませんし、チームにも柔軟な発想が求められます。 「さあブレストしよう」→アイデア出ない問題 さあ業務を改善しよう、と意気込んでブレインストーミングを開いても、なかなか十分なアイデアが出きらないのはよくある話です
2014年にリモートで試したミーティング類のパターン - はまさき
今年の初めからアメリカに引っ越したので社内の人とのやり取りをどうするかという悩みに現実的に直面し、この1年で色々試したのでセーブポイントとしてまとめておくことにした。（ブログの記事を書かなさすぎてはてな記法忘れつつある...） チームとミーティングの距離感 8人くらいの会社。誰もがSPOFで、何かに詳しい人間はだいたい一人に絞られる*1。会社として重要な箇所に一人だと心許ないというより、誰も休めなくなってしまうので概ねわかるだろうという他者を含めるか、共有するなりで冗長化して、2人以上がひとつの何かに取り組んでいる形を組織中に点在させている。 その2人の間や異なる担当間でそれぞれミーティングの時間を取っておきたいが、大仰に週例、月例、毎朝のスタンドアップみたいなミーティングをそっくり入れ込むにはちょっと負荷が大きいので何か工夫が必要だ。 勤務地は強制していない。オフィスはあるけれど必要にな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
