スクラムマスダーの日記

アジャイル、スクラムに関連した内容が多めです。

テレワークで使いたいホワイトボードアプリ5選!

テレワーク(リモートワーク、在宅勤務)をしているときに、「ホワイトボードがあればなぁ。」と思うことは、ありませんか?

「ホワイトボードがあれば、簡単にアイデアを共有したり、議論を見える化できるのに。」と感じた方も多いと思います。

f:id:scrummasudar:20200428094833j:plain

ただ、自宅に、大きなホワイトボードを置くことは難しいと思います。

そこで、今回は、ホワイトボードの代わりになる、ホワイトボードアプリを5つ紹介します!

また、ブログを読んでいただいたみなさんに、ホワイトボードアプリをすぐに試していただけるよう、自由に使えるお試し用スペースをアプリごとに開放しています。
ぜひ、気になったものを使ってみてください!

Jamboard

f:id:scrummasudar:20200428102122p:plain

Jamboardは、Googleが提供しているホワイトボードアプリです。
GmailGoogleドライブと同様に提供されています。

Googleアカウントさえあれば、作ることができるので、一番簡単に利用できるホワイトボードアプリです。

主な機能は、以下の通りです。

  • ペン
  • 消しゴム
  • ポインター用の矢印
  • 付箋
  • 画像貼り付け
  • 一時的に書けるマーカー

ホワイトボードの範囲自体は、それほど大きくありません。
しかし、いくつもホワイトボードを増やすことができるので、話題を切り替えたときに、すぐに新しいホワイトボードを用意できるというメリットがあります。

URLを知っていれば、アカウントなしで利用することができます。

お試し用ホワイトボード

jamboard.google.com

Miro

f:id:scrummasudar:20200428112901p:plain

miro.com

2020/04/24に、シリーズBで54億円調達したことでも話題になったMiroが提供しているアプリです。

主な機能は、以下の通りです。

  • ペン
  • ポインター用の矢印
  • 付箋
  • 画像貼り付け
  • テキストボックス
  • 図形の貼り付け
  • 吹き出しコメントの貼り付け

一つの大きなホワイトボードに書くといった使い方ができます。
テキストボックスがあるため、付箋をグルーピングして、欄外に文字を書く、といった使い方が可能です。

また、マインドマップ、ユーザーストーリーマップ、カスタマージャーニーマップといったテンプレートが用意されており、企画やマーケティング時に、利用しやすくなっています。

ちなみに、無料版で利用できるホワイトボードは3枚までです。

URLを知っていても、アカウントの作成は必須です。

お試し用ホワイトボード

miro.com

Mural

f:id:scrummasudar:20200428174858p:plain

www.mural.co

Miroと同じくスタートアップ企業で、今年、シリーズAで23ミリオンドルを調達しています。

主な機能は、以下の通りです。

  • ペン
  • 付箋
  • 画像貼り付け
  • ファイルの貼り付け
  • テキストボックス
  • 図形の貼り付け
  • アイコンの貼り付け
  • 吹き出しコメントの貼り付け

アカウント登録をすると、チュートリアルが始まり、使い方を教えてくれます。

ビジネスモデルキャンバス、リーンキャンバス、ペルソナ、カンバンといった、様々なフレームワークが提供されており、簡単にフレームワークを利用することが出来るようになっています。

アイコンとフレームワークを組み合わせることで、視認性の高いドキュメントが簡単に作成することができます。

無料プランはありません。
無料トライアルで90日間、スタータープランを使うことが出来ます。

URLを知っていれば、アカウントなしで利用することができます。

お試し用ホワイトボード

app.mural.co

Metro Retro

f:id:scrummasudar:20200428211933p:plain metroretro.io

Metro Retroは、名前の通りレトロスペクティブ、すなわち、ふりかえりに重きをおいたホワイトボードアプリです。

主な機能は、以下の通りです。

  • 付箋
  • 付箋のグルーピング
  • 画像貼り付け
  • テキストボックス
  • 矢印の貼り付け
  • 吹き出しコメントの貼り付け
  • 付箋への投票
  • 付箋へのリアクション

