AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

#iOSDC Japan 2019にて2位になった話

Pocket

まいど。POSチームの地福です。

2019年9月5日(木)~9月7日(土) @ 早稲田大学キャンパスにて開催された、iOSDC2019に参加してきました。

※ エンジニアブログと名乗っていますが、技術的なものは出てきません。

iOSDCとは

iOSDC is iOS DEVELOPERS CONFERENCE
その名の通り、iOSデベロッパーのカンファレンスです。
単純明快ですね!

今年で4回目の開催でした。
毎年新しいことに挑戦して、イベント関係者全てを楽しくしてくれる工夫が
各所にあります!(そして今年はダークモードにも対応していました🌚)

その中の全日イベントiOSDCチャレンジで2位になったことについてお話しします。

iOSDCチャレンジとは

iOSDCチャレンジ

“#” + “任意の文字列”

イメージ図

から形成されるトークンを入力して得点を競い合う企画です。

言語もイベントも違いますが、
PHPerチャレンジというのもあったそうです。

2位になった秘訣

ひたすら探しまくる。

ただこれだけです。
セッションの休憩時間にひたすらスポンサー各社様のブログを見たり、
パンフレットをひたすら見たり、
公式サイトをひたすら見たり、
ブースをひたすら見回ったり、
ラジバンダリ(自主規制)

クライマーズ・ハイならぬトークンズ・ハイでした。
口を開けばトークン。
弊社のSlackではトークン乞食と揶揄されていましたが。。。
いいんです。楽しければ。

1位は逃しましたが2位です。

おかげさまで2位になりました。

ありがたいことに運営の方より、景品をいただきました。

いただいたボードゲームたち

お茶会で使われていた使いさしではありません。
フィルムをかぶったサラの状態です。

本当に感謝。
ボドゲやる友達募集中。

あとがき

イベントの楽しみ方は人それぞれで、
セッションに張り付くもよし、Ask the Speakerに居座るもよし、ブースをひたすら回るもよし。

全てを受け入れてくれるイベントで、改めて感心させられました。

iOSDCは運営の方々、各スポンサーの方々、そして参加者の全員で作り上げていく、とても心温まる良いイベントだと思っています。

去年はスタッフとして参加していましたが、また違った一面を見ることができて、非常に楽しかったです(語彙力)。

ここだけの話、iOSDCチャレンジのせいで#を見てしまうと
「あっ、トークン。」
っていう弊害が出ています。

来年も開催されることを祈って、締めさせていただきます。
みなさまお疲れ様でした!

#非公式iOSDCチャレンジトークン一覧

もっと読
Pocket

チームビルディングについてのふりかえりLTをしたので、ふりかえりをしてみます

Pocket

はじめに

外販グループの中嶋(@jnuank)です。
この記事は、チームビルディングのふりかえりLTを終えたあとに、自分自身でふりかえりをしてみた、というお話です。
タイトルからお察しのとおり、テクニカルなお話ではありません。

この記事を書くきっかけ

3ヶ月前に今のチームでリーダーを務めることになり、今に至るまでのふりかえりを社内でLTしてみました。

その時のフィードバックの中で、「この内容だったらブログも書けそう」というお言葉を頂き、じゃあ書いてみようと考えたのがきっかけです。

どうせならスライドの内容をそのまま書くのではなく、
LT後の皆さんのフィードバックを元に、自身で更にふりかえりをした内容を書いてみようと思います。

ふりかえりLTのふりかえりという、なかなかこんがらがりそうな感じですが、どうぞよろしくお願いいたします。


当日発表したLT資料

詳細はスライドを見て頂けたらと思います。


LT後に出た意見・質問

リーダーの職務記述書がリーダーズインテグレーションっぽい

これは最近リーダーズインテグレーションをやったチームからの意見でした。
確かにリーダーズインテグレーションの「③リーダーに知ってほしいこと」「④メンバーがリーダーのためにできること」は、私がやったことと近いものを感じます。

メンバーと「リーダーの職務」のすり合わせを行った一番の理由としては、 「リーダー忙しそうだけど、何やっているのかわからない」「メンバー側からは、これやって欲しいのに、リーダー何もやってくれない(ように見える)」など、不幸なすれ違いを早めに解消したかったという想いがありました。

リーダーの期待マネジメントという意味では、リーダーズインテグレーションも同じような効果が望めるのかな、と思います

