Agile Japan 応援メッセージをお送りします

シアトル近郊のレッドモンドに来ております。マイクロソフト本社にふらりと遊びに来ました。明日は移動して2年ぶりに Menlo Innovations にも行くつもりです。この5-7月で、2017年に訪問して刺激を受けた三社(Microsoft, Menlo Innovations, Hunter Industries)に訪問して、ここ2年で考え、やってきたことの答え合わせをするような旅になったらいいなと思っております。戻ったらまた何かの折に共有できればと思います。 

f:id:wayaguchi:20190716061445j:plainf:id:wayaguchi:20190716061617j:plain

f:id:wayaguchi:20190716055509j:plainf:id:wayaguchi:20190716061845j:plain

牛尾さんの応援メッセージ(5分20秒)

あまりにもふらっと来てしまいまして、アジャイルジャパンを欠席することになってしまいました。それを決めた場所に実行委員の小坂さんがいまして「リモートでつないで」などとご要望をいただいたのですが、それならば、ということで米国にいる牛尾さんと応援メッセージを収録することにしました。私たちが今どんなことを考えていて、日本のアジャイルコミュニティの皆さんに伝えたいことはなんだろうか、と考えた結果、「はげちゃびん」について話すことになりました。ナンノコッチャですが、内容はビデオをご覧いただければ幸いです。


Agile Japan 2019 応援メッセージ

f:id:wayaguchi:20190717232304j:plain

Sam Guckenheimerさんの応援メッセージ(40秒)

Agile 2014のキーノートスピーカーで、Azure DevOps という アジャイル&DevOpsツールを長年リードしてきて、今はさらに社内向けの One Delivery System という共通プラットフォームも手がけている Sam Guckenheimerさんの応援メッセージもいただきました。字幕も付けました。


Agile Japan 2019 応援メッセージ by Sam Guckenheimer

牛尾さんのメッセージの未編集版(9分)

ちょっと尺が長くなってしまったので、多少切って作ったのが上のバージョンです。未編集版はこちらです。牛尾さんがなぜ米国に渡ったのか、についても語られています。9分なので、長いと言っても電車とかで聞くにはちょうどいいサイズな気がします。


Agile Japan 2019 応援メッセージ 未編集版

 

アジャイルジャパンでは、Fun! Done! Learn! もあります

私は欠席させていただくことになってしまったのですが、仲間たちによる「Fun! Done! Learn!」のふりかえりセッションがあります。Fun! Done! Learn! は特に奥ゆかしい日本のチームにとてもあっているふりかえりプラクティスだと思っております。未体験の方も、アジャイルジャパンのふりかえりをしたい方も、ぜひご参加ください。楽しく前向きに学びを捉えてアジャイルジャパンを締めくくりましょう!

f:id:wayaguchi:20190717231458p:plain

f:id:wayaguchi:20190717232024p:plain

f:id:wayaguchi:20190717232044p:plain

https://www.agilejapan.org/session.html

 

(おまけ) Microsoft キャンパスにいた野良うさぎさんです。

f:id:wayaguchi:20190716054917j:plain

 

上司ガチャ - 組織の体制変更がチームを壊す日

大きめの企業でスクラムで回し始めて、ビジネスもうまくいくようになってきたところで、急に訪れがちなのが「体制変更」です。これまで陰に日向に支援してくれた上司や役員の方がいなくなって、新しい方がいらっしゃるという。ここで苦労したり、諦めてしまう例が多いと感じます。

f:id:wayaguchi:20190505091942j:plain

答えはないのですが、雑多な考えをここに記録しておこうと思います。まとまってもいないので、無駄に長くてごめんなさい。

うまくいく確率は論理的に50%を下回る

「新しい人とうまくいく可能性もあるので、50:50じゃないの」という意見もあるかもしれません。しかし、なにかを始めるときはだいたいうまくいきそうな上司や役員を選んで相談するわけです。しかし、人事異動で次に来る人は選べません。ですから、うまくいっていたことがうまく行かなくなったり、説明を求められたり、基本、いままでよりは手間が増えることは確実ですし、その結果、フラストレーションが溜まりがちです。