ふりかえり手法13種類のテンプレートが用意されており、ふりかえりに活躍してくれること間違いなしです。

付箋のグルーピングや投票、タイマー機能など、他のホワイトボードアプリにはない、かゆいところに手が届く機能がついています。

無料で、すべての機能が使え、出来る限り無料で提供し続けると公式で回答されています。*1

URLを知っていても、アカウントの作成は必須です。

お試し用ホワイトボード

metroretro.io

Conceptboard

f:id:scrummasudar:20200428215016p:plain

conceptboard.com

Conceptboardは、コミュニケーションすることを重視したホワイトボードアプリです。

主な機能は、以下の通りです。

  • ペン
  • 付箋
  • テキストボックス
  • 図形の貼り付け
  • 吹き出しコメントの貼り付け

チャットやビデオ通話機能(ビデオ通話は有料機能)も用意されているため、ホワイトボードを複数人で更新しやすいようになっています。

大きなホワイトボードの上に、複数の小さなホワイトボードを乗せるイメージで運用できるため、書きたい内容ごとに範囲を分割しやすいです。

無料版でも100枚のホワイトボードが利用できるため、普通に使う分には十分運用に耐えることができます。

URLを知っていれば、アカウントなしで利用することができます。

お試し用ホワイトボード

app.conceptboard.com

おわりに

ホワイトボードアプリといっても、アイデアを発散させる、アイデアをまとめる、ふりかえり、タスク管理など、目的や用途によって、最適なものを選択するのが良さそうです。

ぜひ、お試し用ホワイトボードを利用してみて、使いやすいと思ったものは、実際に登録してみてください!

『みんなでアジャイル』を読みました! #みんアジャ

発売されてから1ヶ月ほど経過しますが、『みんなでアジャイル』を読みました。

書籍は、原田さん(@haradakiro) からスクラム道関西宛に献本いただき、僕が一番最初に読ませていただきました。
まことに、ありがとうございます!

献本いただいたので書籍に加えて、いろいろな方に知っていただきたい内容も数多くあるので、ブログで書籍の紹介および、僕の感想を記します。

もくじ

本書のもくじは、以下のとおりです。

3章から5章が、本書のオリジナル要素です。
各章のタイトルが、本書で重要だとされているアジャイル原則であり、組織運営において陥りがちな3つの重力(いわゆる課題)に対して取り組む必要があることが記載されています。
また、それぞれのアジャイル原則において、組織が良い方向に進んでいるのか?、悪い方向に進んでいるのか?、を判断できる組織の兆候が記されているため、自身が所属している組織の状態を、明確に知ることができることも本書の良さだと思います。

ムーブメントとしてのアジャイル

この書籍では、アジャイルには、「手法としてのアジャイル」と「マインドセットアジャイル」の2つがあると言っています。

「手法としてのアジャイル」とは、数多くあるアジャイルな手法のうち、チーム内で定められたプラクティスや方法を活用すること。
マインドセットとしてのアジャイル」とは、チーム内で各自が、アジャイルな考え方や価値・原則を受け入れ、育てていくこと。

しかし、真にアジャイルな状態は、上記2つのどちらかを採用している状態ではなく、2つがコラボレーションしている状態であるとしています。

その状態が、ムーブメントとしてのアジャイルです。

様々なアジャイルといわれる手法(例えば、スクラム、XP、クリスタル)は、アジャイルという言葉が生み出される前に、同時期(1990年代)に次々に生み出され、まさにムーブメントと言えます。

また、ムーブメントと捉えることで、個人で取り組むものではなく、チームや組織が協力して取り組むべきものであり、思考(マインドセット)と行動(手法)のどちらかではく、それらを両輪として捉える必要がでてきます。

感じたこと

ムーブメントとしてのアジャイルは、僕が、アジャイルに対してモヤモヤしていたことを解決する一つの考え方でした。

