滅びゆく山岳会が潰れかけのIT企業に見えてきた
登山の技術を学ぶために山岳会に入りました。コミュ障で人見知り、年功序列大嫌いな自分にはまったく縁がなさそうな山岳会ですが、大人になって違った世界を見る経験として踏み込んでみたのです。まだ少ししか参加していませんが、SNSなどの台頭でどんどん失われつつある山岳会の状況を見ていると、「なんか将来、潰れてしまうであろうIT企業みたいな状況やな・・・」とびびった感じ。 新しいことを学ばない年寄りたち 僕は新しいことを学ぶとき、とりあえず手に入る本を読み漁って知識を得ようとするタイプです。やってみなきゃわからないものではないなら、やるまえに知識を自分の中で整理しておきたいのです。 ひとまず、登山について何十冊も図書館で借りました。似たような本を何冊も読んでいると、かぶる内容があります。それを登山における共通認識として理解します。 さらに、雑誌だと1年ぐらいの周期で登山における共通認識を特集しているよ
4ヶ月間毎晩ガンダムを見ながらUdemyでアジャイル開発入門・応用コースを作りました
4ヶ月間、毎晩ガンダムを10話見ながら、Udemyでアジャイル開発とスクラムの入門コース・応用コースを作りました。スライド数も説明のために細かく刻んだため、過去最大の879枚となり、開くと固まるレベル。達成感半端ないです。 動画トレーニングコースを作ろうと思ったきっかけ 僕は普段アジャイルコーチとして働いているのですが、アジャイル開発の導入だけでなく、最近は すでにアジャイル開発を導入している 複数チームにアジャイル開発を展開している でも、組織全体やスクラムマスターチームを育成できる人がいない といった相談が増えてきました。そこでトピックに合わせてトレーニングや勉強会をするのですが、もうちょっと体系的に学べるものがあれば、お客さまも喜ぶかなぁと考えるようになりました。 それと同時に、10年以上アジャイルコーチをやってきて、この数年はがっつりアジャイルコーチをやってきたので、自分の知識の棚
Redmineやチケット管理ツールの運用まとめ
NECの友人に誘われてRedmineの運用に関する勉強会に参加しました。ツールにとどまらず、タスク管理についていろいろ議論できて面白かったです。いただいた質問に対する回答はこんな感じ。 使った資料 チケットの種類や粒度について 分ければ分けるほど複雑になります。だから、できるだけわけないのがポイントだと思います。分ける場合は、そのコストにみあった意味づけが必要です。それがないと、利用者からみれば不便なルールになってしまいます。 ワークフロー ワークフローは使ったことないです。JIRAを試しに使うときに設定を考えましたが、これも使えば複雑になりますし、「リーダーがチェックする」みたいなフローになると、リーダーの負担が増えて流れが遅くなるので、使わない運用（例えば、口頭やメッセでリアルタイムに依頼するとか）にしました。 おすすめは、「かんばん」を使ったチケットの状態管理です。『リーン開発の現場
アジャイルQAに求められるプロセス全体を俯瞰する「ホリスティックテスティング」とは何か？（翻訳）
この図に問題はなかったのですが、完全に満足していたわけではありませんでした。そこで、私はこの図を微調整し、本当に伝えたいメッセージは何かを考え、私が開発ライフサイクルをどのように見ているかを示す新しいモデル（図2）に落ち着きました。 これはDevOpsサイクルと似ていますが、サイクルの中でコーディングとテストを別々のステージとして分けていることにお気づきでしょう。ビルディングステージ（BUILD）には、コーディングとそれに付随するすべてのことが含まれており、テストはすべてのステージにおいて実施されるものだと私は考えています。 あまり複雑にならないように、フィードバックサイクルを図に含めるのは難しいのですが、この図が表現するサイクルは、時間で枠を決めるものではありません。既知または未知の課題ががどれだけ存在するかによって、ステージのいくつかは非常に早く進むこともあれば、非常に遅く進むこともあ
アジャイルなQAを実現するための「アジャイルQAインセプションデッキ」を作ってみた
アジャイルなQAを実現するためのガイドラインとして、アジャイルQAインセプションデッキを作ってみました。使いながらどんどん更新していますが、資料はこちらで公開しています。 なぜ作ったか？ アジャイルコーチとして活動する中で、テスト自動化の相談が増えてきたように感じています。立ち上げ、ツール選定からテスト実装までいろいろ支援させていただき、いろいろ経験を積んでいくと、注意するポイントがだんだん見えてきました。 さらに、テスト自動化の成功はなかなか難しいと感じており、その成功率を高めるために、ガイドラインのような形にまとめられないかなーと試行錯誤しました。その中で、インセプションデッキのフォーマットがしっくりきたので、アジャイルQA向けのインセプションデッキを作りました。 どうやって使うか？ 資料のノートにコメントも書きましたが、テンプレートにあわせて書いていくことで、ゴールやアクションが明確
フリートドライバーとしてオリンピックボランティアに参加してきたよ
大会関係者（各国のオリンピック委員など）を送迎するフリートドライバーとして、オリンピックボランティアに参加してきました。初日は散々でしたが、だんだんボランティアというものがわかってきた気がします。 フリートドライバーオフィス 我がフリートドライバーオフィスは、選手村の横にありました。「晴海休憩所」という文字が残っているように、倉庫街の休憩施設を使っているようです。最後には男子用トイレは30％ぐらいが「使用不可！」になっているぐらいボロボロでしたが、合計9回参加していくと、だんだん愛着が湧くものです。 あとで聞いた情報によると、同じボランティアのツワモノマダムがいるらしく、配車や担当まで仕切っていたそうです。だから、中のいい人は毎日仕事があり、それ以外は運が良ければ・・・みたいになっていたとか。 ありがとう、3密オフィス。ありがとう村社会。くたばれ！ オフィスはその他2箇所あり、選手村に一番
mablが勝手にスモークテストする機能がなにかと人気 #mabljapan
mablはテスト対象を登録すると、それを開こうとするだけのテストや、開いたページのリンクをクローリングしまくるテストを自動実行します。詳しくはmablが自動作成するなにかと便利なテスト「ログインテスト」と「リンク切れチェックテスト」を解説にまとめたので参考までにですが、このテストがなかなかおもしろい使われ方されるようになりました。 コーポレートページをクローリング これは長年お付き合いのある支援先スタートアップの事例でもあるのですが（詳しくはイベントレポート： 人類よ！これがテスト自動化の実践だ！立ち上げのプロ＆運用のプロから実践知を発見しよう！で動画も公開されています）、彼らは、テスト対象のアプリではなく、自分たちのコーポレートページや、静的サイト郡もクローリングしています。 たまたまテスト対象のアプリにコーポレートサイトへのリンクがあって、クローリングがコーポレートサイトに及んだときに
テスト自動化で削減できる「コスト」とやらについての考察
テスト自動化サービスmablのお手伝いをしていると、よく「テスト自動化のコスト」について質問される。今回は、現状僕がわかっている範囲でその回答をまとめてみようと思う。 なぜこれを書こうと思ったかというと、ちょっと前に「人類よ！これがテスト自動化の実践だ！立ち上げのプロ＆運用のプロから実践知を発見しよう！」というイベントを開催して、ゲストの増原さんも似たようなことを言及していたからだ。 このイベントは、自分で言うのもあれだが、テスト自動化ツールの実践という意味では、かなり内容の濃いものになっていると思う。いい意味でマニアックなのだが、動画も公開しているので、mablのようなツールを活用してアジャイルテスティングを目指す人にぜひおすすめしたい。そして、もっといい実践があればぜひ話してほしい。 彼の言葉を思い出すと「開発にコストをかけようとするのに、品質になぜコストをかけようとしないのか？」とい
子供向けプログラミング教室のバイトを辞めました
子供向けプログラミング教室のアルバイトを辞めました。1年の契約でしたが、非常事態宣言で10ヶ月ぐらいの勤務でした。なによりも、18年ぶりぐらいのバイトでしたが、何かと新鮮で楽しかったです。子どもたちには未来しかありません。 なぜバイト？ 学校でもプログラミングの授業が行われるようになり、プログラミングに関わる仕事をしている身として、どういった内容を教えているのかが気になり、色々調べたりしていました。 また、子どもがキーボードを叩けるようになってきたので、面白そうならやらせてみたいなぁと思っていた次第です。 そして、育休中にScratchの無料コンテンツを作ったり、プログラミング教室のバイトが決まってからは、休日にArduinoの回路やコードを作り、酒を飲みながら勉強するようになりましたなりました。 学んだこと： プログラミング教室なんて通わせるもんじゃない 僕が通っていた教室だけなのかはわ
発注元からみたアジャイル開発とスクラム
普段、僕はアジャイルコーチと名乗り、開発組織に入って改善活動する仕事をしている。受託開発の現場もある。しかし、最近は話題のDXの影響か、受託開発における発注側のユーザ企業のアジャイル開発支援もやらせていただいている。そして、発注側から見た開発は、全然違った風景だった。 開発が正しくできているのかという不安 僕と契約してくださった企業は、「開発が正しくできているか」を課題として感じていた。よって、ユーザ企業と開発企業全体で「うまく」開発できるように支援するのが僕の仕事になる。 もし、発注側に問題があるなら、問題を解決するための提案を行い、実行を支援する。たとえば、「仕様が不明確」などがよくあるケースだが「ここを決めないと作れませんよ。それに、作ったものをこちらも確認できないですよね？」みたいなやりとりをしていく。 もし、開発側に問題があるなら、いつもの仕事のようにアドバイスやコーチングを行う
[翻訳] DevOpsにおける継続的テストとは何か？
Dan Ashby氏による「Continuous Testing in DevOps…」を、本人の了承を頂いてざっくり意訳させていただいたきました。彼のアイデアを知ったのはAgile 2019というカンファレンスでしたが（DanさんはTesting系セッションのオーナーだった）、記事は2016年のもので、今になっても全然色褪せない本質をついた内容です。彼の書いた手書きの図が、さまざまな場所で引用されているのをみても、彼の視点がとても高いレベルにあるのだとおもいます。 Continuous Testing in DevOps… 最近、いくつかのカンファレンスに参加しました。テストやアジャイル開発や開発に関係するイベントです。新しい人達に出会えたり、色んな人の物語を聞けるた点では全体的にとてもよいイベントだったと思いますが、いくつかの講演はなかなか辛いものでした。その理由は、自動化、アジャイル
![[翻訳] DevOpsにおける継続的テストとは何か？](https://cdn-ak-scissors.b.st-hatena.com/image/square/754177bad9afc459466642f0662d49c7ce0ee1ce/height=288;version=1;width=512/https%3A%2F%2Fdaipresents.files.wordpress.com%2F2022%2F01%2F62966-model-1-1.jpg%3Fw%3D1200)
昔、ローソンの店長が言ったことは正しかった
Fiona Thomson – Lawson Station 昔、バイトを探していたときに、池田のローソンの面接を受けたことがある。そのときはとくにやりたいこともないままふらふらしていて、その面接で言われたことは今も覚えていて、面接の後「ムカつくなー」とかフンフンしていた気がする。 ローソンの店長の一言 面接でのやりとりはこんな感じだった。 店長「なんでバイトしたいの？」 僕「まぁ、特に理由はないっす」 店長「やりたいこととかないの？」 僕「特になにも。まぁ、強いて言うなら映画が好きだから映画監督ですかね」 店長「だったら、コンビニでバイトしてたらだめだよ。映画監督につながる仕事しなきゃ」 当時の僕は、適当に言ったことが拾われ、さらにダメ出しまでされてとてもムカついた気がする。 でも、よくよくかんがえると、店長の言っていることはごもっともで、こういう人やその人の言葉ほど大切なものはないと思
AWS認定ソリューションアーキテクトアソシエイトに合格しました
フリーターになり時間が無限になったので、これまで時間をかけられてなかった分野の勉強をはじめています。その第一歩がこのAWS認定ソリューションアーキテクトアソシエイト（SAA）でした。ひとまず、高めの点数で取れたのでまずまずの結果ですかね。 なぜSAAなのか 近年は、マネージャとしての業務が多く、AWSのようなサービスを使う機会がありませんでした。いつも調べながらポチポチしていましたが、もうちょっと細部まで理解しておきたかったので、なにかいい勉強方法はないものかと。 たまたま、ある人が「インフラ周りを理解するならAWS認定いいですよ」と教えてくれて、調べてみると、SAAはサービス全般の理解から活用方法、クラウドを使ったシステム構成のプラクティスを学ぶのにピッタリ。 ということで、SREの後輩と週1集まってカフェで勉強をしてきました。後輩には色々質問しましたが、「どうやって実現してるの？」とか
映画『ソラニン』を観て会社を辞めました
アジカンの『ソラニン』が大好きで、ふと「なんでソラニンなんだろ？」と調べてみたら漫画と映画があるとわかり、帰ってアマゾンプライムビデオで『ソラニン』を見てしまい「会社やめよう」となって、先月で会社を辞めました。 藤原大 41歳 厄年。無所属。しばし お暇いただきます。 ふりかえり 「日本一の品質組織を作ろう」と思い立ち、無我夢中で働いた2年間は「楽しい」しかなくて、どんどん空が広がっていくようでした。目指すべき未来に共感して集まってくれた、優秀なメンバーには感謝しかありません。そこまでたどりつけなかったのは、ひとえに僕の力不足です。 正直、自分が作り上げた部署を、自分が一番に去るなんて考えもしませんでした。大きなショックを受けています。でも同時に、まだ心のどこかで、「もっとすごいことできるんじゃないか？」という思いもあるので、立ち上がるんだボクサー。 最後の半年ぐらいは、「マネージャたるも
自動化はテスター撲滅の夢を見るか？JaSSTで語られたテストの未来、品質の未来 #JaSST
2019年3月27日、日本大学理工学部 駿河台校舎１号館にて、「JaSST’19 Tokyo」が開催されました。初日のセッション B2「テストの未来、品質の未来～自動化はテスター撲滅の夢を見るか？～」において、生まれて初めてモデレータをさせていただき、自動化を中心としたテストの未来、品質の未来を議論しました。この記事はそのセッションログをまとめたものです。 このセッションについて （文章を読みやすくするために内容を変えないように書き起こしています） 藤原：みなさん、こんにちは。よろしくおねがいいたします。本日は「自動化はテスター撲滅の夢を見るか」というパネルディスカッションということで、5人の方をお招きしてお話をさせていただきたいと思います。司会はメルカリでAutomation & QA グループ（以下：AQA）のエンジニアリングマネージャをしている藤原と申します。よろしくおねがいします。
中途の人が現状の課題や問題を責めちゃう問題について
だいぶ昔。レガシーなシステムを担当することになった中途エンジニアが、現場のエンジニアとぶつかってしまい、結局、弾き返され、その後辞めてしまったことがあった。中途あるあるの一つだろうけど、最近似たような話を聞いて、あらためてこの問題について考えてみた。 できてないことにイライラしてしまう人たち 課題のない職場なんておそらくなくて、そういう状況だからこそ、経験を積んできた中途が求められたりする。 でも、現状を見てしまうと「あれもできていない」「これもできていない」とか、「これまでよくこれでやってきたな」とか思ってしまう。 僕も昔同じことを思ったけど、超巨大レガシーシステムについて、とある尊敬するアーキテクトが 課題や問題があるとしても、現状に敬意を持つべき と話しているのを聞いて、考え方がちょっと変わった。 そして、この歳になってあらためて非難する人たちを目の当たりにして、「いつの時代も繰り返
タスクをどんどん遅延させていた話
By: Courtney Dirks タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話をちょっと読んで、タスクをどうさばくと効率的かを考えたときのことを思い出しました。全然この記事とは関係ないのですが、そのときの答えは「タスクをできるだけ遅らせる」でした。 お問い合わせ対応をさばく 当時の仕事で問題になっていたのは「お問い合わせ対応」でした。社内からの問い合わせが多く、それに時間がとられてしまい、本来の仕事にとりかかるのは定時を過ぎてから・・・とか。 そのときにヒントにしたのが、リーンソフトウェア開発７つの原則。 原則１:ムダをなくす 原則２:品質を作り込む 原則３:知識を作り出す 原則４:決定を遅らせる 原則５:速く提供する 原則６:人を尊重する 原則７:全体を最適化する 特に覚えている部分を抜粋。 原則１:ムダをなくす やれる時間は限られているので、や
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Selenium IDE形式などテストケースのエクスポートも簡単にできちゃう。そうmabl CLIならね #mabljapan
ガントチャートがほしいならWrikeでプロジェクト管理がよさそう
MTGの時間を見える化するガジェット「TIMEQUBE」を買ってみた