良さそうな上司が来たけど、最初だけだった、というケースも聞きます。外面がよいので上司の上司受けは良かったんでしょうけど、意外とチームの要望に対応できなかったり、(酷ですが) 十分な人生経験が不足していて器が小さかったり。付き合ってみると人間そう都合よくはできていなかったりするのでしょうね。成長には時間が必要ですが、本人や周りが待ってくれるとも限りません。まだ対象領域の業務知識があれば、議論ができるところなのですが。

kawaguti.hateblo.jp

上司ガチャ

最近はソーシャルゲームの用語から、上司ガチャというようです。組織変更に関していえば上司になる人も被害者なんじゃないかと思います。お互いがガチャ。

sayonara-shachiku.com

博士の教え: くそったれ上司には近づくな

スタンフォード大学経営学の権威ロバートサットン教授はこの本で、エネルギーを奪い、惨めな思いになるようなクソったれ上司には近づくなと言っています。身もふたもないですがそれくらい強力だということでしょう。話が通じない人は変わりようもないですしね。また、誰にでもくそったれの素養があるとも言ってます。

あなたの職場のイヤな奴

あなたの職場のイヤな奴

 

アメリカのいくつかの企業では360度評価を使って、問題のあるマネージャーを見つけ出せるようにしているようです。

kawaguti.hateblo.jp

日本の場合はメテオフォール感ありますよね。ご神託が降ってくる。上司の文句言うのは他人のことを悪くいうみたいで嫌だし、自分が悪いような気がしてしまう。我慢する方がいいというアドバイスをもらうことも多いです。

eiki.hatenablog.jp

マネージャーの仕事はチームの能力を最大化すること

マネージャーという役割は優れたチームの成果を最大化することです。マネージャーが生産の中心に来ることはありませんので、あくまで手助けするのが役割なのです。いなくても回るけど、それでいて、いることで価値を出す宿命があります。

皆さん知らないかもしれないが、この世界は実は、売上とそれを支える進捗が救いなんだ。進捗の源泉はアーキテクチャでありドメインモデリングでありシステム設計者だ。マネージャではない。

medium.com

Microsoftデベロッパーの河野さんもこう言ってました。

そういうデベロッパーがバラバラにやっているのに対して、「今はこっちじゃない。今フォーカスすべきはこっちだよ」とちゃんと指導してくれる、ディレクションをしてくれる。船のキャプテンと同じですよね。そこをしてくれる人がいないと、チームとして発散しちゃいます。

ポイントとして、常にマネジメント側から「なにがゴールか」というのをメッセージとして出し続ける必要があります。「我々がこうやるのはどうして必要なのか?」あるいは「これをやることでお客さんに喜んでもらえる。だからやろう」と。これって最初に言うだけじゃなくて、毎日のように言うんですね。

そこへ向かうためのマインドシフトが必要なのだそうです。

というのは、やっぱり日本的な考えだと、上司が指示して自分は「へへー」みたいなイメージがあったので。でも、そこで「上司とは自分のパフォーマンスを最大化してくれるための良きパートナー」だと(考えた)。そこってマインドシフトがすごく大事でした。

logmi.jp

一方、Amazon創業者のジェフ・ベソズはこんなスタイルだそうです。謙虚でやりやすいリーダーが来てくれるといいですね。

「『多くの場合、正しい』を実践できているリーダーを観察すると、そこにはいくつかのパターンがあった。そうしたリーダーは他人の話をよく聞く。そして考えを頻繁に変える。政治家が頻繁に考えを変えるのは問題だが、リーダーにとっては必要なことだ。単に新しいデータを得たから考えを変えるだけではない。多くの場合、正しい判断ができるリーダーは、新しいデータがないときでさえも考えを変える」(ベゾス氏)

tech.nikkeibp.co.jp

頭が硬くて、必要な知識を持っていないリーダーが上司に来た時には、緊急停止スイッチを押さないといけないのかもしれません。人を変えるのは、難しいか、とても時間がかかります。

