チームにScrumを導入してみての振り返り

みなさんこんにちは！

UUUMシステムユニットの sawa__it です。

10ヶ月の子どもが全然離乳食を食べてくれません。どうしたらいいですか？（ガチ）

自己紹介

UUUMには2020年の12月に入社しました。

最初は社内の数値管理システムを担当し、現在ではクリエイター管理システムの担当をしております！

役割はPMです。

PMといってもコンテキストが定まっておらず実態はプロダクトマネジャーとプロジェクトマネジャーとエンジニアリングマネジャーが混ざったようなことをしております。

前職では順番待ちシステムの会社で主に某大手回転寿司チェーン向けにオウンドアプリやアプリ内のスマホオーダー、順番待ちタッチパネル＆配席管理システムの開発及びPMをやっておりました。

2019年にScrumAllienceの「認定スクラムマスター」を取得しており、各種イベントや勉強会にも参加しているので見かけたら声をかけてくれると嬉しいです！

振り返り

上記の通り、役割がいろいろ混ざったようなことをしているためどの立場で何をやってきたかというのは曖昧になりますが参考になれば幸いです。

前提

チームの状態として自分が入る前はこんな感じでした

• チームは５人（PM含む）
• なんちゃってアジャイル
• タスクはアサイン形式
• 要件が降りてくるだけで自社開発なのに受託開発っぽいという意見があった
• エンジニアとユーザの関わりが少ない

Scrumの導入

「Scrumは銀の弾丸ではない」とはよくいうもののソフトウェア開発をする部署や人においてアジャイルソフトウェア開発宣言やアジャイル宣言の背後にある原則は大事な考え方だと思っており

弊社の経営理念である「セカイにコドモゴコロを」や経営戦略である「もっとアソビナカマを」にもマッチした考え方だと捉えています。

チームにはジュニアエンジニアもいたため今後のキャリアにも備えてフレームワークに則った開発経験がある方がよいと思い、2021年の６月からScrumを導入しました。

導入後にチームとして得て欲しいと期待する点は以下です。

• フレームワークに則った開発経験
• 開発の自分ごと化するマインドセット
• ドメイン知識の吸収

体制について

アンチパターンから入るのも申し訳ないのですが

チームとしてScrumを経験したメンバーが他にいなかったため現在においても自分がプロダクトオーナーとスクラムマスターを兼務しております。

正直、導入してから半年以上たった今ではチームも成熟し振り返りでチーム自らカイゼンできていると思っているので不都合を感じないのですが、チームのカイゼンにフルコミットできるわけではないのでやはり兼務はしない方が良いです。

特にScrumの導入とチーム異動によってプロダクトを担当したタイミングが近かったこともあり、導入や変更は少しずつと思いつつも「よくわからない奴が急にプロダクトの決定権を持ち開発体制にまで口を出してきた」というような印象を与えたと思います。見え方伝え方にバイアスがかかってしまったのかなと感じているので、やむを得ず似たような状況になってしまう場合には注意が必要です。

スプリントは１週間

最初は「納期に追われるみたいで辛い」「２週間にしたい」という意見もありました。

その都度「１週間の計画が立てられないチームが２週間の計画を立てられるわけがない」と説明し今ではリズムも定着し週ごとに事業の優先度に対応した開発ができていると思います。

これはスクラムマスター研修での江端 一将さんの受け売りでもあります。

スプリントの開始と終了

最初は月曜始まり金曜終わりのスプリントでしたが、祝日でイベントがずれて調整コストが高かったり、月金で休みをとりにくくなってしまったのでおすすめしません。

次に水曜始まり水曜終わりに変更しなるべくオフラインで行うように変更しました。

オフラインはコミュニケーションの観点ではよかったのですが、コロナに阻まれて結局オンラインで１日中MTGとなりました。

水曜日が近づくとプレッシャーがしんどくなってきたという声や、シンプルに座り続けるのがしんどいという理由で曜日を分ける判断をしました。

現在では木曜始まりの水曜終わりのスプリントで回しています。

水曜日に関連プロダクト含めた意思決定の場があるので翌日に計画を反映できるのでちょうどよくやれていると思います。

リファインメント

リファインメントはスプリントプランニングの前に時間をとって行っておりましたが、デイリーでも新しく作った要望に対して説明をするようにしていきました。これによってプランニングの場で改めて説明する必要がなくなりました。

プランニング

プランニングではストーリーポイントを使っていません。

導入時に徐々にScrumに切り替えていこうとする中でストーリーポイントを使った見積もりへの変更を後回しにしてしまったため未だに時間で行っております。

フィボナッチ数を使った時間見積もりって何それ美味しいの

釈明をさせていただくと時間で行っているもののフィボナッチ数で進めているため単位が違うだけで相対的ではあるし、ベロシティの観測にも影響はありません。

そのため、感覚的には長く時間がかかってしまっており結果としてプランニングが時間通りに終わらないことがしばしばあります。

一方で、タスクの見積もりが８以上になると取りかかった際に「朝のデイリーから夕方までに終わらないということになるので分割した方がいいよね、4以下になるようにしよう」という気づきも得られたのでそこはよかったと思います。

タスクはサインアップ方式で行っているため興味のあるタスクについて自ら選択することができます。

旧来のトップダウンのマネジメントには見られない「自分たちで見積もって自分たちでタスクを決定し自分たちで進める」形式はある種逃げ場がないようですが、これまで以上にチームに責任感が生まれたように思えます。

エンジニアとユーザに直接会話してもらう

Scrumではチームが「自己組織化（作業を成し遂げるための 最善の策を、チーム外からの指示ではなく、自分たちで選択する。）」することを目指します。

実はそんな高尚なことを目指しているわけではなく

「大枠はプロダクトマネージャが考えるけど、詳細は手戻りがなるべく発生しないように自分たちでフィードバック受けた方が身になるよね。」であったり「やらされている感」の払拭がメインでそうしていたのですが

実際に行ってもらうと直接話をしてもらうことで以下のような意見が出ました。

• 要件を落としてもらうだけではわからない課題感や温度感、背景が伝わった
• ドメイン知識が深まることで既存のコードの意図やおかしい点が分かる

社内とはいえユーザ側と直接会話することでこちらも責任感を高める要因になったのではないかと思います。

ところでスクラムガイドの2020年版に「自己組織化」という言葉が出てこないのはなんでなんでしょうかね。

デイリーは朝と夕方の２回

異動した当初は毎日夕方にデイリーを実施してました。

12月頃からメンバー追加で時間の制限があることから朝に移動しました。

チームの課題としてレビュー待ちの状態のタスクが残ってスプリントバックログを完了できないことが多かったため、バーンダウンチャートをデイリー毎に確認するようにしました。