逆にリーダーズインテグレーションをやってみてどうだったのか聞いてみると、やはり準備等に時間が掛かったそうです。
ただチームメンバー同じ場になって話し合うことに意味はありますし、
このワーク自体、リーダーの期待マネジメントとは別に、リーダーを務める人自身を知って、メンバーたちに親しみやすさを生み出す効果があります。
実践したチームの議事録を見せて頂きましたが、「(メンバー)リーダーに恋愛相談してもよいか→(リーダー)私で良ければ」という質問もあって楽しそうなチームだな、というのが傍目から見ていても感じ取れました。

プラクティス名をあえて出さずに、自分で資料を作って個別に説明したのは何故か?

「デイリーでファイブフィンガーをやる時、説明資料を作ってメンバーに説明した」という話を受け、他チームから出た質問です。

理由としては、プラクティスを導入することに対して、なるべく拒否反応を起こして欲しくなかったからです。

仮に自分が「ファイブフィンガーやりましょう」と言ってやり方を伝えただけだと、「5本指で表すことになんの意味があるのか?」という疑問を生み出し、「そんな余計なことしなくても、いつもどおりデイリーをやればいいじゃん」と言われる可能性が、もしかしたらあったかもしれません(ハンズラボの中で、そういう人は少ない傾向にはありますが)

なので、

  • 5本指でタスク進捗を表明しましょう
  • なぜそれをやるのか
  • これを始めたらどういう効果が期待できそうか


という資料を簡単に作成し、説明をすることから始めました。

カイゼン・ジャーニーの第1部にも「プラクティスは強力だけど、そのままやるな」といった記述があります。
あれはプラクティスの手順をそのまま現場に適用しようとするな、という意味でしたが、チームの状況に合わせないで適用とするから、メンバーの拒否反応が出てしまうんじゃないかと思ってます

このスライドでは載せてないけど、やってみて失敗した取り組みはあるか?

取り組みを止めたかどうかで言うなら、と前置きした上で、今の所ノーです。

取り組みを始めて2〜3ヶ月のため、まだ 「失敗もしていないし、成功もしていない」というのが正直な感想です。
そもそも私の中では「上手くいっているチーム」という定義が、まだ曖昧です。
(この辺り、一家言ある方がいらっしゃいましたら、ぜひ教えて頂きたいと思っております)

とりあえずの目標としては、以下の2つを考えています。

  • お互いの成功・失敗を恐れなく共有できるくらいに、コミュニケーションのハードルを低くする
  • お互いチームの問題点を見つけ出し、前向きにカイゼンしやすくする空気を作り出す


上記の目標を達成する為に、デイリーとKPTをやり始めたのは、私の中では「大切な一歩」だと考えています。

もちろん一回やって終わりではなく、やり方自体もカイゼンをしながら、チームに根付かせる努力をしていきたいです。

※目標を書いてて思いましたが、これも定性的ですよね。
 強いて言えば会話の量が増えるかどうかでしょうか。
 とはいえ、会話が多すぎるということは、コミュニケーションルールがうまくできていないということに繋がるので、一概には良いとは言いにくそうです。
 チームで立てた行動目標、成果目標が上手く達成できているのかを見るのが良いのか、うーん…。

デイリーを今やっていないけど、やった方がいいのか?

これは2人チームのリーダーから出た質問でした。
賛否が分かれそうですが、個人的にはやったほうがいいと思っています。
スライドの中でも書いていますが、デイリーをすることで「チームのリズムを作ること、メンバーが均等に喋る機会を1日に数分でも良いから作る」ことが重要だと思うからです。
デイリーに関しては、既に導入済みの他チームからも以下の肯定的な意見を貰えました。

  • デイリーをやることによって、楽しくおしゃべりする機会が増えた
  • 必ず毎日顔を合わせて喋るので、メンバー同士のコミュニケーションを取ることへの心理的障壁が下がった


心理的障壁が下がるっていう意見はとても良いなって思います。

これはいわゆる、心理的安全性が構築された状態だと言えそうです。

どうして心理的障壁が下がるかと考えると、毎日少しでもコミュニケーションを取ることにより、相手の考え方や人となりが理解できる。
そうすれば、相手に合わせた会話がしやすく、コミュニケーションのハードルが下がっていくのではないかと。

KPTをこれからやろうと思うけど気をつけた方が良いところは?

この質問に関しては、導入時と実施後の経験から、以下の内容をお話しました。

  • KPT経験者(チーム外の人、外部CTO)にオブザーバーとして入ってもらう
  • アジェンダを先に作っておく
  • グランドルールの共有


経験者を入れるのは、円滑なKPTを運営する為です。
アジェンダに関しては、時間内に終わらせるためにタイムテーブルを共有する為。
グランドルールは、この場で守って欲しいことを伝える為です(意見に対する批判はしない、など)

