謎の制度プレミアムフライデー始まる

プレミアムフライデーという謎の制度が始まったようである。

会社では何も話題になっていないが、商魂たくましい店舗で何かとプレミアムフライデー限定サービスを謳っていて存在に気付かされる。

go.jpドメインのサイトもあるようだ。
https://premium-friday.go.jp/

しかしながら、国のこういった取り組みを伝える難しさは解決できるものだろうか? テレビもTwitterも見ないと話題にならないと知るきっかけがない。法律の変更などの情報を伝えてくれる国営のメールニュースがあるならアドレスを登録したいものだけど・・・実はこれも知らないだけで存在していたりするのだろうか、聞いたことが無いが。

NHKの番組のメルマガはあるが番組のメルマガなので国のニュースという目的では無さそうだ。
厚生労働省のメルマガがあり、プレミアムフライデーは厚生労働省のニュースでカバー出来たかもしれない。ただ他の省管轄のニュースは拾えるのだろうか?

話はそれたが、裁量労働制(フレックス勤務)で働くエンジニアにはプレミアムフライデーは比較的適応しやすい取り組みなので試してみようかと思う反面、「いつ帰るかは俺が決める、国が決めるな。」という天邪鬼思案も浮かぶ。というわけでオレオレプレミアムデーを別につくっても良いかもしれない。

gacco

無料で学べる大学講座というオンラインサイトで統計学を勉強した。
http://gacco.org/

何をキッカケにこのサイト・講座を見つけたのか覚えていないが、なかなか真面目な講義内容が受講できる。どういう収益構造になっているのかは不明だ。

本サービスは、JMOOC(日本オープンオンライン教育推進協議会)および FLIT(反転学習社会連携講座)と連携して推進しているgaccoプロジェクトにより、ドコモgacco社が提供しているものです。
gaccoプロジェクトは、オープンなオンライン教育環境の実現に必要な本格的な基盤サービスの提供を通じて、 受講生にとって付加価値が高い新たな学習モデルを開発することを目指しています

講義は

  • 社会人のためのデータサイエンス入門
  • 社会人のためのデータサイエンス演習
  • 統計学Ⅰ:データ分析の基礎

を受けた。若干内容がかぶっていたが復習みたいな反復になったのでそれほど苦にはなっていない。雰囲気としては大学の共通基本科目の講義がこんなんだったかなぁという感じ。

一つの講義ビデオが5分から15分なのでちょっとずつ学ぶのには良さそう。ただ短い動画で一瞬で終わってしまうので自分なりに復習しないと身につかない。まぁ大学の基礎講義なんてみんなそんなもんだが。

今回の目的としてはこれらの講義からデータサイエンスの基礎を学ぶ目的があった。最近、機械学習などのソフトウェアが進化して専門的な知識がなくても手が届くようになってきている。一方でそういったソフトウェアを使っても、どうも専門的に詳しくなっているというより、単にアプリケーションの使い方を学んでいるだけな気がしてきたので基礎を固めたくなった。

講義の内容からさらに興味を持って以下の本を読んで勉強したりした。

これをキッカケに統計学検定を受けてみるのも良いかもしれない。復習としてよさそうなら受けるかもしれないが、面倒なので受けないかもしれない。講義の内容的には2級くらいまでいけそうらしいが。

IT系イベントの次の日は休むルール

昨日HTLM5 Conferenceに参加したので今日は会社をお休み。

以前からちょこちょこあったが土日や祝日という休日にあるIT関係のイベントに参加することが増えてきた気がする。

IT系のイベントであれば新しい技術などを勉強して仕事に還元されるわけなので平日であれば業務扱いにしているけど、それが休日に開催されるイベントの場合は趣味というか独習になっていてちょっとした矛盾を感じていた。

社員の社外の勉強会などの参加を促すためにもレポートさえ書けば休出扱いにしてはどうかと少し考えてみたけど、個人的に有給あまり使えていない問題があるのでまずは次の日が平日の場合は休むというマイルールを実行してみることにした。単純にこの手のイベントが時期によって連続することがあって適宜休んでいかないとしんどい。