それはそれで効果があったのですが、朝とったアプローチが上手くいったのか確認するのが24時間後になってしまうため、夕方にも行うようにしました。

また、チームではスプリントに影響を及ぼすような過小見積もりと技術的リスク、不具合、差し込み、体調不良などのリスクを「あばれる君」と称して報告します。「あばれる君」が発動されると、チームは手を止めてリスクを共有し計画を組みなおします。課題が大きければその時点で諦めるタスクを決定します。

Among us の緊急会議みたいな感じですね

「Slackで報告すればいいのでは」という意見もありますが、強制的にコミュニケーションポイントを作ることで報告の流れで課題を報告しやすかったり、アプローチを見直すことができたのでよかったと思います。

スプリントレビュー

スプリントレビューについては特筆するようなこともないのですが、コミュニケーションが増えたことで終わらないものが事前に分かっていることが多いため短い時間で済んでいるように思います。

振り返りはKPT

最初はポジティブに進められそうなYWTを採用しホワイトボードツールで行いました。しかし振り返り慣れをしておらず、課題であれば出しやすいということでKPTをテキストで行うように変更しました。

KPTに切り替えてからもやはり最初は主に自分を主語にした表面的な振り返りばかりでチームに対しての意見は出てきませんでした。

が、「なぜ上手くいかなかったのか」「どうすれば次うまく行くのか」などを半年以上繰り返すことによって徐々にメンバーからもチームに対しての意見が出せるようになってきました。

最後に

このような感じでチームにScrumを導入した流れを振り返ってみましたがいかがでしたでしょうか。参考になるところがあれば幸いです。

最初は一人で頑張っている感じがしましたが、だんだん理解を得られて周りにも評価される実感が得られるのでチームのみならず部署全体に広まれば良いと思ってます。

ではでは！

UUUM エンジニア デスクツアー vol.1

みなさんこんにちは！

UUUMシステムユニットエンジニアのendo_tです。

春花粉の猛威にやられて目薬を消費しながら、必死に書かせていただきます🙇‍♂️

はじめに

最近、コロナの影響で在宅での業務が増える中でUUUMではほぼフルリモートの環境に変わり2年弱が経過しました。

2年も経てば在宅での作業環境もそろそろ確立され、充実したエンジニアライフを送っていることと思い、

今回、UUUMエンジニアデスクツアー[vol.1]と題してUUUMシステムユニットメンバーの作業デスクを覗き見ちゃおうと企画しました🥰

この記事は以下のような人におすすめ！

• 作業環境に満足いってないから改善したい
• 誰かのデスクを参考にしてもっと充実した環境を整えたい
• UUUMのエンジニアってどんな人がいるのか気になる

今回は、システムユニットメンバーから3名にインタビューし、 デスク周りはもちろんこだわりポイントや趣味、エンジニア歴・在宅ワーク歴も共に紹介していきたいと思います。

1人目

まず1人目は、社内数値管理システムの開発に携わっているsendo111さん。 Ruby,Rails,Python,Vueをメインに業務で使用しており、使用しているエディタはVS Codeだそうです。

• エンジニア歴
  • 7年目
• 在宅ワーク歴
  • 2年目

デスク全体

そんなsendo111さんのデスクがこちら。

綺麗に配置され、ワイドモニターとサウンドバーの存在感があるデスクですね。

ディスプレイ

DELLの34インチワイドモニター

以前までは、Macをクラムシェルモードで使用しデュアル・トリプルディスプレイ体制をとっていたそうですが、 最終的にワイドモニター + Macディスプレイの形に落ち着いたそうです。

ワイドモニターほしい...

sendo111さん曰く、ワイドモニターの荷重に耐えられるアームとデスクは気をつけた方が良いとのこと🤔 (彼のデスクは5mmほどたわんでるそうです。)

キーボード/トラックパッド

BAROCCO MD770(クリア軸)/Magic Trackpad

キーボードはMISTELの左右分離型、クリア軸のモデル。 クリア軸は、打鍵音が少なく個人的に静かな方が気が散らなくて好みだからだそうです。 トラックパッドを真ん中に配置しているのは、できるだけMacBookと配置を近づけたかったからとのこと。

開発のお供

チキチキボーン/ドルチェグスト(カフェオレ)

業務中のお供は、どハマりしているというチキチキボーンの鶏かわチップスと最近導入したというドルチェグストでカフェオレだそうです。

2人目

2人目は、UUUMクリエイターのサポートシステムを開発しているmukaiyama_tさん。 業務では、Laravel,Reactを使用しておりプライベートではWeb3(Web3.0)、ブロックチェーンのインプットが多いそうです。

• エンジニア歴
  • 6年目
• 在宅ワーク歴
  • 3年目

デスク

そんなmukaiyama_tさんのデスクがこちら。

L字のデスクを使用しており、業務用PC・プライベートPC・趣味用タブレットを配置しているそうです。

L字デスクであるのは、椅子の回転だけで簡単に別環境に転換できるところがこだわりポイントとのこと✨

真ん中のメインモニターは↓画像のHDMIスイッチャーを使用して、業務用のPCとプライベートPCを切り替えてるそうです。

HDMIスイッチャー

液晶タブレット

以前は、仕事でイラストレータをされていたそうで、今では趣味としてデジタルイラストを描くそうです。

開発のお供

そんなmukaiyama_tさんの開発のお供は、ねこちゃんだそうです😻 仕事中には、膝のうえに乗ってきてくれるそうで羨ましい...

3人目

今回、最後のメンバーはLMNDの開発をされているnoraworldさん。 業務では、Railsをメインに使用していて、プライベートでは最近GithubActionsにハマってるそうです。

• エンジニア歴
  • 4年目
• 在宅ワーク歴
  • 2年目

デスク

デスクはFlexiSpotのE8。電動昇降デスクを使用していて気分転換にスタンディングで作業しているそうです。 スタンディングでの作業は3割ほどで気分転換にはちょうど良さそうですね☺️

PCはクラムシェルモード、モニターはデュアルで使用しているようです。

キーボード/マウス

BAROCCO MD600v3 RGB /logicool MX Ergo

キーボードは、MISTELの左右分離型を使用してみたそうですが左右分離型は合わなかったそうで次の相棒を探してるそうです。 マウスは筆者も3年ほど使用しているMX Ergo。角度を二段階に変えられて手首への負担を軽減できて重宝してます。

マイク

SHURE SM7B

趣味でゲーム配信もされるそうでマイクにもこだわったそうです。

このマイクはSHUREのSM7Bと呼ばれるモデルで、これのオリジナルであるSM7は、マイケル・ジャクソンの「スリラー」の録音でも使用されたモデルだそうで、こだわりMAXの一品✨

開発のお供

PCで動画をみることがときどきあるそうで、自身で開発したChrome拡張を使用しているそうです。

Video Commander

