「パパ、ぼくコンピュータが欲しい」
そう長男に言われたので、あぁ子どももこういう年になったんだなぁ。というわけで、その時のエピソードです。
エンジニア父としては、せっかくコンピューターに触れるのであれば、仕組みとかにも興味持てる形にしたいな、と思うわけです。
そこでRaspberry Piですよ！
というわけで、やっぱりラズパイがいいな、と思って購入しようかと思ったら、なんと同僚のRYoMa@牛勢(@RyoMa_0923)さん | Twitter さんがRaspberry Pi 2 Model Bを譲ってくださるとのこと。というわけでありがたくいただいてしまいました。感謝！
とりあえず見せてみる
父「この前コンピューター欲しいって言ってたじゃん？」
長男「うん」
父「これ、なんだかわかる？」
長男「わかんない」
父「これがコンピューターなんだよ」
長男「えええっ！」
というわけでなかなか反応は上々。ちなみに各パーツの話をしようとしたらつまんなそうにしたんでまだその時じゃないんだな、と思って次回としました。
セットアップ
実は私自身がラズパイを触るの初めてだったので、ググりながら。
順調にRaspbianが入りました。（本当は起動直後に電源落ちて入れ直した）子どもたちにはOSの説明とか軽くしてみました。直後に外に遊びに言ってました。
インストールが終わる頃、「そういえばなんでコンピューター欲しかったの？」と聞いてみることに（今更）
そしたら「マイクラがやりたい」とのこと。
え、マイクラってRaspbianに入るのかな....
マイクラ入ってた！！
そわそわしてググってみたら、なんと
Pi Edition | MinecraftがRaspbianで動作する、ってかデフォルトで入ってるというではありませんか！
起動
というわけで早速起動します。このあたりで長男に加え次男も混じり大歓喜。
父はコマンドでチートを教えてみる
Pi Editionのマイクラは、教育目的で作られているようでPythonコードで色々動かせるとのこと。
というわけで素手でやったら数時間かかるであろう処理（100立法のブロック積んでみる、とか）をコマンド書いて実行してみました。
父、長男、次男「おおおおおおおおおお！！！！」
大歓喜です、本当にありがとうございます。その他、歩いたところに花を植えるなどして楽しみました。
子どもたちもやってみる
コードをちょろっと教えてみたところ、早速カンバンの塔を作成していました。好奇心すごいなぁ。
さいごに
というわけで我が家で長男が初めてコンピューターと戯れた日のエピソードでした。
これをいい機会にしてコンピューターに興味持ってくれるといいなぁ。
最後に、このエントリーは子育てエンジニア Advent Calendar 2018 - Adventarの10日目の記事でした。
前日のエントリーはすくすく！子育てエンジニアMeetUpが自分を救ってくれた話 – 株式会社GEEKクリエイターズブログで、明日はirotoris - Adventarさんのターンです。よろしくお願いします。
ウチのチームがモブってるとき
はじめに
このブログは、モブプログラミング Advent Calendar 2018の3日目の記事です。
前日のエントリーは @mohiraさんの、「モブプロで技術書を攻略する！」でした。今日の話はベーシックに、自分の周りのモブプロ事情の話をします。
モブをやるときに悩んだこと
モブプロに可能性を感じて、導入するときにうまくいかなかった理、悩んだことがここまで多々あります。それは、既にTAKAKING22さんが初日のエントリーで言及していたこれにハマっていました。
大きな誤解の一つとして、多くの方が分担作業とモブワークを二者択一のように考えがちです。私達も1日中モブワークをしていますが、正確には仕事の質や状況に合わせて分担作業とモブワークを切り替えながら仕事をしています。
というわけで、ウチのチームでよくモブになってる状況、仕事をまとめてみます。
ウチでよくモブってるとき
障害対応
頻度は少ないですが、一番自然にモブになってます。場合によっては部署や組織を跨いで、壁一面のホワイトボードで状況確認したり、その中で必要に応じてソロワークして同期したり、といったこともします。
手戻りがあったとき
これはここ１年くらいで増えたケース、最初はリーンソフトウェア開発のラインストップを参考にしつつ、手戻り（例えば開発テスト中にバグが見つかった！みたいなとき）に必ず声をかけて集まるようにしていました。それまでは、何かバグが見つかると担当チーム間をそれぞれ引き渡して対応していたのですが、そうすると情報の連携不足や元々の知識・経験の違いなどがあって解決までにかなり時間を要していたのですが、それがググッと縮まりました。今では重大な手戻りなどがあった際に自然にモブになっているような状態になっています。
要件・案件の理解をしているとき
いわゆる要件定義のタイミング、案件を知るときに、全員で説明を聞き、質問をし、議論をします。一人だと観点として落としてしまうようなことをなるべくなくすためこの形です。この後の実際にコードを書いたりテスト設計したりするタイミングでは、ここで同期とった内容を元にソロワークで分担することもあります。
設計してるとき
設計もモブでやります。厳密には設計の場合はチーム全員ではなく、２人以上のユニットを組んで実施して、あとでチーム全員でレビューしたりもします。レビューするなら全員で設計したらいいのでは？と思われるかもしれませんが、ウチのチームでは「モード」を重視してこの形になっています（「設計者モブ」になっている時は気がつかないことも、「レビュアーモブ」になると気づいたりします。この差が「モードの違い」だと捉えています。）
困ったとき
何か自分で困った時、つまづいたとき、相談したい時、ねぇねぇと相談してからのペアプロ、モブプロに発展することがあります。（必ずというわけではない）
まとめに代えて
ここまで、ウチのチームがモブってる時をピックアップしてご紹介しました。
大事だな、と思っているのは、必ずXXしなければいけない、なんてことはないということです。今のやり方うまくいってる、効率的だ、うまくいっていない、非効率だ、というのは実際手を動かしているチームが一番肌で感じられると思います。やっていて違和感がないことを大事にしながら、これからも適材適所でモブっていきたいと思っています。