今のところ趣味で参加して、代休じゃなくて私事都合で有給を使うということになっているけど、それはそれで業務っぽくなくてイイかなと思っていたりもする。

冬休みの1日

8:00 起床、朝の準備など
9:30 開発1
12:30 自由時間
14:00 開発2
17:00 自由時間
19:00 開発3
22:00 自由時間

昨年、開発を短い時間で集中して毎日やるを読んで以来この3時間メソッドを実践していた。このメソッドのメリット、デメリットは記事に書いてある通り。

今回、冬休みに3時間メソッドを休憩(自由時間)を挟んで繰り返すということをやってみたがうまく機能した。机を二つにしたこともあるがかなり集中して開発ができた。開発中はメールやウェブのチェックもしないでひたすら開発だけに集中するので、終わったら休憩(自由時間)中にその他雑多な作業を気分転換としてやるのを繰り返し。

実際には出かけることが多かったので朝3時間やって午後出かけるとか、朝から出かけて夜3時間やるとか柔軟に時間を区切ってやっていた。朝起きて3時間やるだけでもうその日は勝ったようなもので後の時間はボーナスタイムと思って気楽にやっていて、大晦日など特別な日を除いて規則正しく有意義に休みの時間を過ごすことができた。

今年は土日などの休日はこのインターバルを短くする形で継続していこうと思う。朝3時間開発してから出社できるようになれば、オープンソース活動であったり趣味の開発をしながら仕事を両立できそうな気がした。

自分なりの3時間メソッドの応用法はまた別の日に書く。

ぼくのなつやすみ(DevCon)

一応、夏季休暇による有給消化が推奨されており、夏休みで人が多い7月8月を避けて9月の祝日に合わせて休むというのは常套テクである。

残念ながら今年はPyConやRubyKaigiに行くことにしたので平日休めないどころか祝日を3日もカンファレンスで消費することに。しかも参加費自腹。これは旅費というかある種のなつやすみと思うことにした。(弁当代も含まれているけど往復の交通費で相殺されてしまう)

メモ取りなど頭を使うせいか若干の疲弊。そこそこいい椅子使っている場所もあったけどお尻が痛くなった。今週末は休養したいけどPython/Ruby/iOS8での開発にも勤しみたい。カンファレンスの参加費を有効活用きるかは今後の活動にかかっている。

Redmineを全員で使ったらカオスになった話

タスク管理のツールとしてオープンソースのRedmineを使っていた。エンジニアだけで使っているうちは特に問題はなかった。エンジニアが10数名、全員でも40人規模の会社なので全員の作業を見える化したいよねという話が上がって全員でRedmineを使い始めることになった。そして何が起きたか。

プロジェクトが乱立した

エンジニアであれば「プロジェクト」は単位は大体想像がつくと思う。しかしながらツール上ではその単位でプロジェクトは作られなかった。「正規のプロジェクト」の小規模な機能追加であっても「○○対応プロジェクト」と銘打たれツール上にプロジェクトが作成された。

「〜対応プロジェクト」「〜導入プロジェクト」「〜検討プロジェクト」「〜プロジェクト」・・・どんな言葉にもプロジェクトを付ければ”プロジェクト”にできるんだということは新鮮ではあったし、勉強にもなった。(そもそも”プロジェクト”って何だ?)

そして多数のプロジェクトがそれほどグルーピングもされずに乱立されていった結果どうなったか。

誰が何をやっているかわからなくなった

ツール上に作成された「○○プロジェクト」は実際に手を動かす作業者しかプロジェクトメンバーに登録されていない。Redmineは様々な変更をプロジェクトメンバーに通知してくれるが乱立した「ツール上のプロジェクト」では直接の作業者へしか通知がされないため全体を把握するのが難しくなった。

スケジュールが管理できなくなった

何を言っているかわからねーと思うが俺も何を言っているかわからない。