僕もインタビュー後に使用させていただいてますが、キーコマンドの操作だけで再生速度の変更や繰り返しみたい部分をLoopしたりととても便利でした。 ウェブストアからインストールでき、Youtube以外の動画のあるサイトで使えるそうなので気になる方はチェックです💁‍♂️

まとめ

今回は３名のシステムユニットメンバーにインタビューさせていただきデスク周りや業務のお供を紹介させていただきました！ 在宅ワーク経験が2年目となると自身の環境が確立されていてインタビューしていてとても楽しい時間でした。

UUUMシステムユニットにはまだまだ発掘できていないデスクがあるので、次回も楽しみにしていてください。

個人的興味からはじまった今回の記事でしたが、読んでいただけた方のデスク環境充実の参考になれば嬉しいです。

ハッカソンで優勝を勝ち取ったプレゼンの話

UUUMシステムユニットでPMをやっているエムです。 前々回、前回に続き、今回もハッカソンについての話題を書きたいと思います。

第二回オンラインハッカソンでは私が参加したチームが見事総合優勝をいただき、美味しいご飯を食べることができました。

私は非エンジニアなので開発はしておらず、主に発表資料の作成と当日のプレゼンを担当したのですが、優勝を勝ち取るために工夫したことのお話をつらつら書いていこうと思います。

なお、今回の記事は開発についての内容ではないので、箸休め的にお読みくださいませ。

同じチームのエンジニアendo_shizukaさんが開発の裏話を書いているので、こちらも是非ご覧ください↓ system.blog.uuum.jp

非エンジニアが開発に参加しようとしてみたものの…

私が参加したチームはメンバーが3人いて、発案者と開発者がバラバラだったので、ハッカソンの日を迎える前に事前に何度か集まり打ち合わせを行いました。 作りたいもの、ゴール設定、開発要件のすり合わせ、当日の進行、役割分担など、実業務で行うように結構本格的な話し合いができていたと思います。

当日どのように開発を進めるかの話で、私もエンジニアさんと一緒に画面共有しながらコードいじったりしてみようということになりました。

そして当日。 リポジトリをクローンしたり、 Google Apps Scriptでコード書いてみたり、教えてもらいながら色々やってみたのですが…

意外と時間足りなくね？

ってことに気づき、これじゃ作りたいものすら完成しない＝賞金がもらえないので、途中からスピード効率重視で開発を進めることにし、PMエムへの伝授タイムは一旦中止に。

開発に貢献できない私は、発表にパラメータを全振りすることにしました。

どんな発表資料にしようかな

発表資料の作成に時間を確保することができたので、まずは世に溢れているプレゼン資料の記事を読む。 構成、情報量、デザイン…抑えるべきポイントがたくさん出てきます。

それらを意識したうえで、今回の発表では特に大事だと思った下記を重点に資料作りをしようと思いました。

・成果物の必要性をアピール
・ターゲットを意識する
・目を惹く資料、関心を引く発表

成果物の必要性をアピール

私の参加したチームでは、Google Meet上でミーティング招待者の参加状況をひと目で確認できる機能を開発したのですが、これは私が日頃業務で感じている不便さや不満を解消したい思いをぶつけた機能です。 なので、どうしてこの機能が必要か、この機能がないと何故困るのか、のWhyは自分の中ではっきりしていました。

ただ、それをつらつらと文字で説明しても短い発表時間では伝えきれないので、 「機能がないと損すること」「機能があれば得すること」の観点で簡潔に伝え、この機能が必要だと思ってもらう印象付けをしました。

▼この機能がないと時間が無駄になっていると思わせる

↑この時ネットミームになっていた「45秒で何ができる？」という曲が可愛くて好きだったので挿絵的に盛り込みました

▼作業量のbefore afterを並べ、やることが劇的に減ることを分からせる

ターゲットを意識する

今回のターゲットは誰か。 外部向けの発信ではなく、UUUMのシステムユニット内での発表。つまり、内輪ネタが使える範囲です。

UUUMのシステムユニットは、ちょっとボケてもリアクションしてくれる、寛容に受け入れてくれる、いじってくれる素敵な雰囲気のメンバーで構成されています。（※個人の感想です）

なので、発表を流し聞きしていても耳に止まるようなネタ（知っているネタ）を挟むことで、興味が沸き、発表内容にも関心を持ってもらえると思いました。

僭越ながら、特に関心を惹きそうなシステムユニットの偉い方々に勝手に出演していただき、スライド上で今回の成果物を盛り上げていただきました。

▼普段温厚なNさんやTさんをキレさせてみたり…

▼ガッチリなYさん、ワイン好きのNさんの特徴を表してみたり…

▼Iさんがいつも愛用しているヘッドホンの色にもこだわりました

このくだりの時が一番ウケていた気がします。はい。

目を惹く資料、関心を引く発表

当たり前情報ですが、スライドに書く内容は目で見た時に入る情報量に抑え、細かい情報や補足は口頭で伝えるように、発表のシミュレーションをしながら情報を整理して資料を作成していきました。

また、発表の際に心をつかむためには、話し方の強弱や補足の入れ方が大きく影響すると思うので、テンポ良く発表できるように絵を多めに入れて、ストーリーを意識した構成にしました。

非エンジニアの私が作る資料なので開発寄りの詳細な情報は書けない…ということも逆に割り切って、細かい開発過程には触れず、この機能を使った時のことを重点的にアピールして、堅苦しくならない説明にまとめました。

これ大事。発表前のイメトレ

私は緊張しいで、ぶっつけ本番だと絶対に噛んでグダる！と分かっていたので、余った時間でひたすらイメージトレーニングしてました。

各チームでもらえた発表時間が5分ずつだったのですが、オーバーした場合は強制終了になってしまうので、きちんと時間通りに収まるようにタイマーをセットしてイメトレしてましたw

リモートで参加していたので自宅にいたのですが、シーンとした部屋で自分の声だけがブツブツ響いて…すごく恥ずかしい状況でした。 でも、これをやっておいたおかげで、発表の流れがスムーズになり、時間もピッタリでグダることなく思い描いた通りの発表ができたかなと思います。

いざプレゼン！

発表資料は作り込んでいましたが、それをそのまま読み進めても多分聴いている人の心には響かない。 なので、スライドに書いてあること以外にも、自分なりのコメントを挟んだり、文字起こししていない図の解説を口頭で補足したり、少しふざけてみたり…

発表中は緊張してぶっちゃけ頭が真っ白でしたが、笑いやツッコミなどいいリアクションをもらうことができて、手応えを感じることができました。 （でもまさか優勝できるとは思ってませんでした）

振り返り

偉そうにつらつら語りましたが、結局私が難しい開発の話ができなかったり、説得力のある説明が苦手だったりするので、自分ができそうな発表をイメージして資料作成した結果、このようなプレゼンに落ち着きました。