ここ数年のアジャイルに対するイメージは、マインドセットとしてのアジャイルが中心になり、手法としてのアジャイルは後回しになりがちです。
数年前から、心理的安全性という言葉に、大きな注目が集まり、良いチームを作ろうということばかりが叫ばれるようになっていると感じています。

もちろん、心理的安全性は非常に重要で、マインドセットとしてのアジャイルは必要です。
しかし、技術に関するアジャイル手法(特にXPに代表されるテスト駆動開発リファクタリング継続的インテグレーションなど)については、語られることが少ないと感じています。

逆に、手法としてのアジャイルを採用していれば、アジャイルな状態であるとしている現場も、ちらほら見かけます。
スクラム道関西のイベントに参加してくださっている参加者の方々から、「会社がスクラムを採用する方針を出したので、スクラムをはじめました」は、この2〜3年の間によく聞くようになりました。
また、「リファクタリング継続的インテグレーションなどアジャイルな技術的な手法を採用してるから、私達はアジャイル開発に取り組んでいる」ということも目にしました。

真のアジャイルな状態は、手法としてのアジャイルマインドセットとしてのアジャイルがコラボレーションしている状態であることを言語化して認識できたことが、収穫でした。

顧客から始めるのがアジャイル

組織重力の第1法則は「組織に属する個人は、日々の責任やインセンティブと整合性がなければ、顧客と向き合う仕事を避ける」です。
予算やスケジュールによって評価される個人にとって、顧客に向き合うことは、気を散らすだけ。最悪の場合、既存の計画が複雑になる、見直しが入るなどにより、進行が遅れ、個人は危機に陥るというものです。

また、多くの場合、組織内で顧客と直接やり取りするのは、UXやサポートの担当者であり、ビジネスに対して重要な意思決定をする人は顧客と遠く離れた場所にいて、顧客のニーズやゴールに対する知識を持っていないことが多いとされています。

この重力から脱却するアジャイル原則が「顧客から始めるのがアジャイル」です。
作成するアウトプットではなく、顧客に届ける価値(アウトカム)にフォーカスし、「どうすれば顧客のいちばん重要な問題を可能な限りすばやく解決できるか」を考えます。

この原則を達成するために、アジャイルソフトウェア開発宣言の「包括的なドキュメントよりも動くソフトウェアを」に着目し、ソフトウェアプロダクト、マーケティングキャンペーン、プレゼンテーションなどにおける

  • 検討すべき顧客体験
  • 動くソフトウェア
  • 包括的なドキュメント

とは何かを示しています。

そして、限られた時間の中で何を届けるかを考えるためにも、タイムボックス化したイテレーションの重要性を示しています。

感じたこと

顧客中心主義は、ありとあらゆる企業で口酸っぱく言われていると思います。それでも、実現することは非常に難しく、多くの企業で失敗しています*1

また、エンジニアが顧客とペアプログラミングすることの有用性は、『XPエクストリーム・プログラミング Web開発編』の第5章プロジェクトチームにおいても述べられています。
しかし、書籍の出版から20年近く経過しても、実践している企業はまだまだ少ないと感じています。

私自身が、顧客に価値を届けることへの重要性を痛感したのは、ある新規事業に取り組み、失敗した後でした。
誰がこのプロダクトを購入してくれるのか、利用するのかを正面から考えないまま、開発していました。

加えて、Drift社の事例である「すべての従業員が、顧客からのチャットに直接答える」のように、顧客と直接接点を持つことは非常に重要だと、私が心のそこから思えるのは、私がテクニカルサポートエンジニアとして、働いていたことも大きいです。
個別具体的な顧客の課題を解決する仕事に取り組むことによって、積極的に利用してくれる顧客の課題から一定のパターンに気づき、プロダクトへフィードバックできるからです。

組織が悪い方向に進んでいる兆候として「組織内に顧客からの良いフィードバックしか流れない」は、個人の観測の範囲内ではありますが、あんまり存在しないのかなと思いました。
むしろ、「営業から○○機能がないから売れない」、「顧客サポートから△△機能の使い勝手が悪いと顧客からクレームが入った」など、悪いフィードバックしか流れないが、多いと感じています。
当然なのですが、アメリカ企業と日本企業の差を掴んで、判断するべきだと思います。

