サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
t-and-p.hatenablog.com
年末年始に『単体テストの考え方/使い方』(原著: Unit Testing Principles, Practices, and Patterns, 以下 UTPPP) を読んだ。 単体テストの考え方/使い方 作者:Vladimir Khorikovマイナビ出版Amazon UTPPP 内でも紹介されているが、テスト駆動開発 (TDD) には大きく「デトロイト学派1」と称される考え方と「ロンドン学派」と呼ばれる考え方が存在して、その最も大きな違いはモック (テスト・ダブル) に対する考え方にある。自動化されたテストによるアプリケーションのテストカバレッジを向上させる上でテスト・ダブルの活用は避けて通れないが、テスト・ダブルの利用にはメリットもデメリットもあるため、2つの学派のスタンスを踏まえた上での落とし所を見つけることが重要となる。 テスト駆動開発にはざっくりいうとモックを積極的に使う派
6月から、 株式会社ココペリ というところで働いています。 そういえば6月からこんな会社で働いています (Twitterに書いてなかった pic.twitter.com/C67PL4ARrb— むらみん (@Mura_Mi) June 15, 2021 mobile.twitter.com これまで働いた FOLIO や CADDi に入社した際はサーバーサイドアプリケーションエンジニアのポジションから始め、エンジニアリングマネジメントも行うようになっていたのだが、ココペリに関してはオファーの段階でエンジニアリングマネージャー (EM) のポジションの話を頂いた。実際に、入社してから (たぶん) 1行もコードは書いておらず、日々 EM としてのあれやこれやに取り組んでいる。 ココペリに加入した時点で私が組織内で唯一の EM となる状況もあり、エンジニアリング職のメンバーのみならずそれ以外の
この記事は何 昨日, Engineering Manager Advent Calendar 2018 にて 今,個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間 という記事を公開しました.その記事の続編かつ実践編として,本記事では, FOLIO が2017年から2018年にかけてどのようにエンジニア組織を形成し,課題を抱え,その解決のためにどのようなアプローチを取ってきて,更にその後どのような課題に取り組もうとしているかを紹介しようと思います.自分が FOLIO に入社するよりも前の頃の話も多く含まれていますので,その点はご留意ください. この記事は, FOLIO Advent Calendar 2018 14日目の記事です. adventar.org この記事は何 βリリースまで: 職能組織 プロジェクト体制 組織組成においてプロジェクト
株式会社FOLIO にてエンジニアリングマネージャーをやっています.FOLIO では この1年間,プロダクト開発を円滑に進めるための組織を目指し,様々な試行錯誤をしてきました.その中でも,適切なチーム・グループの境界設定やミッションに基づいた組織の構造化は現在進行系で大きなトピックの一つです. Engineering Manager は Engineer のマネジメントではなく Engineering のマネジメントだ,という指摘が今回の Advent Calendar でもありましたが,エンジニアリング組織の持てるポテンシャルを十二分に引き出せるかどうかを左右する変数のひとつが「組織のカタチ」だと思います。 本稿は,10月のあるタイミングで社内に向けた啓蒙活動の際に書き出した『組織づくりを考える上で知っておく必要のある概念たち』という wiki の内容を素にしています.私が今の仕事のコン
今年の2月より、FOLIO という会社で働いています。本業はバックエンドシステム開発とかエンジニアリングマネージメントなのですが、それとは別に、「社長による社内向けの音声コンテンツ」の企画及びインタビュアーをやっているので、その話をしようかな、と思います。 この記事は、そんな FOLIO のアドベントカレンダー 2日目 の記事です。昨日は id:ken5scal による 『踏み台環境でテレポートする』でした。 adventar.org 組織の「100人の壁」 自分が入社したときの FOLIO は50人から60人という会社でしたが、私の加入後にも続々とメンバーが参画し、今では100人に迫ろうとしています。 一般に、組織には「100人の壁」と呼ばれる、会社規模が大きくなることで発現する組織課題があると言われています。実際に FOLIO でも、今年の初めには1フロアだけだったオフィスも3フロアま
スウォーミングとは何か スウォーミング (Swarming) とは,無数の虫が何かの場所や標的に群がって何かを行うことであり,ソフトウェア開発の文脈では,一つのタスクや開発トピックにチームの全員 (全員ではなくても,多人数) で取り組むことを指します. 最近しばしば話題に上がるモブ・プログラミングも概念としてはスウォーミングのひとつといえますが,もっと幅広く,ひとつのユーザーストーリーにチーム全体で取り組むことがスウォーミングという言葉がソフトウェアの文脈で一般的に指す活動です. ソフトウェア開発チームは,一度のタイムボックス (スクラムに習って スプリント と呼びます) で複数のユーザーストーリー (例えば 注文の一覧を表示する というユーザーストーリーと,1つの注文の詳細情報を表示する というユーザーストーリー) に取り組むかと思います. 1つのユーザーストーリーを実現するためには複数
単一のチームでスクラム開発を行う時と比べて,LeSS や Nexus といった Scrum of Scrums,または大規模スクラムを実践する際,「プロダクトは何か」という定義はより重要になります. LeSS の解説書である Large-Scale Scrum: More with LeSS (Addison-Wesley Signature Series (Cohn)) を読み進める中で,プロダクトの定義についての記述が結構良いなと思ったので,自分なりの例も交えつつ説明したいなと思います. なぜプロダクトの定義が重要なのか 大規模スクラムに限らず,スクラムにおいてプロダクトの定義が明確であることは極めて重要です.プロダクトの範囲が明確でなければ,プロダクトバックログがどこまでをカバーするべきかも,プロダクトバックログアイテムの受け入れ基準にどのようなことが書かれているべきかも判断すること
最近のソフトウェア開発チームの多くは,スクラムのフレームワークを適用していなくても,いわゆる「アジャイルなプラクティス」に則ったイテレーティブな開発スケジュールを持っている組織が多いのではないかと思います. 自分もそのような組織に幾つか属してきた中で,周囲のやり方やインターネット上で見られる事例を形だけ適用してイテレーション *1 の「ふりかえり」*2 を行っているもののうまくいかない,という組織をこれまで多く見てきました.本稿では,特にスクラムには特に精通していないチームに向けて,スクラムから得られる知見や,自分がこれまでスクラムに取り組んできた中での経験を元に,よく見受けられるパターンと,それに対する処方箋をまとめようかなと思います. 時間内に議論が収まらない チーム規模やイテレーションの長さに対して,どういうことが起きたか,何が問題だったか,どう改善するかという話が,予め予定したタイ
最近,チームを自己組織化させるためにどうするかみたいなことをよく話したり考えたりするのだけれど,チームの自己組織化を考えるうえで,特に組織の「境界」をどこに引くかはとても重要なんじゃないかなあと思うので,今の考えをまとめておく. 基本的にはどのような組織にも当てはまる話ではあるが,主にソフトウェアシステム開発の現場での経験が元になっていることをご理解いただきたい. 自己組織化とは何か いろんな定義があると思うのだけど,自分は Scrum Alliance の認定スクラムマスター研修にて日本人唯一 *1 の認定スクラムトレーナーである江端一将さんが仰っていた定義がわかりやすいと思う. 1. チームのゴールが明確であること 2. チームの仕事や裁量の境界が明確であること 3. チームメンバーが,自分たちのやるべきことを自分たちで 0.1 秒以内に決定できること また,最近同僚と話していた中で出
フロー効率性と「This is Lean」 あくまで自分の観測範囲での話ではあるのですが,2017年,ソフトウェアやITシステムの開発プロセス関連に興味がある人たちの間でホットだったキーワードのひとつが「リソース効率性とフロー効率性」だったと思います. 私自身,それまで「リソース効率性とフロー効率性」という概念は知らなかったのですが,9月にあった XP 祭り2017 での発表を拝見してから,自分の中では一気に火がつきました. 具体的に「リソース効率性とフロー効率性とは何か」という話は,その時の発表者である id:i2key さんの発表資料やブログのほうが詳しいと思うので,興味のある方はご覧いただければと思います. i2key.hateblo.jp Leanstartupをリーンにヤル #リーンスタートアップ from Itsuki Kuroda www.slideshare.net 簡単に
これはなに 世の中の3人~8人程度のソフトウェア / システム開発チームの多くは,俗に言う「アジャイルな開発手法」のプラクティスを実践し,1週間から1ヶ月に1度といった定期的なタイムボックスを設けてチームの開発プロセスや成果物などを対象とした「ふりかえり」をしていると思います。 そして,日本の多くの現場では,「KPT」と呼ばれる Keep (続けること) / Problem (問題になっていること) / Try (次のタイムボックスで新しく試みること) を挙げる方法による振り返りをしているのではないかと思います. 私が開発リードを務めているチームでは,KPT とは違ったフレームワークで週に1度のふりかえりを行っていて,割とうまくいっていると思っているので,それを紹介しようと思います. KPT は「チーム」のふりかえりには向かない 最近個人的に思っているのは,KPT はチームのふりかえりには
行ってきた.個人的に2週連続のカンファレンス参加. 聴講したセッションについて. XP祭り2017 基調対談: ワークスタイル改革を実践する2人が働き方の本質を語る まずは,サイボウズの青野さんとソニックガーデンの倉貫さんの働き方改革についての話. ウォーターフォールの何が辛いか,それぞれの会社のアジャイル文化の話,DevOps 化,有給や昇給や経費の管理,キャリアに対する考え方などの幅広い話題について.アジャイルの考え方は,本当の「働き方改革」とすごい親和性があるなぁという,非常に面白い話だった. ひたすら Twitter で実況していたのだけど,一番個人的に面白いなと思ったのは,ソニックガーデンの「YWT」の話. 倉貫「YWT やったこと,わかったこと,次にやることを面談する.#xpjug #xp祭り— むらみん (@Mura_Mi) 2017年9月16日 倉貫「YWT を続けるとみん
転職して8ヶ月ほどになるかと思うが,今年も新卒のメンターになる運びとなった. 今年も新卒のメンタリングをして改めて思うのは, エンジニアにとっていくつかある基礎体力のうち,一番最初に伸ばせるのに誰も本気で取り組まないのがタイピングスピードだということ だ. 日本のスポーツや武道の世界に「心技体」という言葉がある.競技を行う上で,精神力 (心),技術, 体力の3つが大事になるという話だが,このうち入門者に一番最初に求められるのは「体」だと思う. 技術を磨くには圧倒的な鍛錬の時間が必要だが,この鍛錬を積むためには体力がなければいけない.*1 かつて,横浜ベイスターズに石井琢朗という選手がいた.彼が引退するにあたって,とあるプロ野球 OB によって書かれた 『66番だった』という記事が個人的には非常に印象的だ. ameblo.jp 石井琢朗はもともと投手として横浜大洋ホエールズに入団したのだが,
TL; DR 「プログラマの三大美徳」はソフトウェアに向けるものであり,人に向けるものではない. 「HRT」は人に向けるものであり,ソフトウェアに向けるものではない. プログラマの三大美徳 プログラマの三大美徳というものがある.Perl を開発した Larry Wall が提唱したもので,「怠慢」「短気」「傲慢」からなる. 詳しくは上述のリンクにある各解説記事に譲るのだけど,例えば「怠慢」とは,「エンジニアとして手間を省くために最大限の努力をする気質」を指す.元の Larry Wall の記述では当たり前過ぎて省略されているのだけど,「最大限の努力」とは「仕事をしないために交渉する努力」ではなく「技術で手間を解決する努力」を指すものだと思われる (勿論,場合によっては前者が大事になるケースも有るのだけれど) . 「プログラマの三大美徳は "怠慢", "短気", "傲慢" である」というワー
このページを最初にブックマークしてみませんか?
『t-and-p.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く