優先度付きキューと二分ヒープ

AtCoderのABC第141回のD問題はmaxヒープを使うことで簡単に回答できます。

優先度付きキュー（priority queue）とは、各要素に優先度をつけて、優先度の高いものから順番に要素を取り出すという抽象データ型です。

優先度付きキューの実装方法の1つに、二分ヒープ（Binary Heap）というデータ構造があります。

二分ヒープでは、要素の挿入・削除はO(log n)で、先頭のノードの値の取得はO(1)で行うことができます。

maxヒープを使うと、計算量O(1)で最大値を取り出すことができるんです。

しかもPHPでは、このmaxヒープをライブラリを使うことなく手軽に使うことができます。

「SplMaxHeap」はPHPで手軽にmaxヒープを扱うためのクラス

PHPではmaxヒープを利用するためのSplMaxHeapというクラスがあります。

使い方を見てみましょう。

<?php

$numbers = [2, 5, 9, 4, 6];

// ①SplMaxHeapクラスのオブジェクトを生成しています
$heap = new SplMaxHeap();

foreach ($numbers as $n) {
    // ②値を$heapに格納していきます
    $heap->insert($n);
}

// ③heapにノードがあるかを調べ、ある場合はtrue、ない場合はfalseを返します
while($heap->valid()) {
    // ④ heapの先頭からノードを取り出します
    echo $heap->extract() . ' ';
}

// 出力
// 9 6 5 4 2

以上が基本的な使い方です。

また、先頭のノードを常に最小値にするminヒープを使う場合は、SplMinHeapを使います。

PHPにはSplPriorityQueueクラスもあります。

ただ、値をinsertする際に、実装者は値の優先度を決める必要があります。

Python, Rustでもmaxヒープを簡単に扱える

Pythonではheapq、Rustではstd::collections::BinaryHeapを使って手軽にmaxヒープを扱うことができます。

各プログラミング言語では複雑なアルゴリズムを手軽に扱うことができるように、便利なクラスやモジュールが実装されているんですね。

だいぶ知ったつもりでいましたが、まだまだPHPも掘り甲斐があると思いました。

プログラミングコンテストのチャレンジから得た学びでした。

「経験学習の理論的系譜と研究動向」より引用。

プログラミング学習における写経とは

プログラミング学習において、自分が慣れていない言語のサンプルコードをそのまま書き写すスタイルは写経と呼ばれています。

この写経について、有意義な学習方法だと考える人もいれば、学習効果はそれほど大きくないと考える人もいます。

自分でも興味を持ったプログラミング言語を学ぶ際は、いつも公式のチュートリアルを写経しています。

そもそも人が新しいことを学ぶプロセスとは、どのようなものなのでしょうか。

コルブ氏の「経験学習」における循環型モデル

物事は推測や個人的な経験からではなく、データや事実といったファクトから思考することが重要です。

これにより、前提を誤ったり間違った概念化をしたり、あるいは十分に議論されてきた概念を再発明することを避けることができます（このことは「ファクトフルネス」という本が詳しいです）。

そこで、人の学習についてGoogle Scholarを使って検索すると、アメリカの教育理論家であるデイビット・コルブ氏の経験学習という学習モデルを要約しているパンフレットがありました。

経験学習モデルでは、学習はサイクルであると仮定します。

曰く、具体的経験、内省的観察、抽象的概念化、能動的実験という4つのフェーズが循環しているという学習モデルです。

以下の経験学習の内容は経験学習の理論的系譜と研究動向というパンフレットから引用しています。

具体的な経験を省察して抽象化して教訓を得る

具体的経験

具体的経験は以下のように定義されています。

学習者が環境（他者・人工物等）に働きかけることで起こる相互作用

自分が環境を変化させるような行動をとってみる、ということですね。

仕事に当てはめると、まずはアウトプットを出してみた、というフェーズに当たります。

内省的観察

この具体的経験をしたのち、次は内省的観察のフェーズに移ります。

ある個人がいったん実践・事業・仕事現場を離れ，自らの行為・経験・出来事の意味を，俯瞰的な観点，多様な観点から振り返ること，意味づけること

内省的観察は、「内省」や「反省的思考」と呼ばれることもあります。つまり、経験を振り返ることです。

