読者です 読者をやめる 読者になる 読者になる

Bel*log

プログラミングと読書たまに麻雀。

2015年7月の読書メーター

2015年7月の読書メーター
読んだ本の数:21冊
読んだページ数:4982ページ
ナイス数:7ナイス
http://bookmeter.com/u/6581/matome?invite_id=6581

あとは、オーバーロードWeb版をmobiに変換してKinleで全部読みました。
オーバーロード面白いです。
オーバーロード:前編
オーバーロード:後編
今は書籍版を読んでますが、しばらく楽しめそうです。
アニメも本当に面白い。今期始まったアニメじゃ一番面白いんじゃないか?

老人と海 (新潮文庫)
読了日:7月31日 著者:ヘミングウェイ
http://bookmeter.com/b/4102100040

■世界でもっとも強力な9のアルゴリズム
読了日:7月27日 著者:ジョン・マコーミック
http://bookmeter.com/b/482228493X

■国語教科書の中の「日本」 (ちくま新書)
読了日:7月18日 著者:石原千秋
http://bookmeter.com/b/4480065121

■SE の教科書 ~成功するSEの考え方、仕事の進め方 (技評SE新書001)
読了日:7月18日 著者:深沢隆司
http://bookmeter.com/b/4774126527

■強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」
読了日:7月14日 著者:ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン
http://bookmeter.com/b/4152094338

■新訳 星の王子さま
読了日:7月12日 著者:アントワーヌ・ド・サン=テグジュペリ
http://bookmeter.com/b/4796646957

■すのはら荘の管理人さん (1) (IDコミックス 4コマKINGSぱれっとコミックス)
読了日:7月12日 著者:ねこうめ
http://bookmeter.com/b/4758082383

ONE PIECE 78 (ジャンプコミックス)
読了日:7月12日 著者:尾田栄一郎
http://bookmeter.com/b/4088804228

孤独のグルメ 【新装版】
読了日:7月11日 著者:久住昌之
http://bookmeter.com/b/459405644X

図書館戦争 図書館戦争シリーズ (1) (角川文庫)
読了日:7月7日 著者:有川浩
http://bookmeter.com/b/4043898053

■社会言語学入門<改訂版> 生きた言葉のおもしろさに迫る
読了日:7月6日 著者:東照二
http://bookmeter.com/b/4327401579

■テストから見えてくるグーグルのソフトウェア開発
読了日:7月6日 著者:ジェームズ・ウィテカー,ジェーソン・アーボン,ジェフ・キャローロ
http://bookmeter.com/b/482228512X

■高1ですが異世界で城主はじめました6 (HJ文庫)
読了日:7月6日 著者:鏡裕之
http://bookmeter.com/b/4798610240

■高1ですが異世界で城主はじめました5 (HJ文庫)
読了日:7月6日 著者:鏡裕之
http://bookmeter.com/b/4798609579

JavaからRubyへ ―マネージャのための実践移行ガイド
読了日:7月5日 著者:BruceA.Tate
http://bookmeter.com/b/4873113202

■高1ですが異世界で城主はじめました4 (HJ文庫)
読了日:7月5日 著者:鏡裕之
http://bookmeter.com/b/4798609129

■高1ですが異世界で城主はじめました3 (HJ文庫)
読了日:7月5日 著者:鏡裕之
http://bookmeter.com/b/479860822X

■NEW GAME! (2) (まんがタイムKRコミックス)
読了日:7月4日 著者:得能正太郎
http://bookmeter.com/b/4832245465

ヘウレーカ (ジェッツコミックス)
読了日:7月4日 著者:岩明均
http://bookmeter.com/b/4592135008

■ライフアライヴ! キミと始める学園総選挙 (MFコミックス アライブシリーズ)
読了日:7月4日 著者:ねこめたる,あさのハジメ
http://bookmeter.com/b/4040672925

■ハナヤマタ (1) (まんがタイムKRコミックス フォワードシリーズ)
読了日:7月4日 著者:浜弓場双
http://bookmeter.com/b/4832240897

2015年6月の読書メーターより『人月の神話』

