スクラムを通じてアジャイル開発の良さに気づいたPMのはなし / The story of a PM who realized the goodness of Scrum Agile developmentスクラムフェス大阪2023（2023/07/01） https://www.scrumosaka.org/
伊藤直也氏が「Web開発は高度化している」と語る理由と、押さえておきたい3つの技術領域【2014年前半のインプットlog】 - エンジニアtype
KAIZEN platform Inc. Senior Technology Advisor 伊藤直也氏（@naoya_ito） 2002年に新卒入社したニフティでブログサービス『ココログ』の開発担当となり、一躍有名になる。その後、はてなで『はてなブックマーク』など各種サービスを立ち上げ、2010年にグリーへ入社。2012年に同社を退職して以降は、フリーランスとしてベンチャーの技術顧問などを請け負う。自身のブログ『naoyaのはてなダイアリー』が人気 「Webアプリの実装で差別化は無理」という考えが変わった 現在、KAIZEN platform Inc.をはじめ複数社の技術顧問を務めている伊藤直也氏。「普段から、アウトプットの目的なく技術の勉強をすることはほとんどない」という性分から、今年上半期は「顧問としてベストプラクティスを提供するために知っておくべき領域」にフォーカスして情報収集を
Modern Java Web / SPA Development
JJUG CCC 2014 Spring の発表資料です。
アーキテクチャ設計に品質特性を使おう - arclamp
アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。 このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。 利害関係者にインタビューをして重視しているポイントを聞き出す そのポイントからシステムに求められる品質特性を整理する 整理された品質特性を元に、実際のアーキテクチャの設計を行う 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う 品質特性というのは色々なところで定義がありますが、経産省が公開している「情報
誰も欲しがらないかもという恐怖
先日、弥生会計やFreeeをサポート、爆速で会計入力できる青色申告アプリTaxnoteをリリースしましたという記事を書いたら、想像以上に反響があった。 これは確定申告の時期的なものもあると思うけど、作っている最中は常に”そこまで需要はないかも..”という恐怖との戦いだったので、ニーズがありそうでよかったです。 いつもなにかアプリを作る時は、実際にコード書き始める前に需要があるか少しでも把握できないか考える。 それはもちろん時間かけて作っても誰も欲しがらなかったというリスクを避けたいからに他ならないのであるが、結果的に、今回もほとんど何も分からず作ってリリースすることになった。 時間と効果のバランスでいろいろ選択肢を試したけど、結局リリースまでにほぼ何もわからなかったという過程を書いてみる。 コンセプトページで需要リサーチを検討 まず、去年自分が青色申告するようになって、日々の仕訳入力を素早
ベンダーよ、シェルパの屍を越えていけ ～ 細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」
ベンダーよ、シェルパの屍を越えていけ ～ 細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」：Developers Summit 2014 リポート（1/2 ページ） リスペクトなきプロジェクトには死が待っている―― 山本一郎さん（やまもといちろう a.k.a.切込隊長）と、東京地方裁判所 民事調停委員 細川義洋さんによるDevelopers Summit 2014の最終セッションは、雪の寒さとは違う意味で会場を震え上がらせた。 2014年2月14日、関東地方は記録的な大雪に見舞われ、各地で交通機関の混乱が発生した。都内の企業が続々と社員に向けて帰宅勧告を出す中、「Developers Summit 2014」の会場は熱気に包まれていた。 今年14回目を迎えるDevelopers Summitは、「技術者の、技術者による、技術者のためのカンファレンス」で、最前線の技術者による解説や
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
JavaScriptフロントエンド開発の昨今
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
テスト駆動開発を継続する
2013年はじめのTDD Boot Camp in 大阪 外伝 の資料です。 http://kokucheese.com/event/index/64957/
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 Domain-Driven Design ( DDD ) 準備 ／ スタートアップ ／ ブラッシュアップ ／ チャレンジ ／ 参考書籍 ／ Read less
ダメなシステムが無くならない理由はエンジニアを正しく活用できないから - GoTheDistance
Twitterで流れてきたのでつい見てしまいましたが、この方の連載は全体的にやっつけ感が否めないですね。 なぜ“ダメなシステム”は無くならないのか？ - なぜ“ダメなシステム”は無くならないのか？：ITpro この"ダメだしとっつあん"があの手この手で言わんとしてることは｢上流工程と下流工程の分断は悪であり、ダメなシステムはそこから生まれている｣ということですので、この記事を読んだ人は連載読まなくて大丈夫です。僕が書いたこのエントリ読んでください。もっと突っ込んで書いてあります。 ｢SIerでのキャリアパスを考える｣というイベントに登壇しました - GoTheDistance もうそろそろぶっちゃけてもいいでしょ。ダメなシステムができる理由は簡単だってことに。ウオーターフォールが逆流できないせいだ/丸投げするからダメ/リスクをとらないからダメ/技術力のないやつが舵を取るからダメ・・・ってさ
リーンカンファレンス2013に行ってきた - numeha's blog
リーンカンファレンス2013～ヒット商品を作る仮説検証型開発プロセスとスキル～に行って来ました。 自分の中でのリーンといえば、 【送料無料】リーン・スタートアップ [ エリック・リース ] 価格：1,890円（税込、送料込） か 【送料無料】Running Lean [ アッシュ・マウリャ ] 価格：2,310円（税込、送料込） くらいなもんです。実際に本を読むだけではダメで、生の声を聞いて少しでも自分の仕事に役に立てばという思いで参加させて頂きました。気になったところだけ箇条書きにしてみます。 資料はまだWebにUPされていないようですが、UPされ次第更新します。 アジャイルからリーンへ、そしてリーンスタートアップに 平鍋健児さん @hiranabe 英和さんでもまだ50％はWF。アジャイルは契約がかなり問題。作ったのに使われないのも問題 アジャイルはホールケーキを作るのではなくショート
3年使ったRedmineの使い方について共有したい10のこと
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
優れた仕様を決定するために必要なこと - GoTheDistance
たまにはブログ更新したいから、ついさっき流れてきたエントリに食いついちゃうよー。 ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change! 工程の分断はあり得ません ソフトウエアの設計に実装経験が要るか要らないかというのはそもそも議論にならない。「ソフトウエアの設計＝仕様の設計+コードの設計」なんだから、例えればコインの表と裏。それらは引き離すことは出来ないのに引き離して分業しようとするからよろしくないことが起きてしまうというのが、上記記事の主題かと思います。簡単に言えば。 僕もこの点については「工程の分断」という言葉で何度も書いています。コインの表と裏であるべきものを分断してしまうと、互いのフィードバックを得る術を無くしてしまいます。そうなったら良いことは無い。ここは誰でも納得がいく所でしょう。 仕様を設計するチャンスって超少ないんじゃない？
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ
いつまで開発のやり方ばっかり語ってるの？ #sgt2013
DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ........................................
実録！SIerがネットゲーム事業に参入できない理由
SIerにおける某ネットゲームシステム（以下「NGS」）開発プロジェクトの発言録です。内容はもちろんフィクションですが、SI業界の実情を踏まえて構成してみました。SIerが内部に抱えるネットゲーム事業への参入障壁、さらにはSIerの将来の姿が垣間見えるかも知れません。 プロジェクト計画レビュー部長「NGSは、今年度の重点目標『高利益率ビジネスへの参入』を達成するために立ち上げる非常に重要なプロジェクトです。本部長から直々のご指示を頂き、開発チームのメンバーを集めました。」 PMO事務局「PMOとしてもプロジェクトの成功に向けて最大限貢献したいと考えています。」 部長「それは心強い。ありがとうございます。」 課長「それでは、早速ですが、NGS開発プロジェクトのプロジェクト計画レビューをお願いします。」 PMO事務局「プロジェクトのマスタスケジュールに計画が不明確な箇所が散見されます。βテスト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
github を用いた開発フローテンプレート
大規模 JavaScript その設計と実装と現実