enterprisezine.jp

これは最近になってスクラムが普及して云々とか、シリコンバレーがどうこうではなく、私が知る限り昔からできるマネージャーはチーム若手をそそのかすのが上手くて、報いるのも上手です。

うまくいっているのを壊さなければいいのでは

歯車が噛み合っている上司とチームのセットは貴重な存在ですので、なるべくなら変えないほうがよい、と思います。逆にいうと、そういうことを見る目を持たず、壊してしまう上司や経営陣の判断に注意すべきかなと思います。「見る目」くらいは期待したいですよね。

岩田 基本的には、その会社が
「得意なことをする集団であろう」
ということを目指すとしても、
人と人がいっしょに仕事をするためには、
最低限、苦手だろうがなんだろうが、
やってもらわないと困るということを
決めないといっしょに働けないんですね。
というときに、その「最低限のこと」を
なるべく小さくすることが、
経営者として正しいんじゃないかなと
わたしは思うんです。

HOBO NIKKAN ITOI SHINBUN - 1101.com

 

文化のシャボン玉を守るにはリーダーの力がいる

マイケル・サホタ氏は、企業の中でアジャイルなどの新しい文化を普及させるには、Culture Bubble (文化のシャボン玉) を維持するべきだと主張しています。新しいことを行っている組織は、うまくいくと外部との衝突を起こしやすくなります。その際にリーダー(図上で一番上にいる人)は、とても重要とのこと。

ほかにも外部とのつなぎ役(Adapters)になる人たちがうまくふるまう必要があるとのことです。急速に膨らんだり、外からつつかれると、しゃぼん玉は弾けて、また小さなシャボン玉(組織関係なくいやりたい人たち)に戻ります。

f:id:wayaguchi:20190708012345p:plain

アジャイル系のカンファレンスで常に参照される、社内政治といえばこの本です。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

 

 こちらの本は新規プロダクト開発の本なのですが、意外と社内説得の話が多くて、おもしろかったです。アダプターにお勧めかもしれません。

SHIFT:イノベーションの作法

SHIFT:イノベーションの作法

 

今日はアジャイルリーダーシップサミット

こうした組織運営についても、みんなでどんどんとうまくなっていけたらいいですね。今日行われるアジャイルリーダーシップサミットでも、こうした議論が行えるといいなと思っています。

Home | Agile Leadership Summit 2019

f:id:wayaguchi:20190708061805p:plain

 

f:id:wayaguchi:20190708061904p:plain

 

OSTでの議論の内容

当日の議論の内容を森雄哉さんがまとめてくれました。

