TokyuRuby会議07で働き方について話してきました
TokyuRuby 会議07 で「仕事する時間や場所ってもっと選べてもいいんじゃないか」という主旨の LT をしてきました。
思いがけず LT 王の称号をいただいてしまってだいぶ動揺してしまいましたが、滅多にない機会なので素直に喜ぶことにしました。わーい(∩*´∀｀)∩
賞品としていただいたTシャツとプレモル（の食品サンプル）は大事にします。
桜のお酒は飲むのがもったいないくらいかわいいです。
皆様ありがとうございました！
なぜこの話をしたかったのか
プログラマの仕事の中には PC と回線があれば場所を選ばずできるものも少なくないはずなのに、それを許容している会社さんって少ないよなーなぜなんだろうなーとよく考えています。
そんなに難しいことなのか？と。
自分が実際聞いた、リモート勤務やフレックスに否定的な方の意見は以下のようなものでした。
- 「同じオフィスにいた方が話が早いから」←わかる
- 「目の届かないところでは仕事しないかもしれないから」←うーん
- 「同じ時間帯に同じ場所へ出社しないと一体感がなくなる」←えっ（困惑）
今回は LT タイトルに育児を連想するようなキーワードを入れたのですが、育児中の人に限らず、事情がある人にも特別事情がない人にも、働き方の選択肢がひとつでも増えるといいのになーと思います。
話した内容について
1. 自分の経験談
要領悪い自分でも、働き方を変えたら働けたよって話です。
本当は自分の過去の話をするのは得意じゃないし、好きでもないです。
でもバックグラウンドを話さないと伝わりにくい気がしたので、少し時間を使って自分の話を聞いていただきました。
（悲壮感漂う話は極力端折ったつもりなのですが、しんどかった話とか端折りすぎても話す意味がなくなってしまうし難しいな……）
2. 転職活動の話
転職活動のときに「子供と一緒にごはんを食べられる働き方をしたい」という希望を出していて、協力しますって言ってくれる会社さんは意外とありましたよっていう話をしました。（そう言いつつ内情は……という話を聞いたこともありますが、そういう会社はごく一部だと信じたい）
発表後、クラウドワークスさんと tmix を運営している株式会社 spice life さんからも声をかけていただきました。
確かにクラウドワークスさんはコンセプトがド直球ですよね。
spice life さんが応相談なのは初めて知りました。tmix は素敵なサービスなので、もし求職中だったらぜひ一度お話を伺ってみたかったです。
弊社も勤務時間と場所のご相談、受けますよ！！ #tqrk07
— igaiga (@igaiga555) 2014年3月29日
3. 子供の話
小学生になったら楽になるとか幻想だ！という話です。
乳幼児期に比べれば体も丈夫になり、自分で自分のことができるようになるのでその辺は確かに楽です。
実際一気に楽になるご家庭もあるかもしれません。
でも当たり前だけど親も子供も個人差があるんですよね。
さらに小学校高学年くらいになると思春期突入で難しくなるケースもあります。
あと学校行事な、これも当たり前なのですが平日のお昼前後にあったりします。
会社によっては午前休や午後休では対応できず、丸一日休みをとるか、学校行事に参加しないという選択になるんじゃないかと思います。
育児中の時短勤務なども3歳〜就学前までの会社が多い印象です。
4. リモート勤務の話
結論：やればできるよ！
もちろん個人の向き不向きもあるでしょうし、業務内容によっては難しいかもしれません。
Web 系のプログラマさんでしたら条件が揃えばリモート勤務自体それほど難しくないと思っていますし、条件を揃えるのも比較的難しくないのではと思っています。
LT 中にさらっと話したのですが、数年前に以下のような条件でお仕事させてもらっていたことがあります。
- 雇用形態は正社員
- 受託開発（顧客折衝やチームでの開発あり）
- 週4在宅勤務、週1出社（出社時は早く帰ってよい）
- 会議等、必要に応じて会社やクライアント先へ行く
- 勤務時間は自由（保育園送迎や行事等への参加、家事育児のため）
- 社員間の連絡は内線（SIP サーバを立ててもらい遠隔でも内線が使える状態に）
最初のうちはメンバー間でうまくやりとりできず、要件とズレたものを作ってしまったこともありました。
それでもリズムやコツみたいなものってやっていくうちに掴めてくるんですよね。
子供たちがインフルエンザにかかって1ヶ月まるっと在宅勤務だったこともありましたが、特に問題なく仕事を進めることができていました（と自分では思っている）。
この働き方が実現できたのは、周りのメンバーが協力的でいてくれたことが本当に大きかったです。
数年前と比べると現在はチャットやタスク管理などのツールも充実していますので、環境も整ってきているのではないかと思います。
リモート勤務の話（追加）
最後にリモート勤務の話を少しさせていただいたのですが、緊張しすぎて話したかったことの半分も話せませんでした。人前でお話しするって難しいですね。何回かさせてもらってるのですが未だにまったく慣れません。（皆さん内容も話し方も素敵でしたが、特に飯王の Kwappa さんは LT 3回ともぐいぐい聞かせる感じで改めてすごいと思いました）
ソニックガーデン倉貫さんの記事に私の言いたかった以上のことが書いてありますので、もしリモート勤務に興味があってまだ読んでいない方がいらっしゃいましたらぜひご覧になってください。
サイボウズさんが会社全体で働き方を考えている記事は以前にも拝見していましたが、この規模で実践できているのはすごいなー。
リモートワーク（在宅勤務）を導入するためのポイントと残された課題 | Social Change!
残業はエクスタシー!? イクメン経営者に学ぶ"働き方革命"──フローレンス駒崎代表×サイボウズ青野社長 | サイボウズ式
上の方にも書きましたが、私はプログラマとしても親としても足りない部分が多いです。
仕事でも日常でも周りに迷惑をかけてしまうことが多々ありますが、できることをやっていきたいと思っています。
TokyuRuby 会議って楽しい
最後に。
初めての TokyuRuby 会議でしたが本当に楽しかったです。
発表も食べ物もバラエティ豊かで、特に皆さん手作りのごはんの美味しいことと言ったら！どのお料理も美味しかった…！
プレモルもたくさん飲んでしまいました。
ビールは苦手だったのですがプレモルがきっかけで飲めるようになりました。
サントリーさんごちそうさまでした。
会場の VOYAGE GROUP さん、いつも勉強会などでお世話になっています。
発表するのも楽しいですね。
緊張しすぎて飲み過ぎたり話すことや息継ぎ忘れたりテンパってしまいましたがw
知り合いの方にお会いできたり、発表したことでたくさんの方に声をかけていただけたのも嬉しかったです。
スタッフの皆様、参加者の皆様ありがとうございました！
また次回楽しみにしています。
ハートキャッチプリキュア！の好きなところ
このエントリーは プリキュア Advent Calendar 2013 12月15日分の記事です。
前日のUemmra3さんの記事 はお父さん目線でのエントリーでした。せっかくなので自分も母親目線を交えつつ、ハートキャッチプリキュア！の好きなところについて書きます。
※一部ネタバレを含みます。
※黄色さんと紫さんに言及しちゃうと収集つかなくなりそうだったので今回は控えました。（2013/12/16 追記）
DDD体験ワークショップに参加してきました
PHPカンファレンス2013 で PHPメンターズ さんの『モデルとの向き合い方：ドメイン駆動設計体験ワークショップ』に参加してきました。
PHP メンターズさんの記事と資料はこちらに掲載されています。
http://phpmentors.jp/post/61286646859/phpcon2013-ddd-workshop
ドメイン駆動設計って？
そもそもドメイン駆動設計とは何なのか。
ドメイン駆動設計（DDD）はビジネスドメインの概念をソフトウェアという人工物にマッピングすることです。
ドメイン駆動設計・開発の実践
上記引用元にも出ている Eric Evans 氏の書籍は 「エリック・エヴァンスのドメイン駆動設計」というタイトルで日本語版が出版されています。（この書籍については以降 DDD 本と表記）
500ページ超とそこそこボリュームはありますが、読みやすい本だと思います。
気になっているけど躊躇しているという方は書店で手にとってみるのをおすすめ。
ワークショップ振り返り
以下、手元にある DDD 本と当日のメモでスライドを補完しつつ、ワークショップを振り返った記録。
ドメイン駆動設計は哲学である
スライド - DDD 基礎 - 何であって、何でないか にもある通り DDD とは哲学です。
具体的な手順や実装、プロセスについて語るとき、その哲学や思想も一緒に理解することはとても大事なことだと思います。
また、DDD 本にはこの哲学を議論するための語彙としての役割があります。
哲学、思想を共有するための用語集ですね。
ユビキタス言語とモデル駆動設計
スライド - DDD を俯瞰する - 最重要パターン にはユビキタス言語とモデル駆動設計が挙げられています。
これらの用語について DDD 本には以下のように書かれています。
ユビキタス言語（UBIQUITOUS LANGUAGE）
ドメインモデルを取り巻いて構築され、チームのあらゆる活動をソフトウェアと結びつけるために、チームメンバ全員によって使用される言語。
モデル駆動設計（MODEL-DRIVEN DESIGN）
ソフトウェア要素のサブセットがモデル要素と密接に対応している設計。また、相互に一致した状態を保ちながら、モデルと実装を共に開発するプロセス。
モデリングとは？
モデル駆動設計の「モデル」というのは一体何なのか。
これは スライド - モデリングとは？ で説明されています。
モデルの説明を読んでいると概念とか抽象化とか出てるけど、じゃあモデリングと設計って何が違うの？という疑問も出てきますが、それは スライド - モデリングと設計の違い に書かれている通り。
モデリングは設計書作成の手がかりなんですね。
イテレーションをぐるぐる回していくうちにこれらは洗練されていきます。
ドメイン辞書をつくる
要件からユビキタス言語を抜き出し、ユビキタス言語をまとめた辞書（ドメイン辞書）を作成します。
辞書作成時に留意する点は スライド - ドメイン辞書 にまとめられています。
スライド - ドメイン辞書(2) にあるのはドメイン辞書の一例です。
あくまで一例であって、唯一の答えではありません。（くどいけど大事なことなので二回書いとく）
ドメインモデルを表現する
ドメイン辞書を作成したら、次は スライド - ドメインモデル を参考にモデリングしてみます。
最初からがっちりしたものを作る必要はなく、 略式 UML（UML っぽいもの）や付箋紙 CRC から始めるそうです。今回は略式 UML でやってみます。
ここで表現するのはあくまで概念であって、実装ではないです。
要件を聞くとつい「こーいうテーブルを作成して…」とか「あーいうページ遷移で…」とか具体的な実装が頭をよぎりがちですが、ここではいったん忘れます。
大事なのは概念を抽象化して表現することです。
下記は略式 UML によるドメインモデルの一例です。
一例であって正解では（以下略
ユースケースを考える
ユビキタス言語、ドメインモデルを作成したら次はこれらの検証を行います。
スライド - ユースケース
ユースケース作成の際、スライド - ユースケースのレイヤー にも注意します。
ドメインユースケースではサービスが起点となり、主語がサービスになります。
ユースケースを考えたときにドメインモデルに違和感を覚えることもあるかもしれないですし、ドメインモデルを作成する段階でユビキタス言語に不足を感じることがあるかもしれません。
気になった点などを確認しながら、ドメイン辞書（ユビキタス言語）→ドメインモデル→ユースケース→ドメイン辞書…とぐるぐる回していきます。
体験してみて
DDD 本を読んでいるだけだといまいち「実際どうやって適用するか」というところがピンと来なかったのですが、今回体験してみてこの辺りが少し見えてきたように思いました。
足踏み状態から一歩前に踏み出せた気がしています。
あと、参加して改めて感じたのが PHP メンターズさんのメンター力の高さ。
参加前は何も分かっていないふわふわな状態でも、参加後には何かを得たと思えるような。
Symfony 勉強会のときもそうだったのですが、導入としてまず「哲学や思想を共有する」という方法は素敵だなーと思っています。
ワークショップには参加できなかったけど DDD に興味がある方、スライドを見ながらぜひ実際に手を動かしてみてください。
PHPカンファレンスのこと
PHP カンファレンスは昨年に続いて2回目の参加。
今回もとても充実した楽しい時間を過ごすことができました。
数百人の方が訪れるとても大きい規模のイベントですが、進行も非常にスムーズで大きな問題もなく素晴らしいイベントでした。
スタッフの皆様、スピーカー・ワークショップ担当の皆様、本当にありがとうございました！
2013/09/18 14:28 追記：
「体験してみて」に表示していた画像を修正しました。
修正前の画像には「哲学だけではご飯は食べられない」というネガティブな表現が含まれていて、「DDD は哲学 → 哲学はご飯食べられない → DDD は役に立たない？」と誤解されかねない表現でしたので少し補足します。
まとめで言いたかったことを3行でまとめると以下になります。
- 哲学だけでは解決できない問題が多々ある
- 哲学を実際の現場なりシステムなりに適用するための、具体的な方法が欲しい
- 今回 DDD でその方法を知ることができてよかった！
今回 DDD 体験ワークショップを通して、DDD の哲学を具体的な手段に落とし込むためのひとつの方法が得られたように思っています。
哲学を手がかりにしてどのように問題を解決していくか。
哲学を元にどのような手段、プロセスを作っていくのか。
なので最終的な答えとしては「DDD は現場で使えるもの（ご飯が食べられる！）」です。