4月から6月の3ヶ月間に身をもって体験した『人月の神話』。スケジュールの遅延、膨れ上がった予算、そして欠陥製品といった怪物。銀の弾丸?そんなものはなかった。
本書を読み、思索した人がマネジメントをしていたならば、もっとやりようはあったのではないでしょうか。人海戦術で人をひたすら投入するのではなく、優秀な人を適切なタイミングで投入しチームとして前進できたはずです。

人月の神話【新装版】

人月の神話【新装版】

『人月の神話』は原著初版が1975年、つまり40年前の書籍ですが、プロジェクトの問題における本質は変わっていない。
人月と呼ばれる言葉を使い仕事を進め、失敗するプロジェクトは後を絶たないわけですが、いつになったら前に進めるのかと暗澹たる気持ちになり、読了後は3ヶ月間属していた案件の人たちに配って読ませてえ…と思いました。


難しさを本質的なものと偶有的なものに分けて考えたり、問題の認識と対応を思索した議論には今でも価値があります。
新装版は振り返りがあるのも良いですね。


人の数をそのまま人月へ換算して、うまくいくはずないのは明らかなので、スキルほぼ無視でとりあえず人かき集めてるプロジェクトには今後近寄りたくないなぁと思ったのでした。将来マネジメントやるにしても、過去の知見を学んだ私たちは、『人月の神話』なんて信じない心ある管理者になるように努めないといけないですね。


2015年6月の読書メーター
読んだ本の数:43冊
読んだページ数:9315ページ
ナイス数:14ナイス
http://bookmeter.com/u/6581/matome?invite_id=6581

続きを読む

大規模開発のJUnitではresourcesを分けたほうがいいのではという話

今参画しているプロジェクトでは、業務共通部品と業務部分のチームがそれぞれ分けられています。
業務共通部品はJARファイルで提供される形です。
開発が並行して進められているため、単体テストでは業務共通部品をモック化し、テストするという方針があります。
しかし、現状、単体テスト用にresourcesが分けられていません。


これは問題ではないでしょうか。
実際JUnitが動かなくなり、業務共通部品がリリースされる度に同様の問題が発生しています。
(そもそも業務共通部品側もちゃんとテストしろよって話ではあるが…。)


業務側では、業務共通部品を使用するため、resources配下のXMLに何をimportするのかという設定を記述します。
しかし、その設定を記述しているがために、業務共通部品側のXMLに問題がある場合、設定ファイルを読み込んだ際にエラーになります。
単体テスト用にresourcesを分けられていないと、業務共通部品の欠陥のせいで、単体テストが動かなくなるわけです。


JUnit用で設定ファイルをいじりたい場合は、そもそもresourcesを分けると思うのですが、大規模開発でJARファイルとして提供される業務共通部品がある場合も分けたほうがいいのではないかと思いました。



JUnitうまく動かなくなって、うごごごgってなった愚痴でした。Ciao!

2015年5月の読書メーター

去年あたりから読書スタイルを少しずつ変えていて、最近では10~20冊を同時に読んでいるのですが、そのような読み方を推奨している書籍がこれです。

読書スタイルを少し参考にしていた友人もこの本を読んで、現在のスタイルになっていったとのことでした。
昔から何冊かを同時に読んではいたのですが、10冊以上を同時並行で読むようになってから、一冊一冊読んでいる時よりもたくさん本が読めるようになったと思います。
思えば、自分が受験生の時は1日に7科目を勉強していて、飽きないように時間や場所でやる教科を変えたりしていたものでした。読書も、時間や場所で読む本を変えたほうが、脳にとっては刺激的なのかもしれません。
今はKindleもありますから、本を1、2冊とKindle端末を鞄に放り込んで出かければ、何冊でも同時に読めますね!素敵です。


2015年5月の読書メーター
読んだ本の数:27冊
読んだページ数:6772ページ
ナイス数:77ナイス
http://bookmeter.com/u/6581/matome?invite_id=6581

続きを読む

時間貯蓄家になっていないか

SHIROBAKOがとても良かった。放映終了してからも何回も見返している。こんなに毎回面白くて感動した作品は初めてかもしれない。まだ観てない方は是非!
今はP.A.Worksつながりで花咲くいろはをまとめて観ている。これもまた面白い。


早くも2015年も4月、新年度になってしまった。


