会社で
「テーマ別に社内 Blog を分けるべきか?」
という質問をもらった。
私の意見としては、ほとんどの場合分けるべきではないと思う。
Blog 分けてそれぞれをきちんと更新していくのは、結構な手間と時間がかかるものだ。
たいがいの場合 Blog のカテゴリ機能やタギング機能を使うことで十分整理でき、その方が効果的に運用できると思う。
仕事用に Skype 名を作成し、ついでに社内 Blog に Skype ボタンを貼りつけてログイン状態を表示できるようにしてみた。
そういえば電話もそうなんだけれど、本社に連絡を取るとき「もしかして会議中?」などと勘繰ってかけるかどうか迷ってしまうことがある。 かけたい人の予定がわかればいいのになと。
ならば逆もしかりだろうということで、自分の仕事のスケジュールを晒してみようと思いついた。 グループウェアとかそういうのは大袈裟なので、まずは社内 Blog のサイドバーに表示するようにしたい。
ということでこの3連休に実装してみた。
完全なスケジュールはほぼ日手帳に手書きで管理しているので、ミーティング・外出など晒しカテゴリのイベントだけを、電子化する必要がある。 手で HTML 毎回ごりごり書き直すのも嫌なので、スケジュール管理ソフトを使いたい。 この部分は KDE の KOrganizer を使うことにした。
で、KOrganizer のスケジュールを iCalendar 形式でエクスポート。 このファイルを社内 Blog を配信しているサーバに rsync で転送。
この処理はちょっと手間なので自動化したいところ。
この iCalendar 形式ファイルを読み込んで、今日以降の10件(程度)を HTML フラグメントに変換し JavaScript プログラム (document.write() 列) として出力する Perl CGI プログラムを作成。
iCalendar の形式の読み込みについては Data::ICal や iCal::Paraser などの Perl モジュールを利用できる。 今回はシンプルに使えそうな iCal::Parser をチョイス。 基本的には
use iCal::Parser; my $parser = iCal::Parser->new; my $calendar = $parser->parse($ics_file_name);
で読み込んだデータがハッシュリファレンスとして $calendar に設定される。 イベントは $calendar->{2007}->{01}->{01}->{$uid} のように「年、月、日、イベントUID」のハッシュ階層として格納されているので、これを読み出せばよい。
で、この CGI プログラムが生成する JavaScript プログラムをサイドバーで JavaScript Include。
まずは表示までできるようになった。
これで
おいおいスケジュールの表示デザインとかは改良していきたい。 hCalendar 形式にしてスタイルシートでデザインするのがいいのかな。
去年の11月から会社で、電子化した週次レポートをベースに週次定例ミーティングを行うようになった。 それにあわせて、書いた週次レポートを DiKicker で立てている 社内 Blog に毎週載せておいたのだが、これが思ったよりよろしくない。
DiKicker でキーワード串刺し表示を行うと、これらの週次レポートが記事リストに毎度のように沢山表示されてしまうのである。 自分が担当している各プロジェクトの1週間の成果・進捗報告なので当然各プロジェクトのキーワードを使って文が書かれているわけで、キーワードで一覧表示すると大概ひっかかってしまうというワケ。
週次レポートはその他のプロジェクトの情報も浅く広く書かれているから、串刺しで見るには邪魔なのである。肝心のキーワードに関する情報も、週次レポートという要約記事の前に別途詳細の記事があることも多いし。
ということでとりあえず週次レポート専用に社内 Blog を作って、それらの記事はひとまとめにしておくことにした。 社内 Blog にしておいて役立つかどうかちょっと様子見。
珍しくまとまってコードを書いたり、あとはもりもり文章書いてたりで1日経ったので若干ネタ不足。20%は Web 日記に書くネタ作りに精を出したいね。
新卒2年目のエンジニアが社内 Blog で提言していてグッジョブだった。次はそこからどう広げていくかか。Joel on Software の「下っ端でも何かを成し遂げる方法」的に下から改善する戦略をとるのが一つの方法かなぁ、やっぱり。というかどのポジションにいても多くの場合やはり「実行あるのみ」「じわじわと広めていく」がやれることなんだと思う。
2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!
手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽坂から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。
現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。
大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。
「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。
退職時に使っていた社内 Wiki は Naney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.
同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。
そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。
思考を整理・明確化していくのには書いて考えるのが有効である。文章として書くことで必然的にしっかりと考えることになる。日頃から文章を書くことで思考力が高まる。
日々仕事で会議の資料を書いていたとしてもそれが箇条書きで列挙しているだけなら、考えたつもりになっているだけかもしれない。箇条書きではなく文章で書くことが質の高い思考につながる。
他の能力の獲得と同じく、文章力を高めるにはある程度の長さの文章を書いて見直すのを繰り返していくことが必要だ。「気をつける」「意識する」だけでは文章力はつかない。書かずして文章力が高まることはない。
文章力を高めるには、読者がいる前提の文章を書く必要がある。誰でも気軽に始められる Blog サービスや Web 日記サービスは、日頃からまとまった量の文章を書いて公開できる場として最適だ。
仕事に関する話題を社内 Blog に書くのもいいかもしれない。内容だけでなく文章についてのフィードバックがもらえれば、多いに文章力向上の参考になるだろう。
[ opinion ]
月曜日に部門の情報共有ツール (Qiita Team) にワーキングノートを新規作成し、その週はそのノートを更新するというのを今週やってみた。
共有するかどうかとは別に、そもそもデイリーノートとワーキングノートを分けない方がいいという気持ちになった。知的作業空間としてはデイリーノート一本化に戻す。作業中に共有・非共有の判断にエネルギーを割かないようにする。
コミュニケーションの補完という目的では、雑感記事をデイリーで情報共有ツールに書いていくのが良さそうだ。
結局行き着くところは社内 Web 日記 (社内 Blog)か。
[ 組織内公開ワーキングノート ] [ 公開で作業する ]
ワーキングノートを部門の情報共有ツールに書いてみた結果、コミュニケーションの補完という目的で部内 Web 日記として雑感を書くのがいいかなと思ったので、先週の月曜日から Qiita Team に1日1投稿を続けてみている。
「(その日の)トピックス」「(その日に確認し考察した)メトリクス」「雑感」と「(アイデアなどを含むちょっとした)バックログ」が今のところのセクション(該当内容がないセクションはカット)。
情報の鮮度を考えて1週間後に Qiita Team からは削除。ローカルでは非公開のデイリーノートと合わせて Markdown ファイルとして残しつつ、ローカルの他のノートと同じく整理のタイミングでマージされたりしていく想定だ。
また Web 日記を増やしてしまった。まあ Web 日記ドリブンも悪くない。
[ 社内 Blog ] [ 組織内公開ワーキングノート ] [ 公開で作業する ]
11月29日から4週間ほど部内 Web 日記として毎日雑感などを Qiita Team に書いてみた(記事)。仕事納めの今日は個人的な仕事の整理が多くてプロダクトについて書くネタが思い浮かばなかったというのもあり、惰性で続けずいったん昨日までで終わりとした。
読み手を意識して書くため、デイリーノート(非公開)にメモ書きするより思考の整理・明確化につながった。
メトリクスについての考察などの意見を書いておく場所として適していた。
仕事終わりの時点で書きたい話題が無いと何かないかなと無理やり考えることになって、それはちょっと違うかなと。
読まれているのかどうかが分からないと虚しくなりやすいというのも再認識した(読んでますと1人からフィードバックを頂いたのが心の支えだった)。
今回はお試しなので書きます宣言 & 宣伝をしなかったし、1週間後に削除する旨を冒頭に書いていたことでフィードバックを誘わない記事であったのも拍車をかけていたとは思う。
誰が読んだかわかる既読表示のある DocBase の方が読まれている実感があり継続に繋がりやすいのではと思う。
コミュニケーションの補完という目的で部内での情報発信はしていきたいなあというのは引き続きあるので、来年も何か実験してみたい。
[ 社内 Blog ]
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。