ようはバージョンやマイルストーンに変わる単位としてプロジェクトが生成されていた。最初はそれでも大丈夫だったのだろうが、沢山プロジェクトが作成されるとどれが現在アクティブなプロジェクトがわからず、今何がどれだけ進んでいるのかはさっぱりわからなくなった。

そして俺が死んだ

とあることで社員1人1人にヒアリングを行っていた。(この話も別の機会に書きたい)みんなが口をそろえて「誰が何をやっているかわからない」「今どの案件が進んでいるのかわからない」と言い出していた。「Redmine上に全部書いてありますよね?」と尋ねても同じ回答が返ってきてようやく社内の幾つかのプロジェクトが機能していないことに気付いた。

奇妙な使い方だとは思いつつ当人達はそれが使いやすい方法なのだろうと傍から見ていたけど実際には使いやすい方法ではなかったのだ。

そこから乱立したプロジェクトの統合やプロジェクト上のタスクやWikiの大移動を始めた。悲しいかなRedmineではマイルストーンやWikiのプロジェクトの移動に対応していないので、わざわざRedmineのプラグイン(タスク)を書いてActiveRecordのモデルやSQL文を直接実行したりした。直接実行するのは怖いからわざわざVagrant+Chef Soloで同じ環境を作って検証することもした。

何で俺がこんなことをしているのかと思いつつ、各メンバーに移動していいか確認しながら1週間かけてようやく整理ができた。結果的には全体が把握できるようなプロジェクト階層と、プロジェクトを分割した方がやりやすいところはそのまま続けるハイブリッド運用に落ち着いた。

真の問題

慣れていないことをするのだから何かしら失敗すると思っていたし、とりあえずやってみるという話だったので、あれこれ余計な口出しをせず、実際に問題が起きた後で自分たちなりの使い方を模索していけばいいと思っていた。だから非効率な使い方をする人がいたのは想定内だったし、整理した結果それなりの運用に復旧したのでそこは失敗は成功の母。根本的な問題は誰もが良いやり方だと思っていないのにも関わらずそれを変えようと相談したり実行したりしなかったところだ。もっと早く手を打っていれば誰かが致命傷を負わずに済んだはず。

ルールやツールは守るため、使うためにあるのではなく、いいアウトプットを出すための手段でしかない。結局のところ良い仕事をする、良いものを作るのは運用ルールでもツールでもなく人だということである。しかし自発的に人を巻き込んで問題を解決できる人はそうはいない。経営者はみんなにそうして欲しいだろうしそういった文化を作りたいと思うだろうが、営業時間会社にいればサラリーが貰える環境ではなかなかそういうわけにはいかない。周りに流されて仕事をする方が圧倒的に楽だからだ。

僕はコードを書いてツールを向上したりデータを整理することはできても、人の心を変えたり教育する力はまだ持ち合わせていない。それをどこまでやるべきなのかという落とし所もよくわかっていない。客観的に見ても僕が開発に時間を割けないことは会社としてはマイナスなはずだ。開発ができない人や苦手な人でもモチベーターとして有能な人がいるならその人に任せたいのが正直なところ。

ベホマやザオリク唱えられるMPにも限界がある。

何故かこの記事に反響があるようで、2つのカテゴリの反応があるのを見て自分の文章が悪いことに気が付いて多少修正してます。

それは
・Redmineの導入を失敗した話・苦労話
・効率の悪いやり方をやり続けてしまう意識の問題
の2つの論点をごっちゃにしてしまったところ。

前者については本当笑い飛ばしてもらって同じ過ちを冒さないようにしていただければ書いた甲斐があったというもの。後者についてはどうしていいかわからないのでMPが尽きるまでになんとかしたい。

個人的にはRedmine自体の課題やRedmineの利用にはルールが必要という話はどうでもよくて、良い仕事、良い物を創るために方法を改善していくところしか興味が無い。

ウェブ開発者のための働くことと投資の話

という面白そうなセミナーに参加した。実際ためになった。