早期から頻繁にコラボレーションするのがアジャイル

組織重力の第2法則は「組織における個人は、自分のチームやサイロの心地よさのなかでいちばん簡単に完了できる作業を優先する」です。 現代的な組織において、リスクを最小限に抑えることが成功戦略です。それ故に、上司から求められた成果物の締切を優先するとなると、ほかのチームからのインプットがあれば成果物がより良いものになることがわかっていても、成果物完成に対するリスクが高くなるため自分のチーム内に閉じてしまいます。
また、コラボレーションした場合、ほかのチームに仕事を台無しにされたり、成功した場合にも手柄を横取りされてしまうといったリスクがあり、コラボレーションしづらいとうこともあります。

この重力から脱却するアジャイル原則が「早期から頻繁にコラボレーションするのがアジャイル」です。
報告と批評の文化から、Spotifyモデルに代表されるような協調的な文化へ移行することが重要となっています。
完成する前の成果物が、組織やチームで区切られた範囲に関わらず共有され、機能横断的なチームが同じ場所(物理的に同じとは限らない)で作業しているような感触を得ることが出来る状態にします。

定められた公式な会議だけでなく、非公式に話をしたり、一緒にランチをとることで、様々な職能のメンバーが、お互いに関心をもてるようにします。

感じたこと

「風通しの良い組織づくり」
この言葉も、様々な企業において、何度も企業方針や理念として耳にします。

しかし、エンジニアは「私達は、良いものを作っているのに、営業が売ってこないから悪い。」、営業は「私達は顧客と会い、製品の要望を上げているのに、エンジニアがまともなものを作らないから悪い。」といった話を聞きます。

組織がコラボレーションすることの重要性はわかっていても、仕事がフェーズによって区切られていることで、各職能の人だけが担当することになりがちです。

スクラムでは、スクラムガイドに記載の通り「スクラムチームは自己組織化されており、機能横断的である。」と機能横断チームを目指しています。
開発者とテスター、サーバーサイドエンジニアとフロントエンドエンジニア、機能開発チームと保守運用チームといった、エンジニア内でのコラボレーションの事例は、よく耳にします。
しかし、開発と営業、開発と顧客サポート、開発とマーケティング、開発と法務といったコラボレーションを見かけることは、まだまだ少ないです。 プロダクトをリリースする、つまり顧客に価値を届けるには、様々な組織との連携が必要であり、まだまだ真のコラボレーションを実現する組織を作るには、まだまだ道は遠そうです。

書籍では、アメリカらしく、非公式な場面での組織間コラボレーションは、ランチやコーヒーブレイクを例にしていました。
日本では、就業後の飲み会が鉄板だと思います。アメリカと日本の文化の差を感じました。
もちろん、飲み会をうまく生かした企業も多く、ホンダのワイガヤ、京セラのコンパは有名です。
中には、こういった文化に対して良いイメージを持たない方もいらっしゃると思います。ただ、2社とも日本を代表する企業であることは間違いなく、これらの文化が貢献したことは間違いないと考えています。

不確実性を計画するのがアジャイル

組織重力の第3法則は「進行中のプロジェクトは、それを承認したいちばん上の人が止めない限り、止まることはない」です。 プロジェクトやプロダクトが経営幹部から承認されれば、仮に顧客ニーズや企業の目標に合致しないことが明らかになっても、そのまま続けられるというものです。
顧客からのフィードバックがあり、失敗することが明らかな場合であっても、組織における政治の世界では、人前で恥をかくことは、上司が承認したアイデアに対して間違ったということより、リスクが低いと思えてしまうのです。

この重力から脱却するアジャイル原則が「不確実性を計画するのがアジャイル」です。
個人にこの重力に逆らうのではなく、プロセスを変更することが唯一の方法です。プロジェクトを承認する経営者は、プロジェクトには必ず変化の余地を残さなければならないことを理解し、組織が共感する言葉を使って短いサイクルを広め、不確実性に対するより良い計画を立てることが重要です。