最近読書熱が上がり続けている。
直近で読んで面白かったのはミヒャエル・エンデの「モモ」です。なんで今まで読んでなかったんだろう。
児童書だと思って侮る無かれ。大人になった今だからこそ面白く感じた部分があった。
現代人は気づいていないだけで、灰色の男たちに時間を奪われてないだろうか。時間と気持ちに余裕のある生活を送れるように気をつけたい。

モモ (岩波少年文庫(127))

モモ (岩波少年文庫(127))


そういえば、昨日Twitterを眺めていて、こんなのを見かけた。


itpro.nikkeibp.co.jp
設計作業は当初60人体制でプロジェクトをスタートしたが、遅延が始まったため、順次増員して、200人→450人→1300人(!?)。itpro.nikkeibp.co.jp
絶対関わりたくない案件だこれ。


anond.hatelabo.jp

そもそも、開発の遅れは人を増やす事で対処できるものなのだろうか?

やはり人海戦術というものはあるんだと思うんだけど

正しい分業化とマネージメントが行われずに盲目的に人数を増やすと、ただただ炎上にしかならないってこと。お金だけが莫大にかかっていくということ。

ほんまこれに尽きる。


初めて客先に出ていて、今にも火が吹きそうなんですが、この特許庁のやつに比べたら全然大丈夫そうなのでなんとなく気楽に構えている。

2014年振り返り

「最近の若者をすぐ仕事を辞める」という指標の新卒3年以内の離職率に貢献し、全然関係ない業界から転職してSEになりました。転職という人生ががらっと変わる選択をしたので色々ありました。

1月

新卒で入社した会社で千葉から栃木の那須塩原に転勤したのが2013年9月。異動先での業務も慣れはじめた頃、頭のなかは"転職"の二文字で満ち溢れていた。大阪での全体研修1週間前から転職サイトを巡回し、研修中に行われる試験の勉強そっちのけで独習Rubyを読んでいた。職務経歴書の草稿を書き始める。

2月

転職エージェントなるものに登録した。アドバイス自体はそこまで役立たなかったが、面接を受ける際に考えておくべきことや想定される質問を教えてくれたのでそれは良かった。未経験からのプログラマやSE職というのは中途や第二新卒だと敷居が高いのかなとは思う。年齢的なことを言うと自分はぎりぎりだった。25歳くらいまでなら全然問題ないと思う。
会社が繁忙期に入り忙しい中、職務経歴書を書き上げ、数撃ちゃ当たる方式で応募していった。

3月

会社の忙しさが爆発する。増税前で売れ行きが伸びたためだ。この時期になると休日は2、3社面接を入れて、週に2回栃木と東京を往復していた。ただでさえ繁忙期は休日が少ないのでほぼ休みなしで動いていた。
今の会社の面接が終わった日は、誕生日だったのだが、その日に、というか面接終わって2時間も経たないうちに内定をもらった。
その後、内定をもらっていた別の会社で飲み会をやるというから行ったら、連日の仕事の疲れがどっときて記憶なくなって二子玉川駅まで行ってしまい、翌日朝から栃木で仕事あるのに帰れずマクドナルドで一夜を明かした。
朝起きたら携帯入った紙袋がなくなっていてかなり焦った。探す時間もないのですぐ栃木に帰って仕事。後日、落とし物として届けられていたので休日を潰して取りに行った。なんだか大変な誕生日だった…。


次の働き口が見つかったら、今働いている会社に辞意を伝えて退職手続きをしなければならない。
辞意を伝えるにはどうしたらいいんだ?お作法とかあるのかな…?などと考えたりしたが、退職願などは別に用意せず当時の上長に口頭で辞めることを伝えた。職場の人には一切そんな素振りを見せていなかったため驚かれる。自分の目論見通り4月末で辞めることが決定した。
退職が決まった瞬間は開放感がすごかった。

4月

有休は4月末に固めてもらい、やり残した作業や引き継ぎができると思っていたが、他部署のヘルプに行かされた。物流の繁忙期は3月・4月なので配送センター手伝ってこいという本社の意向だった。その配送センターまで車で片道70kmあったが、ヘルプに行ったわりに暇だったので、良い息抜きになった。所属部署にはなんとなく居づらいしね。
あっという間に時間は過ぎ、退職日になった。
書類上は4月末まで在籍していたが、有休で1週間以上休みがあったので軽くニート期間を楽しんだ。

5月