二年後に来る上司ガチャの悪い影響を止める方法
 - チームにとって上司にしてほしいことを書く(ディスクリプション
 - 自分のチームの状態を話す(自分達ができることと、上司にやってもらいたいことを話す
 - チーム側がマネジメントを受けているだけになっていないかをふりかえる
 - 実はチームがクレクレ君になってない?
 - 上司の上司と関わりを持って対応出来るようにしておく
 - チームを鍛えまくる
 - チームFA

scrapbox.io

 

ソシャゲに詳しい人の説明もあります。ありがとうございます!

上司ガチャ問題の対策をソーシャルゲームのガチャから考える - ミッションたぶんPossible

 

 

The Phoenix Project をアジャイルコーチがやると....

以前見学させていただいた The Phoenix Project のワークショップ。継続的デリバリーの先のバリューストリームを体験するカードゲームとして面白いなと思っていたら「こんどアジャイルコーチスペシャル体験会やるんで、誘いますね」とITプレナーズの岡本さんよりお誘いいただきまして。

kawaguti.hateblo.jp

ということで昨日体験してきました。講師はクリエーションラインの笹健太さんと荒井裕貴さん。DevOpsDaysTokyo実行委員でもあります。

先に中村知成(@ikikko)さんのレポートがありますのでこちらもどうぞ。

ikikko.hatenablog.com

雰囲気のレポート

詳しい内容はネタバレになるので書きにくいので、雰囲気だけお伝えします。

f:id:wayaguchi:20190706093115j:image

ロゴにかぶってしまう講師。

f:id:wayaguchi:20190706093144j:image

必死の採点。

f:id:wayaguchi:20190706093203j:image

午前中はこんな感じ。ルールを理解する人と自由な人。

f:id:wayaguchi:20190706093214j:image

午後はフローが見える化される。環境を変える人たち。 イノベーションの発生と普及。考えながら手を動かしながら歩きながら会話する人たち。問題を中心として有機的な組織が形成され、全員が考え、全員が動く。

f:id:wayaguchi:20190706093227j:image

昼休みにご飯食べながら問題を解析して組まれるワークプレイス。緊急イベントへの対応すら考慮されている。残り3分でも焦らずチャレンジする人たち。「それってどういうこと?」「ここなにやってんのー?」「はーい質問があります。」「ちょっとみんな聞いてー」f:id:wayaguchi:20190706093241j:image

結果発表。惜しくも目標を達成できませんでしたが、売上は単調増加して株価も回復。V字回復とはまさにこのこと。このまま次期ももっと良くなることが間違いないです。CFO役としては文句ございません。 

f:id:wayaguchi:20190706094021j:plain

遊びに来たわけではありません。真面目に仕事しております。休憩中や懇親会でも、闊達に意見が出る場を作るための心理的安全性について、人数が多くても議論が建設的効率的にできる条件や振る舞い、一時的に余った人はどう動くか、情報共有と手分けのバランス、セットベース開発とWIP制限、などの話題で盛り上がりました。

f:id:wayaguchi:20190706094013j:image

楽しかったでーす。(語彙力

f:id:wayaguchi:20190706094052j:image

ピンぼけ! 

f:id:wayaguchi:20190706100040j:plain

 

なぜアジャイルの方が成功しやすいのか?

スクラムギャザリングというカンファレンスの実行委員会がありました。実行委員会といっても、会議をやってるというより、淡々と決めて作業を進める会です。このカンファレンスは2011年からやっていて、来年でちょうど10年になります。紆余曲折ありながらも、ここ数年は実行委員業も枯れてきて、ああうまくいくアジャイルチームってこういう特性あるのかもな、と気づくところもありまして。今日はそのあたりを記してみます。

今日は趣意書の公開まで

今日は 4-5時間ほどで、趣意書(スポンサー向け資料含む)と、スポンサー受付のサイト作成までが終わりました。ちなみにWebサイトまでは終わらなかったので基盤まで整えたところで、次回の作業になりました。

趣意書はこちらです。

f:id:wayaguchi:20190630072527j:image

f:id:wayaguchi:20190630072338j:image

うまくいってることは変えないでおく

やりながら考えたことは、

  • うまくいっていることは変えないでおく
  • というか問題なければ変えない
  • なので問題だけ議論して決めて
  • なる早でなるべく細かい単位でデプロイする

ということです。

趣意書は去年のものをベースに、昨年実績の追加記載と会場が変わるのでそれに伴う変更を入れてます。逆にいうとそれ以外は変えてません。

チームの中で作業を進めているので、面倒くさいところや、議論は盛り上がるけど前に進まなさそうな点は「あとで必要になったら話そう」と一旦話を切って進めました。今日中にある程度アウトプットしたいからです。

議論と作業のバランス

分業をしていないので、議論も作業も同じ人たちがやります。決定や作業計画だけ詰めたところで、作業ができなければアウトプットが出ません。一方で議論や決定が必要な部分ももちろんあるので、適宜、必要なタイミングで議論をやっていきます。

これが、多重請負のウォーターフォールだったとしたらどうなるでしょう。「私たちの責務は意思決定。今日は議論と意思決定に集中して、実作業は全体工程が決まった後でやりましょう。作業はそれぞれの担当や、その道のプロにお願いしましょう」ということになりがちかなと思います。たぶんそれ自体は「そういうもの」なのだと思いますので、悪い話ではないと思うのですが、問題は「いつ結果がわかるか?」です。もし今日、方針やスケジュールだけ決めたのだとすると、間違いがわかるのは実装後になります。来月か、もっと先か。

一方、趣意書の実装と即日公開で得られたものは以下です。

  • 会場見取り図でスポンサー受け入れ可能数を見積もる
  • 収益見込みを確認し、キャッシュフローとリスクのある変数について見当をつける
  • 公開後、すぐにスポンサーの応募を数件いただく。それによって趣意書が機能しているという認識を持つ
  • スポンサー申し込みフォームも機能していることがわかる。いくつか細かな改善を行いつつ今後のオペレーションの見当がつく

このようにいくつかのアウトプットと、その結果のアウトカム(成果)がありました。最大のアウトカムはスポンサーのお申し込みをすぐもらえたことです。嬉しい誤算。本当にありがたいご支援でした。

イムリーなアウトプットがアジャイル成功のヒント

ほとんどが去年と同じことをしているにもかかわらず、「マンネリ」「つまらない」と感じることがない点も特筆すべきかもしれません。それどころか一年ぶりの作業なので、むしろ多くの発見や学びがありました。使っているサービスの機能が進化していたり、逆にうまく動かなくなってて直したり。ConfEngineというサービスの開発者に「前回のイベントからのコピーで新しいイベントを作る」という要望を出していたのですが、なんとそれが実装されていて、喝采が上がりました。

これももし多重請負のウォーターフォールだったら、企画会議で「昨年と同じではつまらないのではないか?」という話になって、アイデアが足された挙句に、実施部隊に情報が渡るのが遅れ、実施部隊は膨らんだ企画と変わった状況の狭間で右往左往しながらギリギリでリリースにこぎつけた後に問題が発覚して予定外かつ緊急の作業に追われる未来が見えます(知らないけど)。

アジャイルでは、というか別にアジャイルと呼ばなくても良いのですが、私たちが重視していたのは、ローコストで、タイムリーに、アウトプットしながら、結果を得て、それを通じて学びを得て、時間内で手仕舞いする。...ということです。私たちはアジャイルの実践を通じて、この「あたり前」のことを学んできたに過ぎないのかもしれません。

イノベーションは安定したチームから

あらゆる企業活動にこれが通じるなんて思いませんが、多くの作業はこうして日々回っていくような気もします。その結果、本人たちすら気づかないうちに「簡単には真似できないチームのノウハウ」が溜まってるような気もしなくもないです。小さなイノベーションの積み重ねは安定したチームから。...そんな気もしました。

きっとそんなことはみんなわかってるけど、意外とそこまで我慢できずに新しいアイデア投入をやってしまったり、人を入れ替えてみたり、売り上げが立たずに予算が尽きたり、ステークホルダーや偉い人お客さんに振り回されたりするものなのかもなー、とも思います。頑張っていきましょう。

アジャイルを始める時の成功のヒントは、今いる人で今できるアウトプットを最速で目指してみる。...そんなところにあるんじゃないかと思ったのでした。

 

...というわけで、今日も作業が進んで満足でした。早速のスポンサーのお申し込みもありがとうございます。「ほんとこのカンファレンスは愛されてるね(私たちではなく)」ということで、またちょっとやる気も補充できました。フィードバック大事ですね。次回作業日を決めて今日は終了しました。

 

P.S. 4-5時間作業して3時間飲んでたみたい。ワークライフバランス。まあ仕事じゃないですけど。

f:id:wayaguchi:20190630072850j:image

 

実行委員のてやまぐさんの資料もいいですね。こんな話をいつもしてる。XP祭りの実行委員も2010年くらいからやってました。

Conference Organize Tips at 2019/06/22 #devlove #devlovex

Electron + Angular でマルチウインドウタイマー

前回の続きの作業記録です。

kawaguti.hateblo.jp

 

Electronでのマルチウインドウ化

マルチウィンドウを積み残しにしたのでその点を進めました。

Electron ではウインドウを起動するために、new BrowserWindow する、という記述があり、これを使うことを考えました。

BrowserWindow | Electron
... が、このウインドウはネイティブのウインドウでした。今回欲しいのは JavaScript 上で起動し、JavaScript で通信できる別ウインドウなので、ちょっと用途が違いました。

今回、ここの理屈を理解するまでに多くの試行をしました。最終的に、イベントでモブをしまして、よた(@y0t4) さんの手助けもあって、筋違いに気がついた次第です。モブすごい。

ayumi-hsz.hatenablog.com

 

ほんとうに必要だったものは window.open

結局のところ、必要なコードは window.open でした。あ、それもう20年ぐらい使ってるわ。どうってことのないこの一行のために費やした時間は数日(のちょっとした時間)。学びが多いです。

window open · kawaguti/tiimer@8618f42 · GitHub

ということで、二枚目をウインドウを起動できるようになりました。普通にJavaScriptなので、複数ウインドウ間のメッセージングについても、前回と同じく npx-multi-windowが使えそうです。

Angular 7 でカウントダウンタイマー - kawaguti’s diary

ということで、組み込みました。

普通にメッセージのやり取りができるようになったので、引き続き、メッセージにコマンドを仕込んで、時計のセットをできるようにして、アプリ完成です。

f:id:wayaguchi:20190623062358p:plain

 

Mac用にパッケージ

Mac OSX 用にパッケージしたものをこちらにおいておきます。セキュリティ上、App Store以外のものは動かないと思いますので、実行する場合は、詳細設定-セキュリティ から許可をしてあげる必要があります。

https://www.tiimer.net/tiimer-darwin-x64/tiimer.app.zip

Windows用も動作したのですが、うまく配布用のZipが作れていないので、また調べまーす。

 

はこだて未来大学さんと DevLOVEXさんでお話しました

先週、はこだて未来大学の大場みち子先生に呼んでいただきまして、学生さん向けにアジャイル開発のお話をしてきました。どうしてそういうものが生まれたのか、というところを私なりに整理してみたものです。「アジャイル開発の時代」という大仰なタイトルになっており、恐縮です。釣りバカ日誌の話をしたかっただけです。

speakerdeck.com

 

また、昨日は DevLOVE Xさんに呼んでいただきまして、モブプロのお話をしました。こちらは5月の連休で行ってきた Hunter Industries さんのモブプロの報告になってます。

speakerdeck.com

学んだことの詳しい内容は、以下の記事ですでに書いていますので、よかったらどうぞ。

kawaguti.hateblo.jp

kawaguti.hateblo.jp

並行セッションの裏番組の登壇者の皆さんが豪華すぎて、全部聞きに行きたい感じでした。そんな中で選んで聞いていただいた方に大感謝です。同窓会のようなカンファレンスに呼んでいただき、ありがとうございました。楽しかったです。今日は二日目、盛会をお祈りしております。

 

f:id:wayaguchi:20190623064646p:plain

 

Electron でカウントダウンタイマーをアプリにする

前回のカウントダウンタイマーに関して、早速ネットで繋がってないときにも使いたいという要望をいただいたので、Electronを試してみようと思いました。....の、作業ログです。

kawaguti.hateblo.jp

Chroniumブラウザを使って Webを単体アプリにパッケージするElectron

Electronというのは、ChromeやSaferiなどのブラウザのコアになっているChroniumを使って、Webフロントエンドの技術でスタンドアローンのアプリを作れるというものです。必要なソースを全部固めてexeとか実行ファイルにするツール群とデバッグ環境、という感じかなと思います。

人気のあるクロスプラットフォームエディタのAtomとかVSCodeがElectronで作られているそうなので、信頼性もありそう。

Electron Apps | Electron

2000年代前半くらいにあったWindowshtaという仕組みがあるのですが、それに近い感じもします。AngularやReactなどのWebフロントエンドのツールがそのまま使えるというのが面白いところかなと思います。普通にツール作るならなんとなく Swift とかのほうが簡単なんじゃないかと思うのですが、クロスプラットフォームで動くものを作れる(ChroniumとかJavaScriptのおかげ)ので、そういうときには便利なのではないかという感じがします。その分複雑度は上がってしまうので、ハマった時に抜け出すにはそれなりに熟練が必要そうな気がします。まあなんでもそうですね。

とりあえずマルチウインドウは避け、カウントダウンタイマーが動くところまで

今回はまず Electron で Angular のカウントダウンタイマーが動くところまでやりました。マルチウインドウでの同期は少しハードルが高いかもしれないので、まずはありがたいサンプルの組み合わせで、できそうなところまで。

前回のソースは agx-multi-window を組み込んでしまったので、その前まで戻します。別のフォルダを切って一からやることにしました。

ElectronでAngular初期画面まで

結構ここで時間を消費して調べることになってしまったのですが、AngularもElectronも変化が速くて、しかも別の組み合わせもあるので(React+Electronとか)、ハマった時に情報を調べるのがなかなかしんどかったです。Angular7 + Electronというキーワードで見つけたこちらがドンピシャでした。

qiita.com

ということで淡々と作っていきました。

npm i -g @angular/cli

ng new single-window

cd single-window

npm install --save-dev electron@latest

npm install --save-dev electron-packager@latest

npm install --save-dev ngx-build-plus@latest

https://github.com/kawaguti/tiimer/commit/fa170f51078e35a0ea80f51516cffc5e060ec902

プロジェクトを作ったら、上記のサイト通りに修正を入れました。

https://github.com/kawaguti/tiimer/commit/122398d0a3b38053134dd5c785fd682ec83ce5ba

実はこの時、ちょっとした失敗をしました。package.json の main 項の追記を忘れて、ビルドエラーはないのに起動しないという状況になりまして。手がかりが見つからずに数時間迷子になりました。簡単なサンプルが動かないと、疑うところが無限にあってしんどいですね。ミスなのでだいたい情報もなくて。

"main": "main.js",

f:id:wayaguchi:20190616194921p:plain

別の環境でもう一回作ったらけろりと出なくなって、気がついた次第。対照実験だいじです。

ちょっとハマった先で Angular の初期画面がElectron上で表示できたときには感動しました(自作自演)。同じプロジェクトで Web版も動きます。

f:id:wayaguchi:20190616195601p:plain

リアルタイム時刻表示は動くか?

次は時刻表示です。rxjs の Observable (pub/subイベント機構) が動くことの確認です。上記のサンプルがちゃんと動いたので、なんとなくシングルウィンドウものは動きそうな感じがしますが、一歩一歩確認します。

ありがたいこちらのブログを見ながら、コードに時刻表示を入れていきました。

【Angular】小ネタ:現在時刻の表示 - Qiita

コミットログはこちら

Add clock · kawaguti/tiimer@d69efb2 · GitHub

f:id:wayaguchi:20190616201328p:plain

Electronでも時刻が表示されました。同じプロジェクトで Angular CLI も動くので、ブラウザでも動きます。WindowsでもMacでも配布用のビルド(packager)できました。

f:id:wayaguchi:20190616223156j:plain

カウントダウンタイマーにする

時刻表示までいければ、あとはカウントダウンタイマーをちょっと作り込むだけです。

Add countdown timer · kawaguti/tiimer@e5c8253 · GitHub

remove example · kawaguti/tiimer@20167d7 · GitHub

Add timer set button · kawaguti/tiimer@40da1ff · GitHub

Angularのロゴを消すなどして、カウントダウンタイマーになりました。

f:id:wayaguchi:20190616202140p:plain

 

Beep音の実装

あ、beepもありました。こちらもありがたく拝借

JavaScript で Beep 音を鳴らす方法 - Qiita

音もちゃんと出るようです。

Add beep · kawaguti/tiimer@9f42b66 · GitHub

Beep音がオフィスで鳴り響いてドキッとしたので、BeepOffボタンも追加しました。押さなくても10回で勝手に止まるようにしてます。

Add BeepOff button · kawaguti/tiimer@86598e3 · GitHub

f:id:wayaguchi:20190616202626p:plain

以上で、 Electron でカウントダウンタイマーが動きました。

 



まだデバッグ版なので、本番用のpackage作成は次回。あとマルチウインドウもやりたいですね。