サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
猫
kawaguti.hateblo.jp
8月にサンディエゴに行った時に感動した電動スクーターシェアですが、日本でもAnyPayが福岡市で実験を始めるというニュースが流れてきました。 kawaguti.hateblo.jp prtimes.jp ...という昨今なのですが、東京近郊でもはじめたいという熱い想いで「いまできること」からはじめている、Kimさんのスクーターシェアの情報をいただきまして、さっそくですが、試乗させてもらってきました。 ナンバー取得済みの電動スクーター!公道を走れます(要原付免許、ヘルメット) 光栄なことに私たちが最初のユーザーだということです。わーい。 機材はシンガポールの企業が作っているものに、ミラーやウインカーなどを追加で装備して、ナンバーを取得しているとのこと。 説明を受けて、ヘルメットをつけて、公道へ! Scoot20190113 電動スクーターは、スクーターみたいに場所取らないので、都市部の足に最
前回のエントリもずいぶん多くの方に読んでいただいたようで、大変驚いております。 kawaguti.hateblo.jp さらに、いただいたフィードバックから、もう一点補足した方がよいかなと思いまして、このエントリを書き始めました。補足の補足ですみません。 リーダーがITを学ぶのが早いか、IT技術者が経営を学ぶのが早いか 前回、IT技術者ではないキャリアを歩んでいる方々がプログラミングを学んだ事例としてジャパンタクシーの川鍋社長のエピソードと、若手向けプログラミング研修の例を出しました。 ビジネスマンがプログラミングを学ぶ価値 アジャイルジャパン2018で、ジャパンタクシーの川鍋社長が話していたことが印象に残っています。川鍋さんは正月休みを利用して、1週間詰め込み型のプログラミングスクールに行き、Railsを使ったプログラミングを学んだそうです。そこで発見したのは、「一文字間違えただけでも動
昨日のエントリは思いがけずアクセスをいただきまして、はてブのホッテントリにものったようで、驚いております。ありがとうございます。ここのところお腹の中にぐるぐるしている思いを新年にかこつけて吐き出した記事で、切れない「なまくら刀」のような後味で申し訳なく思っております。 kawaguti.hateblo.jp この記事の中で、業務知識という言葉の定義を曖昧なままに使ってしまって、ブクマコメントで「業務知識とはだな...」というご教示をいくつかいただきました。ご指摘ありがとうございます。 SIerで業務知識といえばお客さんの業務に関する知識 システムインテグレーター(SIer)方面の方は「(自分たちはIT知識を持っている前提で)、ユーザー企業の人が持っているべき知識のことを業務知識と呼ぶ」という認識なのだろうと認識します。そういえば、10年以上前になってしまいますが、業務知識はSIerに必要か
2017年1月に米Microsoftに遊びにいって感じたことを、そのあといろんな人に伝えてきたのですけど、ブログには書いていなかった気がしますので、年頭にあたり書いておきます。 機動警察パトレイバー アーリーデイズ | Netflix (ネットフリックス) ツアーの際に現地で講演してくれた方の1人が河野さんで、ありがたいことに翌年のRSGTで基調講演していただきました。(もう1人Chap AlexはDevIpsDaysでお呼びできました。) 米Microsoftで働く日本人エンジニアが語る、“楽しく開発”するために必要なこと - Part1 - ログミーTech ここで痛感したのは、ビジネスに必要な業務知識を経営層・マネジメント層が持っていないと、もう儲からないんじゃないか?ということです。ソフトウェアに関する業務知識というと、コンピュータサイエンスだったり、もうちょっと基本的なレベルで、
このエントリはRSGTアドベントカレンダーの非公式な27日目の記事です。 adventar.org 昨日は非公式な26日目としてきょんさんが「#RSGT2019 の歩き方 - うさぎ組」について書いてくれました。当日どんな風に過ごしたらいいか、大変参考になるお話だったかと思います。私は前回「RSGTのセッション採択はどのように決まるのか - kawaguti’s diary」というのを書きました。カンファレンス関係者しかうれしくなさそうな内向きの記事だったわけですが、長らく書き出そうと思って書いてなかった内容だったので、個人的には大変満足しています。 あと、ログミーさんの方で、昨年の基調講演であった河野通宗さんの記事がでています。改めて読み返して、本当に素晴らしいお話だったなと思います。 logmi.jp さて、今日のお話は、またカンファレンス運営に関する話をしようと思います。 非営利カン
ykmc09.hateblo.jp 横道さんにやたら褒めていただいたRSGT実行委員会の作業ですが、一つ大事な文化があるとおもってます。「集まった時に、議論や検討より、できる限り作業を進める」という文化です。 どうしてもみんな集まった時に議論とか意思決定をやりたくなっちゃうんですよね。いろいろ決めるんだけど、そのあと別れてからの実行ができなくて、次に集まった時にまた同じ議論しちゃったり....。前に来てなかった人が蒸し返して、進めてる人との間で雰囲気悪くなったり。 これ原因は、作業が前に進んでないところだと思うんです。特にコミュニティは主業務じゃないでしょうから時間取るのも大変。そりゃうまくいかないです。 作業を終わらせるために意思決定するわけですから、時間内に作業まで進めれば、結果見てOK/NGのフィードバックも得られます。セッション募集などすぐに結果がわからないものも、作業結果(募集サ
adventar.org RSGTアドベントカレンダーの3日目です。昨日は天野さんが「僕がスクラムマスターになった訳 - はてブロ@ama_ch」という実践者ならではの記事を書いてくれました。こうした事例があるのも、この八年くらいで大きく変わったところで、大変頼もしいですね。今日はセッションの決め方について書いてみます。書いてみて思ったことは、これ興味あるのカンファレンスやる人だけじゃない?ということですが、きっと深読みすると様々なプロダクトバックログ作成にも通じるものがあるのではないかと思います。そう、これはプロダクトオーナーシップの話なのです!(どうかな?) オープンプロポーザルとLike投票機能を使ったセッション採択の進め方 Regional Scrum Gathering Tokyo (RSGT) は、永瀬さんが書いてくれたような紆余曲折の結果、おかげさまで大変多くのセッション公募
「アジャイルやってないんですよね」「うちアジャイルじゃなくって」っていう話をたまに聞くんですけど、「アジャイルじゃない」って、どういうことかなぁ、と思ったりします。 アジャイルはアジャイルマニフェストで定義された言葉なので、その内容をみて、そうなっていない、というのが「アジャイルやってない」ということなのかな? agilemanifesto.org 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 これをひっく
Beyond Legacy Code の著者、David Bernstein (@ToBeAgile ) さんの記事を翻訳しました。ソフトウェアエンジニアは新しいことを常に学ぶ必要性がある、 それはなぜか、というお話です。 David さんは DevOpsDays Tokyo 2019 (4/9-10) の 基調講演で来日予定です。 Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software 作者: David Scott Bernstein 出版社/メーカー: Pragmatic Bookshelf 発売日: 2015/08/03 メディア: ペーパーバック この商品を含むブログ (1件) を見る ソフトウェア開発における学習曲線を受け入れる David Bernstein著 -
日経SYSTEMSの安藤さんの記事が、それなりに盛り上がりまして。 3分でわかる アジャイル開発 | 日経 xTECH(クロステック) 以下の記述が、企業さんなんかを訪問させていただいて意見交換していると出てくる「私たちウォーターフォールでー」というご発言の部分をうまく写し取っているのではないかと思いました。膝ポンです。 現在多くの開発現場で利用されているウォーターフォール型の開発では、要件定義工程で要件を確定させてから、設計工程や開発(製造)工程に移る。後工程になって要件定義の漏れや変更などが発覚すると、要件定義の工程まで戻って作業をやり直さなければならない。 要件定義の漏れや変更が発生した際、アジャイル開発では次のイテレーションの始めに要件の優先度を再検討する。これにより変更リスクに備えつつ、より価値の高いソフトを提供できるようになると言われている。 この2つは実はほとんど同じことにす
9月末日をもちまして、楽天株式会社を離れることにいたしました。 2012年4月に入社しましたので、6年半の間、お世話になったことになります。アジャイルのトレーナーやコーチとして各部門のチームをお手伝いさせていただいたり、外部のスペシャルなトレーナーの研修を運営したり、楽天テクノロジーカンファレンスを運営したり、新卒研修をやったり、ラッカソンをお手伝いしたり、英語公用語化のコンサルをしたり、本当に色々とやらせていただきました。こうしてふりかえってみると、あまり前例のないことを、思い切って任せていただいた件ばかりで、ご信頼をお寄せいただいた皆様には、感謝の念にたえません。 今後はしばらくお休みをいただきながら、次のステップを考えていくつもりです。この機会に話したい!という方がいらっしゃいましたら、ぜひお声かけくださいませ。 Fearless Change アジャイルに効く アイデアを組織に広め
アジャイルバンクーバー2010で行われた、リンダ・ライジングさんのポジティブレトロスペクティブと、ジェフ・パットンさんのユーザーストーリーマッピングを活用したふりかえりについてのブログエントリの翻訳です(著者のSteve Rogalskyさんの許可をいただきました)。翻訳にあたっては高橋陽太郎(@poohsunny)さんにレビューのご協力をいただきました。ありがとうございました。 ポジティブな点を述べることで「行った事実」にフォーカスできることと(課題を言うとwishが増える)、インデックスカードで整理する手法を組み合わせているところがよいなと思いました。 原文はこちら Agile Retrospectives - a Rising Patton Fusion http://winnipegagilist.blogspot.com/2010/11/agile-retrospectives-
原題の Fearless Change にはアジャイルという表現はございませんで、リンダ・ライジングがアジャイル(とパターンのコミュニティ)で活躍している人だというニュアンスで、アジャイルについて気になっている人に届けたいという思いがありまして、タイトルに入れることになりました。 内容については、もちろんアジャイル開発に限定せず、新しいアイデアや技術、文化などを組織に導入する際に参考になるものになっています。 この「アジャイルに効く」というタイトルを決めるまでにはかなり議論があったのですが、アジャイル開発の導入に効く、と、使い方もアジャイルに柔軟に、というような意味合いでダブルミーニングを志向してみました。 出版後、「アジャイルアレルギーの人はこれで読まなくなるので、ないほうがよかった」というフィードバックもいただきまして、なかなかむつかしいなぁ、と思っております。 Fearless Ch
360度評価ってあるじゃないですか。日本語でググると多面的評価とか出てきたりします。 いくつかの北米企業やコンサルの方に聞いてみたところでは(調査対象が偏っている可能性はあります)、360度評価の目的は、「課題のあるマネージャーをみつけること」です。つまり、部下が「あのマネージャーとは仕事しづらい」というのをフェアに報告できる制度です。もちろん部下のなかでも、仕事しやすいという意見とそうでない意見が混在する可能性も高いかなと思います。なので全員に聞く。 パフォーマンスを引き出すのがマネージャーの仕事 マネージャーの責務、会社が期待することは、部下の人たちに仕事をしてもらって、組織全体としてパフォーマンスを最大化することです。一方で、事業のトップや人事部にとって、マネージャーの評価ってとても難しいんです。うまい人は上司や人事部にはいい顔しつつ、部下にはつらく当たったりしますから。ですので、3
先週1年ぶりのアメリカ、1.3年ぶりのサンディエゴに行ってきたのですが、街中に見慣れないものが。キックボードみたいなこれが、電動スクーター Bird です。 結構走ります。どこにモーターやバッテリーが載ってるんだかわからないくらいコンパクトなのに、25km/hくらいでるそうです。セグウェイの技術で作られているようです。 Bird スマホでポケモンを探すように近くのBirdを探して、筐体のQRコードを読むと、ロックが解除されて乗ることができます。 こちらはもう一つのサービス Lime。後発っぽいけど自転車も探せるし、バッテリーパックが追加されていて航続距離は長そうです。こちらは免許証登録が不要です(Birdは初回に免許証の写真を送ります。日本のでOK。アメリカの免許証だとバーコード写真に撮るだけで登録できるみたい)。 免許が不要なせいか、一緒にカンファレンスに行ってた楽天の内定者の学生さんた
海外カンファレンスの講演でちょくちょくでてくる軍服の女性がいる。 File:Grace Hopper.jpg - Wikimedia Commons グレース・ホッパーさん。 グレース・ホッパー - Wikipedia 話を聞いてる英語圏のソフトウェア系の人はみんな知っているだろうけど、Wikipediaによれば、最初のコンピュータENIACを設計したエッカートとモークリーが立ち上げた商用コンピュータプロジェクトUNIVACに参加して、「機械語ではなく、英語に近い言語によってプログラミングできるようになるべきである」というポリシーのもとCOBOL作った人でもある(らしい)。 File:Grace Hopper and UNIVAC.jpg - Wikimedia Commons Wikiquote によると “It's easier to ask forgiveness than it i
@nihonbuson さんから、アジャイルでのレビューについて話してほしいというご相談をいただいた。そういえばレビューについてあまり調べたことがないし、カンファレンスでもテーマとしてそれほど聞いた感じがしない。 森崎先生が書かれた連載が本になっていて大変勉強になったのだけど、ご本人曰くこれは設計レビューであってコードレビューではないとのこと。スプリントレビューもまた違う観点もあるかなと思いつつ、指摘のダメパターンはだいたい共通している気がしている。 なぜ重大な問題を見逃すのか?間違いだらけの設計レビュー改訂版(日経BP Next ICT選書) 作者: 森崎修司 出版社/メーカー: 日経BP社 発売日: 2015/10/06 メディア: Kindle版 この商品を含むブログを見る Erik Dietrich さんの Manual Code Review Anti-Patterns という記
RSGT2018まで2週間を切りました。今回は久しぶりに Open Space Technologyを行うのですが、全然説明しておらず、「3日目ってなにやるの?岩切さんのキーノートだけ?」というお問い合わせを複数頂きましたとのことで、遅ればせながらこちらに説明を用意しました。カンファレンスサイトには準備でき次第掲載いたします。 2018.scrumgatheringtokyo.org オープンスペーステクノロジー まだ議論し足りない? 聞きたいことが聞けてない? 誰かに聞いてほしいアイデアがある? 本年のRSGT3日目は、東京では3年ぶりのオープンスペーステクノロジー(OST)を行います。 Regional Scrum Gathering Tokyo 2018 - Program Schedule | ConfEngine - Conference Management Platform
Tech Crunch Japan 2017 に参加してきた。2日目の最初のセッションはソラコムの玉川憲さんのトーク(聞き手は西村賢さん)で、だいぶクラウドメモ帳(Facebook)にメモったのでここに置いておきます。素晴らしい聞き手と素晴らしい答え。ありがとうございました。メモ内容の正確性は...ごめんなさい(指摘いただければ直します)。 jp.techcrunch.com IVSとWiLから7億調達。 起業に不安はなかった。 クラウドによって起業しやすくなった。 以前はラック立てるために一億円とか しかし日本であまりスタートアップが出てこないという葛藤が 安川さんとシアトル出張 ビールを飲んで盛り上がる クラウドでなんでも作れるよね。でも世間は思ってない 銀行の基幹システムとか 別れてホテルに帰ったあとねれなくて仮装のプレスリリースを書いた(アマゾンの文化 その時の名前はコネック 起き
いつだったか、たぶん今年だけど、Zero Bug tolerance (既知のバグをゼロにしてデリバリーする) の話によしおかさんから「それは現実的じゃない。」という指摘を頂いた。確かに昔はやってなくて アジャイルとか CI/CD とかで変わってきたところだと思う。 むかし、半年以上のスパンで出すときは、リリース時にQAで見つかったものに重要度/緊急度の分析をして対応決める(トリアージ)が普通だった。深刻じゃないバグは注意書きしたりした。一定以上、深刻なのは小さく再リリース(HotFix)したり。なのでリリース後は結構忙しかったり。 あ、HotFixっていうのもマイクロソフトが自動アップデートするようになったWindowsの方のXPあたりから聞くようになった単語ですね(個人的にはそうだけどもっと前からあったのかもしれない)。 継続的デリバリーの世界では毎日潰してく。品質が上がったというより
Ron Jeffries たちが、2009年くらいから、Scrumとかチームのプラクティス中心になってしまったアジャイル業界を嘆いて、技術プラクティスの復権のためのミーティングを行っていて、そこで生まれたのがソフトウェア職人マニフェスト ( Manifest of Software Craftsmanship : ソフトウェア・クラフツマンシップ・マニフェスト) だ。 平鍋さんが当時行った翻訳はこれ。 動くソフトウェアだけでなく、しっかり作られたソフトウェアを。 変化に対応するだけでなく、着実に価値を付加していくことを。 個人と相互作用だけでなく、プロフェッショナルたちのコミュニティを。 顧客との協調だけでなく、生産的なパタートナーシップを。 なぜか本編サイトにマージされていない。 Well-Crafted は「しっかり作る」よりもっと技術職人っぽく、「精巧に作る」、「巧みに作る」というニ
外から見ていると、難易度の非常に高い達人の仕事でも、さも簡単にやっているかのように見えてしまう。....これを思い出すような体験をしたのでメモしておく。 スクラムの改善ワークショップで.. こないだ、旧知の方が勤めるある会社さんで、スクラムの基本を紹介するセッションをやった。3時間半から4時間で行うそのセッションでは、ピンポンゲームを使って、改善の仕組みを学んでいただくことが多い。今回はその旧知の方がピンポンゲーム体験済みだったので、ゲームの参加者グループからは外れてもらい、外部からの視点で見ておいてもらうことにした。 一通りゲームが終わり、全体のふりかえりをすることにした。協調問題解決の練習の一環として、参加者全員でそれぞれ気づいたことを付箋に書き出し、全体でまとめていくというプロセスをとる。まとまった付箋について、誰かに立候補してもらって、外側の人間(講師である私)に対して説明していた
「問題をいたいほどよく知っている人」が、熱意を持って改善のために努力するということ。 こういう人がいると、プロジェクトはうまくいくと固く信じている。言葉は悪いが「熱意ある共犯者」と定義したい。 2009年に参加した参加したカンファレンスで、住友信託銀行(当時)の小吉文子さんのセッションに参加して、こんなことを書いていた。 人事や総務といった業務担当の方を支援する仕事に最近関わらせてもらっていて、開発部門を支援するのとはまた違った趣があるのだけど、成功要因の根っこにあるのは、こういうことなんじゃないかという思いを強くしている。 ずっとこの思いは変わっていないし、誰かと仕事するときには指針としている。変化は情熱のあるエバンジェリスト(イニシエーター)から起こるものだろう。 もちろん仕事には様々な要因が影響し簡単ではない。共犯者の情熱も有限なので、途中で諦めてしまったり、中断して時期を待つことも
Agile 2017 の帰り道、少し滞在を延長して、デトロイト近郊のアナーバー(Ann Arbor)にあるメンローイノベーションズの見学ツアーに参加しました。アナーバーは名門ミシガン大学(U-M)の本拠がある街です。ちょうど200年前に設立されたこの大学の周りに街ができたようなところみたいです。成田から直行便があるデトロイト空港から車で30分くらいでした。 ジョイ・インク 役職も部署もない全員主役のマネジメント【電子書籍】[ リチャード・シェリダン ] ジャンル: 本・雑誌・コミック > ビジネス・経済・就職 > 経営 > 経営学ショップ: 楽天Kobo電子書籍ストア価格: 1,944円 ジョイ・インク 役職も部署もない全員主役のマネジメント 作者: リチャード・シェリダン 出版社/メーカー: 翔泳社 発売日: 2017/01/20 メディア: Kindle版 この商品を含むブログを見る
昨日に引き続き Agile Conference の記録を日記にしとこうと思います。 ※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5 High Performance via Psychological Safety (Joshua Kerievsky, Heidi Helfand) POPULAR Modern Agile で再ブレイク中の皆さん大好きジョシュアですが、SFAgile という2011-13年くらいにやってたカンファレンスで2年連続でキーノートやってて、ベイエリアのアジャイルコミュニティではもともと人気者な気がする。 今回は Modern Agile から心理的安全のセッション。心理的安全を確保すると、生産性が上がるというのがタイトルなんですけど、その時点ですでに納得なわけです。逆に心理的安全がないと
最近ほとんどSNSばかりでブログを書いておりませんが、今年も Agile Conference に参加しております。2009年からなのでもう8回も参加したらしいです。 ※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5 初日は基調講演から始まって90分の並行セッションが3つという構成です。 オーガナイザーからの説明とか。 リーダーシップに関する基調講演。潜水艦のマネジメントだった経験を踏まえて、マネジメント層の重要さとか、心理的安全とか自律性の話をしていました。 基調講演の後は、アジャイルコーチのスコアカードの話に参加。メトリクスを取ろうという話でした。 Productivity, Predictability, Responsiveness, Quality, Agile Maturity/Fluency, Busin
Developers Summit 2017 でやった、Joy, Inc. のジグソー法ワークショップの資料を公開しました。Joy, Inc. は2000年代初めからアジャイル開発とデザイン思考を取り入れて顧客を巻き込んだ受託開発を行っている、メンローイノベーションズ社の取り組みについて、ファウンダーであり現職のCEOであるリチャード・シェリダン自らが描き下ろした本です。米国のアジャイルコーチの多くが見学ツアーに訪れる、活きた実例であるメンロー社の徹底した顧客志向の文化に触れることができます。 書籍の無料お試し版(電子版、固定レイアウトのみ Kindle Kobo ほか)がありますので、購入前の方でもこのワークショップを行うことができます。イベントなどでワークショップを行うこともできますので、お声掛けいただければ幸いです。 ジグソー法の読書会への適用は教育心理学概論読書会で試みられ、知識
周りの目が必要以上に気になってしまう人がいます。たぶん生まれ持ってしまったか、家庭や社会の環境との付き合いで長い時間をかけて作られてきたそうした感覚なのだろうと思います。もし生存のために必要に迫られて獲得した能力だとすれば、急に変えるなんて難しいでしょうね。 私ももちろん相手が自分をどう思っているかは大変気になります。ものを教えたり、アドバイスするようなことを仕事にしてしまっているこの数年は特にそこは重要になりました。しかし相手の心なんてどうあってもコントロールできない。ストレスがある環境下でパフォーマンス出せるほど、人間がうまくできてないし...。どうするか....。 で、私なりにいくつか心がけていることを書いてみます。 なるべく攻撃してくる人や話が合わない人とは付き合わず、認めてくれる人とだけ付き合うようにしていけるといいなぁと思います。生きて行くために何人と付き合わなければならないか
技術評論社の傳さんからご恵贈いただきました。中小企業で内製化やIT投資のためにはじめてエンジニアを採用する方を主に想定して書かれたエンジニア採用についての本です。「2万名近いエンジニアの職務経歴書を読み、エンジニア採用の責任者として年間700人以上の社員雇用の最終決裁を判断し、約500社の経営陣と面接してきた著者が...」と帯にある通り、豊富な実例(主に失敗例)を持つ著者の方が、ズバっとえぐってくる感じの内容になっています。知らなかったことがたくさん書いてある、という意味では HARD FACTS レベルでした。 その「エンジニア採用」が不幸を生む 〜良い人材を見つけ、活躍してもらうには何が必要か?【電子書籍】[ 正道寺雅信 ] ジャンル: 本・雑誌・コミック > ビジネス・経済・就職 > マネジメント・人材管理 > 人材管理ショップ: 楽天Kobo電子書籍ストア価格: 1,922円 とい
次のページ
このページを最初にブックマークしてみませんか?
『kawaguti’s diary』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く