サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
hageyahhoo.hatenablog.com
今朝起きてスマホをみたら、しいばさんからこんな通知が届いていました。 たしかに @hageyahhoo さんのプロポーザルはいつも伝わってくる。すごいよなぁ。 Scrum Fest Osaka のプロポーザルを世界最速で眺める https://t.co/yDPIQDRahR— Mitsuyuki Shiiba (@bufferings) 2021年3月13日 教えていただいた「Shinagawa Agile Talks」で、47:30くらいから、確かに私のセッションプロポーザルの書き方を、参考例の一つとして紹介していただいていました。 「お手本になるプロポーザル」として紹介していただいた例は、こちらになります。 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2021/proposal/14621/tips
約1週間前の8/5(月)に始まった、Regional Scrum Gathering Tokyo 2020の公募。本稿執筆時点で、既に60件ものプロポーザルが登録されています。 今日Facebook上でやっとむさんと雑談していたところ、 プロポーザル出した人が「私はこれも面白そう」って他の紹介をするコーナー、とかあったら面白いかなあ という話が出たので、早速実験してみることにしました。 その前に自分のプロポーザル紹介! 私たちLINEのSETチームが実施した/している様々な改善施策を、特に技術面から整理して、皆さんの日々の仕事に活かせる知見として紹介されていただきたいと思っています。 発信内容のクレディビリティを高めるため、同僚の高橋勲さんと一緒にお話しさせていただきたいなと。 ちなみにこのプロポーザルは、来年夏にアメリカで開催されるAgile2020向けに現在執筆中の論文の内容をある程度
私の勤めている会社は、ちょうど今が(人事)評価の時期です。 今日もチームメンバーと「どんな評価指標を使うのが良いのか」という雑談をしていたのですが、その内容が他のチーム・会社でも使えそうな気がしたので、ブログにまとめてみました。ちなみに雑談のまとめなので、あくまでアイデアの1つとして読んでいただければ幸いです。 ちなみに評価対象は、ソフトウェア開発に関わる人、具体的にはプログラマ・インフラエンジニア・QAあたりを想定しています。 1. ダメな評価指標例 まずは、「これは(アカン)」というものから。 (1) プログラム・コードを作成・追加した行数 そもそも、「行数が多い == 生産量が多い」ではないです。 何も考えずに行数だけ増やしてしまうと、メンテナンスコストやバグの混入確率が増え、結果としてチーム・会社にマイナスになります。 (実際に学術的にも実証されています。) (2) GitHubへ
2018年2月17日(土)に開催された『プロダクトオーナー祭り2018』で、LINEでのSETの活動についてお話させていただきました。 An Agile Way As an SET at LINE ~プロダクトオーナーシップ編~ 今回は、この発表のポイント、および発表したことで学ぶことができた点を、簡潔に紹介します。 発表のポイント 要点を一言で言うと、「技術施策をビジネスに貢献する観点から考えると、できること・工夫すべきことがたくさんある」ということです。 1) まずはやるべきことを見つける 何をすれば良いのか?これを見つけることができれば、具体的なプランニングや施策の実施に持っていくことができます。 仕事での課題はいろいろあります。しかし、それが具体的に何なのかをうまく言葉で表現できていないがために、施策につなげられないことは多いです。したがって、まずは課題を発見して言語化することが肝
今年も、アメリカで開催されている Agile2017 に参加しています。 3日目に開催された Spotify のセッション、『You can do better than the Spotify Model』がちょっと興味深かったのでチラ裏します。 スピーカー Joakim Sunden さん 『カンバン仕事術』の著者です。聞き間違えていなければ、2年ほど前にストックホルムからアメリカに移住し、Spotify に入社したとのことです。 カンバン仕事術 作者: Marcus Hammarberg,Joakim Sundén,原田騎郎,安井力,吉羽龍太郎,角征典,?木正弘出版社/メーカー: オライリージャパン発売日: 2016/03/26メディア: 単行本(ソフトカバー)この商品を含むブログ (8件) を見る 『アジャイルサムライ』の Jonathan Rasmusson さんといい、『リーン
「どうすれば英語を使えるようになれますか?」という相談を受けることが増えてきたので、今日会社で、「英語を使えるようにする方法」と題した勉強会を開催しました。 あくまで私の意見に過ぎないので、チラ裏扱いで、勉強会の内容を公開します。 1. 勉強会の目的 英語を勉強するきっかけを作ること 英語のスキルを向上させる方法を知り、実践できるようにすること 英語を使って、仕事で成果を出せるようにすること 2. 私の実績 「そもそも何でお前が教えるの?」という質問への回答です。 1) TOEIC 895点(あと5点が遠い) 2) Agile2014(アメリカ)で、英語で書いた論文が採択されて登壇しました。 ・採択された論文 3) DevOps Summit 2016(台湾)で、英語でキーノートスピーチを担当しました。 学習のポイント 私が日々実践していることを列挙します。 1. i英辞郎:ボキャブラリー
行ってきたぜ船堀!2017年4月13日(木)にタワーホール船堀で開催された、Agile Japan 2017に参加してきました。 今回の私の立場は、ワークショップの講師。『メトリクスによる「見える化」のススメ:No 見える化、No 改善』というタイトルで、アジャイル・メトリクスをみんなで創るワークショップを開催してきました。 今回は特に、私のワークショップと、モダン・アジャイルにまつわるお話をさせていただきます。 1.アジャイル・メトリクスのワークショップ 参考資料 (1)今回のワークショップの資料 メトリクスによる「見える化」のススメ:No 見える化、No 改善 (2)アジャイル・メトリクスについて最初に明示的に紹介した資料 メトリクスによる「見える化」のススメ: エッセンシャル・リーン (3)アジャイル・メトリクスについて踏み込んで勉強するための資料 世界と事例から学ぶ、プロダクトオー
今年2017年も大盛況のうちに幕を閉じたデブサミ2017。 初日の2月16日(木)、「Yahoo! JAPAN Tech Conference 2017」と称して、弊社のメンバーとともに登壇させていただきました。部屋も一番大きな「会場A」を使わせていただき、主催の翔泳社の皆様には本当に感謝です。 特に今回私は、2つのセッションに登壇させていただいたのですが、その際の狙いや気付きなどについてお話できればと思っています。 ちなみに各セッションの詳細は、当日のTogetterまとめが詳しいので、こちらも併せてご確認ください。 1. 市場で勝ち続けるための品質とテストの技術 弊社の山下とともに、ヤフーでのテスト自動化の取り組みについてお話させていただきました。特に私は、「テスト自動化を支援するコーチ」として、どのような狙いを持って何を成し遂げようとしているのか、そしてどのような将来を見据えて行動し
しれっと真ん中に収まる私。 2017年1月12日(木)と13日(金)に大崎ブライトホールで開催されました、Regional Scrum Gathering Tokyo 2017 (RSGT2017)に参加してきました。 今回は、スピーカーとしての登壇に加えて、スポンサーブースの運営担当の二刀流に挑みました。 1. スピーカーとして 中邑真輔の新日本プロレス時代の入場曲「Subconscious」に乗って入場。(Supported by 及部 敬雄さん) ※入場シーンの動画を、永瀬美穂さんと開原 隆弘さんに撮影していただきました! https://www.facebook.com/miholovesq/videos/1367363473327310/ 発表した資料 アジャイルメトリクス実践ガイド from Hiroyuki Ito この資料を作成した背景 2014年にメトリクスに関する多くの
今年(2016年)7月末に、オリンピックや CNN で有名なアメリカのアトランタで開催された Agile2016 に参加してきました。その社内向けレポートを公開しても良いことになりましたので、共有させていただきます。 世界最大級のアジャイルカンファレンス報告:Agile2016参加レポート お伝えしたいことは極力このスライドに詰め込みましたが、スライドだけでは説明足らずの箇所も多々あるかと思いますので、可能な範囲で追加説明をしてみようと思います。 1. カンファレンスのここ数年の変化 キーノートスピーカーの Jurgen Appelo さんとともに。 ちなみに私は、Agile2014 以来の参加だったのですが、その間でも多くの変化を見て取ることができました。 (1) 参加者数の増加 今回は、42か国から2,500名以上の参加者がアトランタに集結しました。 Agile2014・Agile20
2016年3月11日(金)に、『再演 ~ 組織にテストを書く文化を根付かせる戦略と戦術 +α』というイベントに参加してきました。 @t_wadaさんの下記スライドが、今まさに自分がやっているテスト自動化支援・アジャイル支援のヒント満載だったため、どうしても直接お話を伺いたく参加した次第です。 『組織にテストを書く文化を根付かせる戦略と戦術』 http://www.slideshare.net/t_wada/test-strategy-and-tactics 以下、個人的に気付きがあった点のメモです。 戦略編(6-19ページ) 7ページ目 導入を目的にしてはいけない。 ついやりがち。 現実を見せ、現実に即した解決策で改善していくことになる。(伊藤) 11ページ目 文化を変えるのには、2-5年はかかるとのこと。 環境は変わり続けるので、コードに触れないわけにはいかない。 13ページ目 AS-I
一部の方にはお伝えさせていただきましたが、2015年10月15日付けで、楽天株式会社を退職することとなりました。 3年弱の在籍ではありましたが、自分自身のキャリアの中で一番手応えのある職場でした。入社直後から多くの難題にぶち当たりましたが、その都度手を差し伸べて下さった方たち・仲間たちがいたおかげで、この刺激的で激しい会社を生き延び続けることができました。 また、会社のニックネーム制で「The Hiro」(The Rockリスペクト)と名乗っていたのですが、それをもじって「ヒーロー」「スーパーヒーロー」といじっていただいたことは、良い思い出です。 関わらせていただいた皆さんに、心から感謝の気持ちを伝えさせていただきます。 なぜ退職するのか? アジャイルコーチ・自動化アーキテクトとして、現場に入ってチームを指導し、最強のチームを創るということに専念したいと考えたためです。 組織が色々と変わり
解決したい課題 例えば、スクラムを採用しているケースで、スプリント期間中に全てのスプリントバックログアイテムを完了できないことがある。その原因として、突発的な障害対応や急なレビュー依頼など、想定外の割り込みタスクが多いという意見が出ることがある。しかし、具体的にどの程度の頻度・量の割り込みタスクがあるのか、コレガワカラナイ。これが分からないと、適切な対策を打つことが難しい。 解決方法 「割込率」を算出する。 割込時間 = 総勤務時間 - 割り込みなく仕事を出来た時間 割込率 = 割込時間 / 総勤務時間 利点 作業の遅れや割り込みを、客観的な数値で他者(特にマネージャ)に説明できるようになる。 割り込みの頻度と量が分かるため、関係するチーム・メンバーとの交渉を進めやすくなる。 割り込みの頻度と量が分かるため、減らすための具体策がチームから出やすくなる。 注意点 初めのうちは、割り込み時間
2015年3月7日(土)にDevLOVE関西さんにて、『メトリクスによる「見える化」のススメ: エッセンシャル・リーン』と題して、プロジェクトメトリクスに関するワークショップを実施させていただきました。 年度末かつ雨の土曜日にも関わらず、総勢24名の方にご参加いただき、約4時間の濃ゆ〜いワークショップを実施しました! なお、当日の様子をTogetterにもまとめておきましたので、こちらもあわせてご確認下さい〜 メトリクスによる「見える化」のススメ: エッセンシャル・リーン at DevLOVE関西 : Togetter http://togetter.com/li/792373 ワークショップの内容 基本的には、前回「ゆるぎー」さんで実施させていただいた内容をベースとしつつ、時間が90分ほど長いこともあり、ワークショップの内容を倍にし、キッチリ皆さんにプロジェクトメトリクスを「体得」しても
このエントリーは、『DevLOVE Advent Calendar 2014 「越境」』の、67日目の記事になります。 ※詳しくはコチラ → http://devlove.doorkeeper.jp/events/14580 きくち ゆりさんの後を受け、DevLOVE Advent Calendar 2度目のエントリーです。なので自己紹介は省略します。詳しくは前回のエントリー『日本国外で自分のアイデアをぶつけるということ』をご覧下さい。 「コミュニティ」と「越境」に昨今感じる「違和感」 今年度も敢えて2度目のエントリーをしたのは、「コミュニティ」と「越境」という2つの言葉の関係に、個人的にある種の「違和感」・「ズレ」を強く感じるようになったためです。 その「違和感」・「ズレ」は、あくまで個人的なものに留まるものなのかも知れません。しかし、一度それを自分の言葉で自分なりに整理して見える化して
先日参加してきた Agile2014 の、社内向けレポートを公開しても良いことになったので、共有させていただきます。 Agile2014 Report: As a Speaker and a Reporter of the latest Agile in the world from Hiroyuki Ito 本当は帰国時(8/4)の飛行機の中で書き終えており、帰国次第即公開しようとしたのですが、社内手続きなどの都合で公開が遅れていました。 また、公開まで期間が空いたので、レポートを書いた当時は理解できなかった点についてもある程度理解が追いつくようになったのですが、帰国時の雰囲気をそのまま伝えたいと考えたため、あえて追加修正をしないでの公開とさせていただきました。 英語で書いたということもありますが、説明足らずの部分も多々ありますので、可能な範囲で追加説明をしてみようと思います。 3つのト
昨年末に軽い気持ちで論文を書き始めてから約8ヶ月、ついにAgile2014で登壇してきました。 "Technology-Driven Development: Using Automation and Techniques to Grow an Agile Culture" と題しまして、30分だけですが、昨年自身が関わったプロジェクトでの、テスト等の自動化の仕組みを活用することでチームの効率化・学習・コラボレーションの改善を実現した経験談をお話してきました。 発表内容 Agile2014のプログラム Agile Alliance に掲載された論文 プレゼン資料(PDF) PowerPoint 版のプレゼン資料、公開。 Technology-Driven Development: Using Automation and Development Techniques to Grow an
その発想はなかったわ〜 先日、「勉強会に参加して感銘を受けたプレゼンを再演する」(!)という社内勉強会が立て続けに2度ありました。なかなか興味深い内容だったのでシェアです。 1.自動テストの推進 by 新卒 テスト系男子として今まさに旬のきょんさんに、先日弊社で下記のプレゼンをしていただきました。 自動テストの誤解とアンチパターン in 楽天 Tech Talk from kyon_mm Mm 昨年10月に入社したとある新卒社員が、このプレゼンに大変感銘を受けたとのこと。「自分たちのチームでは手動テストが多いので改善が必要」と考えた彼は早速、自動テストを推進するために、先輩たちを集めて業後にプレゼンするという荒業に出ました。 当人のプレゼンの理解度の不足もあり、多少ツッコミを受けていたものの、先輩たちから「俺、実は自動テスト始めようとしていたんだ」的なことを打ち明けられ、早速やろう!という
ガイアが俺に書けと囁いているので、徒然なるままに。 一緒に働けない人 1.常に他人事 たとえ仕事であっても、絶対に自分でやろうとしない 自分の仕事ではないと常に考えようとする/発言する 「へ〜大変ですね〜」が口癖 2.言葉の定義にイチャモンをつけたがる 「それって、xxという言葉の定義と違いますよね。それじゃ私の仕事じゃないです。」 「何でそこでその言葉を使うのか理解できません。そもそも(以下略」 『「バグがあるかもしれない」と「バグがある可能性がある」とは意味が違いますよね』 私も意味が分からなかったです 3.話している最中に内容をすり替える 4.最終的には逃げる これが癖になっている人って、何で社会人やっているんだろうね? こういう人とは、話しても理解し合うことは不可能。一緒に仕事をしていても、尻拭いを強いられている感に苛まれるだけ。関わらない環境を作った方が良い。 昔しんどいと思った
このエントリーは、『DevLOVE Advent Calendar 2013 「現場」』の59日目の記事になります。 ※詳しくはコチラ→ http://devlove.doorkeeper.jp/events/7039 mfks17さんの華麗なバトンを受け、DevLOVE Advent Calendar 2度目のエントリーです。なので自己紹介は省略します。詳しくは前回のエントリーをご覧下さい。 最近芽生えた疑問 今回敢えて2度目のエントリーをして「現場」の話を書きたいと思ったのは、「現場」という言葉を、エンジニアが自分たちを理解してくれない上司やマネージャを批判するための言葉として使っている人が多いなと改めて感じたためです。 実は私自身も昔、自分の能力を「正当に」評価してくれないマネージャに対して、「もっと現場を見て下さい」と言っていたことがあります。(ここでの「正当に」とは、自分の能力に
2013-12-13(金)に、「Android Test Casual Talks」というイベントで、『「最強」のチームを「造る」技術基盤 ディレクターズカット』と題して、Android の CI/CD・TDD・ATDD についてお話させていただきました。 [2013-12-18] スライド公開しました〜 「最強」のチームを「造る」技術基盤 ディレクターズ・カット from Rakuten, Inc ★twitter のハッシュタグは #androidtest です〜 https://twitter.com/search?q=%23androidtest%E2%80%AC&src=typd&f=realtime 今回、60名もの方が参加されていて、改めて Android のテストに対する関心の高さを肌で感じることができました。 今回のイベントに参加してみての、私なりの気付きをまとめてみまし
テスト駆動開発による組み込みプログラミング C言語とオブジェクト指向で学ぶアジャイルな設計 [ ジェームズ・W.グレニング ] ジャンル: 本・雑誌・コミック > PC・システム開発 > その他ショップ: 楽天ブックス価格: 3,888円2013年の5月27日(月)と28日(火)の2日間、ジェームス・グレニングさんの『テスト駆動開発による組み込みプログラミング 〜 C/C++言語とオブジェクト指向によるアジャイルな設計』研修に参加してきました。 私自身、エンタープライズ系・Web系システムの開発がメインで、組込システムの開発経験は皆無です。ですが今回、次の3点を特に学びたいと思い、「組込」と銘打たれていましたが参加しました。 (1) TDD自体 自社のシステムに「レガシーコード」(テストの無いコード)が多く、手動テストが多くてエンジニアに大きな負荷がかかっていると認識しています。自分自身、
昨日2013/03/19(Tue) に、以前から憧れだったアジャイルサムライ横浜道場で、特別編「Domain-Specific Language としての魔法少女まどか☆マギカ入門」という題で登壇?させていただきました。 内容的には、魔法少女まどかマギカのネタがシステム開発の場のコミュニケーションを促進するよ!という居酒屋トークでしたが、20人を超える参加者があり、登壇者の立場からすると、まさに「わけがわからないよw」な状態でした。皆さん本当にありがとうございます。 ちなみに、当日のスライドはコチラです。(版権で怒られたら消します) Domain specific language としての魔法少女まどか☆マギカ入門 from Hiroyuki Ito togetter も既にまとまってた! http://togetter.com/li/474247 ※若干風邪気味なので、書ける範囲で
もうこれで十分な気がしてきた。
2012/10/17(水)に、楽天タワーで開催された 『Jeff Patton と平鍋健児が語る、価値創出のプロセス「ユーザーストーリーマッピング」』に参加してきました。 参加動機 次の日から Jeff Patton さんの CSPO 研修「情熱プロダクトオーナー研修」を受講することから、ユーザーストーリーマッピングを予習したいと思ったこと。 事前に「10分でざっくり理解するユーザーストーリーマッピング」などに目を通しておいたのですが、百聞は一見に如かずなので、直接お話を伺いたいなと思いました。 日本のアジャイルの大先輩の平鍋健児さんにまだご挨拶させていただいていなかったので、これを機にご挨拶させていただきたかったこと。 まずはじめに Jeff さんおよび平鍋さんの写真を期待された方はごめんなさい。 私の撮影能力不足&iPhone4S の解像度の都合で、ピンボケした写真しか撮れませんでした
「SI業界(日本)のJavaプログラマーにはオブジェクト指向より忍耐力が求められている? - 達人プログラマーを目指して」を拝見させていただいて、ひとつ思うところがありましたので書いてみます。 私自身、7〜8年ほど、オブジェクト指向分析・設計を業務で使用しています。 しかし、実務を継続していると、「本当に自分はオブジェクト指向を理解して活用できているのか?」と自問自答することが多いです。 というのも、「オブジェクト指向でないもの」に合わせて仕事をしなければならないことが多いためです。 例えば、ここ数年、コンサル上がりの「シニア」エンジニアと一緒に仕事をすることが多いです。 この人たちに基本設計書を作成してもらうと、どうしても次のような設計書が出来上がってきます。 COBOL 的な手続きが順番に記されている「だけ」。 機能追加は、IF 文やパラメータ追加のオンパレード。 継承などの概念の記載
個人的に愛読させていただいている「達人プログラマ−を目指して」に触発されて、日頃自身が感じている疑問について考えてみたいと思います。 私はこれまで、プログラマ・SE として、10年程キャリアを積んできました。 この間、さまざまな業種・システム・役割を担当させていただきましたが、常にある疑問を抱え、この疑問に直面してきました。 それは、※プログラムの書けないエンジニアが存在することと、このエンジニアがプログラムを書けるエンジニア(特にプログラマ)よりも地位が高いことが多い、という疑問です。 ※「プログラムは書けるけれども、役割の都合でプログラムを書かないことが多いエンジニア」は除外します。 私がこれまで関わることの多かった金融業界では、要件定義や基本設計だけをずっと担当していて、プログラムを書けない「シニア」のエンジニアが多くいます。 またこうした人たちは、「プログラムは下流エンジニアに任せ
GAE から他の Web サービスを呼び出すには、基本的には URL Fetch を使えばOKです。 では、GAE 上で Web サービスを構築・公開するには、一体どうすれば良いのでしょうか? コチラによると、restlet で実現可能とのことでしたので、試してみることにしました。 ちなみに、restlet を GAE/J で使用する方法については、下記サイトを参考にしました。 http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/252-restlet.html また、筆者は REST を「SOAP よりも簡単な Web サービス」という程度でしか知りませんので、REST について至らない点はご容赦下さい。 1.環境設定方法 (1)restlet の「Version 2.0 Snapshot」を、ここからダウンロードします。 色々
前回、slim3 の画面遷移制御用コンポーネントである ”Controller”の実装方法をまとめました。 今回は、この Controller の UT の実施方法を見てみます。 1.テストクラスの概要 Controller のテストクラスは、Controller クラスと一緒に Ant で自動生成されます。 テストクラスのポイントは、以下の2点です。 (1)org.slim3.tester.ControllerTestCase を継承すること。 (2)jUnit 4.x 系でテストを実装すること。 詳細は、jUnit4.x系の使い方をご覧下さい。 2.テストケースの基本的な実装手順 Controller のテストケース(テストメソッド)の基本的な実装手順は、以下の通りです。 (1)ControllerTester#start() で、Controller のパスを指定する。 Contro
次のページ
このページを最初にブックマークしてみませんか?
『The HIRO Says』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く