結果論にはなりますが、変に背伸びせず自分が納得した形でプレゼンができたことで、アピールポイントが伝わり最終的に評価いただけて、良かったかなと思います。

それと、今回ここまでプレゼンにこだわれたのは、チーム内でしっかり役割分担ができていたこと、安心して開発を任せられるエンジニアさんがいたこと、そのおかげで時間が確保できたからだと思います。

毎回この状況に恵まれるとは限らないので、どんな時間がない状況でも良いプレゼンができるようになりたいです。

オンラインハッカソンの開催方法・開催に伴う準備について。システムユニットのハッカソン開催の裏側

こんにちは！エンジニアの中村です。 今回は過去に開催したハッカソンを元にハッカソンの運営方法やシステムハッカソンの裏側などを紹介していきたいと思います！ コロナ渦でイベント開催が難しい中、ハッカソン開催について興味がある人は是非参考にしてください😃

ハッカソンについて

ハッカソンの目的・開催理由

システムハッカソン開催の目的は、社内のコミュニケーション促進、スキルアップや通常業務ではできなかったチャレンジの機会を設けるためです。 以前まで開発合宿が半期に1回行われていましたが、情勢が変わりコロナ禍において開催が困難になったという背景からオンラインハッカソンを開催しました。

過去のハッカソンの記事

気になる方はこちらから記事を見てください！

【第1回】 https://system.blog.uuum.jp/entry/2021/01/22/110000

【第2回】 https://system.blog.uuum.jp/entry/2021/11/17/110148

開催までの準備

開催までにしたこと一覧

ハッカソンを開催するまでにしたこと一覧です。 第1回と第2回のハッカソンを通して自分が開催するときには必要だよなと思うことを書いたので、ご参考までに。

⚠︎第2回のハッカソンはテーマを参加者に事前に伝えており、ハッカソンでやることやチームを事前に提出してもらいました。

【準備】
[] 運営メンバー集め （司会者・カメラ係・タイムキーパー・情報共有者・ブログ執筆者・評価集計・評価者）
[] 実施計画書を書く（目的・概要・日付・開催場所・予算etc..）
[] 予算の申請
[] ハッカソンの参加者・運営のグループを作成する（運営だけのグループも作成）
[] 参加者集め（シート作成）
[] やることが似ている人たちをチームにまとめる（参加者集めのシートと同じところにまとめる）
[] ハッカソンについての説明会・質問会（複数回）
[] GoogleDrive等に発表資料置き場など資料をまとめる場所を作る
[] 評価基準を決める
[] 賞と景品を決める
[] 実施場所の予約・場所の確認
[] 実施の全社周知
[] 打ち上げの準備

【資料】
[] オープニングの資料
[] 発表前の資料
[] 結果発表の資料
[] ハッカソン参加者アンケート
[] 評価シート
[] 評価コメントシート

準備の詳細

次は開催までにしたこと一覧の詳細です。いくつかピックアップして詳細を書きます。 細かいことが多いですが、実際ここまで決めるとスムーズに行くことが多いので、 めんどくさいですがやるといいかもしれません。

運営メンバー集め

今回のハッカソンは小規模でしたが、運営メンバーは最低でも6人くらいはいるといいと思います。

役割は以下のようにしました。

・責任者 * 1 
・運営メンバー * 2
・司会進行 * 1
・ブログ執筆者 * 1
・評価者 * ?

運営メンバーは基本的にすること一覧の開催までの準備をするのですが、 本番ではカメラ係、Slackなどへの情報共有・タイムキーパーなどを担当しました。 運営メンバーがハッカソンに参加する場合は、タイムキーパーは2人いると1人が発表している時に タイムキーパーがいなくならないのでいいのかなと思います。

発表時間も発表人数から算出して「発表時間+質問タイム+評価入力時間」を出しておいて、全体的に数十分程余裕を持たせてスケジュールを作成しました。 評価集計の人も1人決めておくと、集計が楽です。（今回集計係を決めていなかったので集計が少しもたつきました）

ハッカソンの参加者・運営のグループを作成する

ハッカソン専用のグループを作成して、そこで基本的にハッカソンの話をしていました。 専用のグループを作り、そこでハッカソンについて色々と話すことで、 情報共有が楽なのと、ハッカソン開催への意識を持ってもらうためです。

運営メンバーは当日の動きの確認や、景品についてなどハッカソン参加者に知らせないがいい話をするので別でグループを作成してそこで話していました。

参加者集め・やることが似ている人たちをチームにまとめる

参加者を集める時は、スプレで参加可否・参加者名・テーマ・テーマ内容・テーマ説明を書いてもらい、提示した日までに書いてもらいました。

日を提示しても忙しくて忘れていたりする人がいるので、運営の人は1人参加者を集める担当を決めると期限までにデータが集まりやすかったです。 その日までに担当者が定期的にメンションをつけてリマインドをすることで、参加者自身が忘れないし、 何に悩んでいるのかを運営側が把握することができるからです。

オープニングの資料

オープニングの資料は主に以下の内容を準備しました。

・ハッカソンとは
・タイムテーブル
・発表について（発表日時・一人当たりの発表時間・強制終了時間・発表資料について）
・投票について（Googleフォームなどの投票場所のURLとQRコード・投票基準と各項目の点数）
・賞について（景品の発表・注意点など）
・注意点

注意点では発表前に資料を共有することや、発表中は出来る限り顔出し必須など 書いておくことで発表がスムーズにできるのかなと思います。 オープニング後はオープニングに来れなかった人や資料を見直したい人のために資料をグループに展開するといいかもしれません。

発表前の資料

発表前の前段階の資料は主に以下の内容を準備しました。

・発表について（オープニングと同じスライドでOK）
・注意点
・発表の流れ
・投票について（オープニングと同じスライドでOK）
・発表順番
・集計時間
・アンケート

発表順番に関しては参加人数が多い場合は運営側で先に決めておくとスムーズでした。 第2回は参加者が多かったので先にこちらのサイトで決めました。

順番決め.com: https://xn--ebku91pdvftn1b.com/

参加者が少ない場合は、発表順番を発表が終わるごとに決めても時間的に大丈夫そうだったので、 第1回はこちらのサイトを使わせていただきました。

３Dあみだくじ: https://exe.tanidaiz.com/3D-Amida.php

注意点に関しては、辛辣なコメントを控えるなど書くといいのかなと思います。 発表するだけですごい！と私は思うので、辛辣なコメントがあると次開催するときに参加したくなくなりますし、次発表する人も萎縮してしまうからです。

評価シート

今回はGoogleFormで評価シートを作成しました。 項目はチーム名・個人orチームのよかったところ・テーマごとの得点にしました。 第2回のハッカソンではテーマを3つに絞っており、 それぞれ評価基準が違うのでGoogleFormでチーム名を選択した際に飛ぶページをそのチームのテーマの評価シートになるように設定しました。