今の会社に入社。2ヶ月研修期間があるらしい。
JavaMySQLなどの基礎的なところを学んだ。
よくわからんところが多い。
仕事せず勉強してていいの楽しい。

6月

相変わらずJava。Struts1.0やった。可能であればもう触れたくない。
よくわからんところがまだ多い。
仕事せず勉強してていいの楽しい。

7月

研修もう1ヶ月あったらしい。
Spring FrameworkJUnitJMockitDBUnitSeleniumを使った。
プログラミングの理解が急に進み始める。このへんから技術書を貪り読み始める。
仕事せず勉強してていいの楽しい。

8月

案件にテスターとして入った。
詳細設計書とコード読んでテストケース洗い出しテスト仕様書を書くってのを8機能くらいやった
後に先輩からの無茶ぶりであったことを酒の席で他の先輩から聞く。
JUnitJMockitDBUnitSeleniumにだいぶ慣れた。
Springちょっとわかるようになった。

9月

違う案件にアサインされる。詳細設計書から実装、テストまで出来る新人育成にはもってこいな案件に恵まれた。
1ヶ月間詳細設計書を書いた。数だけで言うとチーム内で一番書いたっぽい。
初めて詳細設計書を書いていく過程で学びは多かった。この頃CODE COMPLETEを読んでいた。
詳細設計書の書き方やチームマネジメントについてあれこれ考えた。

10月

詳細設計フェイズが終わり、製造フェイズに移った。

このへんちゃんとわかってる人がプロジェクト内にあまりいなかったので結局リファレンス読みつつ実験しながら理解した。
あとは画像表示やCSVアップロードの実装なども少し悩みはしたが勉強になった。

11月

引き続きひたすらジャヴァジャヴァしてた。
スケジュールには遅れが出ていたが、自分が悪いとは全く思っておらず、スケジュールの引き方が現実に沿ってないだけだと思っていた。
JavaよりJavaScriptJQueryに苦労した。
仕事外ではRubyを触り始めた。

12月

師走に入ってすぐインフルエンザにかかって1週間休み、有休が半分吹っ飛ぶ。
しかし復帰後遅れを取り戻し、前倒しで担当機能の実装とテストは終了した。
11月にスケジュールに関して自分が思っていたことは正しかったなと確信する。

総括

仕事内容は大幅に変わりましたが、仕事のやり方は共通するところが多いと思っています。
Rebuid.fmで伊藤直也さんが言っていた話に通じるんですが、プロジェクトで問題を抱えているとすれば、技術的な問題より組織の問題だったりコミュニケーションの問題がほとんどなので、仕事のやり方をある程度おさえておけば全然関係ない職種に変わってもあとはどう適応していくかが大事ではないでしょうか。Rebuild: Aftershow 71: Green Grass On GitHub (Naoya Ito)


SEは忙しいとよく言われますが、正直なところ私が元いた会社のほうがたぶん忙しいし、忙しさの質が全く違いますね。部署や役職やプロジェクトによるところが大きいとは思うのですが。今のところ炎上案件には関わっていないのですが、周りを見渡すとわりと炎上してたりするので、そのうち関わる機会があるかもしれません。


個人的には前の会社から転職して良かったことは下記5点でしょうか。これがあるだけでかなりまっとうな生活になりました。

  • 毎日決まった時間に出勤
  • 土日休み
  • 転勤ない
  • お昼ごはん外に食べに行ける
  • 有休とれる

有休が取りやすいのはかなり精神的に余裕をもたらしますね。


書籍代に20万以上突っ込んだり適度に遊んだりして楽しかった1年でした。
今年はわからないことだらけで大量にインプットしたので、来年はバランス取りながらアウトプットを出していきたい。

来年の抱負

  • たくさんコード読み書きする*1
  • 英語でコミュニケーション取れるようにする
  • ひとつ上の視点をもって仕事をする

*1:とりあえずJavaのCoreAPIあたり読みます

案件に配属され実装とテストを書いて思うところ

はじめて詳細設計書を書いて製造に入ってから2ヶ月が経ちました。12月に入っていきなりインフルエンザにかかって丸一週間休んで進捗やべえやべえ言ってましたが、今は進捗出すマッスィーンになっています。
詳細設計書を書いていた時とはまた違う問題点があり、将来自分がプロジェクトマネージメントをするならどう対応するか、考えられる機会にはなりました。

  • 詳細設計書通りに実装しても動かない????