振り返りと言っても、その対象は「仕事の出来栄え」や「仕事の出来栄えを左右するプロセス」です。

その対象と程度としては「ある状況下の個人の行動・振る舞い」、「ある個人が存在している前提・状況、あるいはその個人に作動している権力や社会関係」など様々です。

プログラマに当てはめると、前者は自分の書いたコードの良し悪しという成果物や、バグが多いシステムに対してバグの混入率を減らすためにテストコードを書いていこうというプロセスの話ですね。

後者は、そもそもバグを含む可能性があるコードをデプロイせざるを得なかったのはリリース日が決まっていたのでとても焦っていたからであるという状況が想像できます。

あるいは、そもそもエンジニアが工数を見積もる際にビジネス側から「これくらいの機能ならもっと早くリリースできるでしょ」と言われ、社内ではエンジニアがNoと言えない力関係であるというようなケースです。

抽象的概念化

次のフェーズは抽象的概念化です。この定義は以下のようなものです。

経験を一般化，概念化，抽象化し，他の状況でも応用可能な知識・ルール・スキーマやルーチンを自らつくりあげること

振り返りの内容を抽象化することにより、他の場面でも応用可能なルールを作り上げることです。

前出の例を続けると、そもそも同じエンジニアでも正社員やフリーランスという切り口から考えることが挙げられます。

また、出社が必須の時とフルリモートで働く時の社内コミュニケーションの取り方の違いなど、大きな切り口から自分の経験を捉え直します。それにより、深い考察ができるようになります。

能動的実験

最後に能動的実験のフェーズがあります。

これは、前段階で構築した理論を実践することです。

この実践が経験になり、その経験を振り返る。そして、また自分なりの新しい理論を構築する、あるいは既存の理論を修正することが経験学習における学習モデルです。

プログラマにおける経験学習の例

プログラマの例を続けると、以下のようなケースを想定できます。

具体的経験：コードをデプロイしたが、バグが混入していたので切り戻しをした
内省的観察：そもそもデプロイ前にバグを検知することはできなかっただろうか
抽象的概念化：アプリケーションにおけるバグには、実行時エラーというものがある
能動的実験：デプロイ前に必ずテストコードを書いて、アプリケーションを実行するようにする

抽象的概念化が４つのフェーズで最も重要

自分は経験学習の４つのフェーズのうち、３つ目の抽象的概念化が最も重要だと考えています。

上記の例では実行時エラーを予め回避するためにテストコードを書くという結論を出しています。

しかし、他にも考え得る選択肢は存在します。

例えば、その実行時エラーの内容があるクラスの存在しないメソッドを呼び出していたというものであるとします。

この場合、抽象的概念化のフェーズにおいて、運よく静的解析という概念があることを知ることができたとします。

すると次回はコミット時に静的解析ツールを走らせるようにするとか、IDEを使うであるとか、そもそも静的型付け言語やコンパイラを使う言語を使って開発するというアクションを選ぶことができます。

プログラマにとって写経は是か非か

自分は写経をすること自体はニュートラルだと思っています。

しかし写経という経験をした後、振り返りや抽象的概念化、または次のアクションを怠っていると写経の学習効果は薄いのでしょう。

新しい言語や構文を写経する中で、文法や背景にある概念やプログラミング言語の歴史的変遷を調査することで、学習効果は大いに高まります。

抽象化の果てには、知的に刺激的な問題にまでたどり着き、実験的な行動に移ることができることでしょう。

動的型付け言語は実行時エラーがある
→ 静的型付け言語を写経して学ぶ
→ コンピュータに型を教えてあげなければならない
→ 現実世界ではモノに型なんてないのに、コンピュータに扱えるデータの型は限定されている
→ 現実世界のモノ（オブジェクト）をコンピュータで再現するために、どのようなモデルを作ればいいのだろうか
→ アラン・ケイによるオブジェクト指向の定義を調べる
→ オブジェクト指向言語の見方、書き方が変わる

終わりに

今回はコルブ氏の経験学習という学習モデルの切り口からプログラミングにおける写経の意義を考えました。