評価シート

第2回ハッカソンの評価例↓

例：
テーマ：業務効率化
業務効率化  5点
ギーク度    5点
完成度      3点
プレゼン力   2点
総合点 ->   15点

テーマ：通常業務+a
業務効率   5点
ギーク度   5点
完成度     5点
プレゼン力  5点
総合点 ->  20点

テーマ：新規事業
新規・事業性 3点
完成度      3点
ギーク度    5点
プレゼン力   5点
総合点 ->   16点

評価コメントシート

評価コメントシートというのは、評価シートの個人orチームのよかったところを集めたシートです。 評価コメントシートは必須ではないとは思うのですが、作ったものへの評価を聞きたい人 がほとんどかなと思うので作成しています。

⚠︎基本的にはひどいコメントないかもしれませんが、あった場合は弾くなどの配慮が必要なのかなと思います。

評価コメントシート

ハッカソン参加者アンケート

ハッカソンの参加者アンケートは 次のハッカソンをもっと良くするために作成しました。 質問内容は以下のようにしました。

・ハッカソンはこれまでに参加経験
・審査基準は妥当か
・審査基準の評価の理由
・開催期間は妥当か
・開催期間の評価の理由
・次やりたいイベントはあるか
・気になったこと、次のハッカソンでは直して欲しいところはあるか
・次のハッカソンへの要望 

ハッカソン参加者アンケートは運営の結果集計時間に共有すると待ち時間にアンケートを書いてくれるのでいいのかなと思います。

第２回ハッカソン開催までの裏話

開催が決定して運営でMTGして話は進んでいましたが、コロナが悪化してきて集まるのが難しいという話になったり 今回のテーマが業務改善だったので何をすればいいのかわからない人が一定数いて、このまま進むとモチベーションも上がらないしいいものも 作れないよねという話になり、9月に行う予定でしたが10月末になりました。 それと、ハッカソンまでに準備しないといけないことが用意ができてなく、 全体的な流れがぼやけていて止まっていたので準備にある程度時間がかかりました。

当日は会場に必要なものがなかったり、最後の集計でGoogleFormのデータスプレに吐き出してデータを確認すると データがバラバラで、集計に時間がかかったり、結果発表の資料が一部できておらず、即席でこんな感じの資料を準備してもらいました笑

モンエナ

思った以上に想像が欠けていた部分が色々出てきたので、運営側は色々大変だなと思いました😇

まとめ

今回書いたような準備シートや期限を設定してMTGを都度行なったりすることをやってからスムーズに進んだので ハッカソンを開催する際は準備シートや期限、MTGの頻度をきちんと決めてから作業をすると延期や中止になりにくいのかなと思いました。 ハッカソンを開催するのは意外と準備が必要ですし、「ハッカソン？まぁ司会とかの資料作成くらいしとけばあとはどうにかなるでしょ？」 くらいのテンション感だと当日想定できてないことが起きてスムーズにいかないので、きちんとした計画が大切だと思いました。 第2回ハッカソンは1回目よりテーマの難しさや参加人数の増加により考えることが多かったですが、 いろんな人が協力してくださったのでうまく行きました。 第3回があるかはわかりませんが、開催できたら今以上にいいハッカソンができるようにしたいと思っています。

今回の記事でハッカソンを開催したいけど何をしたらいいのかわからない人や、 開催準備を進めているけどうまくいくか不安な人の何か参考になれば幸いです。 ここまで読んでいただきありがとうございました🙇‍♀️

第2回オンラインハッカソンで作成した拡張機能の裏話

こんにちは。エンジニアのendo_shizukaです。

UUUMに入社して1年半が経ちました。

「入社して1年半経ったとか時間の流れ早すぎん！？」って感じで日々業務に勤しんでいます。

さて、今回ブログを書くにあたりネタをいろいろ探していたのですが、

個人的にかなり大変だけど楽しかった第2回オンラインハッカソンで作成した機能でつまずいたポイントについて書いていきたいと思います。

第2回のオンラインハッカソンについてまだご存じない方は、

弊社の新進気鋭なエンジニア、久保寺君が書いてくれた記事がありますので見てみてください。 system.blog.uuum.jp

それではどうぞ。

そもそもGoogle Meetの出欠席確認機能って何？

前提としてGoogle Workspaceを使用している会社・チームが対象になります。

もしかしたら既に経験ある方もいるかと思いますが、会議の開催時刻になると招待されたメンバーは続々とGoogle Meet(以下、Meet)に参加します。

ファシリテーターは招待者の出欠確認を行うのですが、Meetの標準機能だと現在参加中のメンバーしか表示されていないので、Google Calendar(以下、Calendar)とMeetの参加者を照らし合わせながら確認するという手間が発生します。

もし、会議に招待しているメンバーが参加するのか否か、また現在Meetに参加しているか否かがMeet上で一目で分かれば出欠確認の手間が大幅に削減されるのでは？ということを目的に開発されました。

出欠席確認機能

　 さて、ここから本題です。 　 　

つまずきポイント

参加中のMeetからどの会議に参加してるかが判断できない...

会議で使用するMeet URLはCalendar上から確認できますが、

Calendar画面

Meet上からだとMeetのURLと入室前の会議タイトルしか情報が無く、どの会議に参加してるかが判断できません。

Meet画面

解決策

以下の手順で参加中のMeetの会議情報が取得できました。

1. JavaScriptのlocation.pathnameを用いてMeet URLのhttps://meet.google.com/以下の文字列を取得

2. CalendarAPIのEvents.listを用いて本日入っている自分の会議を全て取得

3. 2で取得した会議の中にconferenceDataオブジェクト *1 があるので、その中のconferenceIdと1の文字列が一致するものを開催中の会議として取得する

参考1 developers.google.com

参考2 conferenceDataオブジェクトのデータ構造(2022/02/25現在)

conferenceData: 
{ entryPoints: [ [Object], [Object], [Object] ],
    signature: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxx',
    conferenceSolution: 
    { key: [Object],
    name: 'Google Meet',
    iconUri: 'https://xxxxxxxxxxxx' },
    conferenceId: 'yer-necw-rbs' },

会議室もゲスト扱いになって参加者一覧として表示されてしまう...

組織内で会議室もCalendarに作成して管理していた場合、

その会議室を使用した会議を作成するとゲストの1人として会議室も表示されてしまいます。

解決策

会議室のゲストのメールアドレスはドメインが@resource.calendar.google.comで設定される事を発見しました。

会議のゲストリストを取得する際に上記ドメインのゲストを弾くことで解決しました。

同じ会議IDで同じ予定が2つ取得されてしまう...