この重力を克服するアジャイルラクティスとしては、ふりかえりが重要とされています。
アジャイル原則を重視することで、チームが、そもそもなぜ仕事のやり方を変えようとしているのかを着目し続けるのにも役立ちます。
また、将来の変更を強制ではなく実験として扱うことで、新しいプラクティスやアプローチを試すことに、ほとんどリスクがないことを意味します。

感じたこと

経営層の判断が非常に重要であり、経営層が承認した計画をなかなか変更できないことが、アメリカ企業であっても、よくある課題に挙がるのは個人的には意外でした。
日本のライン重視の組織体系ならではという感じもしていたのですが、世界のどこでも発生してるようです。

日本企業で典型的な問題は、悪い方向に進んでいる兆候に記載されている「決定を下す際に100%の確実性を要求している」だと思います。

「顧客のニーズを100%叶えなければならない」、「この機能を、この期日までに完成させることは絶対です」、「バグの発生は0%の状態でなければ出荷しません」など、具体例は、幾つもあがります。

顧客のニーズは日々変化していますし、技術的な要素も目まぐるしく変化しています。
AWSGCP、Azureなどのクラウドサービスをインフラとして利用する限り、データがロストする可能性が0%、サーバー稼働率100%の状態などは、理想の理想で、一般的な企業が達成できるものではありません。(むしろ、自社管理のオンプレ環境の方が、リスクが高いでしょう。)

そもそもビジネスの話になるのですが、儲かることが明確なのであれば、困らないです。
「このタイミングでリリースすれば、〇〇円儲かること」がわかるのは、神のみぞ知る世界だと、私は考えています。
儲かるかどうかわからない不確実な世界で活動しなければならないからこそ、不確実性を計画することが重要だと、思っています。

おわりに

本書を一番読んでほしい方は、各企業の社長やCEOといった企業のトップの方だと感じました。
個人的に一番抵抗できない組織重力は、「進行中のプロジェクトは、それを承認したいちばん上の人が止めない限り、止まることはない」だと考えたからです。
いくら、各チーム内で、他のチームとコラボレーションし、顧客に向き合ったとしても、会社の方針を覆すには、トップの判断が必要だからです。

と言いつつ、組織全体をアジャイルな状態で運営にするには、各人がアジャイルマインドセットを持って、アジャイルな手法で取り組む必要があるため、どんな役割の方でも読んだ方が良いとも思いました。

タイトルの「みんなアジャイル」という言葉こそが、組織内での共通言語となり、組織内におけるアジャイルなムーブメントを起こすためには、必要なんだと思います。

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

  • 作者:Matt LeMay
  • 発売日: 2020/03/19
  • メディア: 単行本(ソフトカバー)

勝又さんは関数型言語を経験するべきと言っているので、結局Scalaをおすすめするしかないと思う

エンジニアで、YouTubeで配信もされている勝又健太さんが、「Scalaが日本で衰退し始めている理由を説明します」という動画をアップされました。

僕は、過去、Scalaを少しだけ触ったことがあります。
そのため、以前から、勉強のために、日本でトップレベルのスキルをもつScalaエンジニアの方のTwitterをフォローさせていただいていました。

勝又さんが動画をアップされた日や翌日は、そのScalaエンジニアの方が、いつもとは異なるツイートをされていました。

僕は、少し違う感じ方をしたので、今回ブログに記します。

勝又さんの動画の要約

詳しくは、Youtubeにアップされている動画を確認いただければと思いますが、ざっくり要約すると以下の通りです。

  1. 学習コストの高さによる技術的負債の進行
    • 学習コストの高い、関数型言語が日本で普及していないから
    • 一度右肩下がりになった言語は、過去の例を鑑みると、右肩下がりのまま。数年以内にはWebサービス開発の言語としてはマイナーポジションになる。
  2. Scalaコミュニティがにわかファンの方達の心理的安全性の確保ができなかったこと
    • 一部のエンジニアが、入門者にマウンティングする、他の言語を悪く言うなどの問題行動をとっている
    • 初学者に「マサカリ」を投げる人がいるため、「Scalaコミュニティが怖い」というイメージがエンジニア内で定着している。その結果、新しい人が寄り付かなくなる。