特にグランドルールを共有することは、心理的安全性を作るのにとても重要だと感じています。

また、LTを終えたあとに、こうした方がいいのかな、と思った事は以下の3つです。

  • KPTのファシリテーターは順繰り制にしてみる
  • KPTボードに目標・テーマを入れる(オプション)
  • 最低でも4回はやってみましょう、と導入前に伝えて合意を得る


常にファシリテーターを固定してしまうと、その人が不在の際にはスキップする、という心理が働いてしまうので、順繰り制を導入した方がいいのかなと考えました。
目標・テーマについては、永和システムマネジメントさんのKPTふりかえり会体験で学んだことですが、ただ漠然とKeep、Problem、Tryを考えるよりテーマを渡した方が考えやすいそうです。
最低4回やろう、というのは実際に私がチームに導入するとき、「KPTはふりかえりのフレームワークなので、ある程度の期間やって効果を見ましょう」と話し、最低4回、毎週やるとしたら1ヶ月やって、それでも意味が無いと思えばやめましょう、とメンバーに伝えました。
ふりかえりが重要だと私個人が思っていても、メンバーがその効果を感じれず、「やらされている」感が抜けないのであれば、それは潔くやめてしまうのがチームの為だと思ったからです。

LTを終えたあとのふりかえり

ふりかえりLTしてみて、
いろんなことにTryしてみたな、という実感と、
これだけやっても、まだまだチームの問題は尽きないっていう気づきが得られました。

ソニックガーデンの倉貫さんの記事でも、KPTでProblemが出ないことは良いサインではなく、出ないのであれば日々挑戦していないかもしれない、といった事を書かれているので、そういう意味ではちゃんと挑戦が出来ているのかもしれません。

あと、「やると良さそう」というのはわかっているけど、
どんな風に始めたら良いのか、どうやって他のメンバーを巻き込んだら良いのか、というニュアンスの意見がチラホラあり、みんな最初の一歩が踏み出しにくいんだなって印象でした。

私の場合も最初の一歩が踏み出しにくかったですが、いま外から来ているCTOとの1on1で「とりあえず、やってみましょう」と背中を押されたのが大きかったと思います。
人間、相談できて背中を押して貰える、ということは大切だなと感じました。

自分がやったLTも他のチームの方々の背中を押せるようなLTになってればいいな、なんて今は思っていたりします。

今後の妄想

デイリーでは日々のタスク、KPTではチームのカイゼンが主となっているので、今後はメンバー個人にフォーカスした1on1を実践していきたいです。

KPTなどで定期的なチームのふりかえり、1on1で個人のキャリアや志向のキャッチアップしてチーム状況の変化に気づきやすくできれば良いかな、と考えています。
最近のチーム状況的に、KPTが合わないような気もしてきたので、折を見てYWTも試してみてもいいのかなーと考えています。

あとは、開発〜運用フローを可視化するバリューストリームマッピングを試してみたいという気持ちがあります。
ちょうど最近メンバーの入れ替わりがあった為、これを機にプロセスの可視化をして、できるところからカイゼンしていきたいです。

