nDiki : 社内 Blog

社内 Blog (社内ブログ)

2006年8月21日 (月)

社内 Blog でのぼやき

社内 Blog にはどんな事を書くべきであろうか?

ネタものはスパイスになるが、ぼやきはどうも見ていてあまりいい感じがしない。 閉塞感や焦燥感を表現するにせよ、その先につなげる何かが欲しい。

その記事が読んでいる人・組織にどんなメリット・インパクトを与えるのかを考える書くととより価値のある情報になるはずである。

とぼやいてみる。

[ 8月21日全て ]

2006年8月25日 (金)

社内 Blog をテーマ別に分けるべきか?

会社で

「テーマ別に社内 Blog を分けるべきか?」

という質問をもらった。

私の意見としては、ほとんどの場合分けるべきではないと思う。

  • 分けると閲覧者が巡回する負担が増える (RSS リーダ活用などが浸透していない現状で)
  • Blog の更新頻度が下がる
  • そのテーマが終了した時に、その Blog がメンテナンスされなくなる → 忘れられる → 蓄積された情報が目に触れる機会が減る
  • そのテーマが終了した時に、その Blog がメンテナンスされなくなる → メンテナンスされていない Blog が一つ増える → 社内 Blog が活用されていないという印象が広まる

Blog 分けてそれぞれをきちんと更新していくのは、結構な手間と時間がかかるものだ。

たいがいの場合 Blog のカテゴリ機能やタギング機能を使うことで十分整理でき、その方が効果的に運用できると思う。

[ 8月25日全て ]

2007年1月8日 (月)

iCalendar 形式経由でスケジュールを社内 Blog に表示

仕事用に Skype 名を作成し、ついでに社内 BlogSkype ボタンを貼りつけてログイン状態を表示できるようにしてみた。

そういえば電話もそうなんだけれど、本社に連絡を取るとき「もしかして会議中?」などと勘繰ってかけるかどうか迷ってしまうことがある。 かけたい人の予定がわかればいいのになと。

ならば逆もしかりだろうということで、自分の仕事のスケジュールを晒してみようと思いついた。 グループウェアとかそういうのは大袈裟なので、まずは社内 Blogサイドバーに表示するようにしたい。

ということでこの3連休に実装してみた。

構成

入力

完全なスケジュールはほぼ日手帳に手書きで管理しているので、ミーティング・外出など晒しカテゴリのイベントだけを、電子化する必要がある。 手で HTML 毎回ごりごり書き直すのも嫌なので、スケジュール管理ソフトを使いたい。 この部分は KDE の KOrganizer を使うことにした。

サーバへアップロード

で、KOrganizer のスケジュールを iCalendar 形式でエクスポート。 このファイルを社内 Blog を配信しているサーバに rsync で転送。

この処理はちょっと手間なので自動化したいところ。

社内 Blog 内表示用 JavaScript Include ファイル生成 CGI プログラム

この 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」のハッシュ階層として格納されているので、これを読み出せばよい。

社内 Blog サイドバーに表示

で、この CGI プログラムが生成する JavaScript プログラムをサイドバーJavaScript Include

まずは表示までできるようになった。

これで

をまとめて公開できる社内 Blogアップグレード

おいおいスケジュールの表示デザインとかは改良していきたい。 hCalendar 形式にして CSSデザインするのがいいのかな。

[ 1月8日全て ]

2007年1月11日 (木)

週次レポートは社内 Blog には邪魔

去年の11月から会社で、電子化した週次レポートをベースに週次定例ミーティングを行うようになった。 それにあわせて、書いた週次レポートを DiKicker で立てている 社内 Blog に毎週載せておいたのだが、これが思ったよりよろしくない。

DiKicker でキーワード串刺し表示を行うと、これらの週次レポートが記事リストに毎度のように沢山表示されてしまうのである。 自分が担当している各プロジェクトの1週間の成果・進捗報告なので当然各プロジェクトのキーワードを使って文が書かれているわけで、キーワードで一覧表示すると大概ひっかかってしまうというワケ。

週次レポートはその他のプロジェクトの情報も浅く広く書かれているから、串刺しで見るには邪魔なのである。肝心のキーワードに関する情報も、週次レポートという要約記事の前に別途詳細の記事があることも多いし。

ということでとりあえず週次レポート専用に社内 Blog を作って、それらの記事はひとまとめにしておくことにした。 社内 Blog にしておいて役立つかどうかちょっと様子見。

[ 1月11日全て ]

2013年4月2日 (火)

【日記】下から改善する戦略

珍しくまとまってコードを書いたり、あとはもりもり文章書いてたりで1日経ったので若干ネタ不足。20%は Web 日記に書くネタ作りに精を出したいね。

新卒2年目のエンジニアが社内 Blog で提言していてグッジョブだった。次はそこからどう広げていくかか。Joel on Software の「下っ端でも何かを成し遂げる方法」的に下から改善する戦略をとるのが一つの方法かなぁ、やっぱり。というかどのポジションにいても多くの場合やはり「実行あるのみ」「じわじわと広めていく」がやれることなんだと思う。

[ 4月2日全て ]

2015年5月13日 (水)

レクサー・リサーチ開発同窓会

rimage:/nDiki/Flickr/17034996273.jpg