写経以外にも、仕事で振り返りを行ったり、日報を書く機会があれば、具体的経験、内省的観察、抽象的概念化、能動的実験という4つのフェーズを意識してみてくださいね。

2019/12/1に開催されたPHP Conference Japan 2019に参加しました！

弁護士ドットコム株式会社は、PHPカンファレンスのプラチナスポンサーです。当日はブースを出しており、たくさんの方にお越し頂きました！

以下では、私が参加したセッションについてレポートを書いていきたいと思います。

MVCにおける「モデル」とはなにか - 天重誠二

まず、「MVCにおける「モデル」とはなにか」というセッションに参加しました。登壇者は弊社テックリードの天重（@tenjuu99）です。

https://speakerdeck.com/tenjuu99/what-mvc-is

この講演は、トリグヴェ・リーンスカウク博士が考案したMVCの考え方を通して、コンピュータと人間の関わり方を探求するセッションです。講演内容は「ドメインモデル」「メンタルモデル」「パーソナルコンピュータ」「MVCとは何か」という4つのセクションに分かれています。 「デザイン」「ユーザー」「社会」「個人」「分散情報システム」など根底にあるテーマが非常に多岐にわたるので、要点のみ紹介します。

ドメインモデルについて天重は、「ドメイン駆動設計 ～ユーザー、モデル、エンジニアの新たな関係～」という杉本氏のスライドを引用し、ドメインとドメインモデルを区別します。ドメインをビジネス、つまり目的であり、ドメインモデルをドメインに対する情報処理の手段であると考えます。ドメインモデルは情報処理の手段なので、ITシステムに限った話ではなく、飲食店であれば複写式伝票や自動券売機などがあることを例に挙げます。

また、メンタルモデルという概念はドナルド・ノーマン氏の「誰のためのデザイン？—認知科学者のデザイン原論」という本をきっかけに広まったことを紹介します。メンタルモデルは「頭の中にある、ああなったらこうなるという行動のイメージを表現したもの」であり、さらにノーマンの言葉を引用し、ソフトウェアデザインにとっては「人が作業そのものに没頭し、コンピュータを使っているという意識がなくなるソフトウェア」が重要と語ります。

次に「パーソナルコンピュータ」について、ダイナブックを引き合いに出します。ダイナブックとは、アラン・ケイが考案した個人向け（パーソナル）コンピュータです。ここでは、アラン・ケイが、ダイナブックを使う人たちを想定した架空のエピソードが紹介されます。

「9歳のジミーとベスがダイナブックの宇宙船ゲームで遊んでいる。ジミーはゲームに負け惜しみのようにに、『宇宙船の動きが太陽の重力を無視して不正確なんだ』とベスに話す。二人は図書館で宇宙について調べた後、プログラムを修正して再び宇宙船ゲームを始める」（「A Personal Computer for Children of All Ages」より抜粋・筆者による要約。日本語訳はこちら。）

そして、パーソナルコンピュータを使って、ユーザーが自分でシステムを書き換えることが重要だと話します。

このセッションを通して、天重はシステムと個人の関わり方を語りました。ドメインモデルについて、ドメインと情報処理手段であるドメインモデルの関係を語り、メンタルモデルについて、ユーザーが作業に集中することができるためには、コンピュータを操作している意識がなくなるシステムが理想であり、そのためにはユーザーイリュージョンが必要だと語りました。

また、パーソナルコンピュータについて、「理想的なMVCのソリューションは、ユーザーがドメインの情報を直接見て操作するという、ユーザーイリュージョンをサポートすること」というリーンスカウク博士の言葉を引用して、人間が作業に使用するシステムは、限られたソフトウェア開発者のみではなく、ユーザー自身によって容易に改変可能であることが理想であると語りました。

なぜユーザーがシステムを改変できることが重要なのか。それは、社会（会社）が個人（社員・作業者）に業務を行うためのシステムを一方的に押し付けることになると、人間がコンピュータに行動を規定されてしまい、「仕事の楽しみ」が奪われるからです。

私は、ここでのシステムを「業務マニュアル」と読み替えてもいいと思います。マニュアルから逸脱した行動を一切許されない場合、仕事を楽しむことは難しいでしょう。