CalendarAPIのEvents.listでその日に開催される会議を取得した際に、同じ会議名で2つのオブジェクトが取得される場合があります。

これは定期的な会議の場合に発生するもので、実際に取得できたオブジェクトをそれぞれ確認してみると、 一方は定期的な会議の初回開催時の情報が入ったオブジェクト、もう一方は本日開催の情報が入ったオブジェクトであることがわかりました。

解決策

オブジェクト内を詳しく見てみると以下のような違いがありました。

• 初回開催時の情報： recurrence: [ 'RRULE:FREQ=WEEKLY;WKST=SU;BYDAY=FR' ] *2

• 本日開催の情報： recurringEventId: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxx',

なぜ、定期的な会議の場合２つオブジェクトが流れてくるかの理由については調べきれていませんが、 実装としては本日開催の会議情報が得られればいいのでrecurringEventIdが含まれるオブジェクトを取得することで解決しました。

参加者のフルネームや招待ステータスなど参加者にまつわる情報を取得したいけど...

こちらは自分の完全な見当違いだったのですが、 CalendarAPIのEvents.listで会議情報を取得したら参加者のメールアドレスやフルネーム、招待ステータス *3 などが全て一括で取得できるものだと思っていました。

Events.listはあくまで会議自体の情報しか取得できず、参加者については別途APIを叩く必要がありました。

解決策

画面表示には 参加者のフルネーム メールアドレス 招待ステータス サムネイル画像 の値が必要だったので、

メールアドレス 招待ステータスをCalendarEventのgetGuestListを使用して取得しました。

const guests = event.getGuestList(true)

developers.google.com

参加者のフルネーム サムネイル画像 についてはAdmin SDK Directory Serviceを使用する事で、会議の参加者のフルネームやサムネイル画像を取得することができました。

  do {
    page = AdminDirectory.Users.list({
      domain: DOMAIN,
      viewType: 'domain_public',
      maxResults: 500,
      pageToken: pageToken
    });

developers.google.com

注意点として、AdminDirectory.Users.listを実行する際にviewType: 'domain_publicを書かないとエラーになります。

GoogleJsonResponseException: API call to directory.users.list failed with error: Not Authorized to access this resource/api))

まとめ

拡張機能はストアでの公開を目標にアップデートしていますが、頑張って対応中ですので公開までもうしばらくお待ちくださいmm

なお、実装した当時はここまでで紹介した解決策でなんとか乗り切れましたが、

現在や今後の仕様変更でもっと簡易に実装できたり同じやり方では解決できない場合も出てきますので、参考にされる際は自己責任かつその時その時の一番いい方法で実装して頂ければと思います。

*1:conferenceDataオブジェクトはMeet URLが発行されている場合のみ含まれるので、Meet URLを発行していない場合はオブジェクト自体存在しません。

*2:毎週金曜開催の場合このような値が入っています。

*3:はい / いいえ / 未回答

【第2回】UUUM攻殻機動隊オンラインハッカソンを開催しました！

こんにちは！22卒エンジニアで現在内定者インターン中の久保寺です。 10月末に今年もオンラインハッカソンが行われました。

弊社オフィスのスタジアムエリア

ハッカソンの概要

本来はハッカソンではなく半年に1回開発合宿をするのですが、

system.blog.uuum.jp

去年と同じくコロナ禍ということもあり、今年も開発合宿の代わりにリモートでオンラインハッカソンが開催されました。

【初】UUUM攻殻機動隊オンラインハッカソンを開催しました！ - UUUM攻殻機動隊(エンジニアブログ)

今年のハッカソンのテーマは、「業務効率化」

今回のハッカソンは2回目ということもあり、ハッカソンの流れを熟知しているメンバーも多くなったため、去年よりもより実用的なテーマ「業務効率化」になりました。

※去年のテーマ「今年話題だったもの」

タイムテーブル

タイムテーブル

去年は3日間あり、1日目にアイデア発表・中間発表などがありましたが、今年は2日間に短縮されてアイデア発表などは事前に行われました。発表はGooglemeetを使い進めました。有志でオフィスに集まり、オンライン＆オフライン併用で開催されました。

参加チーム一覧

参加チーム一覧

今回は全15チームの参加で、なんと去年の倍以上のチーム数となりました。

成果物の紹介

1.999 【無計画ハッカソン】

トップバッターからいきなり不穏なタイトルから始まりましたが.......

docbaseという社内のドキュメントがまとめられているWebアプリがあります。しかしdocbaseを見るには認証が必要なため、Slack内でそのリンクを貼ってもプレビュー機能は動作しません。それを上手い感じに動作させる拡張機能を作成していただきました。

しかし完成はしていたのにデプロイがギリギリ間に合わず、成果を確認できませんでした（後日しっかり完成していた）。M1とかを見てても思いますが、やはりトップバッターは不利ですね。

このスライドは発表直前に慌てて作ったらしいです。

2.ぶち【プロジェクトのER図を管理する方法】

関わっているプロダクトにER図が無かったとのことだったので、ドキュメントの充実のためER図を簡単に作成できるツールを調べていただきました。

DBeaverというツールを使ったそうで、これを使ったら一瞬でER図ができたそうです。開発だけでなく、目的に合った最適なツールを探し出すことも業務効率化の最短ルートだったりしますよね〜

3.しだ【非エンジニアはじめてのGAS】

支払証明書のファイルを取引先にメールで送信する作業があり、そのメールを手動でファイル添付をして送信するというやり方で時間が掛かっていたので、GASを用いてその作業を自動化していただきました。

GASを実行すると本当にメールが勝手に作成されていました。GASはこの発表で初めて知ったのですがとても便利ですね。毎日固定で行う業務があったら是非チャレンジしてみたいです。

4.スーパーカムイ改め特急カムイ号【社内コミュニケーションの可視化】

「社内の人同士の繋がりがひと目で分かるものがないか」という要望があり、それを実現するようなアプリを作成していただきました。

Slack内でやり取りをしたことがある人同士をグラフで繋いでいくものなのですが、実装してみたらダークマターが出来上がっていました。

「Slackでやり取りであった人」同士を全て繋ぐとダークマターになったので、「該当チャンネル内で繋がりのある人」に絞るといい感じに繋がりがある人同士の可視化ができていました。 ダークマター以外にも笑えるポイントが多々あって、成果物以外にもオーディエンスを飽きさせない工夫が施されていました。

※伏せ字には実名が含まれているため非公開とさせていただきます。

5.なかはし【GASをSlackコマンドから受け付けるためのゲートウェイをCloud Functionsでこしらえた】

SlackからGASを操作できるような仕組みを作っていただきました。

しかし弊社のセキュリティが非常に厳しいのもあり、デフォルトのままではSlackからGASにはアクセスできません。そこでSlackからGASを呼び出すのではなく、Slack→GCPのCloud Functions→GASという流れで呼び出すことによりSlackからGASを動かすという仕組みでした。