また、Joinしたてのメンバーが早くコードベースに馴染めるように、ペアプロ・モブプロを業務の中で取り入れたいなと密かに思っていたりします。(せめて週イチくらい

おわりに

今回のLTで思いのほか、社内外問わずにフィードバックが貰えたのが嬉しかったです。

隣の芝は青い理論で周りを見渡していると、「他のチームみんな上手くいってるな……こういう内容興味ないかな……」と萎縮していましたが、
いざ共有をすると、意外とそれぞれチームの悩みがあったりして、
「なんだ、みんな悩んでるじゃん。もっと早く言って一緒に悩めばよかった」なんて思えたのが一番の収穫かもしれません。

人がそれぞれ違うように、チームもそれぞれ違います。

となると、チームビルディングのやり方もそれぞれ変わってくるはずです。
これをやれば絶対うまくいく、といった銀の弾丸はありませんが、
いろんな体験を共有しあって、より良いチーム活動が出来るようにしていきたいなと思っています。

Pocket

AWS認定ソリューションアーキテクト – プロフェッショナル(改定後) おすすめ学習方法

Pocket

はじめに

ビジネスソリューション本部のフジワラです。

問題改定後のAWS認定ソリューションアーキテクト – プロフェッショナル(以後SAPと記述)を受験し、1度の不合格の後、2019/7/25 に スコア750というギリギリで合格できました。

2019/2に問題が改定された後のSAPはインターネット上に情報が少なく、情報収集に非常に苦労しました。そこで、全く自慢できないスコアではありますが、試験の概要と私が実施した学習方法を共有したいと思います。

試験について

概要

  • 問題数:75問
  • 制限時間:180分
  • 合格ライン:75%正解
  • 日本語訳文と英語原文を切り替え可能

75の長文問題を平均して2〜3分以内に回答する必要がある上、試験途中の飲食や休憩は許されないため、体力勝負になります。体調をしっかり整えての受験をおすすめします。

範囲

問われるユースケースは非常に幅広く実践的です。アソシエイトではサービスの機能そのものを問われる問題が多かったと記憶していますが、SAPではサービスの機能を把握した上で「何を求められている問題なのか」を読み解き、解答する必要があります。今求められているのは、コストを抑えることか?それとも作業の容易さか?それとも完了までのスピードか?読み解く力が必要です。 

誤訳に注意

日本語版試験を受験しましたが、たびたび誤訳に苦しめられました。日本語文ではどの選択肢も不正解になってしまう… → 英語原文に切り替えると記述内容が異なる! ということも数回ありました。日本語問題文に関係しないサービスが突如現れた場合等は、英語原文に切り替えて確認することを強く推奨します。

誤訳問題をAWSに報告するには一体どうすれば良いのでしょうか……

学習方法

何もわからず手探りで行った学習と、2度の受験経験を合わせて考えて再構築した、私がもう一度SAPを受験するなら… と考えた学習方法を紹介します。

AWS公式デジタルトレーニング

実はSAP試験対策用のデジタルトレーニングがAWSから提供されています。英語ではありますが、とてもリッチでわかりやすく有用な学習資料です。しかも、なんと無料です!

この「Exam Readiness: AWS Certified Solutions Architect – Professional」では、SAP試験範囲である以下の項目について、基本的な学習を行えます。

  • 組織の複雑さに対応する設計
  • 新しいソリューションの設計
  • 移行の計画
  • コスト管理
  • 既存のソリューションの継続的な改善

全編英語ですが、Chromeのgoogle翻訳拡張を使えば、容易に翻訳可能です。

各章の冒頭にはアーキテクトを解説する動画があります。当然英語ですが、私のような英語ダメダメ人間は動画に文字が表示されたタイミングで停止して、スマホ版Google翻訳のカメラ機能を利用して内容を理解しました。もちろん、英語をヒアリングできれば1番良いのですけど…。

デジタルトレーニングには例題と、その例題に対する解説動画も用意されています。特に例題解説動画は誤まった選択肢についても一つ一つ丁寧に説明してくれるため、必見です。Ask yourself:

解説動画を全て見ていくと4時間以上かかりますが、動画にのみ出現する構成図も存在するため、なるべく飛ばさずに視聴することをオススメします。本トレーニングを修了することで、SAP試験対策の基礎は整うはずです。

また、私は受講できていませんがSAP向けの無料デジタルトレーニングは他にも存在するようですので、そちらも合わせて受講するのも良いかもしれません。

AWS クラウドサービス活用資料集

先述のデジタルトレーニングで大方の雰囲気は掴めたはずですが、各サービスのベストプラクティス などの詳細部分までは説明されていません。トレーニング中に出てきたサービスについては、おなじみのAWS クラウドサービス活用資料集で追加学習することをオススメします。

ホワイトペーパー

SAP試験ガイドに記載のあるホワイトペーパーを少し読みました。ホワイトペーパーは文量が膨大かつ日本語化されてないものも多く、読み進めるのが辛いため、設計思想のおさらいという感覚で軽く読みました。「AWS Well-Architected Framework」についてはBlackBelt化されていましたので、そちらで学習しました。

その他

ここ1年以内にリリースされた新し目のサービスに関連する問題もありました。AWSに関する情報は広く貪欲に集めておくことをオススメします。

おわりに

私がデジタルトレーニングの存在に気付いたのは、2回目の試験の前日でした。もっと早く存在を知っていればもう少しマシなスコアが取れたかもしれない…と考え、この記事を書きました。改定後SAP取得を目指す、何処かの誰かの助けになれば幸いです。

それにしても、デジタルトレーニングにせよ試験の誤訳にせよ、今1番必要なのはAWS認定ではなく英語のスキルなのでは……

Pocket

すごいVBAをLambda+HTML帳票+Puppeteerに置き換えた話

Pocket

CRMチームのyktakaha4です。

今日は、私たちが日々開発・運用しているハンズネットにおけるレガシーマイグレーションの現場をお届けします。

みなさんは、Excel、とりわけVBAはお好きでしょうか?

方々のエンジニアから親の仇のように忌避されながらもなぜだか中々無くならず、今日においても大小様々な企業で使われ続ける不思議な存在です。
嘘だとお思いでしたらInxxxxやレバxxxで「VBA」で検索してみてください。年収700万円も夢じゃないみたいですよ…?

私はExcelもVBAも好きです(でした)。

Officeの入ったWindowsがあれば使えるという可搬性に加え、
ユーザーフォームやExcel関数、CreateObjectやDeclareまで駆使すれば、控えめに言ってどんな処理でも実現できます。
また、Numbersやスプレッドシートの関数名、GASにおける各種オブジェクト名なんかを見ても、彼らがいかに広く浸透した概念であるか分かります。

前職では金融系の社内システムを開発していたのですが、資格を取得するくらいには活用していました。
もちろん不満・力不足に思う部分も沢山ありますが、エンドユーザと同じコンテキストを共有できて、どこでも使えて何でも作れるって、それ普通に全エンジニアの夢じゃないかと思うのですが…!

しかしながら、潮目は少しずつ、でも着実に変わってきています。
過去にはExcelでPythonが使えるようになるかもというニュースがあったり(結局JavaScriptになったんでしょうか?)、東急ハンズでも各種RPAツールの導入や、G Suiteの利用を推進していたりと、その利用の場は減っています。
令和の時代にはきっと新たな何かが世を席巻し、その陰に消えゆく運命にあるのでしょう…

そんなVBAに最後の餞として用意されたかのごとく、東急ハンズでExcelとVBAが大活躍する業務がありました。

そう、ハンズネットの荷札発送業務です。

ハンズネットは、すごーく大まかに言って、東急ハンズ新宿店の在庫をバックヤードで梱包してヤマト運輸経由で発送しています。
ヤマト運輸で商品を発送するためには、所定の送り状にお届け先の情報を印字してダンボールに貼り付ける必要がありますが、
この荷札の作成及び印刷をExcelとVBAマクロを駆使しておこなっていたのです。

図にあらわすと以下のような感じです。

出荷担当者目線では「梱包作業の時間になったらWebの画面にボタンが出るんで、押したら荷札が出てくる」程度のものですが、
システム担当者からすると、業務ロジックに基づいた荷札種類の決定、データへの書式設定、mm単位での微調整が必要なレイアウト、バーコードの生成、複数プリンタを指定する必要のある印刷処理などが渾然一体となったすごいやつ(尊敬)を保守し続けなければならず、
私含むエンジニアのほぼ全員がMacbook Proで開発を行なっている現状においては、環境を用意するだけでも一苦労…という状況でした。

そんな中、今年の10月に施行される消費増税、とりわけ経過措置としての軽減税率導入へ向けた対応の中で、当マクロの改修が必要なことが分かりました。
東急ハンズでは軽減税率対象となる食料品を一部扱っており、税率を分ける必要がある→荷札と一緒に添付する領収書で表示する税額を分けたり、商品ごとの税区分を明示する必要があったんですね。

現行のマクロを改修するという逃げの一手もありましたが、CRMチームのエンジニアリーダであるwatarukuraさんの判断もあり、この機会に保守が容易な別の仕組みに置き換えようという運びとなりました。
(私見ですが、こうした判断をエンジニアサイドから自発的におこなえるのは弊チームの良いところの一つだと思います。こちらもよければご覧ください)

今回は、マイグレーションによってコードを保守可能なものに置き換えることと、複数システムにまたがる税対応の中でスピード感を持って改修することを優先し、
外部サービスやパッケージを使うといった抜本的な運用変更までは考えず、既存と同等の荷札を別の仕組みで出力できるようにする…という方向性で改修方針を立てました。

改修後は以下のようになりました。

ユーザ目線では、従来Web画面でボタンを押下した際に自動的に荷札が印刷されていたのが、
出荷対象の全ての荷札が印字されたPDFファイルがダウンロードされるのでそれを印刷する…という形になっています。
印刷方式についてはチーム内でも議論がありましたが、業務部門のOKをもらった上で、今回の作業スコープからは一旦外すこととしました。
(運用がこなれてきたらより良い形を考えて、改めて提案したいですね…!)

業務的な話とは別に、本対応のキモであるVBAをPDF生成APIに置き換えた部分をもう少し詳しく紹介しておきます。

大枠では、VBAに組み込まれていた業務ロジックとデータへの書式設定をNode.jsに置き換えた上で、Excelでレイアウトしていた荷札をテンプレートエンジンであるEJSを用いたHTML帳票として出力し、それを更にGoogle ChromeのヘッドレスブラウザのPuppeteerでPDF化する…という感じです。
HTMLならVBAよりは修正にかかる心理的負荷を軽減できますし(WinMergeを使えば…とかあるかもしれませんが、コードでそのまま比較できるのはデカいと思います)、PDFはフォントや画像埋め込みもできて環境差異が出づらく、かつ業務部門にとってもある程度扱えそうなものだったため、利用技術として選定しました。
Puppeteerを使ったのは、公式で活発に開発が行われていたからというのもありますが、東急ハンズではGoogle Chromeを社内標準のブラウザとして定めており、色々知見が溜まれば今後に活かせそうに思えたからです。

また、今回の業務要件特有の話になりますが、1日の間に締め時間が数回あり、その時点までに受け付けた注文をなる早で荷札出力する必要がある…という課題がありました。
一回の締め処理で扱う注文数は、業務的な繁忙期も考慮すれば最大で約1000注文程度を想定しなければならず、
処理量に応じていい感じにスケールアウトしつつ、出荷のない夜間帯などはお金が掛からない仕組みを構築したいと考えていました。
あと、細かい話ですが、プリンタがジャムったり締め処理後に注文情報が変更になった時用に、個別に荷札を再印刷する機能も作らなければならず、バッチ・Webの双方から呼び出し可能なAPIである必要もありました。

これについては、社内でも幾つかのプロジェクトで利用実績のあったServerless Frameworkを使って、APIとしてリクエストを受ける親のLambda関数と、EJSによるレンダリング〜PuppeteerでPDF出力までを担う子のLambda関数をそれぞれ別に定義し、処理量に応じて子Lambda側の並列実行数を増やして対応することとしました。

平行処理については、作る前は苦戦しそうかな…?と思っていた部分だったのですが、結果的にはほとんど詰まるところがなく、改めてマネージドサービスは便利ですごいな…と思い知りました。
また、Serverless Frameworkについても、ソースコードのパッケージングからデプロイ、関数毎のメモリ使用量やタイムアウト秒数まで面倒見てもらえるので、本番デプロイなどコマンド1発で済んでしまい、大変助かりました。

最後に。
ご参考まで、対応前後の荷札サンプルも貼っておきます。今まで単に荷札と説明してきましたが、右部は商品明細になっていて、切り取ってダンボールの中に入れるようになっています。
上が対応前(VBA)、下が対応後(PDF)です。開発中の写真で位置調整が甘いですが、なんとなく雰囲気は分かってもらえるのでないかと思います。

VBA版
PDF版

余談ですが、従来バーコードコントロール9.0でおこなっていたバーコード出力はJsBarcodeを使うようにしました。フォントもおなじみMSゴシックからNoto Sansに変えたので、なんとなく見やすくなった感じがしますね。

現在は、従来のExcelバージョンとPDFバージョンを双方出力できるような状態で本番化して、処理量と処理速度を監視しつつ、業務部門に不都合がないか最終確認してもらっている段階となっています。
消費税対応のためにはじめたマイグレーション作業でしたが、これをきっかけに、実は他にも荷札で直したいところがあって…というような依頼もいくつか頂くようになり、業務改善にも寄与できそうでいい感じです。

っていうか、ようやく税対応のスタート地点に立つことができたという話なので、
これがキャリア最後のVBA対応になることを強く願いつつ、もう一息頑張っていきます…!

Pocket

ボードゲーム「プロジェクトテーマパーク」をプレイ!

Pocket

こんにちは。前回の更新からだいぶ経ってしまっていました。松本です。

ハンズラボではプロジェクト管理ツールとして、主にnulabさんのbacklogを活用させていただいています。backlogはプロジェクトごとに課題管理、ガントチャート、Wikiなどをまとめられるサービスです。
かわいらしいデザインが印象的ですよね。

そんなnulabさんがかわいさとプロジェクト管理要素をフルに活かしてなんとボードゲームを作ったそうです!
それがこちらの「プロジェクトテーマパーク」

レポート記事を書けばこの「プロジェクトテーマパーク」をプレゼント!というキャンペーンを見つけたので考えるよりも早く即申し込み。
幸運にも当選し、ゲームが届いたので社内有志と試遊会を開きました。
(※キャンペーン申込期間は終了しました)

その様子の一部

  • 「協同建築?ペアプロってこと?」
  • 「こういうことですよね?(突然ゲームルールのフロー図を書き始める)」
  • 「「リスケ前提?!」」

大変たのしかったのでレポートしていきたいと思います。

ハンズラボが解釈したゲームルール

読み違えてたらすみません・・・。

ゲーム概要

↓公式より転載↓

「プロジェクト テーマパーク」は、3名〜5名、30分程度でプレイする協力型ボードゲームです。サイコロや「ヤル気カード」を用いて、ジェットコースターや観覧車などのアトラクションを1ターンずつ建築していき、期日までに全てのアトラクションを完成させれば完全クリアとなります。「役割カード」や「イベントカード」などによってゲームの進行が左右されるなか、チームワークを高め合いながらテーマパークのオープンを目指します。

引用元:テーマパークを建設したら働きやすくなる!?🎲プロジェクト管理を学べるボードゲーム、いよいよ完成!


ゲームのルール

ゲームは主に2種類のフェーズの繰り返しで進んでいきます。

  • みんなで今月作れそうな建築物を見積もるフェーズ
  • プレイヤー(役割)ごとにサイコロを振って建築成否を決めるフェーズ

弊社の非公式サークル?モデリング部(仮称)のメンバーがスッと立ち上がって書いてくれた建築フェーズの流れ がこちら

「建築」はサイコロを振ることですね。 建築物ごとに必要な出目が決まっています。 プレイヤーは一人で建築するか、「協同建築」か選べます。 一人での建築の場合、ダイスロール成功で何度でも次の建築に挑戦できます。 「協同建築」の場合、他のプレイヤーとターンをシェアすることで、出目の合計が成否の判定値となります。つまり、大きな建築物を作りやすくなります。

建築成否を決めるのはサイコロの出目だけではありません。 プレイヤーたちに配られる「ヤル気カード」の値を加えた結果が、各建築物建造に必要な数の範囲内であれば建築成功となります。

見積もりフェーズでは手札の状況を見せずにそれとなく各自のヤル気具合を示しながら何を建築できそうか話し合います。自分のヤル気カードを他のメンバーに見せてはいけないのでロールプレイ力の見せ所となります。

さらにこの通常ルールに特別な影響を与えるのが「役割カード」というわけです。

今回プレイしたときのイカれたメンバーがこちら。

  • 0〜5の赤いサイコロしか使えない「新人」
  • 2〜7の青いサイコロしか使えない「完璧主義」
  • ヤル気カードの譲渡ができる「プロジェクトマネージャー」
  • 見積もりフェーズで喋ってはいけない「無口」
  • 赤・青サイコロ、そして普通の白サイコロのどれでも好きなものを振っていい「エース」

イカれたと言いましたが割とまともな顔ぶれでした。 役割カードは全9種類からランダムに配られます。 今回はたまたま入ってきませんでしたが「トラブルメーカー」とかいう不穏な名前の役割も存在するのです。こわい。

さて果たしてこの5人でアトラクションを必要数建築できるのか!?
顧客の信用を失わず!さまざまなアクシデントやラッキーを乗りこなしつつ!
期日内に!!

Let’s play!

プロマネ「どうですか皆さんのコンディションは、いけそうですか」
新人「ノリノリっすね」
プロマネ「ノリノリ!?まじすか」
新人「ノリノリっすね」
無口「・・・」

ノリノリの「新人」役、ロールプレイもノリノリ

プロマネ「でも今ちょっと力をセーブしておいてほしいんですよね・・・」

建築物はフリーセルのように重なっており、手前に来ているものしか建築できません。 ヤル気の出しどころは重要ポイント。

プロマネ「まぁちょっと落ち着きなよ(そっとヤル気カードを渡す)」

ヤル気カードにはマイナス値をもつものもあり、どうやらプロマネはそれを新人に渡したようです。

完璧主義「どうですか?」
新人「ちょっと落ち着きました笑」
無口「・・・」

ちょっと落ち着いた新人たちとじわじわ建築を進めていきます。

見積もり通りに建築できなかったときは顧客の信用1ポイントを犠牲にダイスロール権が復活するらしい・・・それってどういう仕組み???

完璧主義「土下座・・・?」
プロマネ「顧客に対する虚偽報告で帳尻をあわせる・・・?」
※だめです

信頼がある限り土下座をし続けて振り直しができるのか?などと闇の議論にはひとまずルール上は制約がなさそうなので「できる」と仮定して先へ進みます。

なかなが出目が合わず進捗具合はちょっとまずそう・・・。

と、ここで追い打ちをかけるように今月のイベント「インフルエンザ」!

一同「「「や っ ぱ き た」」」
完璧主義「ありそうだと思ったんだよな」

プロマネと無口がインフルエンザで出社できないことに・・・!

完璧主義「これヤル気の受け渡しどうなるんですかね」
プロマネ「いつでも譲渡できるみたいだから出社しなくてもできるんじゃないですか」

プロマネ「出社しなくてもヤル気の受け渡しはSlackで可能!!」
※インフルエンザのひとはSlackも見ないでしっかり寝ましょう

また通常ならターンの頭での有休取得宣言など、何らかの理由で建築せずにターンを終えた場合、ヤル気カードが補充されるんですが、出社しなかった場合もあてはまるのか?という疑問はひとまずあてはまるだろうということで進めます。

プロジェクトに復帰したプロマネ、再び見積もりフェーズ。 ちなみにプロマネ役割のひとが見積もりを仕切る必要はありませんが、みんなロールプレイがしっかりしていたためかなんとなくそういう流れになっています。

プロマネ「うわーどうしよう、けっこうきついな」

プロマネ「でもできれば次観覧車いきたいからポップコーンやっときたいんですよね」
無口「・・・」
プロマネ「無口にポップコーンいけるかききてぇー…」
無口「・・・」
無口「見積もりでしゃべれないのめっちゃつらいです笑」

ロールプレイで沈黙を守ってくれていますがご本人はとてもしゃべりやすい方です!
見積もりでは話に入れてない無口、プレイの順番が後ろにまわされがちのためか、たびたびプレイせずにターンが終わったりしてさみしい。

ヤル気カードがどんどん補充され、物理的にヤル気いっぱいに。

無口「建築成功するとヤル気カード2枚出せる建築物があるんですね」
プロマネ「あ、ほんとだ」
無口「こういうの協同建築した場合は後手でサイコロを振ったほうが2枚出せるようになるみたいです」
プロマネ「なるほど」

無口、エース、完璧主義ががんばるもなかなか進捗はぎりぎり・・・!

プロマネ「信用ポイント4を犠牲にリスケすれば・・・」
一同「「「リスケ前提?!」」」
プロマネ「いやだってしんどいんですもんー・・・」
※かわいく言ってもリスケ前提はだめ絶対

プロマネがダークサイドに落ちそうになりましたが 新人のヤル気が炸裂したこともあり一気に勝利! 完全勝利はできませんでしたがなんとか無事に顧客の信頼を失いきらずに終われました。

疑問点まとめ

  • 信頼がある限り連続で振り直しができるのか
  • 出社しなくても能力は使えるのか(主にプロマネの)
  • 出社してない=建築してないとしてヤル気が補充されるか

上記疑問はひとまず「YES」で仮定して進みました。

考察

参加者感想から抜粋したものがこちら

  • いくら頑張って見積もりしても、外部要因で色々くつがえるという、理不尽さを学べた
  • リスケに逃げずに納期を守る事の尊さを学べた
  • 序盤は信頼が2しかないので失敗が許されず、より堅実に組んで信頼を得ていく必要があるが、堅実に行けばいくほどその分プロジェクトの進捗は遅くなる
  • 見積もりで意思表示がなく成果が見積もれないメンバーはどうしてもリスク扱いになる
  • 工数負荷的にはエースと完璧主義にだいぶのしかかってた気がする。建てた建物を手元に置くのにはそれを可視化させる意味もあったのかも
  • めっちゃくちゃ問題児キャラは今回いなかったけども迷惑な人もいるにはいるからそこのケアが必要(多分信頼2ポイント消費でのメンバー交代かな)
  • プレイする上では、迷惑役を引いてしまったリアルメンバーのケアも含めてチームマネジメントだと思う
  • ソリティア的な感じで決められた順番にしか着手出来ない&工程のツリーも複数本あるので、どのクリティカルパスをいつまでに処理すれば納期までに間に合うかってのを自然に考える仕組みになってた

プレイしてみて振り返るとランダム要素がけっこう多いなという印象を受けました。

  • 建築物の種類(コスト)・並び順
  • 役割カードの種類
  • イベントカードの内容・順番
  • ダイスロールでの建築成否判定

多少制御できるのはヤル気くらいでしょうか。

役割カードの組み合わせでゲームがけっこう変わる気がしたのでプレイヤーたちのレベルごとに役割カードの組み合わせを提案してもいいかなと思いました。ドミニオンのアクションカードの組み合わせ例みたいなイメージ。そして現実でいえば採用によるメンバーコントロールですね。

例)初心者グループ4人向け組み合わせ案
⇨プロマネ、エース、新人、愛されキャラ

まとめ

手に汗握る展開があったり、思いあたるところのある細かい設定にニヤリとしたり、とてもおもしろかったです!

30分程度でプレイできるはずが、ゆっくりロールプレイしたりルール解釈したりしていたらあっというまに90分くらいかかっていました・・・笑

現実のプロジェクト管理にも当てはまるような反省点がでてくるところが魅力のこのゲーム。

プレイの際はぜひ感想戦の時間も考慮してスケジューリングしましょう!

参考

Pocket