この講演は、テーマが多岐にわたり、ソフトウェアに対して非常に示唆に富むセッションでした。

「弁護士ドットコム」を作り続ける開発組織について

https://speakerdeck.com/bengo4com/about-bengo4com-development-organization

弊社テックリード狩野による発表です。

弁護士ドットコムという会社・事業から話は始まります。弁護士ドットコムというプロダクトは10年以上PHPで開発されており、PHPファイル数は約5000、コードの行数は約55万という大きなシステムです。

組織について、弊社では組織体制が機能別から事業部制になり、さらに現在ではマトリクス型の組織に発展したことに触れ、その時々で発生する問題に対して組織体制を柔軟に変更してきたことを説明しています。技術についても、サービスを成長させることを軸に、基盤部分は堅実に、新規案件ではチャレンジした技術を採用していると述べます。例えば、新規案件でPHPフレームワークであるBEAR.Sundayを使っているシステムもあります。また、技術レベル向上のため、社外向け勉強会を開催したり、書籍購入制度を整えていることを語りました。

また、現在はマネージドサービスの活用も進めていることにも触れ、SREチームを中心にインフラの民主化に向けて動いており、アプリケーションエンジニアでもインフラの設定を行えるようにして、ボトルネックの解消を目指していると述べました。

さらに、弊社では毎週金曜日はTech Focus Dayという名前で20%ルールを運用しています。これは一般的な20%ルールとは少し違い、エンジニアがミッションを持ったチームとなって改善活動を行っていると語りました。 この日はエンジニアは技術的負債の返済、サイトの価値向上に取り組む日としていることを説明しました。

最後に社員のマインドセットについて語っています。それは、ビジネスを行うにあたり「覇道より王道」を掲げ、一人勝ちではなくwin-winになるようなことを重視しているというものでした。また、弁護士ドットコムでは何より人を大切にしているという話で締められました。

講演後には、参加者から「Tech Focus Dayでの具体的な成果を教えてください」という質問がありました。これには「サイトの表示速度の改善をすることができました。これによりSEOも良くなり、エンジニア以外の方ともメリットを共有することができました」と答えていました。また、狩野曰く、「サイトの表示速度改善は、エンジニアの視点から負債解消の必要性を発信した例であり、単に負債を解消するだけではなく、サービスとしてユーザーに価値を提供できた好例です」 とのことでした。

PHPUnit: Past, Present and Future - Sebastian Bergmann

（当日の資料はこちらから見ることができます）

このセッションでは、Sebastian氏がプログラマになろうと思ったきっかけや、PHPのバージョンアップとともに歩んできたPHPUnitの歴史が語られました。

PHPUnitの最初のレポジトリには6ファイルしかなく、開発を一歩ずつ進めてきたことや、Xdebugの作者の方とたまたま同じ職場になり、しかもご近所同士だったので、互いのコードをレビューし合っていたというエピソードが披露されました。

その他、今までPHPUnitにはロゴはありませんでしたが、PHPUnit8をリリースするとともに、ついにロゴを作成したそうです。

また、「いつPHPUnitを開発しているのですか」という質問に対しては、「開発は週末だけにしていて、普段は旅行をして過ごしています。OSSの作者によくある燃え尽き症候群を避けるためです。PHPUnitのようなOSSは多くのプロダクトに使われるが故に社会的責任を負っており、開発を止めてしまうようなことがあってはならないと考えているからです。自分はOSS開発にはお金という見返りを期待していません」と答えておられました。

REST 6+4の制約  - 郡山昭仁

PHPフレームワークのBEAR.Sunday作者であり、弊社技術アドバイザーの郡山のセッションです。

ロイ・フィールディング氏の論文で提唱されたRESTのアーキテクチャの誤解を説明します。フィールディング氏の論文について、誤解が広まってしまってました。本来REST APIはいいURLや/v1、/v2などAPIのバージョニングとは無関係のものです。REST APIとはハイパーメディアAPIであると説明し、WebとRESTの関係を語ります。

Webが成功した理由は、「サイト制作の参入障壁が低いこと」「サーバーとクライアントが独立しているため、拡張性があること」「サーバー同士が通信をする分散ハイパーメディアの構成であること」「インターネット上でスケーラビリティがあること」であるとしています。RESTはそのうち、ハイパーメディアであり、拡張性があり、インターネット規模にスケールできることを共通点としていると語ります。

