ワンランク上の健康管理を！「FiNC Plus（プラス）」をスクラムで開発しました
FiNCでAndroidエンジニア 兼 スクラムマスターをしている吉田です。 日課は毎朝の散歩とラジオ体操です。 弊社では、2020年7月21日（火）に、糖質管理やアドバイスレポート機能など、ワンランク上の健康管理ができる新しいサブスクリプションサービス「FiNC Plus」をリリースしました。 FiNC Technologies、新月額サービス「FiNC Plus」を開始！ 糖質管理やアドバイスレポート機能など、ワンランク上のオンライン健康管理を月額480円で提供… 弊社ではユーザーに価値あるサービスを継続的に提供するためにアジャイル開発を取り入れているのですが、その実現方法は開発チームに委ねられています。そんな中、このFiNC Plusを開発している「dev2」というチーム(以後分かりやすく「Plusチーム」と呼びます)では、スクラムガイドに則ったスクラムでFiNC Plusを開発し、
Holacracy と Scrum は共存できるのか
LAPRAS株式会社では全社的にHolacracy(ホラクラシー)という組織体系を導入しています。一方で開発チームではアジャイル開発のフレームワークであるスクラムを導入して開発を進めています。ホラクラシーの思想は個々人が別々の役割を持って、各人が優先順位を決めて主体的に動いていくものである一方、スクラムはだれもがどんなバックログアイテムでもできるのが理想で、プロダクトオーナーが決めた優先順位に従って開発をしていきます。根本的に違う思想を持っているように見える2つのフレームワークが同居できるのか、運用して1年ぐらい経つのでまとめてみることにしました。 ホラクラシー組織のおさらいホラクラシー組織とはティール組織の一種です。より詳細な話は 代表の島田 がいくつか記事を書いているので、それを参考にしてもらうと良いです。参考になりそうなものをピックアップしてみました。 - ホラクラシー組織への誤解と
Go言語のio.Pipeでファイルを効率よくアップロードする方法
パイプ（土管）をGo言語でも楽しめるはじめに前回はGo言語のmime/multipartパッケージによるファイルのアップロードを見ましたが、パフォーマンスの特徴にはあまり触れませんでした。 大規模なETLジョブや、制限の厳しいサーバーレスの環境などでは、ファイルを扱うプログラムのリソースを慎重に考える必要があります。本記事ではメモリ使用量を大幅に減らすio.Pipeの使い方を見ていきます。 全てのコードはサンプルレポジトリにあります。 同期処理にある問題前回のコードをもう一度見てパフォーマンスを考えてみましょう。 // ファイルを開く file, _ := os.Open(filename) // リクエストボディのデータを受け取るio.Writerを生成する。 body := &bytes.Buffer{} // データのmultipartエンコーディングを管理するmultipart.W
【初級編】Go言語を始める方のための落とし穴、問題の解決方法やよくある間違い
こちらの記事はGo言語初心者向けのサイト「50 Shades of Go: Traps, Gotchas, and Common Mistakes for New Golang Devs」の中から初級編だけを日本語に翻訳したものとなります。特にGoを始めたばかりの方にはとても役立つ情報かと思いますので是非ご覧ください。また、多少日本語がおかしい部分あるかもしれませんがご了承ください。もし分かりづらい部分は直接本家サイトを参照頂ければ幸いです。 概要Goはシンプルで楽しい言語ですが、他の言語と同様に、いくつかの問題点があります。それらの多くの問題点は、Goのせいではありません。あなたが他の言語から来ているならば、これらの間違いのいくつかは自然な罠です。 公式情報、wiki、メーリングリストでの議論、Rob Pikeによる素晴らしい投稿やプレゼンテーション、そしてソースコードを読むことで言語を
The many approaches to scale Scrum — an introduction
Scrum is a framework to address complex adaptive problems. The single source of truth for Scrum is the Scrum Guide. This Scrum Guide is very clear about what Scrum is in a single team environment. It is less clear about multiple teams on the same product. Sure, the Scrum Guide has something to say about this: “Multiple Scrum Teams often work together on the same product. One Product Backlog is use
心理的安全性が高くアジャイルな組織設計
心理的安全性の高いチームを作るためにサーバントマネージャーに徹する話などを聞くことがありますが、なんか大変そうだなーと考えてたら、これは組織設計の課題だと思ったわけです。 サーバントマネージャーは過渡期と割り切って、本来の仕事である課題解決に時間を使えるようにしていったほうがいいです。 心理的安全性とは他者の反応に怯えたり羞恥心を感じることなく、自然体の自分を曝け出すことのできる環境や雰囲気のことを指します。 だそうです。失敗するかも…と早めに言えることはアジャイルな組織には必須です。 心理的安全性は1人のメンバーが日常的にコミュニケーションする相手との視座、視野、視点が近いと高くなると仮説を立ててみました。 視座、視野、視点の図 https://tech.drecom.co.jp/viewpoint-of-being-leader/視座が離れてる例：リーダーが超ベテランでメンバーが超若い
「技術を極める仕事にシフトしたい」というメンバーへのフィードバック
「自分は○○技術に強みがあって、それを活かせる仕事をしていきたい」というメンバーがいました。自社ではまだ○○技術はあまり採用されていなかったのですが、筋は良いと思っていて、このメンバーにも期待していましたので次のようなフィードバックをしました。 フィードバック内容技術を極めて仕事にするというのは、実は「自分の好きな特定の技術にめっちゃ特化したらそれが仕事になる」というものではないのです。 技術がビジネスに繋がるまでには、 コア技術アプリケーション運用パッケージングブランディングセールスマーケティングなどなど、様々な要素が組み合わさってできています。 むしろ、ビジネスのほうから逆算してこそコア技術に価値があります。 特定の技術分野に対して、応用事例や運用まで考えてある程度広く浅く日頃からインプットをしておいて、ビジネス的価値が見えたときに「ここぞ」とばかりに自分から提案してコア技術を学べる力
10 Experiments With Product Backlog Refinement
It might feel frustrating to practitioners at times, but Scrum does not prescribe ‘how’ to do certain things. Many Scrum practices only emerge with experimentation, and this is in fact the best way to build a shared understanding of context with a Scrum team. Over the last few months, I’ve been experimenting together with one team in relation to how we do Product Backlog Refinement. With this team
エビデンスベースドマネジメントガイド by Scrum.org – Waicrew – Medium
※本記事は旧版です。最新版はオフィシャルサイトからPDFをダウンロード可能です。 ビジネス価値の計測と経験的マネジメントの活用によるビジネス成果の継続的改善方法 2018年9月 この作品は、Scrum.orgが提供する「Evidence-Based Management Guide」の日本語訳であり、クリエイティブ・コモンズ 表示 — 継承 4.0 国際 ライセンスの下に提供されています。概要アジャイルなプロダクトデリバリーのプラクティスを導入している組織は、ビジネス成果よりも活動やアウトプットの改善にフォーカスしがちであり、提供する価値を向上させるという本当の目的を見失いやすい。 アジャイルは目的を達成するための手段であり、目的そのものではない。つまり、アジャイルプラクティスを導入するときに最も重要なのは、ビジネスの業績を向上させることである。組織がこのことを見失うと、意図しない、望まし
我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか
フューチャーアーキテクト Advent Calendar 2017 の2日目です。 システム設計が大好きで大嫌いな皆さん、こんにちは。 突然ですが、皆さんはどのようにシステム設計における ドキュメント腐る問題 に立ち向かっていますか？ … ドキュメント腐る問題とは、設計時に作成した各種ドキュメントがGoogle Driveやファイルサーバ上で陳腐化してしまい、現状の正しい状態を指していないことです。せっかく新規参画者がキャッチアップしようとしてもドキュメントが真実を示していないという怖いやつですよね。 今まで出会った一番辛いドキュメントは、PJ初期に作成したホワイトボードに書かれたラフスケッチの画像しか無かったところですね。まず字が汚いし、内容も最新版と微妙に異なっていました。新規参画者殺しにもほどがあると、ほんのちょっとだけ恨みました。 いやいや、ちゃんとサボらず整合性を取れよって？サボ
メルカリの小泉さんと組織の課題について話したら恐ろしい程勉強になった話 – tsukuruba – Medium
僕の中で仕事人生に影響を与え続けてくれている三大COO（と勝手に呼んでる人たち）がいる。 一人目がアカツキ共同創業者COOの香田哲朗くん、二人目がフリークアウト(元)COOで現hey代表の佐藤裕介さん、そしてメルカリ社長兼COOの小泉文明さんだ。 それぞれ社長もできる人だが、COOとして事業及び組織の構築も構造的分析もハイレベルにできる。恐ろしく広域のアビリティを持ち、バイタリティとバランス感覚に優れ、超人的な仕事量をこなす人たちである。 そのうちのお一人であるメルカリ小泉さんと1on1させてもらう機会があり、その話が組織の課題に悩む他の人にもとても有用だと思ったのでメモを公開させていただくことにした。（ほんとにメモなんで乱文ご容赦ください） ツクルバでは組織・文化づくりに社をあげて徹底的に投資していく方針なので、非常に参考になった。 ＊＊＊以下メモ＊＊＊ [お題] メルカリで急激に組織を
https://link.medium.com/1jsAtPLA6T
デザイン思考は、問題を探索・解決するための方法です。リーンは、私たちの信念を試し、適切な成果につなげる方法を学ぶためのフレームワークです。アジャイルは、ソフトウェアの変化していく状況に適応するための方法です。 デザイン思考は、能力と学習に関するものです。スタンフォードd.schoolのCarissa Carter主任は、デザイナーを高める能力について、素晴らしい記事を書いています。たとえば、曖昧さ、共感的学習、統合、実験などが、その能力として挙げられています。意味を生み出し、問題の枠組みを設定し、潜在的な解決策を探索する、デザイナーの能力が重要なのです。 『誰のためのデザイン？』の著者であるドナルド・ノーマンは「デザイナーは最初のアイデアに満足しない」と述べています。あなたも考えてみてください。最初のアイデアが最高のアイデアだったことはありますか？意味や新しいアイデアが生まれるのは、物事を
休日にカンファレンスがあるときに、参加者はどうするか？
土日や祝日にフルタイムで技術カンファレンスがあるとして、例えば参加しますよね、そのときにどうするか考えようという提起です。 カンファレンスは疲れるセッションを黙って座って聴いてるだけでもそれなりに疲れるし、せっかく参加するなら登壇者の人を捕まえて話をしたり、他の参加者と議論したり、もしくはワークショップセッションに参加したりとかしますよね。聴いてるだけみたいな参加の仕方をしても「あとで資料だけみればいいや」程度の価値しかないから。なので、フルタイムで1日参加するとそれなりに疲労するわけです。楽しさとは別に。 土日2daysなカンファレンスの場合、前の週フルタイムで働き、土日に疲労し、次の週またフルタイムで働くとか、たぶん働きすぎなので、最低でも次の月曜とかは休みたくなるのが人間ってものだと思います。私はそうする。 平日カンファレンスの参加は休暇を使いますか？CROSS 2016に登壇したと
「Angular CLIがわかる本」の近況報告
この本についての詳細は次の記事をご覧ください。 「Angular CLIがわかる本」を出版しました。 販売状況の報告出版直後から、今までの状況について報告します。 現在「Angular CLIがわかる本」は52人の読者に購入していただき、売上は$470程度になりました！ 🎉黒字！！🎉 登録料の$100を取り戻せればいいかなと思っていましたがこんなに多くの方に買ってもらえるとは思ってなかったので、ただただ感謝です。 完成度はまだ60%程度でまだ完成していないので、1ヶ月に1回程度のペースで完成に向けてアップデートを続けていきます。よろしくお願いします！ 今月のアップデート内容というわけで11月のアップデートを本日公開しました。すでに購入いただいている読者の方は最新版をダウンロード可能です。 10月からのアップデート内容は以下のとおりです。 - Angular CLI v1.5対応 - N
ソフトウェア開発の基本的な問題〜 18年前からXPが提示するリスクの紹介
自分が、ここ数年アジャイルのトレーニングの際に必ず示している図がある。それが「エクストリームプログラミング」の第一版から第一章で提示されている、ソフトウェア開発に関するリスクについての図だ。 先日、Agile459のオンライン読書会で紹介したら好評だったので図を貼って置くことにする。 念のため、エクストリームプログラミングを読んだことのない人向けに説明しておくと、これらの元ネタは書籍（初版では１章まるごと、第二版・新訳版では１章で部分的に）では列挙されているが、本文に列挙されているだけなので、自分なりに整理してこのような図にしている。 実現できないスケジュールが遅れたり、度重なる遅延で実現の前に資金がなくなりプロジェクトが終わってしまうというリスクがまず最初にある。 動かないなんとか実現しても、欠陥が多くまともに動かなかったり、その結果としてシステムが劣化（＝メンテナンス不能に）になり、作
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to build the Great Team?
Cross-functional team game
“Cross functional teams are a stupid idea – no one can do everything “
“We need an API team and a UI team”