6.カッコウ【GoogleMeetチャットSlack連携】

Googlemeetのチャット欄のコメントをSlackにそのままリアルタイムでメッセージとして投稿されるという、弊社以外でも汎用的に活躍できるSlackアプリを作成していただきました。

ハッカソンのSlackチャンネルにも事前に仕込まれていて、参加者全員で実際に動いているのを確認できて沸いていました。 Googlemeetのチャット欄って退出したら消えてしまうので、これは本当に便利すぎます。一般公開まで漕ぎ着けていただきましたので現在私も1人のユーザーになっています。

chrome.google.com

7.KAZAMAN【チャットボット風Slackアプリ】

弊社はドキュメントが非常に多く、新入社員さんにまず最初にレクチャーしなければいけない情報などが錯乱していて、どこに存在するかが分からないという悩みがありました。そこでチャットボット風お悩み質問Slackアプリを作っていただきました。

知りたい情報をプルダウンで選択できるようになっており、選択すると対象の情報先へのリンクが回答として返ってきます。 ハッカソンということもあり、スピード重視で動けばいいという発想になりがちですが、アーキテクチャーも素晴らしく、技術力が高くて感動しました！

8.現場猫【Slack leaving work】

現場猫チームにはslackから勤怠が切れるSlackBotを作っていただきました。

弊社システムユニットの出退勤の流れとして、

1.出退勤アプリを起動して打刻する

2.出勤したことをシステムユニットのSlackチャンネルで報告

という流れで出退勤時に2回の作業が必要なため片方を忘れるということが頻発していました。このBotを入れておくと、Slackで出勤の報告をするだけで自動で打刻してくれるようになります。

システムユニット全員がおそらく抱えていた打刻の面倒臭さを解決してくれた素晴らしい成果物でした。

9.通りすがりの仮面ライダー㌠【無料で(←超大事)NFTアートを作る】

詳しくなくて大変恐縮ですが、今流行っているNFTアートを作っていただきました。

NFTアートはブロックチェーンで管理された代替不可能なデジタルアートのことで、複製ができないため唯一性を証明することができます。世界では1つのNFTアートが70億円とかで落札された事例もあるみたいです。

本来であれば、作るのに手数料などのお金がかかるのですが、HokusaiAPIなどを利用することにより無料で作ることに成功したそうです。実装に使用されたNFTアートの絵はご自身で描かれたそうで、エンジニア以外の才能も惜しみなく発揮していました。

10.W遠藤feat.宗像【出欠席確認機能】

オンライン会議特有の問題である「誰が来ていて誰が来ていないかイマイチ分からない問題」を解決するChromeの拡張機能を開発していただきました。

この拡張機能を有効にすると、Googlemeet上で誰が参加していて誰が参加していないかを一目で簡単に確認できるようになっています。カレンダー上では参加にしているけど実際の会議にはいないってパターンあるあるだと思うので、これは便利ですね。弊社以外でも活躍間違い無しの機能です。

そしてこのチームにはエンジニアだけでなくプロジェクトマネージャーもいて役割分担が完璧にされており、成果物だけでなく、発表のスライドもかなり面白いという二刀流で、参加者のハートを鷲掴みにしていました！

11.さわだ【シェルスクリプトでコマンドを一括実行する】

詳細は社外秘なので詳しく載せられないのですが、 大量のCSVファイルを手動でDLして、aws s3 cpコマンドで一個一個アップロードしていたため作業に手間と時間がかかっていたものを、 シェルスクリプトでアップロード作業を一発で終わらせられるように対応していただきました。

12.かきき【youtube slack bot】

Slackコマンドを叩くと、YouTubeの各種データを取ってこれるSlackBotを作成していただきました。

しっかり社内ドキュメントに操作方法なども残していただいたので、完成度抜群です。 弊社ならではの便利なBotですよね！

13.てんびん座【GoogleMeet × LIVE配信風リアクション 2.0】

前回のGoogleMeet Live

前回大会優秀賞のGoogleMeet × LIVE配信風リアクションの拡張機能を更にアップデートしていただきました。

GoogleMeetの会議中に何も反応がないと寂しい・・みんなミュート・・🥺という寂しい状況を打破するために、 よくLive配信であるボタンを押したら❤️が画面に飛んでいくようなchrome拡張を作ってくださいました！ 技術はFirebaseのRealtimeDatabaseを使っており、実演でもきちんと動作していて凄かったです！

【初】UUUM攻殻機動隊オンラインハッカソンを開催しました！ - UUUM攻殻機動隊(エンジニアブログ)

今回のアップデートではGooglemeetのピクチャ・イン・ピクチャ機能を実装し、そちらの画面でも❤️などのリアクションが見れるようになっています。試行錯誤を繰り返し14時間ぐらい実装に時間がかかったそうです。

私自身金魚のフンとして、このチームのメンバーとして参加させていただきました！

14.フィフ兄さん【Gmailに受信されたメールをSlackに通知させる】

ここまでの成果物からも推測できますが、弊社で最も利用されているツールはSlackです。逆に言えばSlackと連携できていないツールはSlackをメインに見ている社員からすれば対応が遅れるリスクもあります。 なのでSlackと連携がされていないGmailをSlackと連携させて、Gmailに受信されたメールをSlackに通知させる機能を実装していただきました。

社内ドキュメントにもまとめていただきましたし、弊社以外にも需要の高い成果物でした！

15.WAGMI【スマートコントラクト実装 & NFT認証機能】

通りすがりの仮面ライダー㌠でも題材になった、私からしたらヤムチャ視点のNFTの発表でした。

WAGMIチームではスマートコントラクトを実装していただきました。スマートコントラクトとはブロックチェーン上で契約を自動的に実行する仕組みのことで、NFTの売買などができるようになります？（浅い知識で申し訳ないです）

通りすがりの仮面ライダー㌠の綺麗な女性の絵とは対極的な似顔絵がNFTアートとして表示されており、会場内からは笑いも出ていました。

結果発表について

投票の基準としては実用性・ギーク度・完成度・プレゼン力の４項目を各5点満点の最高得点20点で総合優勝が決まります。

加えて点数に関係なく特別賞として、実用的賞・ギーク賞・完成度賞・おもしろ賞の計4つの賞が用意されています。

結果発表

総合優勝

🏆W遠藤feat.宗像

Googlemeetの出席確認拡張機能を開発したW遠藤feat.宗像チームが総合優勝しました。おめでとうございます！ 票数が圧倒的だったそうです。

実用的賞

⭐しだ

実用的賞にはGASでメールの自動作成を実装していただいた、しだチームが実用的賞を受賞しました。 賞品のカップラーメン1ヶ月分に対し、場内は「いいなあああああ😳」と沸き上がりました。