また、RESTは下記に挙げる6つのアーキテクチャ制約と、4つのインターフェイス制約があるとしています。各項目の詳しい説明は動画をご覧ください。

講演の最後に郡山が「新しい技術は大切だが、ソフトウエアの進化は層を成してきた。過去の遺産を塗り替えたり置き換えたりするのではなく、積み重ねていく技術の継承が重要だ。 偉人達が築き上げてきたものを学ぶことは大きな意味あり、未来に向かっていく事でもある」と語っていたことがとても印象的でした。

まとめ

今年のPHPカンファレンスでは、「英語のセッションを増やす」というチャレンジをしたそうです。また、PHPに限らず、様々なテーマのセッションがありました。学びがとても多く、来年もぜひ参加したいと思います！

弁護士ドットコムでは共に働く仲間を募集しています！興味を持たれた方はまず弁護士ドットコム主催の勉強会に遊びに来てください！

開発合宿を開催しました

2月8〜9日に弁護士ドットコム初の開発合宿を行いました！

「開発合宿をしてみたい」という声が社内から上がり、CTO、VPoE（*1）の後押しを受けて開催が決定しました。今回の開発合宿の特色は、どのような職種でも参加可能としたことです。その結果、エンジニアだけではなく、ディレクター、デザイナー、編集者(*2)と、様々な職種の方が参加し、参加者は総勢13名となりました。

(*1) Vice President of Engineering。エンジニアの採用、育成、組織体制の管理を担当する役職。弁護士ドットコムではCTOが技術面で組織をリードし、VPoEがエンジニア全体のマネジメントを担当する体制が構築されている。
(*2) 弁護士ドットコムは「弁護士ドットコムNews」「Business Lawyers」といった自社メディアを運営しており、記者、ライター、編集者も在籍している。今回参加したのは「Business Lawyers」の編集者。

合宿の目標は、「各チームで業務上の課題を洗い出し、その課題を解決するプロダクトを作ること」としました。ゼロから開発を始めるという意味で、ハッカソンと同じような企画なのですが、優勝チームを決めることはしませんでした。今回は様々な職種の方が参加しており、参加者の職種による有利不利があるとフェアではないためです。

（合宿に参加したメンバーの集合写真）

合宿所の紹介

合宿を実施する場所については、「DGCAMP 鎌倉」を利用することにしました。鎌倉駅でタクシー運転手の方に「DG CAMPまで」と伝えると10分ほどで到着します。建物一棟の中に作業スペース、食堂、宿泊エリアがあり、どのエリアも内装は清潔で、手入れが行き届いています。

（作業スペース）

作業スペースは、大きな窓から海が見える場所にあり、気分良く開発ができます。ハニカム構造のテーブルや天井から垂れ下がるコンセント、カラフルな椅子など、おしゃれなコワーキングスペースでした。Wi-Fiも高速で動作し開発作業には申し分ない環境です。

寝室も海が見える和室で、大人3人だとスペースが余るぐらい広い部屋でした。開発に集中できる環境が整っていて、素敵な合宿所だと思います。

合宿前の準備

合宿1週間前にオリエンテーションを開催。参加人数が13名のうち、エンジニアは6名（CTO含む）、デザイナーは4名です。このため、各チームには最低1人はエンジニアとデザイナーが入り、4チームに分かれることになりました。

また、合宿当日のスケジュールや持ち物は旅のしおりを作るアプリ「tabiori」上で共有することに。tabioriのおかげで細々とした事務連絡や情報共有がスムーズに進みました。

合宿までの1週間、各チームは時間を見つけてミーティングをし、合宿当日に何をするかを決めていました。課題発見や解決のアプローチについて、各チームそれぞれの個性が出ていました。

・チームPassione：多忙なチームメンバーの会議の調整を簡単にする
（デザイナー、エンジニア（2名））
・チームB：Laravelを使ってみたい！を出発点とする
（デザイナー、エンジニア（2名））
・チームVPoE：会社の本の貸出管理を楽にする
（VPoE、エンジニア、デザイナー、編集者）
・チームCTO：会社の日頃の課題を解決する
（CTO、ディレクター、デザイナー）

