現代的システム開発概論2023年度リクルート エンジニアコース新人研修の講義資料です
エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく｜mtx2s
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
開発組織の貢献は売上として直接語るのはやはり無理があるのではないかという考察
先日サーバントワークスさんが公開した 計測によるスクラムチームのパフォーマンス向上 を読んで、 以前自分が書いた 開発の改善はKPIに翻訳しなければいけないのか をもうちょっと言語化することができそうだったのでメモ。 TL;DR 結論としては、開発の改善はKPIに翻訳しなければいけないのか でも書いた通り 開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない から考え方は変わってないが、改めて整理して 開発組織は、Ability to Innovate と Time to Market 2つのケイ
バッチ処理 プラクティス
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
今年できたチームの生産性を向上させたプラクティスの紹介 / Kaigi on Rails 2022
sdevtalks.org開発報告 / reporting that sdevtalks.org was launched
freeeのエンジニアにリモートワーク環境のこだわりを聞いてみた - freee Developers Hub
こんにちは、DevBrandingのellyです。 先日、こちらの記事でfreeeの開発メンバーがどのようなキーボード・マウスを使っているのかをご紹介しました。そのアンケートの中で、キーボードやマウスの他にも、椅子や机、音響、カメラ等の作業ツールへのこだわりやライフスタイルの変化についても回答してくれた人も多くいました。 今回はその中から特に気になる5人のエンジニア・デザイナーに、書斎を持つことが夢なichienさんと一緒にインタビューしてきました！ kenoji tomoz toofu harutan manabusakai kenoji ―kenojiさんはfreeeでも随一のガジェットマスターらしいですね。キーボードは何を使ってますか？ キーボードはTEX Shinobi(TTC Gold Pink スイッチ)かHHKB(全キー35gへ押下圧軽量化&グリス塗布済み)をよく使っています
【夫婦で開発】1年かけて1週間を振り返えるアプリを本気で開発してみた
1年と2ヶ月かけて開発していたアプリがリリースできたので記事にしました。 詳しい開発のログは以下のスクラップにまとめています 👌 リリースしたアプリ ダウンロードはこちら。 ■ iOS ■ Android LPサイト アプリを開発したきっかけ 以前から週1で家族の振り返りの時間を設けていて、今週あった出来事を互いに共有して議事録に残すことを習慣にしていました。 ただ、上記の運用をしている間に以下のような問題があることに気づきました。 振り返りの際に、今週の出来事を思い出せない まとまった期間の振り返りたいときに、テキスト情報のみだとピックアップしづらい 良かった出来事のみピックアップしたい 振り返りを開催する時間が毎回ズレる 日付を忘れてスキップしてしまう そこで、上記を改善するためアプリを家族で開発しようという話になりました。 どんなアプリ？ memoirは1週間を振り替えるアプリとし
「急いで作って！」と言われたとき、私がまずやること→Miroだけでスクラム
VTeacher所属のSatomiです。 ※ 本家Miroさんからコメントをいただいたので掲載します！ ミロジャパン高山です。本記事ではMiroについてご紹介頂き誠にありがとうございます。大変参考になります。もし本記事の趣旨にあっていればですが、以下の２つのテンプレートを日本語対応をしましたので、よろしければ、リンクを付与頂けますと嬉しいです。 スクラムボード：https://miro.com/ja/online-scrum-agile-tool/ マインドマップ：https://miro.com/ja/mind-map/ 或る日突然、「100万円のプロモーション予算がついたから急いで作って」と頼まれました。 ※ちなみにプロモーション予算（100万円）に人件費は含まれないそうです。 そして、偉い人から下の画像が送られてきました。 （「4月1日に夢を語る」という PR TIMES の企画だそ
リモートアジャイル開発のノウハウ集 第2版を公開しました | Agile Studio
Agile Studio プロデューサーの木下です。2020年の3月に公開した『リモートアジャイル開発のノウハウ集（第1版）』に続き、このたび第2版を公開しました。こちらからダウンロードいただけます。...
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
[翻訳] なぜ私はElixirに賭けたか - メンテナンスプログラマになりたくなければ君もそうしろ - Qiita
Ken Mazaikaさんの2015年1月31日付のブログ記事、Why I’m betting on Elixir And why you should too, unless you want to become a maintenance programmer.の翻訳です。 [翻訳] Elixir - 次に来る大物Web言語もそうでしたがなんかRailsのプログラマさんたちがやたらアツく語ってるんですね、Elixirを。 メンテナンスプログラマになりたくなければ1、なんてタイトルからして挑発的です。私の3つ前の仕事はまさにそういう保守系でしたけど。 あんまりアツいんで皆さんとアツさを共有したくて翻訳しました。 なおQiitaのCentOS + Erlang + Elixir + PhoenixのDockerイメージで今日から始めるElixir on Phoenix入門の追記のところでも
![[翻訳] なぜ私はElixirに賭けたか - メンテナンスプログラマになりたくなければ君もそうしろ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/b5be2031f0952034effc167454c126ae8c3c86fd/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJTIwJUUzJTgxJUFBJUUzJTgxJTlDJUU3JUE3JTgxJUUzJTgxJUFGRWxpeGlyJUUzJTgxJUFCJUU4JUIzJUFEJUUzJTgxJTkxJUUzJTgxJTlGJUUzJTgxJThCJTIwLSUyMCVFMyU4MyVBMSVFMyU4MyVCMyVFMyU4MyU4NiVFMyU4MyU4QSVFMyU4MyVCMyVFMyU4MiVCOSVFMyU4MyU5NyVFMyU4MyVBRCVFMyU4MiVCMCVFMyU4MyVBOSVFMyU4MyU5RSVFMyU4MSVBQiVFMyU4MSVBQSVFMyU4MiU4QSVFMyU4MSU5RiVFMyU4MSU4RiVFMyU4MSVBQSVFMyU4MSU5MSVFMyU4MiU4QyVFMyU4MSVCMCVFNSU5MCU5QiVFMyU4MiU4MiVFMyU4MSU5RCVFMyU4MSU4NiVFMyU4MSU5NyVFMyU4MiU4RCZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9MzcxM2IyMzI5NmI4ZDJjODk0YWI5NmZhMzE2NTg3OTU%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBIaXJvZnVtaVRhbW9yaSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MmFiZjZlMDgzMmY4MmIzNzc2NmE5YWIyNDYxOTg3MGU%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D3469825b2297199887e8872234155491)
バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP
1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました！」「Aクラスのドラゴンを相手にしてる最中だってのに！」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野（しっぽ） (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペイン人エンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペイン人エンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何
7年働いた時点での私の仕事の極意 - Kengo's blog
最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意
Web制作が爆捗するBracketsプラグイン13選＆便利なプラグインを探すコツ
OSSのテキストエディター「Brackets」で使える、Web制作に便利なプラグインを紹介し、拡張機能マネージャーの使い方や便利なプラグインを探すコツ、プラグインのインストール方法について解説する。 OSSのテキストエディターの豊富なプラグインをいろいろと使ってみよう OSSのテキストエディター「Brackets」は、拡張が容易に行えて好みの環境にカスタマイズしやすいのが特徴の一つだ。 筆者は、以前の記事でもBracketsの使い方について紹介したが、今回はBracketsのお勧めプラグイン（拡張機能）を紹介していこう。 その前に、Bracketsでプラグインをインストールする「拡張機能マネージャー」を紹介しておく。 Bracketsの「拡張機能マネージャー」とは Bracketsでは「拡張機能マネージャー」を利用してプラグインのインストールやアンインストールができる。「拡張機能マネージャ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サクッとAWS入門＋モダン開発の基本
スクラムガイド - Scrum Guide 2020 年 11 月
System of Record と System of Engagement
エンジニア向け絶対に挫折しない個人サービスの作り方
日本語版 : IBM Bluemix
スタートアップにjoinして安心して眠るためにやった5つのこと
