五大ニュース2015
今年を振り返ると、不義理な１年だった。
転職先について悶々と悩み、多くの人に相談とも愚痴ともつかない話を聞いてもらって過ごした年末年始を経て、年初第１営業日に上司に退職の相談。人としてどうかと思うくらいのことを言われた年の初め笑
それから３ヵ月必死で仕事して、せっかくいただいた飲みのお誘いのほとんどをうやむやにして断って、いくつか参加した送別会には１時間以上遅刻し、最終出勤は休出。
結果、上司は最後までよくがんばってくれたと労ってくださったけど（さらにその上の上司はまた違うとは思うけど）、送別会のほとんどをうやむやにしたのはミサワ的な話ではなく、自分が送別されるような場が苦手というだけだったようにも思う。
お世話になったあの方にも、あの方にも、定型メールで挨拶を済ませてしまった。
遅刻癖がついたのか、転職後も会社以外の飲み会には毎回のように数時間の遅刻。
でも、ただ、今年起こった変化は素敵なものばかりだった。起こったんじゃなくて、自分で引き寄せたんだと、それは胸を張って言える。
変化の大きな１年だったけど、無事に元気に過ごせてよかった。
そして、せっかく東京に来たので、来年はたくさんの人とたくさん話したい。年が明けたら、とりあえず前職でお世話になった人たちに結婚報告のメールでも送ってみようかな。
そんなわけで今年も勝手にMy５大ニュースで一年を締めるとします。
番外編：はやり目
はやり目にかかって、１ヶ月くらいメガネ生活をした。
５位：バイト先で迎えた新年
ひと時だけお店に戻ってこられた、自分たちの現役時代の店長にお誘いいただいて、学生時代のバイト先で今年の新年を迎えた。16時〜24時までで入って（サラリーマンで副業禁止なので、バイト代は豪華まかない！）、６年ぶりだったと思われるが楽しかった！
４位：RSR
今年もRSRは本当に楽しかった！
１日目は、サニーデイサービス、PE'Z、ハナレグミ（サヨナラCOLORをはじめて生でみた）、安藤裕子、アジカン、KIRINJI。
２日目は、森は生きている、クラムボン（リハでFolkloreをやって、そしてやっぱりシカゴのイントロと来たら！）、怒髪天、CERO（今年はCEROの１年だった！）、フジファブリック、安全地帯、perfume、スカパラ、民野の部屋、銀杏BOYZをみた。
日の出までみんなでテントを囲んでビールを飲んだ。それから、もいわ山から見た夜景＆花火もジンギスカンもカラオケも楽しくてしかたなかった。
銀杏BOYZ。サポートメンバーを従えて出てきたら嫌だと正直思っていたんだけど、EART TENTに着くと、ステージ上にはギター１本と椅子だけが置かれていた。
弾き語りの峯田は、こんなにちゃんと唄う峯田ははじめて見たんじゃないかと思うほどで、そしてたぶん歌がとてもうまくなっていた。カラオケで歌ったI DON'T WONNA DIE FOREVERが、とはいえこの音を出しているバンドって他にいないと思って、あの２枚のアルバムのツアーに行きたかったなと心底思った。
峯田が、音楽が好きだということを素直に言っていきたい、というようなことを言っていて、格好良かった。
３位：転職
そんなわけで４月から転職しました。
前職と同じようにエンタープライズのIT開発をしているけれど、会社規模は1/100以下になった。
就職して一番よく働いた１年だったと思うけど、充実した１年でした。
２位：関西を離れた
関西に12年住んだけど、関西弁はマスターできなかった。
家の近所の居酒屋の方々に良くしていただき、最後の最後に関西にも帰る場所ができたような気がした。
東京で一旗揚げていつかきっと関西弁修行の続きを。
１位：同棲生活開始
４月から同居を始め、年明けに式を挙げることになりました。
皆様が素敵な2016年を迎えられますことを。よいお年を！
ちょうど１年前、転職活動のまっただ中だった
転職が決まりもろもろの手続きが終わって、前職の人事と面談したときに、率直な退職理由のヒアリングを受けた。改めて答えようとすると、退職理由はたくさんあるような、一方では決定的な理由など何もなかった。結局、もっと若手をどう育てるのか戦略的に考えた方がいいよねという話で盛り上がり、現場で感じていた具体的なお願い事項をいくつかしてお茶を濁した。
いまになって考えてみると、端的にはロールモデルがいなかったというのが一番の理由だったと思う。
悩みに悩んで、転職先を最後に選んだ理由は、この人の下で働きたいと思う方がいるということだった。
- エンタープライズの開発は好きだけど、大規模SIerを頂点としたいわゆるSIとは違うSIをしてみたい人
- スーパープログラマーにはなれないことは分かっているけど、お客様の要件や課題を技術に近いところで働いて解決していきたい人
あれから１年が経ってみて、そういう人は外に出てみるのは、悪くない選択肢だと思う。
SE（笑）と思いがちだけど、いわゆるSE的な仕事がしっかりできる人に対する需要は、当然のことながら大きい。
会社を選ぶ基準
SIer的な会社のマッピングにはいろいろ軸があるのだろうけど、１つの観点として下記の３点が挙げられると考える。
①プライム案件比率と主要顧客の業界分散
いわゆる多重請負構造という話だけではなく、優れたツールを開発して提供したいか、それともそれを活用してSIをしたいかという話でもある
プライム比率が高いといっても、小さい会社の場合、ごく少数（極端な話１社とか）の顧客、または、特定のソリューションに売り上げの大半を依存しているケースもある
②常駐比率
コンサル的な仕事をしていると常駐がベターなタイミングは確かにある一方で、自社の都合で社員の時間を使えない制約は大きい
常駐するということは１社のユーザーの仕事に固定されることであり、１社に何年も継続して常駐するのであればそのユーザー企業の社員になった方がいいケースもあると思う
③自社開発比率（BP比率）
自分自身がコーディングするにせよしないにせよ、技術に近いところで仕事をしたければ、自社開発比率は一つの指標として重要だと思う
転職してみて
この人の下で働きたいと思った方が直属の上司で、日々叱られたりしつつも一緒に仕事をするのが充実しているというのはもちろんだけど、1万人くらいの会社から100人くらいの会社に転職してみて、それに加えていくつか思いがけない心地良さがあった。
- 中途社員の多さ
会社立ち上げ時のメンバーに加えて、新卒も採っているのだけど、やはり中途がマジョリティ
そうすると、入社／退社どちらも当たり前だし、中途だからというやりづらさが一切ないのが心地よい。
- 社外との交流の広さ
小さい会社なので、自社のリソースでできることにはどうしても限りがあり、他社との協業は必須となる
コミュニティで活躍している人が多いのも一因だと思われるけど、いろいろな会社にいって相談したりされたりする機会は圧倒的に多く、世界が広がっていくことを感じる
極端な話、前職での他部署との距離より、いまの会社で他社との距離感が近いようにすら感じる
基幹システムの保守で感じたこと
大規模システムの保守をすると開発のときにはのっぺりしていて見えない「でこぼこ」が見えるようになる、と上司が言っていた。
生産管理（受注、納期回答、出荷を中心に）の保守に１年強携わる中で感じたことを、とりとめはないけど書いてみる。
説明できること
「なんでこの納期になっているのか？」というような問い合わせがひっきりなしに来る。
システムの自動引当を疑われているわけだけど、実は得意先から納期変更が入っていたことにユーザが気が付いていなかったり。
ユーザがシステムを見るだけで判断できるようにしておくべきだけど、せめて説明できるようにしたい。
データ容量とのトレードオフで１トランザクションデータの履歴（ex. 受注から売上まで）をどこまでの粒度で追えるようにしておくか、時点時点での状況（ex. 在庫が引き当たっていたのか、生産計画が引き当たっていたのか）をどのように判断できるようにしておくか。
また他システムや他サブシステムとのIFをバックアップしておくこと。
ファイル連携であれば単純にファイルをバックアップすればよいけど、IFテーブルに書き込むのであればどのタイミングでバックアップテーブル（またはファイル）に移送するか、WebサービスでHTTPで飛んでくる場合のパラメタ、直接メソッドを呼び出すのであればその引数のログなど。
これらがまずは泥臭くとも後から参照できること、次のステップとしては簡便に検索できること。
影響調査のしやすさ
マスタの設定値を１つ変えたらどういう業務影響があるかと問われるだけで、影響調査で何日もかかったりした。
項目レベルのCRUD表相当の何かが、メンテナンスコストの低い仕組みで存在しており、最新化されていると信頼できればハッピー。
最終はソースをgrepするわけだけど、並行開発などで最新のソースが散在していてどこをgrepすればよいか分からなかったりした日には地獄。
明示ロック
パフォーマンス上の制約でトランザクション分離レベルをSERIALIZABLEにできない場合、明示ロックを使用することになる。
この場合、デッドロックを回避するために、システム全体で共通のロック順序に従ってテーブルをロックしていくと思われる。
ここで問題になるのが、共通関数的なもの。ロック順序に従ってロックをするためには、共通関数の呼び出し元が、共通関数内でアクセスしているテーブルを把握して、呼び出し前に正しい順序でロックをかける必要がある。
これは、共通関数に処理を隠蔽することと相反する。
影響調査にも同じ問題がある。共通関数内で引数の区分などを判断してCRUDするテーブルを切り替えている場合、特定のテーブルや項目という観点で見ると結局どの機能から更新されているか追いかけるのが困難になる。
取り消しをどこまでシステム化するか
業務システムは取消と開発コストのトレードオフ（だと思う）。
開発時はコスト削減でこれ以上の取り消しは不要にすると決めても、実運用ではあらゆるオペレーションミスが発生する。結局データパッチを当てるのだけど、監査上の問題もあるし、そもそも影響範囲が大きすぎてデータパッチを当てるのも難しい。
締め処理後にも遡って処理したいという要望は必ず出てきて、「締め」とは何かという気分にもなる。
取消機能を開発する場合は、データ源泉で取り消し入力して伝播させるのが大原則。
Excel問題
業務システムはExcelと切っても切り離せない。どれだけUIを工夫しても、複数行を一括で処理する際にExcelのコピペには適わない。
Webシステムであれば、Excel出力→Excel上でユーザが編集→Excelファイルをアップロードして取り込むという機能を作る、ExcelをHTTPクライアントとして使うなどが考えられる。
その際、Web画面のロジックを流用して手軽にExcel機能を実装できることが重要。たとえば画面入力とExcel取込でValidationの実装箇所が異なっており、結果として二重実装になったりすると辛い。
マスタ
ERPパッケージではより顕著なのだろうけど、マスタは際限なく肥大化していく。
例えば、工場と得意先の組み合わせで梱包ラベルの出力内容を設定するとする。
ある工場では全体で共通なので得意先ALLで設定したい、別の工場は得意先をグルーピングして設定したい、特定の品種だけ特別な設定をしたい、はじめての得意先に出荷する場合は特別な設定を適用したいなどの要件が発生する。
さらには、どのトランザクションデータからマスタ変更を適用するかという課題もある。
適用開始・終了で管理するにしても、各トランザクションの受注日で切り替えるのか出荷日で切り替えるのか、また日中に変更するが即時反映せずに夜間バッチ先頭で反映するなどの要件があったりする。
結果として、ユーザもどのようにマスタ設定したらよいか分からず、どの部署がメンテナンスするかも不明確になり、また単純なSQLではマスタ設定値を取得できず調査も大変なマスタが完成する。
一括改定（組織変更、他工場への生産移管、単価改定、品種のくくり方の変更など）も大変で、どれだけのマスタを改定すればよいのか、どのようにトランザクションデータに反映させるのか、複雑になる一方。
本番のデータベースに対して、引数を指定して共通関数（更新がないことが前提）を呼び出せる仕組みがあると便利。
どこまでシステムを業務に寄せるのか、業務をシステムに寄せるのかという問題でもあるのだろうけど。
汎用テーブル
どのシステムにも存在するであろう汎用テーブル的なもの。
- ID、種別区分＋項目１、項目２、…、項目１０みたいなテーブル項目
- だいたいは構造が別途管理されている（ex. 種別：工場では、項目１が工場コードで半角英数、項目２が工場名で制約なし、項目３以降が工場ごとの設定）
そして構造情報を使って、共通のメンテナンス機能を開発して、メンテナンスする。
マスタメンテナンス機能の機能数（= 開発コスト）を削減するために生まれてくるケースが多いと思われる。メタ情報を使って共通機能でメンテナンスするのであれば、複数テーブルを１機能でメンテナンスすればよいようにも思うけど、汎用テーブルが各テーブルに切り出され、数件しかレコードのないテーブルが数百増えたりするのも辛く、難しい。
せめてシステム的な設定（または、データがないと動かない）と、ユーザの設定（または、データがなくとも動く）は別テーブルにしておく方がよい気がする。
テスト環境の構築容易性
特定時点のプログラム一式とデータを使って、テスト環境を簡便に構築できることは重要。
データのマスキング、本番系にメールやデータ連携が流れないようにする設定変更、誤操作しないように画面の背景色を変えるなど、スクリプトに組み込んでおく。
データをダンプするために、ファイルや過去履歴など極端に容量の大きいテーブルは別スキーマにしておく方が簡便。
本番のデータ一式を持ってきて、デバック実行するしか調査のしようがないケースもある。
オーナーの明確化
それぞれの機能、共通機能、テーブルなどのオーナーが明確かつ簡便に判断できないと辛い。壁の向こうにボールを投げておしまいはダメだけど、でもどのチームに聞いたらよいか分からないとどうしようもない。あと名前大事。
ドキュメント
ここの開発テーマに応じて、有用な資料は作られていく。一方、新しい要件が追加されたときに、過去の資料に翻って反映するのはなおざりになり、結果として生き字引が「ここはこの資料を見て、ここはこっちが最新」というパターンになる。
最新化対象の資料を増やすことは、保守コストを上げることなので難しいけれど、どのドキュメントを構成管理するかは明確にしておく必要がある。
フロー、概念図、処理の目的や概要、各項目の業務的な意味など、ソースに表れない論理的なドキュメントは必要。
一方、やはりプログラム設計書は作らない方がよいと思う。どこまでいっても設計書と実装の完全一致は難しい。
ソースを読めない人もいるのは分からないでもない。でも実装を求めるわけではないので、拒否反応さえ解除できれば、Excel設計書を何ファイルも開いてシートを移動しながら読み解くよりは、IDEでF3とかでジャンプしながらデバック実行する方が効率がよいと思う。
プロセスを軽くする人
保守運用ではどうしても事故は起こる。事故が起こると原因を分析して対策を立てる。
そもそも初期構築時の大規模開発ならではの重厚なプロセスが残っていて、そこに事故が起きるたびにチェックリストが追加されていったりすると、大げさではなく身動きが取れなくなってしまう。
時間が経てば、そもそも何のためにそのチェック項目があるのか誰も知らない状態になり、誰も整理できなくなり、最終的にはすべてが平坦におざなりになる。
似たような話で、プログラムでいえば、新機能は拠点ごとに導入していくケースが多いため、何らかのShip Flagのような仕組みでコントロールすることになる。全拠点への導入が終わってもShip FlagのIF文が残り続けることで、ロジックはどんどん複雑になっていく。
プログラムだけではなく、プロセスもリファクタリングが必要。
この10年の夏フェスの思い出
初めて夏フェスに行ったのが、2005年のROCK IN JAPAN。それから10年が経ったので、この10年の思い出をまとめてみた。
この10年、ずっと自分よりちょっと年上の人がメインの客層のような気がしているけど、多分そんなことはなくて、しっかりおれは30歳になってしまった。
ROCK IN JAPAN 2005
大学３回生の夏、はじめての夏フェスで宿の取り方も分からなかった。快晴のひたちなかは、ビールよりポカリ！というくらい暑くて、納豆ねばねば丼とスイカジュースがよかった。
雲ひとつない快晴で、入口のゲートをくぐった瞬間のあの雰囲気と、空に浮かぶバルーンと、そして会場に流れる音楽。一番最初に見た風味堂のときに、空にポカリスエットの飛行機雲が浮かんで。憧れどおりの場所に、なんともいえないわくわく感でした。
感覚的にはブームとしての夏フェスの終わりの始まりのような頃で、まだフェスを追いかけて腕にリストバンドをいくつも巻いている女の子たちがいた。
CoccoとくるりのSINGER SONGER出演（セットリストの最後が『花柄』でぶっ殺すを連呼したのが衝撃だった）、ミスチル・サザン揃い踏み、銀杏BOYZ峯田全裸騒動。
サザンのアンコールで後ろ髪をひかれながら、終電で実家へ帰った。サザンのライブはあの１回しかみたことがないのだけど、あれほどフェスのトリが似合うバンドはない。
何より2005年は真心ブラザーズが復活した年で、ずっとPeace and Loudを聴いてROCK IN JAPANに行った。あの真心のライブは最高で、あのライブをみたから、フェスに行き続けているのだ。
RISING SUN ROCK FESTIVAL 2006 in EZO
大学４回生。ひたちなかはあまりに暑く、「北海道＋フェス会場でのキャンプ＋朝日」に対する憧れも強くて、ライジングサンへ。
麻生駅からシャトルバスに乗って会場に着き、入場待ちをしているときに『恋人たちのロック』がかかっていたことを覚えている。
水曜日夜中に舞鶴発のフェリーに乗って甲板で乾杯、木曜日の夜に小樽につき、札幌へ移動してジンギスカンを食べて、金曜日〜日曜日の朝までライジングサン（土曜日の朝は温泉ツアー）、日曜日の夜に小樽で寿司を食べてフェリーに乗り、月曜日の夜に帰ってくるスタイルを確立。
忌野清志郎さんが体調不良で出演キャンセル、三人の侍（Char、奥田民生、山崎まさよし）が出演。おれは結局、忌野清志郎さんのライブをみる機会はなかった。
クロマニヨンズ結成。デビューの最初からリアルタイムで見ているバンドって良いんじゃないか？みたいなことを、ヒロトがインタビューに答えて言っていた気がする。
ライジングサンにも出ることが発表されていて、確か最初に出演したFM802のイベントで正体が明かされていた（みんな知っていたけど）。１日目のメインステージのラストがスカパラで、アンコールで飛び跳ねながら出てきて『星降る夜に』を歌うヒロトが本当にうれしそうだった。
この年は、COUNT DOWN JAPAN（大阪会場）にも行って、スカパラで年越し。
RISING SUN ROCK FESTIVAL 2007 in EZO
修士１回生。この年は、京都から夜行バスに乗って荒吐にも行った。
曽我部さんに一番はまっていた頃（テレフォンラブに象徴されるような！）で、この年のライジングサンはその曽我部恵一バンドがトリだった。
オオトリの１組前のCoccoのセッティングでトラブルがあり30分押し。Coccoが終わるとほぼ同時に日の出を迎える中、出てきた曽我部恵一バンドの面々は自ら音出しを15分くらいしたあと（普通ステージの転換は30分）１回はけることもなく「じゃあやります、曽我部恵一バンドです」みたいな感じでスタート。
というところであわてたように出ばやしがかかり、しょうがないなって感じでにやけながら４人で円陣。出ばやしが鳴り終わると同時に「おー！」と叫び、ステージの真ん中に小さく集まった４人が弾きだしたイントロはもちろん恋人たちのロック！
ハナレグミのステージにスチャダラがゲスト出演して、初めて生ブギーバックを聴いた。
そのハナレグミは２日連続出演したスカパラの１日目にゲスト出演。この年のGREENOASISは小さい箱で（確か途中で半分壊れていた）、すごい列に並んでなんとか入ったのだった。
THA BLUE HERBや、この頃はまだあったMOON CIRCUSでみたコーネリアスもすごかった。
この年のライジングサンは、リストバンドが足りなくなるほどお客さんが入り、そしてトイレパンク事件が起こった年でもあった。
RISING SUN ROCK FESTIVAL 2008 in EZO
前年末のボード旅行で親しくなった後輩たちと一緒に行ったのがうれしかった。ライジングサンの後は男３人で延泊して、旭山動物園に行った。
この年は、会場についてテントを張るまでが大雨で、リュックの中身からすべてずぶ濡れになった。最初にみたフラカンを待っていると、メインステージからくるりのワンダーフォーゲルが聴こえてきた。
出演アーティストにロックインジャパンに重複出演をしないように依頼したことが波紋を呼び、でも曽我部さんは別ユニットで両方に出演していた。昨年までは北海道中から集めていた仮説トイレを、本州にまで手を広げて確保したらしい。
夕方のRED STAR FIELDでみた曽我部恵一ランデヴーバンドが、風が気持ちよくて最高だった。
まだアルバムを出す前のpe'zmokuがなぜか1時間20分の持ち時間で出演、夢中になって踊った。最後に銀杏BOYZのライブをみたのも、この年のライジングサンだった。
それからメインステージのオオトリ前の一枠が最後まで未発表だった。友達の部屋でビールを飲みながら、これはサニーデイ再結成あるんじゃないか！？と友達が言い出し、その通りサニーデイが出演。学生時代最後のフェスでサニーデイをみた、という鑑賞に浸った夏フェスだった（でも誰も付き合ってくれなくて一人でみた！）。
2009
社会人１年目、夏フェスに唯一行かなかった年。
年末に向けて七尾旅人×やけのはらのRollin' Rollin'が盛り上がり、来年は絶対にRollin' Rollin'を生で聴こうと、友達と一緒に（社会人１年目特有のある種の全能感も相まって）盛り上がった。
RISING SUN ROCK FESTIVAL 2010 in EZO
社会人２年目、2010年はRollin' Rollin'を追いかけてフェスを回った１年だった（大げさ！）。
４月はKAIKOO@東京晴海埠頭へ。会場外の小さいステージでのやけのはらのライブ、最高だった。トリがクラムボンで、海風が気持ちよくて、きらきらしたフェスだった。
８月、ライジングサンへ。はじめて飛行機で行ったライジングサン。前日の夕方に前泊して、さっぽろ夏祭りでビールを飲んでから、ジンギスカンを食べた。
2008年は17,000円だったHEAVEN'テントサイト付入場券が21,000円になっており、出演アーティスト数が目に見えて減りはじめ（メインステージのアーティスト数が、2008年17組⇒2010年14組⇒2013年12組）、大人路線に明確にフォーカスした印象。
ライジングサンの直前に降った大雨で全面沼地状態の会場を、PE'Zから七尾旅人まで走ったことを思い出す。
１日目のトリのスチャダラ、それから何といっても１日目深夜のオオハタハラダナガヅミが、こういうライブをみたくてライジングサンに来ているのだと思わせる、いつまでも夜を楽しんでいたくなるライブだった。
10月、STARS ONへ。穏やかで昼寝したくなるような居心地のいいイベントで、イルリメが最高だった。トリのスチャダラでは、会場の電気を消してブギーバックを合唱。
iPhoneがすっかり普及して、フェス＋twitterがお決まりになった頃。おれもフェスでしか起動しなかったFastweetLiveを見ながら悦に入っていた。
RISING SUN ROCK FESTIVAL 2011 in EZO
社会人３年目。
四人の侍で、斉藤和義が歌う『歩いて帰ろう』に、山崎まさよしがはもってギターソロを弾く、そんなライブをみるなんて夢のようだった。
向井秀徳＋七尾旅人のステージで、向井さんの『CRAZY DAYS CRAZY FEELING』を聴いていて、おれも3.11以後を暮らしているのだと唐突に実感を持った。
ライジングサンが終わってから札幌で銭湯に行くという新しいパターンを確立（ついでに会場までタクシーを使うことに抵抗がなくなった）。そしてこの年、（後輩たちのテントの立派さに憧れ）５年間ライジングサンで使ったテントを捨てて帰ってきたのだ。
この年もSTARS ONに行き、ZAZEN BOYSの演奏に圧倒された。
RISING SUN ROCK FESTIVAL 2012 in EZO
社会人４年目。この頃から、ライジングサン以外でライブを行くのは年に数回あるかないかになってきた。。
はじめて前泊せずに当日朝の飛行機で北海道へ。
この年から会場のレイアウトが大きく変わり、MOON CIRCUSが消滅。独特の光演出＆雰囲気だったMOON CIRCUSがなくなったのは寂しいけど、会場内の移動の利便性やトイレ事情は格段に良くなった。新調したテントを後輩たちに組み立ててもらってスタート。
この年のライジングサンは、Perfumeが出演、すごかった。
フィッシュマンズを初めてみて、RAINBOW SHANGRI-LAのテントステージの中で音の中を自在に泳ぐ原田郁子がキラキラしていた。
友達に教えてもらって１日目の最後にみた初恋の嵐が最高だった。それから、当時一番追いかけていたいバンドだったandymoriのライブを初めて（＆最後に）みたのだ。
トリはエレファントカシマシで、アンコールは『俺たちの明日』だった！
RISING SUN ROCK FESTIVAL 2013 in EZO
社会人５年目。この年のライジングサンは一人でライブをみていることが多く、転換の間にぼんやりといろいろなことを考えていた（仕事がちょっと煮詰まっていた時期だったのだと思う）。
１日目夜のサンフジンズ、奥田民生が唄う青い空と HOW TO GO がかっこよかった。久しぶりにみた真心ブラザーズも最高だった。
それから、RED STARの脇で、ミッシェルのライブ映像に合わせてみんな踊っているのも楽しく、そのあとチバの今のバンドの音圧と張り合いながら後輩と飲んだのも楽しかった。
終演後、記録的豪雨に見舞われるも、テントの中は無傷。昼前まで寝て起きたら、嘘のように晴れていた。
それから飛行機が取りづらいことを言い訳に後泊することを覚え、モエレ沼公園をレンタサイクルで走り回って帰ってきた。
RISING SUN ROCK FESTIVAL 2014 in EZO
社会人６年目。
フェスは初めてという後輩と一緒に行った。後輩は数年前に貸した『フィッシュマンズ 彼と魚のブルーズ』を、トリのフィッシュマンズのライブまでに見るといってフェス会場で読破。
2009年や2011年に出演したときはみていなかったので、2008年のEARTH TENT以来で、サカナクションのライブがこんなことになっているとは知らなかったのだ。メインステージであのMOON CIRCUSをスケールアップしたような光演出の中、ひたすら打ち込み＆セッション。それが30分くらい続いて、その中から歌が立ち上がってきた時の高揚感は圧倒的だった。
フラワーカンパニーズ、まだ西部講堂でやっていた頃のボロフェスタ以来でみたeastern youth。
山下達郎のRED STARでのステージも心地よかった（夜中に演奏するのはデビューの年以来と言っていた！）。すっかりライジングサンの顔であるスカパラのライブは、モンパチをゲストに迎え、いつも以上に多幸感にあふれたライブだった。
そして、トリはフィッシュマンズ、UAの力強くのびのびした歌声もフィッシュマンズの音に最高に合っていた。
そして、この年のライジングサンは、かつて記憶にないくらいのきれいな朝日。
前年に味を占めてこの年も後泊。ライジングサンが終わり、ホテルで昼寝してからジンギスカンを食べるまでの間、後輩と札幌を散歩したのが、穏やかで心が軽くなるような時間だった。翌日は路面電車とロープウェイを乗り継いで藻岩山に行って、新千歳空港で石狩漬を買って帰ってきた。
五大ニュース2014
今年は、STAP細胞と、黒子のバスケ脅迫事件「無敵の人」、それからイスラム国が印象に残った１年でした。
まったく本を読まなかったので今年は印象に残った10冊は書けないけれど、『ナタリーってこうなってたのか』が良かった。
なんと大みそかは学生時代のバイト先で６年ぶりのホールをします。
そんなわけで今年も勝手にMy５大ニュースで一年を締めるとします。
番外編：30歳になった
30歳ってなるものなんやな。
５位：ハイキング
本格的なものではないけど、去年に引き続きハイキングをした。
大文字山、比叡山、葛城山、須磨、大台ケ原、私市星のブランコ、熊野古道に行った。
歩いているときは無心になるし、登っていってぱっと景色が開けたときはの高揚感がたまらない。
４位：RSR
今年のライジングサンは、近年記憶にないくらいきれいな朝日だった！
６年ぶりと言っていたフラワーカンパニーズやeastern youthが最高だった。
ライジングサンが終わり、ホテルで昼寝してからジンギスカンを食べるまでの間、後輩と札幌を散歩したのも穏やかな時間だった。
３位：ETロボコン
今年はチームビルディング面で辛い時期が続いたけど、合宿で楽しすぎて４時まで飲んだことと（２日目寝坊して後輩を待ちぼうけにしたけど！）、大会前日にみんなでわいわい調整したのが楽しかった。
４年やっても全国行けなかったけど、準優勝できて、いい思い出になりました。
２位：常連気取り
今年の２月、常連を集めた鍋パーティーに呼んでもらってから、あれよあれよという間に味わったことのない世界をたくさん見せてもらった１年でした。
仕事帰りにふらっと立ち寄って、店長や常連さんたちと話したり話さなかったりしながらおいしいご飯が食べられる、学生時代のバイト先の次に特別な居酒屋です。
１位：決断
今年は、「決める」ということに疲れてもしまい、自分の考える体力のなさに萎えてもしまった。
でもその中で、４つの（すべてが絡み合っているけど）大きな決断をした。正確には４つ目はしつつある。
来年は新しい生活を迎えるんだ！
皆様が素敵な2015年を迎えられますことを。よいお年を！
マネジメントについて
今年は、組織のマネジメントについて考えるきっかけになった１年だった。
100名以上常駐のお客様先で仕事をしていたこと、上司が２回替わり３人のスタイルがそれぞれ違ったこと、ETロボコンのチーム運営に苦しんだことが理由だと思う。
下記のプロセスを回すとする。
1. 方針を立てる（意識決定をする）
2. 目標を立てる
3. 施策を決める
4. 計画化する
5. 実行する（＆計画を調整する）
6. 評価する
就職する前は、1-3がマネジメントの仕事であり課題解決だと考えていた。取り組むべき価値ある課題を見つけ、SMARTな目標を立てて、具体的かつ現実的な施策を決める。『イシューからはじめよ―知的生産の「シンプルな本質」』に書かれているのはこの領域の話だと思う。
それは、学生時代に知っていた組織は、個人の能力やがんばりで物事が進む規模のもの、みんなが比較的同じ方向を向いるもの（研究室やバイト先、サークルなど）だったからだと思う。4-5は意識せずに進んでいき、6に至っては重要性を認識していなかった。
でも実際のところは、就職して企業に所属しても似たようなものだったりする。
期初には必ずその年の事業計画みたいなものを立てて共有しないといけないので、1〜3（2で終わっているケースもある）は進められる。
だけど、往々にして仕事というのは想定より忙しいものなので、スケジュールが立てられなかったり、担当がアサインされなかったりして4以降が進まず、期末には期初に立てた施策などなかったことになっていたりする（管理職がどう査定されているのか知らないけど）。
そんな中で、今年は、特に「5. 実行する」の重要性を学んだ１年だった。
「5. 実行する」はどうやったらうまく進められるのか？
戦略の現場化といったりもするみたいで、恐らくは当たり前のことを当たり前にやるしかないのだけど、当たり前のことを当たり前にやるのはとてもパワーがいることだ。
- 主担当をByNameで決める（複数人を主担当するとボールの見合いが起こりがち）
- 全員が腹落ち、納得するまで、背景や目的を説明する（マネジメントが矢面に立って自分の言葉で伝える）
- 情報レベルを揃える（みんなが何となく知っていることでも定期的な全体発信が重要）
- 定期的にしつこく言い続ける（上が言わなくなると、温度感が下がったのだと感じて怠けてしまうのなのだ。。）
- 進捗や課題をフォローし続ける（例えば、メールの返信がない人にリマインドし続けて回収しきるとかいうレベルでも）
もう一つ、「人を育てる」ことについて。
システム開発では、最終的な仕様はドキュメントとして残っていても、その仕様になっている理由や経緯は当時のメンバーの暗黙知になっていることが多い。また大規模なシステムでは、後から入ったメンバーには全体感が掴みにくく、勘所が分からない。
去年の終わりから、大規模なシステムの保守にアサインされて、今年は育成される１年だった。
- 生き字引みたいな人から、全体の概要や繋がりを説明してもらう（それを被育成者がドキュメントに起こしてレビューを受けるのがベター）
- 育成主担当（「まずその人に聞いてよい」という人）を決めて、育成主担当の隣の席にする
- 情報を流し、温度感を共有する
- 外部とのメールのやり取りのCCに入れてもらう（メールが情報共有ツールとしてどうなのかというのは置いておいて。。）
- 会議に同席させて議事録を書いてもらう
- 矢面に立たせる（小さな規模のことでよいので任せて外部への説明まで果たしてもらう）
- ＋システム開発固有のことでいえば、アーキテクチャ（インフラ・ミドルウェア構成やフレームワーク）を知る（関係者が増え、横串の理解に繋がる）、シナリオテストのシナリオを読む
議事録でもなんでも成果物を作って説明するこが重要で、こんなことが「人を育てる」ために具体的にできることなのではないかと考えた。
POIで大量データをxlsxファイルに書き込む際のパフォーマンス問題
https://github.com/icchw/XLSX/
Javaプログラムで、POIを使って数万件のデータをxlsxファイルに書き込もうとすると、非現実的なメモリー消費量になって書き込めない。
この問題に対応するために、POIを介さずにDOMを使ってXMLを書き込んでいくライブラリを作成してみた（DBから読み込んだデータなどを行単位で書き込んでいくような用途を想定）。
ただし、xlsxファイルを一から作るのは煩雑なため、事前にExcelで作成した物理ファイル、または、POIで作成したWorkbookをテンプレートとして使用する。
xlsxファイルの拡張子をzipに変更して展開すると、xl/worksheetsフォルダ内に、シートごとにデータを保持したXMLファイルがある（ex: sheet1.xml）。
このXMLファイルのsheetData要素内にデータを書き込んでいき、元のXMLファイルを置き換える実装としている。
ただしテンプレートファイル上で事前にヘッダ行を書き込んでおくケースも想定されるため、全列が空または式の行を最初の空行と判断して、当該行から書き込みを開始する。
またテンプレートファイル上で、最初の空行に設定した書式・列全体に設定した書式・最初の空行に挿入したExcel式を、各行の同一列にコピーしている。
なおExcelで作成したxlsxファイルでは、文字列は独立したsharedStrings.xmlというファイルに保持される。ライブラリ作成時は実装の簡便化のため、sharedStringsは使用せず、各セルの要素にinlineStrとして直接文字列を書き込んでいる。
使用方法は以下の通り。Stringは文字列、Number, BigDecimal, Date, Calendarは数値、その他はtoString()した結果が文字列として書き込まれる。
①書き込むデータのDTOクラスを作成
②XlsxWritable interfaceをimplements
③getMapメソッドを実装、列番号（0始まり）をkey、書き込む値をvalueとするmapを返す
④書き込み対象のシートのシート名・当該DTOのListを引数として、writeSheetメソッドを呼び出す
参考： Apache POI(Java) でExcel その2(パフォーマンス編)
使用例
https://github.com/icchw/XLSX/releases/ からダウンロードできるzip内に、jarファイルと合わせてSample一式を置いている。
テンプレートファイル
DataDto.java
import icchw.xlsx.XlsxWritable; import java.math.BigDecimal; import java.util.Calendar; import java.util.Date; import java.util.HashMap; import java.util.Map; public class DataDto implements XlsxWritable { public DataDto(String str, double d, BigDecimal bigDecimal, Date date, Calendar cal, String prefectureCode) { super(); this.str = str; this.d = d; this.bigDecimal = bigDecimal; this.date = date; this.cal = cal; this.prefectureCode = prefectureCode; } private String str; private double d; private BigDecimal bigDecimal; private Date date; private Calendar cal; private String prefectureCode; public Map<Integer, Object> getMap() { Map<Integer, Object> map = new HashMap<Integer, Object>(); map.put(0, str); map.put(1, d); map.put(2, bigDecimal); map.put(4, date); map.put(5, cal); map.put(6, prefectureCode); return map; } }
Main.java
import icchw.xlsx.WorkbookWrapper; import java.io.File; import java.io.FileOutputStream; import java.math.BigDecimal; import java.text.SimpleDateFormat; import java.util.ArrayList; import java.util.Calendar; import java.util.Date; import java.util.List; public class Main { public static void main(String[] args) { String sheetName = "sheet1"; try { // 使用例１：物理ファイルをtemplateにする場合 File template = new File("input/template.xlsx"); WorkbookWrapper wr = new WorkbookWrapper(template); // 使用例２：メモリ上のWorkbookをtemplateにする場合 // XSSFWorkbook wb = new XSSFWorkbook(); // wb.createSheet(sheetName); // WorkbookWrapper wr = new WorkbookWrapper(wb); // Write xmls List<DataDto> dataDtos = prepareData(); System.out.println("start"); long startTime = (new Date()).getTime(); wr.writeSheet(sheetName, dataDtos); long endTime = (new Date()).getTime(); System.out.println("end:" + ((long)(endTime - startTime)/1000) + "s"); // Generate zip FileOutputStream output = new FileOutputStream(new File("output/" + generateFileName() + ".xlsx")); wr.write(output); output.close(); } catch (Exception e) { e.printStackTrace(); } } /** * テストデータ作成 * @return */ private static List<DataDto> prepareData() { List<DataDto> dataDtos = new ArrayList<DataDto>(); for (int i=0; i<50000; i++) { dataDtos.add(new DataDto("こんにちは", (double)i/100, new BigDecimal("-0.5"), new Date(), Calendar.getInstance(), String.format("%1$02d", i%47+1))); dataDtos.add(new DataDto("", (double)i/100, new BigDecimal("0.5"), null, Calendar.getInstance(), String.format("%1$02d", i%47+1))); } return dataDtos; } /** * テスト用ファイル名生成 * @return */ private static String generateFileName() { SimpleDateFormat sdf1 = new SimpleDateFormat("yyyyMMdd_HHmmss"); return sdf1.format(new Date()); } }
実行結果