自分が所属するチームPassioneは、他の会社の開発合宿の振り返り記事を参考にして、開発環境の構築、周辺の飲食店事情の調査を事前に済ませておきました。これによって開発合宿では考えることや議論を少なくして、手を動かすことにフォーカスすることができました。

合宿1日目

当日は金曜日の12時に会社のある六本木を出発し、目的地である鎌倉に電車で向かいました。鎌倉駅からタクシーに乗ると10分ほどで合宿所に到着しました。施設の利用説明を受けた後、荷物を宿泊エリアに置き、各チーム開発スタートです！

（作業風景）

どのチームも作業に集中したり息抜きをしたり、オン・オフを切り替えており、総じて和気藹々とした雰囲気で作業を進めていました。スケジュール上、初日の開発は20時に終了でした。その後、周辺の飲食店に食事に行くメンバーもいれば、宿泊エリアに移ってキリのいいところまで開発を続けているメンバーもいました。

合宿2日目

起床後、朝9時に朝食を食べに施設内の食堂へ。朝食は和食で、特にメインのシャケの塩焼が美味しかったです。食事前に朝風呂を浴びたり、部屋で開発を始めている強者もいたようです。

（みんなで朝食を食べているところ）

そして10時から開発再開。成果発表の時間は15時ですが、それまでに完成するか不安と戦いながら手を動かし続けます。

開発スタイルにはチームの特色が出たと思います。成果重視で普段慣れている技術を使ったチームはサクサク開発していました。Laravelを使うチームでは、業務でLaravelを使っているメンバーとLaravelを触ってみたいエンジニアの二人でペアプログラミングをしたとのこと。編集者の方がいるチームでは、プロダクトを使うユーザーのストーリーを深く考えていました。自分のチームはON/OFFの切り替えを重視し、初日に2回、2日目に1回の計3回風呂に入りました。2日目にあと一度入りたかったです。

（寝室でも作業をしました）

成果発表

緊張の成果発表です！

・チームPassione

メンバー：エンジニア（2名）、デザイナー
プロダクト：「予約将軍」
ターゲット：同じチームのデザイナーマネージャー
課題：マネージャー自身の予定が埋まりすぎていて、メンバーとの会議の日程調整に時間がかかってしまう
解決策：Amazon Echo dotに「アレクサ、会議の予約」と話しかけて会議のメンバーを伝えると、そのメンバーのGoogleカレンダーを調べて全員が空いてる時間を教えてくれる。予約もしてくれる。話しかけるだけで済むので、複数人の日程調整に時間がかからない
技術：Alexa Skills、AWS Lambda(Node.js, Python), Google Calendar API（Calendar）

メンバーの声「Alexaでボサノバを流しながら楽しく開発できました！合宿前にAlexa SkillsやLambdaの開発環境を準備していてよかったです」

・チームB

メンバー：エンジニア（2名）、デザイナー
プロダクト：「events」
ターゲット：寂しがり屋のチームメンバー
課題：社内イベントや勉強会の存在を開催後に知ると、自分も参加したかったなとプチ寂しい
解決策：社内のイベントを一覧可能に。イベントを知ってすぐに参加できる。connpassのようなアプリケーション。会社のGoogleアカウントでログインできる。プロダクトのメインカラーは親しみを感じるイエロー
技術：Laravel, Apache, MySQL, SCSS

作成したデザインカンプは公開しています！（「events」デザインカンプ）

・チームVPoE

メンバー：VPoE、エンジニア、デザイナー、編集者
プロダクト：司書の「しおりさん」
ターゲット：本の貸し出し管理に時間をかけたくない人（エンジニア・デザイナー）
課題：本の貸し出し管理をスプレッドシートで行なっている。ただ、貸し出し日と自分の名前を記入するのが面倒。また、借り手がエクセルに記入をしていないことがあるため、借りたい本がないときに、誰が借りてるのかわからないことがある
解決策：Slackで特定のコマンドを打つと、「しおりさん」がスプレッドシートに貸し出しの書き込みをしてくれる。これでいちいちスプレッドシートを見に行く必要がなくなる。セリフのバリエーションが豊富。「esaやブログであなたの感想を読むのを楽しみにしていますね」など一言かけてくれる
技術：Google Apps ScriptとSlackの連携

