DevLove現場甲子園2015 東日本大会 https://devlove.doorkeeper.jp/events/34344 Read less
試行錯誤と改善を繰り返し、チームの開発力を高めた方法
DevLove現場甲子園2015 東日本大会 https://devlove.doorkeeper.jp/events/34344 Read less
意見を持つ
今のチームのプログラマたちは、製品の機能や UX に意見を持っている。 UX デザイナがおらず PM もおとなしいプログラマ中心のプロジェクトから来た自分は、アプリやサービスの世界でデザイナや PM がどう物事を決めるのか、そこにプログラマがどう絡むのかに興味を持っていた。どうも一筋縄でない。 定例ミーティングではデザイナのモックを前にプログラマたちが細かいレイアウトや動きを議論している。各リリースの計画会議では誰かしら自分の欲しい機能を持ち出す。廊下でデザイナと顔を合わせては唾を飛ばし合っている。ランチで PM と同席するたび何かを申し立てている。 自分はそんな意見がない。開発しているアプリに興味はある。自分で使っているから良くなってほしい。でもアイデアはない。速くてバグがなければいい、くらい。 コードの書き方には意見があるし、開発プロセスやインフラにも言いたいことは多い。バグを減らした
基本設計を分担してはいけない - 設計者の発言
プロジェクトメンバーが無駄に多いのが、日本型SIの特徴のひとつである。「工数を人数で割れば工期が出る」と考えることが間違いであることは、ブルックスの著書「人月の神話」によって今から40年前に指摘されている。それにもかかわらず、相変わらず多くのプロジェクトで必要以上の人数が投入されている。 私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。 なぜか。業務システムにはアーキテクチャ（意図された構造）が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。また、DB構成と
品質の向上に対する取り組み - クックパッド開発者ブログ
こんにちは。ユーザーファースト推進室ディレクターの大黒です。 私が所属しているユーザーファースト推進室では、「クックパッドに訪れた全てのユーザーが、期待する以上の品質に常に触れている状態にする」というミッションを持っています。今回はその中の取り組みの一つである「気になる！報告」という仕組みをご紹介します。 「 気になる！報告」とは スタッフが普段、何気なくクックパッドを使っている中で、気になったことを簡単に報告することができる仕組みです。休日や外出先などでは、気になったことを後で担当部署にフィードバックしようと思っていても、ついつい忘れてしまいます。そこでサイト内に「気になる！報告」のリンクを設置し、いつでもどこでも報告できるようにしています。 スタッフアカウント*1でログインすると、クックパッドのフッターエリアにスタッフにしか見えないリンクがあり、どのページにいてもすぐに報告をすることが
プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
開発スピードをあげるには - パルカワ2
「開発スピードをあげろ！」と言われる事は多々ある。 実際にチームの開発スピードが遅かったとしたら、それは開発チームがなにかしらの問題を抱えている事になる。それに対して、偉い人達は「とりあえず開発者を増やせばスピードがあがるはず！」と人を追加する。しかし、根本的な問題は解決していないので、大きくスピードは上がらない、もしくは逆に遅くなってしまう事がある。 開発にかかる時間をざっくり分解すると「仕様決め」「コードを書く」「検証」の3つに分ける事が出来る。つまり「仕様決め」「検証」を効率良く進めて「コードを書く」時間を増やす。また「コードを書く」事自体を効率良く進める事が、開発スピードを上げる事だと考えられる。なので、3つのフェーズの問題点とそれらの解決方法を考える必要がある。 例えば、「仕様決め」の問題点は 仕様が決まらず、MTGの時間が長い 仕様を決める人がいない 誰かに確認する事が多い 開
OSS についてあれこれ
2019/01 JSUG勉強会の資料です。 この資料でDisっているのはJPAではなく、 ・何も考えずに「標準だから」というだけでJPAを選ぶ人 ・OSSに全くコントリビュートせずにフリーライドする人 です。
ソースコードを読むときの3つのステップ - 弥生開発者ブログ
はじめに はじめまして。お盆明けからMisocaでインターンをしているhmryuです。Misocaにジョインする前は、個人でサービスを作ったり、研究でプログラムを書いたりしていました。 一方で、チームで開発する経験はあまりなく、Misocaにジョインした始めの頃は慣れないことばかりでした。中でも、他人の書いたソースコードを読んで理解することが、一番大変だったかもしれません。 そこで今回は、機能追加・変更を加えるためにソースコード*1を読む上で、僕が大切だと感じた3つのステップについて書きたいと思います。 1. 機能とソースコードの対応を調べる まず、自分が変更を加える機能がどんなもので、どこに実装されているのか理解する必要があります。実際にサービスを動かして、どんな機能なのかを確認します。その後、その機能がソースコードのどの部分に対応するのかを調べます。 例えば、メール送信について調べる場
安全なリリースのために心がけていること - クックパッド開発者ブログ
こんにちは。会員事業部の高田です。今回は安全にリリースをするために、アプリケーションエンジニアとして心がけていることについて書きます。 クックパッドではなるべく早くユーザーに価値を届けることを大切にしているため、1 日に何度も安全にリリースできるしくみや、リリース後に発生したエラーにすぐに気付けるしくみがあります。しかし、アプリケーションレイヤーの問題はアプリケーションエンジニアが気をつけなければいけません。私個人としては、少し気をつければ防げた問題を起こしてユーザーや会社に迷惑をかけてしまった経験があるため、注意深くなっています。 プロジェクトの大きさや目的はさまざまあり、早くリリースして検証したい施策などもあると思います。今回は慎重にリリースしたいプロジェクトの例として、有料会員の解約の前に特定のユーザーにのみクーポンを配布するという架空のプロジェクトを元にお話します。 1. 準備 リ
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
第1回 事業会社における開発とポエム | gihyo.jp
この連載ではピクシブ株式会社という東京にある事業会社で盛んになっている「ポエム」によって駆動する開発について、その特徴をお話します。第一回は舞台となっているピクシブという会社はどのような環境か、その会社で書かれている「ポエム」とは何なのかをお話します。 「ポエム」で開発を駆動するとは 駆動開発という言葉はソフトウェア開発文脈でよく使われます 例えばテストコードによって開発を駆動するテスト駆動開発という言葉は開発者にとってお馴染みでしょう。 ではポエム駆動開発という言葉を聞いた事はあるでしょうか？ ポエム駆動開発のオリジナルはppworks氏によるポエム駆動開発によるWEBサービスの作り方 pplog誕生ものがたりというエントリーで発表された手法です。 意思決定の際大事なのはポエムなのです。「pplogのポエムは俺たちのゆるふわインターネット「pplog」 をリリースしました（してまし
いけてない設計に出会ったときに考えること - hitode909の日記
どこがいけてないのか？ クラス名とか、機能名とか、概念とか、名前があると考えやすくなる まだ名前なかったら新たな抽象が見つかるかもしれない どんな経緯でそうなっているのか 最初は抽象を捕らえられていたのが拡張を繰り返すうちに失われたのか、書かれた当初は単純な仕様だったのが膨れ上がったのか、動けば良いという感じで書かれたのか 今の設計のいいところは？ 何か意図や事情があってそうなってるのか、動いてるだけなのか 詳しい人や書いた人に気に入ってるところを聞いても良い みんなどう思ってる？ みんなおかしいと思ってるけど手が出せないのか、これでいいと思ってるのか、など雑談して聞いて回る 最高の状態ならどうなってるべき？ 正しいモデリングや、すごい技術があったら、どうなるか 鋭い分析によって豊かなドメインを得られたり、リコメンドシステムなら脳波を読み取って直接推薦してくれたり、変なドアで世界中好きな場
世界最強のソフトウェアアーキテクト
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは！ マーケティングソリューションカンパニー（MSC）開発本部の小川雄大です。 昨年11月に子会社のクロコスからヤフーに移りまして、現在はヤフーで開発を行っています。みなさまどうぞよろしくお願いします。 MSC開発本部では、ヤフーが世界最強を目指してどう取り組んでいくかについて議論する会を毎週開催しています。今回はそこで今年の1月に僕が発表した「世界最強のソフトウェアアーキテクト」について公開したいと思います。 今回はヤフーに入ってはじめての発表ということもありテーマをどうしていくかはかなり悩んだ部分なのですが、テクニックよりもアーキテクトが持つべきマインドを共有することが次につなげていく上で大切になると考えたので、多少抽
ピクシブ広告サーバー開発・運用の軌跡 2015春インターン講義資料
2015春インターン講義資料 これの続編です ピクシブ新広告サーバー構築物語 // Speaker Deck https://speakerdeck.com/catatsuy/pikusibuxin-guang-gao-sabagou-zhu-wu-yu
アプリで利用する画像について - クックパッド開発者ブログ
ユーザーファースト室のhidaka（@kaa）です。 クックパッドアプリ内では元々同じレシピの画像を画面、環境によって様々なサイズで表示しています。 レシピの検索結果でのサムネイルや、レシピ詳細画面、写真の拡大表示時などなど。 その際、端末の解像度にあわせ無駄のないよう、表示領域にあわせて画像をリクエストしていました。 *画像配信にはtofuという配信システムが稼働しています http://www.slideshare.net/mirakui/ss-8150494 これでそれぞれの端末にあわせた画像を配信していましたが、今年あたりからさらに最適化が必要になってきました。 問題1 画面密度の上昇 端末のスペックが上がることにより、１インチあたりのピクセル数が増加しました。 retinaと言われていたiPhone 5で326dpiだったのが去年あたりからの高解像度端末の幅1440pxの機種(a
フロントエンドとバックエンド | POSTD
バックエンドエンジニアとフロントエンドエンジニアの違いは、前者は1つの環境で仕事をするのに対し、後者は予期せぬことが起こる可能性のある数多くの環境で仕事をするということにあります。 「複雑なJavaScriptで動くWebサイトやWebアプリが動作する環境は、単一的で一枚岩のものである」――この無意識な思い込みこそが、バックエンド中心に開発されたWebベースプロジェクトにおいてフロントエンドエンジニアが目にする問題の根本的な要因であると私は考えています。 さらに悪いことに、バックエンドエンジニアは、フロントエンドエンジニアよりも複雑なアプリケーションを構築するのに長けていると考えています。実際そうなのかもしれないのですが、好ましくないのは、彼らの中にはフロントエンドについて学ぼうという意識に欠けている人がいることです。 アプリケーションの構築において、数多くの困難な環境に対応するフロントエ
ラクスルの開発環境・開発体制 Early-2015 - RAKSUL TechBlog
12月に入社した @okapon_pon です。 ラクスルには8人目の開発メンバーとしてジョインしました。（インターン生１人を含む） 現在ラクスルではサービスの機能拡充と合わせて、開発環境改善プロジェクトというものに着手しつつあります。 私が入社した当時の開発環境は、弊社大嶋が以前書いた「ラクスルの開発フローについて」 にある通りGithub、skype、redmineを利用しており、加えてmediawiki、Gyazo-client、cacooといったツールを利用しています。 これらのツールは今でも利用しているのですが、私が入社してからの3ヶ月ほどで開発環境・開発体制も変わってきましたので紹介したいと思います。 コードレビュー体制 コードレビューにはGitHubを使っています。今どきの開発では珍しくないと思います。 ですが、これまでは少人数のスピード重視で開発していたということもあり、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ログイン - はてな
STF | Smartphone Test Farm
営業さんまで、社員全員がSQLを使う 「越境型組織」 ができるまでの3+1のポイント | リブセンス