確かに株なんかギャンブル。株やるくらいなら地道に働くわと思っていたが地道な株式投資もあるものだと新しい視点を教わった。普通のIT系の勉強会は動画で見とけばいいや的な感じになっているのでこういったセミナーにはもっと参加したいと思ってる。

早起きと趣味の開発

忍法早く来て早く帰るの術だけど、あまり趣味の開発にはうまく作用してない。

  • 早く眠くなる
  • 早く帰ると普段行けないところに道草する
  • 帰ってもいつもと違う時間なのかうまく集中できない

と完全に自分の問題なので何か手をうつことができるはず。

また早く眠くなって寝ると次の日も早く起きてしまって、突発的な早朝出社とはいかなくなってしまう。そもそも突発的な早起きはかえって生活を不規則にしている気もするので、「早く起きるけど遅く出社する」がもっと必要なのではと思ったりもする。

うーむ。しかし、ここに来てまさかの「朝型に変更」のスタイルチェンジがあるのだろうか。対応を考えてみる。

忍法早く来て早く帰るの術

僕も例外ではなくソフトウェアエンジニアは夜型の人が多い。要因としては夜のほうが集中できる点と、集中したら長時間コード書き続けたいためだと思う。

早起きは三文の得的な本は今までにも幾つか読んできたがうまく実践できずその都度、夜型で機能するなら別にそれで良くね?で済ませてきた。しかしそんな自分でも早朝出勤をうまく扱えるようになってきたので秘伝を記する。(もっと高度な術としては遅く来て早く帰るの術がある)

早く来たら早く帰る

もう兎に角これに尽きる。

過去に機能しなかったのは早く来ても早く帰らないためだ。ただ勤務時間が長くなるだけでなんの意味もない。なんの意味もない。

今日はこれが終わったら帰ると決めて仕事を始めるとうまくいきやすい。終わったら心を鬼にして帰る、誰よりも早く来たら率先して誰よりも早く帰るべき。やるべきことを片付けたら帰ってもよい雰囲気を作ることも重要だと思う。

早く帰ると世界が明るくいつもと景色が違うので新鮮でもある。

朝から集中する

いろんな本で書いてあったように朝は集中できる。夜が集中できるというよりも静かで割り込みがない環境が良いと気が付いた。普段の朝早く来る人よりもさらに数時間は早く来て誰もいない環境を満喫している。

朝から集中する場合の良い点は、その日を集中モードのままフルスロットルで仕事ができることかもしれない。目標があると持続しやすい。このモードをうまく使うと早く来て早く帰ることができる。

だからとにかく早く来たら早く集中モードに入ること。早起き系の本には早く出社して新聞(ニュース)やこまごまとしたことを整理して、みんなが来るころには万全の状態で仕事をスタートできるみたいなことも読んだ覚えがあるけど、ソフトウェアエンジニアの場合はそういうことをするとだらだらして時間をうまく使えない恐れがあるから余計なことしないでとっととコードを書いて、こまごましたことは集中が解けたときにやればいいんじゃないかと思っている。

会社にいる時間で仕事をした気にならない

ソフトウェアを作るというのは高度な知的創造作業で、ソフトウェアエンジニアにはフレックス勤務など裁量労働制が与えられていることが多い。でも8時間の工数を5時間で終わらせたところで所定労働時間で帰れない。結局、エンジニアという人達はいつも同じような時間に来て同じような時間に帰るという羽目になる。ずっと「フレックスとはいったい・・・うごごご」と思ってた。

8時間の仕事を5時間で片付け、残りの3時間をボーナスタイムとして上司に隠れてものを作ったり、自己向上のために時間が使える人は良いが、意識が高くない人は仕事を早く終わらせる努力をしなくなり5時間の仕事も8時間かけるようになってしまう。結局その努力をしないと自身も向上しないから給料も上がらない。労働時間の設定というのはとても難しい。成果主義が機能しない気がする。