（しおりさんの紹介スライド）

キャッチコピーは「技術書をもっと身近に」
（弊社の企業理念は「専門家をもっと身近に」です😊）

こんな一幕もありました。

しおりさん：「現在購入済みの書籍一覧だ(ﾟДﾟ)ｺﾞﾙｧ！」
→[差替]しおりさん：「いま所蔵している本の目録はこちらです。」
（以下会社で所蔵する数百冊の書名リストが表示される）

・チームCTO

メンバー：CTO、ディレクター、デザイナー
プロダクトその１：「日めくり社員カレンダー」
ターゲット：弁護士ドットコム社員全員
課題：社員が約200名にまで増え、顔と名前を一致させるのが大変
解決策：毎日ランダムで社員1名の自己紹介と顔写真をSlackのgeneralチャンネルに投稿
技術：Google Apps ScriptとSlackの連携

プロダクトその２：「シャッフルランチ(3*)リーダーbot」
ターゲット：弁護士ドットコム社員全員
課題：シャッフルランチのリーダーに選ばれると日程調整と店選びが大変
解決策：シャッフルランチのメンバーを自動で選定。SlackでDMのグループを作成し、会社に近い候補の店をランダムで4店舗紹介。メンバーの投票で店を決める。場所が決まると「ランチを楽しんできてね！」というオリジナル画像が投稿される。リーダーは日程を決めるだけ。
技術：こちらもHubotでSlack連携

(*3)シャッフルランチとは、毎月ランダムに社内のメンバー4名とお昼ご飯を食べる弊社の福利厚生制度。費用は1人当たり1,620円（税込）まで会社が負担する

（マスコットキャラ「ほうすけ」が雰囲気を盛り上げてくれる）

デモでは「さすがCTO！」という声も飛んでいました。

総評

全4チームともちゃんと動作するところまで持っていきました。VPoE川合さんから「開発合宿は初めての開催だったのに、これはすごいことだ」とお褒めの言葉を頂き、一同大喜びです！

普段業務では違う部署、違うチームのメンバーと話しながら開発ができたのはとてもいい機会でした。課題に対するアプローチも違い、自分にない視点からの意見を聞くことで、とても勉強になりました。また、どのチームもいいプロダクトができたと思います。とても実りの多い２日間でした！

（発表したスライドは本文中で公開しています）

・TwitterのDMでLT登壇の誘いを受けた（テーマは「サーバーサイドエンジニアあるある」）
・自分は「エンジニアが人に言われること」という内容で発表した
・会場の雰囲気やLT登壇という実践からしか得られない学びがあった

弁護士ドットコムでエンジニアをしている@Panda_Programという者です。自分がエンジニアに転職してからもうすぐ一年が経とうとしています。

そんな折、去る11月22日に、初めてLTの登壇をしました。

https://www.wantedly.com/companies/andfactory/post_articles/144961

事の始まりは一通のDMから

LT登壇のきっかけはTwitterで届いた一通のDMでした。

何気なくTwitterを開いたら新着DMの通知。送信元はand factory（アンドファクトリー）さんでした。内容は 「エンジニア同士の交流のために、LT未経験やエンジニア経験が浅い方向けにイベントを開きます。そこでぜひLTに登壇してみませんか」 というものでした。

LTというのはLightning Talksの略で、カンファレンスやフォーラムで行われる短いプレゼンのことです。

エンジニアがLTを行う場合、自分の使っている技術のこぼれ話や身の回りで起きた面白いことを5分程度で発表するもの、と自分は認識しています。普通のプレゼンと比べると軽めな内容が多いですが、5分で参加者の方々の印象に残る良いLTをするためには、それはそれで技術が必要だと思います。

前回は「若手エンジニアLT - スマホアプリ開発あるある編」というテーマで行ったとのこと。写真を見ると確かに年齢層が比較的若いように思います。レポートを読み、会場の和気藹々とした雰囲気を見て「マサカリは飛んで来なさそうだ」と思ったこと、今回のテーマは「エンジニアあるあるLT 〜 サーバーサイドエンジニア編」 ということで自分にも話せそうだと思い、ぜひ参加させてくださいと手を挙げました。