2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!

COGS DINING KAGURAZAKA (コグス ダイニング 神楽)

手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。

ソフトウェア開発

現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。

大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。

「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。

退職時に使っていた社内 WikiNaney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.

その他

同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。

そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。

[ 5月13日全て ]

2021年9月9日 (木)

思考力と文章力を高めるために継続的に文章を書く

文章を書くことで思考力を高める

思考を整理・明確化していくのには書いて考えるのが有効である。文章として書くことで必然的にしっかりと考えることになる。日頃から文章を書くことで思考力が高まる。

日々仕事で会議の資料を書いていたとしてもそれが箇条書きで列挙しているだけなら、考えたつもりになっているだけかもしれない。箇条書きではなく文章で書くことが質の高い思考につながる。

文章を書くことで文章力を高める

他の能力の獲得と同じく、文章力を高めるにはある程度の長さの文章を書いて見直すのを繰り返していくことが必要だ。「気をつける」「意識する」だけでは文章力はつかない。書かずして文章力が高まることはない。

文章力を高めるには、読者がいる前提の文章を書く必要がある。誰でも気軽に始められる Blog サービスや Web 日記サービスは、日頃からまとまった量の文章を書いて公開できる場として最適だ。

仕事に関する話題を社内 Blog に書くのもいいかもしれない。内容だけでなく文章についてのフィードバックがもらえれば、多いに文章力向上の参考になるだろう。

[ opinion ]

[ 9月9日全て ]

2021年11月26日 (金)

ワーキングノートを部門の情報共有ツールに書いてみた

月曜日に部門の情報共有ツール (Qiita Team) にワーキングノートを新規作成し、その週はそのノートを更新するというのを今週やってみた。

目的に対して

  • コミュニケーションの補完という目的をどれぐらい果たせているかはまだ不明(1人から公開初日に良い取り組みだというフィードバックはいただけた)。
  • 1つのワーキングノートの公開だけだと「公開で作業する」感はちょっと低め。

運用について

  • 毎日1回以上更新は継続できた。
  • ローカルのデイリーノートと今回の共有用ワーキングノートの2本立てで書き分けるのに、フリクションが発生する。
  • 共有期間を終えたあとのローカルでのアーカイブをどうするかまだ見えていない。

これから

共有するかどうかとは別に、そもそもデイリーノートとワーキングノートを分けない方がいいという気持ちになった。知的作業空間としてはデイリーノート一本化に戻す。作業中に共有・非共有の判断にエネルギーを割かないようにする。

コミュニケーションの補完という目的では、雑感記事をデイリーで情報共有ツールに書いていくのが良さそうだ。

結局行き着くところは社内 Web 日記 (社内 Blog)か。

[ 組織内公開ワーキングノート ] [ 公開で作業する ]

[ 11月26日全て ]

2021年12月7日 (火)

部内 Web 日記を書き始めて約1週間

ワーキングノートを部門の情報共有ツールに書いてみた結果、コミュニケーションの補完という目的で部内 Web 日記として雑感を書くのがいいかなと思ったので、先週の月曜日から Qiita Team に1日1投稿を続けてみている。

「(その日の)トピックス」「(その日に確認し考察した)メトリクス」「雑感」と「(アイデアなどを含むちょっとした)バックログ」が今のところのセクション(該当内容がないセクションはカット)。

情報の鮮度を考えて1週間後に Qiita Team からは削除。ローカルでは非公開のデイリーノートと合わせて Markdown ファイルとして残しつつ、ローカルの他のノートと同じく整理のタイミングでマージされたりしていく想定だ。

また Web 日記を増やしてしまった。まあ Web 日記ドリブンも悪くない。

[ 社内 Blog ] [ 組織内公開ワーキングノート ] [ 公開で作業する ]

[ 12月7日全て ]

2021年12月28日 (火)

部内 Web 日記を書く実験完了

11月29日から4週間ほど部内 Web 日記として毎日雑感などを Qiita Team に書いてみた(記事)。仕事納めの今日は個人的な仕事の整理が多くてプロダクトについて書くネタが思い浮かばなかったというのもあり、惰性で続けずいったん昨日までで終わりとした。

良かった点

読み手を意識して書くため、デイリーノート(非公開)にメモ書きするより思考の整理・明確化につながった。

メトリクスについての考察などの意見を書いておく場所として適していた。

良くなかった点

仕事終わりの時点で書きたい話題が無いと何かないかなと無理やり考えることになって、それはちょっと違うかなと。

読まれているのかどうかが分からないと虚しくなりやすいというのも再認識した(読んでますと1人からフィードバックを頂いたのが心の支えだった)。

今回はお試しなので書きます宣言 & 宣伝をしなかったし、1週間後に削除する旨を冒頭に書いていたことでフィードバックを誘わない記事であったのも拍車をかけていたとは思う。

誰が読んだかわかる既読表示のある DocBase の方が読まれている実感があり継続に繋がりやすいのではと思う。

今後

コミュニケーションの補完という目的で部内での情報発信はしていきたいなあというのは引き続きあるので、来年も何か実験してみたい。

[ 社内 Blog ]

[ 12月28日全て ]

About

Process Time: 0.060492s / load averages: 0.43, 0.42, 0.36