Scala人気ってなんだろ?

勝又さんは、彼自身の観測範囲内で、Scalaの人気が衰退しているということをおっしゃっています。
動画冒頭でも、定量的に観測したわけではいともおっしゃいいますので、個人的に、「関わっている周囲との関係から、衰退していると感じることは、あるだろう」とは思います。

Twitterで、「Scalaに関する技術顧問業に相談件数は増えているので、人気は継続している」というツイートも見かけました。
もちろん、それ自身も事実だと、僕は思います。

これは、観察者バイアスがあるから、仕方がないことだと思っています。
観察している人が異なれば、違う結果がでるでしょう。
全ての個体を検査しているわけではないですし、何か両者の共通の基準を持って計測してるわけでもないためです。

「あんまりScala人気ないよねー。」と言ってる人の周りには、Scalaに関する仕事の話は少ないでしょう。
Scalaを盛り上げて行くぞ!」と言ってる人の周りには、Scalaに関する仕事の話が集まりやすいでしょう。

なので、Scalaの人気があるかどうか、衰退しているかどうかは、結局分からないのと、個人的に考えています。

Scalaの利用状況を定量的に観測してみる

プログラミング言語の利用ランキングを見ていると、関数型言語が上位に入ることが、そもそも難しいことは、現実としてあります。

japan.zdnet.com

octoverse.github.com

今回の動画の県で、「TwitterマイクロソフトFacebookScalaユーザー」というツイートも見かけました。
もちろんそれも真実だと思います。けれども、やっぱり絶対的な利用者数は、他の言語と比べると少ないのも事実です。

日本に限った場合、日経クロステックさんの記事によるとScalaは、22位になってます。

xtech.nikkei.com

世界ランキングが11位以降わからないので、絶対とは言えませんが、世界も日本も同じような状況だと、思っています。

勝又さんおすすめのキャリア形成におけるScalaの立ち位置

勝又さんは、エンジニアのキャリア形成においては、「Ruby→Go→Scala」の順で経験した方がよい、と言っています。

Scalaは、3つの言語の中で、唯一の関数型言語です。
動画においても、勝又さんは、「関数型言語の知見はプログラミング力を高める上で非常に有効」と言っています。

僕自身、関数型言語を通して、副作用やパターンマッチなど、多くのことを学んだので、一度は経験した方がよいと思っています。

結局、Scala以外選択肢ある?

プログラミング言語の利用状況を鑑みて、関数型言語を経験するために仕事を探すとなると、やっぱり関数型言語で選択するのはScalaになると思います。

関数型言語は、F#、Haskellなど、他にもあるけれど、上記のランキングには乗っていません。

勝又さんの動画を見て、Scalaを避けて通ろうとするエンジニアがいるのであれば、結局、勝又さんのおすすめするキャリア形成は、非常に難しくなると感じています。

Scala学びたいと思ったら

このブログを読んで、もしScalaに少しでも興味が出て、学びたいと思った方がいらっしゃれば、はてなさんの学生インターン向け教材や、ドワンゴさんのScala初学者向け学習テキストを読んでいただければと思います。

github.com

scala-text.github.io

もっと興味が出てきたという方には、『Scalaスケーラブルプログラミング』、『実践Scala入門』あたりがおすすめです。

Scalaスケーラブルプログラミング第3版

Scalaスケーラブルプログラミング第3版

実践Scala入門

実践Scala入門

おわりに

このブログでは、勝又さんおっしゃる衰退している理由の1つ目について、少しだけ考えてみました。

勝又さんのおっしゃる心理的安全性については、僕自身思うところもあるけれど、やっぱり解釈が難しい言葉には違いないので、あえて触れませんでした。

関数型言語の中で、日本語の資料が一番まとまっているのは、Scalaだと思うので、なんだかんだで、Scalaおすすめです。