タグ

developmentに関するaroma_blackのブックマーク (176)

  • AWS Samples

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    AWS Samples
  • スタートアップの現場で役立つ開発要件のまとめ方

    こんにちは。ハウスマートの高松(@t2kmt)です。 皆さんは開発要件をまとめるのにどんなフォーマットを使っていますか? 開発要件をいい感じにまとめるのって大変ですよね。 ドキュメント整備せずに開発に着手し始めてしまうと手戻り抜け漏れが出てしまいますが、一方で要件定義書をガチガチなフォーマットにするとドキュメントの作成自体の工数が増えてしまいます。 スタートアップはスピードが命。ドキュメントを書きまくって開発が進まないなんて言語道断です。 開発要件の整理はプロジェクトの成否に多大なインパクトを与えますが、ほとんどの現場では企画を考える人にフォーマットが委ねられていることが多いと思います。 今回は皆さんが快適に開発要件をまとめられるように、ハウスマートで利用している mini spec というフォーマットをご紹介します。 mini spec とは mini spec とは開発の要件をまとめる

  • 新機能をつくる前に整理しておきたい10のこと - Qiita

    この記事は CrowdWorks Advent Calendar 2017 13日目の記事です。 はじめに クラウドワークスにて、プロダクトオーナーとエンジニア組織のマネージャーをやっている @teriyakisan です。 (最近は開発業務の比率がだいぶ下がってしまっているのですが)Webエンジニアの経験をベースに、クラウドワークス上の仕事発注者に向けた機能開発のプロジェクトを進行中です。 今回はプロダクトオーナーをやる中で考えることが増えている新機能などの中規模施策を企画するときに、どんなことを整理しておくとスムーズにプロジェクトを始められるかの話をしたいと思います。 クラウドワークスで馴染みのmini spec クラウドーワークスでの小規模な機能追加や機能改修、キャンペーン企画の要件整理を進めるときにはmini specというフォーマットがよく使われています。 これは、2016年に「

    新機能をつくる前に整理しておきたい10のこと - Qiita
  • ソフトウェア開発で学んだが使わなかったもの

    開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング(いまだに「朝会」って言ってる人いないよね?)、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守

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

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

    スピード感のために品質を落とすということはチームの成長を諦めるということ - ネットの海の片隅で
    aroma_black
    aroma_black 2017/06/03
    "プロダクトの品質を支えるために必要なメンバーの成長とその成長のために必要なフィードバックや学習の時間が秤にかけられているのではないか"
  • サービスか受託か。Webサービスを作るということ | F's Garage

    先日、某SIコンサル社にいる方が、まだ転職を悩んでるという前提でのカジュアル面談に臨んだ。その人の転職理由というのは、僕が受託の会社から転職した時に言っていたこととそのままだったので、是非、面接に進んで欲しいと思った。 その一方で、受託からWebサービスに来る人に、よく言うことして、 「受託からWebサービスに来ると、ファンタスティックな案件がなくなってつまらないかもしれないですよ」 と言う話をする。これはどういうことか?というと「技術的チャレンジ」を求めるならば、筋の良い受託の会社にいる方が楽しくて、Webサービスはコードを書いている瞬間から技術的なレガシーを産んでおり、先々に渡って最初の選択の影響を受けるので、あなたの技術力の定義が「話題の言語でコードを書けること」であるならば、Webサービスはあんまり勧めません、という話をする。 当時僕がいた会社は、技術の共通化がまだ進んでおらず自

    サービスか受託か。Webサービスを作るということ | F's Garage
    aroma_black
    aroma_black 2017/05/30
    “人が辞めていくパターンは、A象限の人は、他社によりファンタスティックな技術を求めた場合が多く、C象限の人に難易度の高い技術を渡して、興味の範囲を超えると心折れて辞めていったりします”
  • チームの良さを確認するためにやったこと - Web錯誤

    この記事はProduct Manager Advent Calendar 2016の7日目の記事として書かれました。6日目の記事はgackyさんのおじさん Product Manager サバイバルガイドでした。 はじめまして。GMOペパボ株式会社でディレクターとして働いています。@jitsuzon です。弊社ペパボには「プロダクトマネージャー」という名称の職位や役職は存在しないため、自称プロダクトマネージャーとして、サービスのあれやこれやに関わっています。自称に至った経緯はこちらのスライドをご参考ください。 いきなりですが、みなさんのチームは「良いチーム」でしょうか?どこが良いのでしょう?どのくらい良いのでしょう? この記事では、それをアンケートを用いて定量的に確認する方法について実践を元にお伝えしていきます。最近話題にのぼってくることも多い「心理的安全性」なんかも登場します。 背景 私

    チームの良さを確認するためにやったこと - Web錯誤
  • Googleが開発する最新ビルドツール「Bazel」を使ってみよう | さくらのナレッジ

    Bazelの特徴2:ビルドによってディレクトリを汚染しない Bazelでは、ソースコードやテストデータなどが格納されているディレクトリとは別のディレクトリでビルドやテストなどを行う仕組みになっている。makeコマンドでは意図的に設定や操作を行わない限りソースコードと生成物が同じディレクトリに混在する事態になることが多いが、Bazelではこういった問題が発生しない。 また、ビルドやテストはデフォルトではサンドボックス化された環境で行われるため、ビルドやテストがそれを実行しているシステムに影響を及ぼす可能性が最小限に抑えられている。 Bazelの特徴3:並列ビルド 大規模なソフトウェアではビルド対象が増えるため、ビルドにかかる時間も増える傾向がある。Bazelでは生成物どうしの依存性を自動的に把握し、可能な限り並列でビルドを実行する仕組みになっている。これにより、ビルド時間の短縮が期待できる。

    Googleが開発する最新ビルドツール「Bazel」を使ってみよう | さくらのナレッジ
  • Asshole-driven development

    Sign Up for Berkun’s Best Posts If you sign up to receive his best posts via email, you’ll get a FREE copy of a preview edition of Mindfire plus free chapters from all of his bestselling books. Over 19,000 people have signed up. Newsletter Signup Privacy policy enforced by my Rotweiller. 561 Responses to “Asshole-driven development” I never saw any of the infamous: 1. DNFL (Drunk Now – Fix Later)

    Asshole-driven development
    aroma_black
    aroma_black 2016/12/20
    これのタイトルはクソ野郎駆動開発でいいのかな。
  • Redefining software quality

    aroma_black
    aroma_black 2016/12/05
    ソフトウェア品質の再定義。 品質のヒエラルキー。 デプロイ可能、機能すること、セキュア、高性能、使える、便利、成功する。
  • Atom と PlantUML で快適シーケンス図駆動開発ライフ | DevelopersIO

    サーバーサイド開発担当のエンジニアが「設計と実装を進めようとしている」という背景で話を進めます。 PlantUMLは強い 「認識合わせ」という名目でホワイトボードに図を書いて会話することがよくあります。共通言語で会話してあいまいなところを少なくしたら、マネージャーも安心感がありますし、プログラマも自分がやるべきことに集中できますね。 …3日経ちました。あのとき描かれていたホワイトボードの図のとおりに、実装することになりました。認識の齟齬をなくしてくれた貴重な図です。写真に撮りました。どこに保存してたっけ。やっぱり変更したくなったらどうしましょう。またホワイトボードに書き起こす?DRYじゃないですねえ。 そこで、UML図 が登場します。表現したい図を電子データで作成、保存できて、あとで見るときも役に立ちますね。が、しかし、UML図はそれはそれでやや手間がかかるところもあります。作図を助けてく

    Atom と PlantUML で快適シーケンス図駆動開発ライフ | DevelopersIO
  • System of Record と System of Engagement

    補足を以下に記載しています: https://www.wantedly.com/companies/ikyu/post_articles/42802

    System of Record と System of Engagement
    aroma_black
    aroma_black 2016/11/24
    SoRとSoEどちらかが優れてるので一辺倒にすればいいというわけじゃなくそれぞれの手法の特性に合わせてそれぞれの比率を変えましょうという話。やはり銀の弾丸は存在しない。
  • エンジニア立ち居振舞い: 技術的な暴力を振るわない - futoase

    お題「エンジニア立ち居振舞い」 技術的な暴力を振るわない 何事も初めて、ということがあるだろう。 プログラミングが好きで、かつ業務経験もあり、 いろいろなサービスに手を出している人ですら、初めてやったこと、というのがあるはずだ。 ECサイトをつくるため、CGIの処理、ブラウザからの快適な買い物を実現するために独学した小売店経営の個人事業主。 iOS上でのアプリ開発が解禁されて、初めてiOSアプリを開発するようになったWindows向けアプリケーション開発者。 Go言語が発表され、初めてGo言語でサーバサイド側のアプリを書いたフロントエンドエンジニアAWSLambdaアーキテクチャ == Serverlessという問題の解決、分散の仕組みに心を惹かれHTTPS経由のファイルアップロードの処理をLambdaに寄せたIoTサービスを始めようとしている組込系エンジニア。 Nintendo S

    エンジニア立ち居振舞い: 技術的な暴力を振るわない - futoase
    aroma_black
    aroma_black 2016/11/21
    自分もやることがあるので肝に命じておこう"「お前は未熟」という言葉だけを残し、問題のエレガントな解決手段については指してくれないのだ"
  • トレタの増井さんに聞く、B2Bサービスのカスタマイズ

    今日の夜、トレタの増井さん(@masuidrive)さんと会って晩御飯をべました。下らない話や日企業の海外進出の話などをする中で、B2Bサービスがカスタマイズを受け入れるというのがどういうことなのか、という話が大変面白かったので、許可を得た上でブログ記事にさせてもらいました。 B2Bとは、Business to Businessの略語であり、企業が主に企業に向かってサービスやプロダクトを提供するタイプのビジネスモデルを指す言葉です。対義語がB2C(Business to Consumer)で、企業が主に個人に向かってサービスやプロダクトを提供するタイプのビジネスモデルを指します。B2Bビジネスの場合は契約1口あたりの金額が大きくなる傾向があり、逆にB2Cビジネスは1口あたりの金額はさほど大きくないのが普通です。 自分も昔の会社でB2Bを経験したことがあるのですが、B2Bをやる上で1つ大

    aroma_black
    aroma_black 2016/10/30
    “長い目で見た場合、カスタマイズというのはジワリジワリと影響が発生し、最終的にかなり大きなコストとしてのしかかることもあります”
  • 『茹でたニンジン』 : ソフトウェア開発の失敗と技術について | POSTD

    子供の頃、私はニンジンが嫌いでした。においや感がイヤだったのです。しかし実家を出て、自炊をするようになってからニンジンが好きになってきました。ニンジンそのものが変わったわけでもないですし、私の味覚が変わったわけでもありません。違いは調理法です。私の母や彼女と同年代の多くの英国人は、料理が得意ではなく、特に野菜の料理はイマイチでした。母はニンジンを20分以上茹でていたのです。適切な方法でニンジンを調理すれば、全く違った味になるということを私は学びました。 ここは調理のことを話すサイトではなく、ソフトウェア開発のことを話すサイトです。しかし、技術やツールはおいしくないニンジンと同じだなと思うことがよくあります。それは、「その技術が適切に用いられなかったことが当の問題であるにも関わらず、技術自体が良くないものとして非難される」という点においてです。 いつか例を挙げてみましょう。私の複数の友人

    『茹でたニンジン』 : ソフトウェア開発の失敗と技術について | POSTD
    aroma_black
    aroma_black 2016/10/27
    “その技術が適切に用いられなかったことが本当の問題であるにも関わらず、技術自体が良くないものとして非難される”
  • デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog

    ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属

    デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
    aroma_black
    aroma_black 2016/10/12
    “属人化は三つの悪をうむからだ。三つの悪に「SPOF」「特権と官僚」「お願いします脳の恐怖」という名前をつけたのでそれについて書こう。”
  • 工数見積もりやスケジュール管理で参考になる記事10選

    プロジェクトを遂行するためには、工数の見積もりやスケジュール管理が必要になります。正確な見積もりは難しく納期に間に合わなかったり、残業や休日出勤で埋め合わせたりした経験はありませんか? 今回は、より正確に工数の見積もるための手法や、差し込み作業を考慮したスケジュール手法などについて解説されている記事をまとめました。 マネージャー、エンジニア、デザイナーなどすべての方に参考なる内容だと思います。 開発の見積もりとスケジュール管理 クックパッド株式会社の方が実践している見積もりとスケジュール管理方法について紹介されています。工数を見積もるステップや、スケジュールを立てるときの注意点、スケジュール管理の方法について学びたい方におすすめの記事です。 開発の見積もりとスケジュール管理 不安とストレスから解放される見積りとスケジュール方法 開発をしているとき、納期に間に合わなかったらどうしようと不安に

    工数見積もりやスケジュール管理で参考になる記事10選
  • エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう?(あるいはいったい何がないのだろう?)

    XP 祭り 2016

    エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう?(あるいはいったい何がないのだろう?)
  • tech venture business » 役職の謎:CTO vs. VP of Engineering

    どうも。10月も半ば、Q4はあっという間に過ぎてしまうのが毎年の悩ましいところです。ふと気が付くと、このブログを始めてから既に1年経過しました。早いものです。よく続いたなーと感慨にふけったりしております。 さて、Q4というタームにかこつけて、今日はマネージメントの話をちょっと。 皆さんは役職名の意味することがよく分からず、困ったことはありますか?私はこちらに来た当初、仕事上適切なコンタクト先を検討するに当たり、アメリカ企業の役職名と日企業のそれを比較したり訳したりするのに、結構苦労した記憶があります。最近は外資系の企業等でアメリカ式の役職を使うことも多く日国内でも珍しくはないですが、それでも例えばヴァイス・プレジデントって実際何なの?と思われる方は少なくないのではないかと思います。 これらの役職名はある程度の「こういうことやってる、こういうレベルの人」的な共通認識はあるものの、業界、業

    aroma_black
    aroma_black 2016/09/22
    “VP of Engineeringは現実と鑑みてそのビジョンを実行に移すことを率いる部門のマネージャーで、ギークである必要は必ずしもありません。 ”
  • 開発組織マネジメントのコツ - Speaker Deck

    一人 CTO Night での発表資料です

    開発組織マネジメントのコツ - Speaker Deck