イベント当日の風景（引用元:「and factory勉強会」）

発表内容、どうしよう？

参加表明をしてみたものの、何分初めてのことなので、皆さんに楽しんでもらい、かつ心に刺さり、有意義であったと思ってもらえる内容にするためにはどのようなものにしようかと考えていました。「サーバーサイドエンジニアあるある」という身近なテーマであるため、他の方の発表内容が被る可能性もあります（結果、これは杞憂でしたが）。

方針をいくつか検討し、結局「『エンジニアなら機械学習やらないんですか？』など、自分が人からよく言われること」という方針にしました。方針が決まった後は、「あるある3つ+番外編」の構成にすること、説得力を持たせるために自分の経験と客観的なデータを入れること、参加者に何か持ち帰って貰うために 「こう言われたらこう言えばOK」という切り返しを入れること はすぐに決まりました。ここまでくれば後は手を動かすだけです。

発表前日の夕方頃、仕事に区切りをつけてスライドの仕上げをするために22時ごろまで残っていました。上司が「大丈夫？仕事が溜まりすぎてるんじゃない？」と声をかけてくれました。周りを見渡すと自分を含めて本社には片手で数えられるほどしか人がいません。上司に事情を説明すると「そうなんだ。面白いこともあるもんだね。頑張ってきて！」と声をかけて貰いました。これで当日も大丈夫そうな気がしました。

そして、発表当日

発表当日、会場はand factoryさんの本社。場所は渋谷の道玄坂を登り切って、池尻大橋方面へ少し歩いた所にあるビルでした。明るくて綺麗な部屋で、アウェイ感に結構緊張してしまいました。

会場の入り口で参加証と乾杯用のビール、そして「あるある札」を受け取りました。「あるある札」は人が発表しているときに「あるある」と共感したら挙げる札です。

あるある札と乾杯用の飲料（引用元:「and factory勉強会」）

「あるある札」によって発表が登壇者と参加者の相互的な交流になり、若手のLT登壇者を勇気づけることができるのだ、と説明を受けました。これはとても良い仕組みだと思います。他の方の発表中、自分もかなり挙げました。

全体の人数はスタッフの方を含めて30名ほどで、今回は自分を含めた8名が登壇するとのことでした。

イベントが始まってみると、他の方が発表する「あるある」には頷かされたり、知らないことを知るきっかけになりました。例えば、「DBをコマンドで操作すると失敗につながるから、出来るだけGUI（画面上）で操作を行うようにしている」 こと、 「エンジニアが本番環境（ユーザーが利用しているプロダクトが動作しているサーバー）で作業をするときは、指差し確認をするとミスの数が６分の１にまで下がる」 ことや、 「Go言語にはtry~catch構文がなく、またエラーが起きても発生箇所がわからない（他のプログラミング言語では、コードでエラーが起きている箇所が表示される）」 など、大変面白く有意義な話をされていました。

さて、発表の順番が回ってきました。話している間は夢中でしたが、振り返ってみるとあるある札が結構挙がっていたので、喜んで貰えたかなと思いました。

https://www.slideshare.net/MashuKushibiki1/laravelreact

(発表内容は個人の意見であり、自分が所属する企業とは無関係です)

かなり情報を盛り込んだので早めに話したものの、結局５分では終わらず主催者の方にご迷惑をおかけしました。スライドの最後まで待って頂き、本当にありがとうございました。今回の発表を通じて、「5分は思ったよりかなり短い」と学ぶことができました。

終わりに

その後の懇親会も盛り上がり、とても有意義でした。ピザとアルコールを用意して頂き、参加者の若手メンバーやベテランの方々とテーブルを囲んで今ホットな技術や仕事の話をしました。

年齢や立場の違う人が垣根を超えて同じ技術の話で盛り上がり、所属企業や技術レベルに関わらず、わからないことがあればベテランが丁寧に教えてくれることはエンジニアの誇れる文化だと思います。

またこのような機会があればフットワーク軽く参加してみようと思います！