ギーク賞

⭐KAZAMAN

様々なモダンな技術を幅広く使用されたKAZAMANチームがギーク賞を受賞しました。 ギークには寝ないことが必要不可欠とのことでモンスター1カートンが贈呈されました。

完成度賞

⭐カッコウ 売り物のような出来前のGoogleMeetチャットSlack連携拡張機能を開発したカッコウチームが完成度賞を受賞しました。 既に一般公開されているので気になる方は是非！

chrome.google.com

おもしろ賞

ダークマターをこの世に生み出すことに成功したスーパーカムイ改め特急カムイ号チームが受賞しました。 賞品のトイレットペーパー半年分に対し、場内からは「邪魔そう😩」と辛辣な声も上がりました（笑）

二次会

ハッカソン終了後には二次会が開かれ、出社した社員皆でピザやお寿司を食べたりお酒を飲んだりしました。私はオンライン参加だったので二次会は不参加でしたが、後から写真を見ると羨ましい気持ちになりこの記事を書くのが嫌になってきましたね😩

皆さん仲良さそうで雰囲気がとても良かったです！

まとめ

第1回オンラインハッカソンも素晴らしかったですが、第2回は作品のクオリティのインフレが進んでいる気がしています。

オンラインだと発表者が一人で喋っている感覚に陥ることがあると思うんですが、見る側はチャット欄で逐一反応したり、発表側は敢えて笑えるポイントを作ってみたりと今回も大いに盛り上げていただきました！

皆さんレベルの高い技術や未知の技術にも積極的に取り組んでいただき見ているだけでもワクワクするものばかりでした。来年以降のハードルがどんどん上がりますね〜。 なんだかんだ今年もコロナ禍が続きオンライン開催にはなりましたが、来年には対面での第3回ハッカソンが開催できたら良いですね。

rubyを通してUNIXプロセスを学ぶ

こんにちは、UUUMでエンジニアやっておりますオオハシと申します。

今までプロセスについて書籍やネットの記事の流し読みでなんとなくわかったつもりになっていたのですが
なるほどUnixプロセス - Rubyで学ぶUnixの基礎という書籍では
普段業務で取り扱っているrubyを用いてプロセスを説明されているのが特徴で
プロセスを理解する上での大きな助けとなりました。
以下、学習したことを大まかにまとめました。

全てのプロセスはID(pid)を持っている

p Process.pid

スクリプトファイルの実行やirb、各種shell、バックグラウンドプロセスなど
プログラムの実行毎に異なる値が割り振られる。

forkして子プロセスを作ってみる

fork
p Process.pid

出力される２つのpidの値が異なる
つまり２つの異なるプログラムが並列して実行されている。

親プロセスと子プロセスで処理を分けたい

p fork

親は子のプロセスIDを、子はnilを返り値にとるので
以下のように書ける

if fork
  p "親のプロセスID：#{Process.pid}"
else
  p "子のプロセスID：#{Process.pid}"
end

子プロセスの処理内容を指定したい

ブロックを渡す

fork do
  p "子プロセスのみ評価される"
end

孤児プロセスとは

親が先に終了してしまった子プロセス

fork do
  p "子プロセス開始"
  5.times do |i|
    sleep 1
    puts "#{i}秒経過"
  end
  p "子プロセス終了"
end
abort "親プロセス終了"

親プロセス終了後も子プロセスの処理が続行し、端末から<Ctrl-c>などで停止も出来ない

何故か？

→子プロセスは親プロセスを通じて間接的に端末制御されるため。
したがって親プロセスが先に終了すると子プロセスを端末による制御ができなくなる。

どうやって管理するのか？

子プロセスの終了を待つ

fork do
  p "子プロセス開始"
  5.times do |i|
    sleep 1
    puts "#{i}秒経過"
  end
  p "子プロセス終了"
end
Process.wait # 子が終了するまで親の処理が止まる。親が生きてるため端末制御も可能。
abort "親プロセス終了"

シグナルを送信する

例えば別のプロセスから孤児となったプロセスのpidを指定してシグナルを送ることでプロセス制御が可能。

fork do
  p "別プロセスから　kill -INT #{Process.pid}　を実行してください"
  p "子プロセス開始"
  5.times do |i|
    puts "#{i * 5}秒経過"
    sleep 5
  end
  p "子プロセス終了"
end
abort "親プロセス終了"

主要なシグナル一覧

ゾンビプロセスとは

カーネルは終了した子プロセスの情報をキューに格納する。 Process.waitして子プロセスの終了ステータスを取得されないと 終了したはずの子プロセスの情報が取り除かれず、ゾンビプロセスとして取り扱われる。

ゾンビプロセス確認の仕方

pid = fork { sleep 1 }
puts "ps -ho pid,state -p #{pid}  を実行してください"
sleep 10

プロセス間で通信する

パイプ（単方向通信）

reader, writer = IO.pipe
# not opened for writing (IOError)
reader.write("読み込む側からは書き込み出来ない")

親・子のプロセス間通信をする

reader, writer = IO.pipe

fork do
  reader.close

  10.times do |i|
    # 子プロセスから書き込む
    writer.puts "#{i+1}回目の書き込み"
  end
end

writer.close

# 親プロセスで読み込む
while message = reader.gets
  $stdout.puts message
end

ソケット（双方向通信）

使用例

require 'socket'

child_socket, parent_socket = Socket.pair(:UNIX, :DGRAM, 0)
maxlen = 1000

fork do
  parent_socket.close

  2.times do |i|
    # parent_socket.sendされるまで待つ
    instruction = child_socket.recv(maxlen)
    child_socket.send("#{instruction} -> parent #{i+1}回目", 0)
  end
end
child_socket.close

2.times do
  parent_socket.send("parent -> child", 0)
end


2.times do
  # child_socket.sendされるまで待つ
  $stdout.puts parent_socket.recv(maxlen)
end

プロセスグループ・セッションについて

セッションは同一セッションIDを持つプロセスグループを束ねる
プロセスグループは同一グループIDを持つプロセスを束ねる
セッション内でセッションリーダーと呼ばれるひとつのプロセスが制御端末と接続し
セッション内全プロセスに端末から受信したシグナルを伝搬する。

終わりに

本書で解説されていたプロセスに関するごく一部を紹介してきました。
この他デーモンプロセスやシグナルの捕捉、rackその他Rescue, Unicornのプロセス管理など
プロセスに関する事項がrubyによって読みやすい形でまとめられています。
UNIXの基礎であるプロセスの知見を深めておくことは、プログラミング言語を問わず通用する技術であり
今後のエンジニアライフをより良くする上でも大変有用であると考えています。
プロセスについて理解を深めたい方は是非著書を手にとってご覧いただければと思います。