自分ははじめ、詳細設計書を細かく書きすぎたせいで、こんなことが発生したのだと思いました。
しかし、細かく考えて作成した詳細設計書がそこまで悪いとも思いません。オフショアも使うのですから。


一つの対策案としては、詳細設計書を書いているときにプロトタイプのコードを書いて実際に動かすべきだったのではと思います。
プロトタイプのコードを書いてさえいれば、いちいち詳細設計書を修正せずに済んだ箇所が無数にありますし、それぞれが最初に書く機能でいきなり躓くこともなかったでしょう。使用するFrameworkに慣れ親しんでいる人が1人いればその人に工数を振って書かかせれば良い。今回のプロジェクトでは、そういう人がいなかったのも問題点といえば問題点ですが、理想は現実とは違う。

  • プロジェクトの共通部分がクソ????

プロジェクト共通で用意しているところの入力チェックアノテーションがダメだったりドキュメントがダメだったり。こっちでいじれないところがクソだとQAでボロクソ言うしかないです。良い子の皆はドキュメントちゃんと書こうな。反面教師にします。

  • プロジェクト独自(追加)のコーディング規約

Excelファイルであるのはいいけど、時系列順に書いていってるだけなので非常に見づらく、とてもコーディングしている時にしっかり参照して欲しいとは思えない構成。せめてhtmlではこう、とかControllerだとこう、とか分かれてたらいいのに。自分でプロジェクト管理するならちゃんと分けようと思いました。

  • レビューの持って行き方、やり方

終わらないレビュー。終わらない修正。これをなくさないといけないです。
レビューはとても大切な工程だと思いますが、時間のかけ過ぎはアホらしい。
実際、今はレビュー工数が大変なことになっていて負担になっています。ここまでくるとやり方に問題があります。


プロジェクト全体でどういう方針でコード書くのかを共有し、レビューもその観点で見る。その役割がコーディング規約だと私は理解しています。ちゃんとしたコーディング規約を作ることが第一ではないでしょうか。
あとは大体コミュニケーションで解決できる問題だと思います。
レビュー依頼する前にレビュアーにちらっと見てもらうとか、こんな感じの方針でいいですよね的なジャブを打ってレビューでの指摘を減らす。レビュアーもレビューイも指摘事項が減れば楽です。
新人の私はまだ指摘事項が多かったので、次回からは気をつけたいと思います。
今は指摘事項が多い分だけ、自分の"気をつけるリスト"が充実するので、今回のプロジェクトではガシガシ指摘してくる人にコードレビューして頂いてすごく良かったです。

  • タスクの振り分け方

機能で似たようなところなどは、コードが再利用できたり、考える事が似通っていたりするので、出来る限り同じ人がやるべきだと思います。違う人がやったり、同時進行で別々の人が開発を進めたりするのはとても効率が悪い。
これもプロジェクト管理する側になったら詳細設計書を全部読んで、ちゃんと判断したいと思いました。

  • 単体テスト
    • JUnit…「プログラミング現場の単体テスト」と「JUnit実戦入門」読めばいいのでは。あとは実践あるのみな感じします。オールグリーンは楽しい。
    • DBUnitSpring FrameworkだとDaoのテストで使います。データベースいじるクラスをテストするためにはテストデータが必要でテストの前に元のデータバックアップしてセットアップしてテスト終わったらバックアップからデータをリストアする。今回のプロジェクトで共通部分がクソだった箇所でもあります。なんでデータをバックアップして戻さねーんだよアホか!
    • JMockit…今回のプロジェクトではServiceのテストで使いました。DaoとかHelperとかMock化してresult定義してあげたらそれをServiceのメソッドで使ってくれる的な。たぶんコード見たほうが理解は早いです。JMockitについては下の記事がよくまとまっています。


Java - JMockit使い方メモ - Qiita

テストケース考えるのはいいんですけど、テストデータ作るのは時間かかるのであまり好きでないです。さらに正確に言えばテストデータの修正がだるいです。


今月は稼動があと2日ですが、1月末までに割り振られている自分のタスクはほぼ全部終わりそうです。あともう少し頑張ります。