毎日早朝出勤するといつも来る時間といつも帰る時間がシフトするだけなのでやりたくない。とにかく勤務時間を意識したくない。突発的に早朝出社すると時計を見てもよくわからないので良い。時間ではなく作業がベースになるので今何時だから退社時間まで何時間とか考えなくて済む。早朝出社のサイクルに慣れる前にこの状態が自然になるようにしたい。

定時に来て定時に帰るのは仕事としては理想的に思えるが、ものづくりにおいては必ずしもそうは言えないのではないかと思ってる。それは目的がものを作ることではなく会社にその時間いることが仕事になってしまう危険性があるから。

90分ピッチの上に立っていれば給料がもらえる、そんなことを考えるサッカー選手は嫌だ。試合に勝つために、観客に魅せるためにハードワークする、そんなサッカー選手のようなエンジニアでありたい。

キッカケとメリハリづくり

僕が早朝出社を始めたキッカケは欧州サッカーが朝6時とか7時前に終わって、目が覚めたし仮眠をとったり余計なことをしないでそのまま出社して早く帰ろうとふと思ったからだった。逆に趣味の開発を夜遅くまでやって次の日は遅く出社するとか別のパターンもやっている。

いつも同じ時間に出社して同じ時間に帰って録画した試合を見たり、時間の合間に趣味の開発をするよりもずっと気分が良い。自分の好きなことにあわせて仕事をしている感があるとメリハリがでて仕事にも良い影響を与えてくれる。

なので早朝出社をする場合は何かしら仕事以外のやりたいことに結びつけるとうまく行く気がする。実際、昔の僕は別に夜でも集中できるからと朝早く行くメリットをあまり感じていなかった。好きなことに合わせて早く来たり、遅く来たりしよう。

まとめ

  • 好きなこと・やりたいことにあわせて早朝出社してみる
  • 早く来たら誰よりも早く帰る
  • その日の目標を立ててとっとと開発する
  • 毎日同じ時間に来こなくてもいい(メリハリをつける)
  • 早朝出社と同様に夜型も存分に利用する
  • 勤務時間をなるべく意識しない

重要なのは会社の勤務時間に縛られないこと、人が少ない時に集中モードに入ること。

ちなみに僕は夜集中できるから夜型にしていただけであって、実は朝弱いタイプじゃない。早起きする時に目覚ましがなる前に何故かその時間に目が覚める術も使えるので寝坊で遅刻したりしない。なのでエンジニアみんなが早朝出社がうまくいくかはよくわかっていないがやってみる価値は十分にある思っている。

あとはみんながみんな早朝出社したら、朝静かで集中できる環境が失われるから別に真似しなくていいとか考える葛藤。術の利用は計画的に。

プロフェッショナルなエンジニアであるために

小保方さんは女性に嫌われて、男性からは好意的という見方があるらしい。若い女性であるというだけで持ち上げられ、問題が起きたらスケープゴートにされるという面は同情の余地があるが、僕はあまり好きではない。

不正をしても悪気がなければ情状酌量の余地があるという論理は破綻していると思うし、彼女が祭りあげられようが、他の共同研究者がチェックを怠ろうが、彼女が本物の研究者ならプロとしてやってはいけないことはやらなかったはずだから。

一方で僕が言えるのは彼女は本物ではなかったということと、好きではないということだけで、本物じゃないから彼女が悪いということが言いたいのではない。人間誰しも失敗を犯すものだし、重要なのは失敗から学んで成長していくこと。

この話はエンジニアにとっても無関係じゃない。プロとしてやっていはいけないことに周囲は関係ない。今回の不正に例えれば、上司がリリースを強行しようと、同僚のコードレビューがザルだろうが、著作権を守らずにプロジェクトに組み込んで公開して良いわけがない。

周囲がどうであれ自分が全力を尽くさなくてもいい理由にはならない

本物のエンジニアであるためにプロとして楽な方に流されずに心を強く持たないといけない。教訓にしよう。

stay hungry, stay foolish, stay professional.