私を支える心の中のバイブル

この記事はコンピュータ書を読んでいる女子の Advent Calendar 2014 - Adventarの記事です。

おすすめのコンピューター書籍！

幾つかある書籍の中で、私の一番のお勧めはアプレンティスシップパターンです。
ある程度の経験のある技術者が、さらなる修行を重ねて熟練技術者になるためのパターンを集めた書籍です。

アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

4年近く前の話

ある程度(俗にいうエンジニアの定年をぼちぼち迎えるぐらい)の年齢で、そこそこの経験があるエンジニアだった私は「次は管理職だね！」という感じの進路を進んでおりました。
ただ、私自身は管理職に興味は全くなかったし、そのポストについたらコードが書けなくなる！ということも思っておりました。
かといって、自分がそんなにできるエンジニアではないことは十分わかっていた。
それに、その時の環境では私自信の成長を望むよりも、今持っているものを下に教えて行かなければならない立場だったので、なんとなく今後の自分の行く末は暗いよな・・・と思いながら日々を過ごしておりました。

書籍との出会い

たまたま誰かのブログか何かで、いい書籍だという紹介がされていたのがきっかけでこの書籍を手に取りました。
当時の私にとってはo'reillyの書籍は敷居が高く、ものすごくドキドキしながら書籍を買ったことを覚えています。

印象に残ったパターン

「壊してよいオモチャ」は仕事で言われたものを言われるままに作るだけだった私にとっては衝撃的でした。
勝手に似たものを作って遊んだら怒られる！と思い込んでいた(今思えば本当にそうだった)ので、なんだ、お試しで作って遊んでみるのは悪い事なんじゃないのか！と
そのパターンを読んだ次の日にはできる範囲内で色々と作って遊んでみたのはいい思い出です。

今読んでいる本

それからもそこそこコンピュータ書籍を読んでいますが、今はリファクタリングウェットウェアを読んでおります。

リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法

人間の脳をリファクタリングするっていう表現にとても心惹かれました。
達人になる旅にいざなわれて−

そんな感じでまた来年もたくさんのコンピューター書籍が読めるといいなと思っています。
それでは。

企画と開発の境界線を超えたかった私の話

この記事はDevLOVE Advent Calendar 2014 「越境」 - DevLOVE | Doorkeeperの41日目の記事になります。
前回はいとじゅんさんの30ごえのWEBエンジニアの日記:技術から経営への「越境」でした

自己紹介

こんにちは。なつななです。
全然ブログを書かなくなって、これの前回の記事が昨年のDevLOVE Advent Calenderでちょっとびっくりですw
普段は某エンターテイメント系の会社でAMゲーム系のサーバーサイドの開発をしております。
個人的には大量のデータを取り扱う仕事が好きなので、KPI集計やそれらの結果を如何に相手に分かりやすく伝える為にはどうしたらいいか？という事を模索しております。
あ、むかーしは金融系や官公庁系なシステムの開発をCOBOL(一部、汎用機のもあったかな)で、というお仕事なんかもしておりました。

越境ってなんだっけ？

とりあえず、辞書を引いてみました。
［名］(スル)境界線を越えること。特に、法的に定められた領界を無視して侵入すること。「―して亡命する」

私が超えたかった境界線ってなんだっけ？

現場にいて、境界線を感じたのは担当の作業が決まっていて、それ以外は何も考えなくていいという状態だったとき。
特にウォーターフォールと呼ばれる開発手法での開発を行っていたPJ(割とお固い系のお仕事)だと、それぞれの担当での役割が決まっていて(例えば、PGはコードをかいていればいいんだよ！とか、SEは設計さえちゃんと出来ればOKとか)
そこを超えてみようものなら「越権行為だ！」と・・・までは行かなかったけど、それに近い何かしらは発生したりする訳で。

Webサービスの開発に携わるようになってからよく遭遇するのですが、「それ、ぜったいにあかんやろ」と思う内容が仕様として降りてきて、作った後にやっぱりダメじゃん！となること・・・。
作っている途中で指摘はもちろんするのですが、その段階では遅かったりする事もあったり(企画とのコミットメントがとれないから等の理由で)、さらにリリース日をずらせなかったりするとそのしわ寄せはどんどん開発やテストの方にきて、そしてデスマへ・・・。
ああ、あまり考えたくない。

心の中では「もうちょっと早い段階で話が出来れば回避できたいになあー。」という思いでいっぱい。

エンジニアだからそこできる発想

「エンジニアだからこそできる発想」というのは絶対にあって、技術的なスキルがない人どうしで話をするよりも話が早かったりするのではないかなー、なんて私はよく思ったりしています。
実現をするのが難しいよねと思っていた事が、実は容易に出来たり、
簡単そうだと思っていた事が、実は難しかったり。

特にスピード感を求められるWebサービスの開発では、無駄な工数をかけずに開発をするのはとても大事な事なのではないかなと思っています。
(とは言え、技術検証等が必要だったりする事もあるので、一概にそうとは言い切れなかったりもするんですが)

エンジニアだけど持っておきたい視点

逆に、エンジニアももう少しビジネス的観点を持って開発をしていけるといいのではないかなと思っています。
開発したシステムが全く役にも立たない(売上げが0)なんて言うのはちょっと悲しいかな・・・。
もっと言うと、コストばっかりか買ってなけなしの売り上げがパーって言うのも悲しいかな・・・。

以前、企画の方に言われた「開発部は開発さえすればいいから、気楽でいいよな」と言われたのがとても衝撃的でした。
その方曰く、企画から言われて開発部で開発したシステムが、それはもう酷いものだったのだそうだ。
(アクセスが少し増えるだけで落ちるとか、運用コストの人的リソースがものすごいとか・・・)

企画と開発の境界線を超えて

とは言え、いきなり境界線を超えるのは難しいかな？と思ったので、少しでも企画の方に寄り添って開発を進めて行く事をしてみました。
企画の方がやりたいと思っている事(割とざっくり)に対して、これはできる、これはちょっと難しい、他にはこんな方法があるよ！と言ってみたり。
「やりたい！」といいつつもなかなか進まなかった機能が実現するところまで一緒に作りきる事が出来たのはすごく良かったと思っています。
その後ぐらいから、仕様が降りてきたら作るという文化だったのが、少しずつ変わってきたのではないかなと思っております。
(実際は、私が何かをしたというよりも自然とそう言う流れになる別の何かがあったのではと思っているのですが・・・)

とは言え、まだ境界線が超えられたとはおもっていないので、もうちょっと頑張っていけたらなと思っています。

あまり上手くはかけなかったのですが、このあたりで。

次回

次は邪道アジャイル等でおなじみのTAKAKING22さんです。
どんな越境の話がでてくるのか、とても楽しみです。

今、私が存在している、この場所に+1

はじめに

この記事はDevLOVE Advent Calendar 2013 「現場」の14日目の記事になります。 昨日は"メイド長"の愛称でおなじみの、めいどのようなもの こと 大和さんの「自分の中にある現場という場面」でした。

自己紹介

はじめまして。なつなな こと やまもとです。あまりこちらでは本名を名乗る事がないのですが今回だけ特別に。
私は小さな会社ではありますがSIerに所属しており、日々あちこちのお客様先で常駐勤務させていただいております。
主にWebシステム開発に携わっています。言語的にはphp、JavaScriptあたりが多いかな。
最近は本当にブログを書かなくなってしまい、ほぼ1年ぶりに書いている気がします。上手く文章が書けるといいのだけど。

私にとっての現場とは

一言で「現場」とは言っても、やっぱり見る視点によって変わってくると思う。
私という個人で見た場合は私が居る今この場所が「現場」だし、私の所属している会社単位で見た場合は所属している社員さんが常駐しているお客様先が「現場」。私が日々お世話になっているお客様から見た場合だと、開発チームが居るところが「現場」かもしれないし、開発部の様なところが「現場」かもしれない。
今回は、最初の私という個人の視点でお話ししたいと思います。

今、私が存在している、この場所に+1

さて、どの視点で話をするかが決まったところでタイトルを「今、私が存在している、この場所に+1」と決めました。
そんな大げさな・・・って思うかな。でもね、何かを行ってほしい(この場合だと概ね人手が足りないので、開発を助けてほしい)から、私達が呼ばれてここに存在するわけじゃない？

呼ばれたからには要望はきちんと満たしたい。欲張りなので、さらに+1もしたいのが私。
「その為には何ができるのだろう？」そんな事を思いながら日々お客様先に赴いていきます。
今までの経験から得たものや、勉強会で学んだもの等の使えそうなカードをこれでもかというぐらいにポケットや鞄、頭の中に詰め込んで。行った先では問題が山積みかもしれない。そんなに問題もなく順風満帆なところかもしれない。
でも「もうちょっとこうやったらいいのになー」と思う事がどんなお客様先であっても大小問わずそれなりにあると感じています。
だからといって、どんなお客様先でもいきなり「もっとよいやり方があるのです！」と思っても劇的に変えていく事はとても難しくて、大体の場合が目には見えない大きな壁に阻まれます。
そりゃそうだ。仕事ではなくても、いきなりやって来た見ず知らずの人にあれこれ言われたらたまったもんじゃないのはみんな同じだよね。

一般的によくあるのは「劇的な変化」ではなくて、「小さな変化をこつこつとしていった結果良くなっていったよね」という方だと、私は認識している。それに解決方法も一つではなく、その企業やチームによって文化や力量も違ってくるので一概に「◯◯をやれば何でも解決よ！」なんて言う事は残念ながら存在しない。*1

なので、その場の状況を目を見開いて良く見て、足りていないものは何で、本当に困っている事はなんであるのかを見てから、今、私にできる事はなんであるか？という事を決めて、それとなく何かを変えてみています。
アドバイスや提案をする事もありますが、最近はとにかく自分でやってみせて、興味を持ってもらったりする事が多いかな。

そうやって、少しずついい方向に変化しながら、お客様先での要望を満たしていく。
変化というものは目に見える成果ではないかもしれないけれども、最初に求められた要望に+1。

なので、私にとっての「現場」とは「今、私が存在している、この場所に+1」するところかな。うん。

では、現状ではどうなのよ？

って、偉そうな事を言っていますが、私の今は(も？)課題の山積みというのが現状。そんな感じで、まだまだなところが沢山あるので、日々精進せねばという感じだったりしています。まあ、それでもあきらめずに、ひとつ、またひとつとこつこつ頑張っていけたらなーっと思っています。

「山のようにある洗濯物も、ひとつ、またひとつとたたんでいけばいずれは全て片付いていくのよ」

そんな誰かの言葉を思い出しながら。

次の現場へ

次の現場はshiracoさんのところです。DevLOVE現場甲子園2013 - DevLOVE | Doorkeeperではかなりの人が集まったセッションを行っていた気がしています。どんな現場か楽しみです！

*1:余談ですが、今回のAdvent Calendarでもすえなみさんやつつひさんのエントリーを読みながら、やっぱりそうよねーと思ったり。

我が家の王子たちについて

この記事は子育てエンジニア子育てエンジニア advent calendar 2012 : ATND への参加エントリーです。

昨日は@kwappaさんの「ムスコさんアフィリエイト2012 - Kwappa談話室」でした。

我が家の王子4人衆

我が家はもうじき10歳双子、8歳、6歳の男の子が4人おります。
(今までのエントリーの家庭と比べて子供の年齢層が高いかな？)
今でも毎日ご飯を8号炊いるのですが、日々食べる量が増えるので今後のエンゲル係数上昇が心配でたまりませんw

普段は仕事をしているので、お買い物は週に1回のまとめ買いです。
お会計では毎回諭吉が居なくなります(>_<)

そんな状況なのですが、最近子供たちはあれこれ買ってくれ等と言って頭が痛いです(^^;
今日はそんな我が家の子供たちについて書いてみます。

インターネットがやりたいです。

10歳双子、特に長男はパソコンやインターネットに興味がある様子です。
最近では学校からも「検索して調べてきてね」のような宿題も出ているようです。
だからといって、ほいほい与えるのもどうかなぁと思っていたりしています。

何事もそうですが、正しい扱い方を知っていればそれはとても便利な道具になります。
ただ、逆に間違った使い方をすれば恐ろしい道具にもなります。
インターネットもしかり。

とは言っても、だめだめばかりでも仕方がないので、砂場の範囲内で色々とやってみてもらうのが一番いいかなと。
私個人の勉強も兼ねて、家でネットワークサーバーをたててPC単位でのアクセス権限管理をしたりとかをがっつりやってみたいところです。
んで、それを自力で突破してやった日には「よくそこまでやったなぁ」とほめてみたいです。
※直接LANケーブルを差し替えるとかは認めませんがw

ギャングエイジはコロコロコミックがお好き

次男なのですが、コロコロコミックがとても好きです。
どれくらい好きかというと・・・

・「何かお土産に買ってくるけど何がいい？」と言うと「コロコロコミック買ってきて！」
・宝くじを買ってよ！と言っていたので「1等あたったらどうする？」と聞いたら「全部コロコロコミックを買う！」

・・・そんなに好きか、コロコロコミック(^^;

私の世代の時はコロコロコミックというと「おぼっちゃまくん」とか「つるピカハゲ丸」とかかなぁ。
最近は「絶体絶命でんぢゃらすじーさん」とか「ペンギンの問題」とからしいです。

そうそう、たまに読むものがない！と言ってくるので
先日、私の本棚にある達人プログラマーを手渡しました。
渡した瞬間にちょっと難しそうな顔をして、読む前から「つまらない」とかけしからん事を言われたりしました。
まぁ、まだちょっと早かったかな？(^^;

何にせよ夢中になれるものがあるという事はとてもいい事だと思います。
母としては、たまにはそれくらい夢中になって勉強してほしいなぁと思ってみたりする今日この頃です。

将来のペーパークラフター(かもしれない)

三男が一番甘えたさんで常に私にべったりです。
買い物に行くときも「お母さん、大好き〜」と言ってはぴったりとくっついてきます。
ただ、それはずーっとではなくて、ひとしきり満足すると「もういい」と言って一人で遊んだりし始めます。
遊びは折り紙や何かを創ったりする事が好きで、折り紙は色々なものを折っては私にくれます。

色々とモノを創るのは好きなようなので、この先どういうものを創って行くのだろうなぁ。
そのときまで、「お母さん、大好き〜」と言ってくれているとうれしいなぁ。

我が家のクレヨンしんちゃん？

末っ子なのですが、保育園で過ごした内容を聞くと「○○ちゃんと遊んだ！」と女の子の名前しか出てきません。
男の子とも結構遊ぶのですが、圧倒的に女の子の名前が多い。
後は、若いくてかわいいお姉さんが大好きです。たまに突然抱きついたりして頭が痛いです(^^;

そんな様子を見ていると、あのクレヨンしんちゃんに出てくるのはらしんのすけか！と思わずにはいられません。。。

それでも「○○くん、かわいい〜〜」と、言ってくれるので助かっております。

まとめ

4人も居るとやる事も違うし、色々と好みや、思う事があったりなので、母としてはまとめるのはなかなか大変です。
ただ、みんなそれぞれ、好きなものがあったり夢中になれるものがあるのはいいなぁと思います。
まだまだ彼らの世界は狭いので色々なことを見たり聞いたり、経験させられるといいなぁと思っています。
(この間も頑張ってMaker Faire Tokyo 2012へ連れて行ってきました！)

とりとめもなく書いてみましたが、我が家の王子たちはこんな感じです。

明日の子育てエンジニアアドベントカレンダーは@anakahalaさんのエントリです。
よろしくお願いしますー。

すくすくスクラム 〜スクラム・ロールプレイング〜に参加しました

10/13に行われた、第34回すくすくスクラム 〜スクラム・ロールプレイング〜に参加して参りました。

■募集ページ
http://kokucheese.com/event/index/56300/

勉強会の概要

今回はとあるストーリーにそって、プロジェクトを通してscrumを学びました。
ざっくりとした内容については以下の通り。

■ストーリー
君たちはとりあえず「何か」を作るという名目で集められたメンバーだ。
今回は2チームに分かれて「町」を作るプロジェクトを行う
※ちなみに、社長は今回の主催者である@ebackyさん

■プロジェクト（今日一日）の流れ
・scrumについての勉強をする
　→各PJで勉強をした成果を発表(scrumについての説明)
・scrumチームを作る
　→役割(PO、SM、チームメンバー)を決める
・社長の話を元にプロジェクトを開始
　→ビジョンや元となる計画をたてる
　→立てた計画やビジョンを元に実際に町づくり
　・計画(工数)
　・実装(さいころ振り&実際に組み立て)
　・レビュー(ユーザーのsergeyさんからの指摘)
（予定では14spだったけど、実際は8spぐらい？）

■成果物
成果物については以下の通り

所感

とにかく、時間が短かった。最初に出てきた単語がこれでした。
ただ、実際の業務を進めている場合はそういう事は多々あると思う。
もっと時間があれば！という言い訳じみた事はあまり考えずに、今回の所感を書いてみます。

■scrumについて
scrumの概要はざっくり理解していたものの、細かい部分で理解できていなかったり
ど忘れしていたりとで、特に後者に関しては穴に入りたい気分だった。
（そのようなはめになる事はなかったのがある意味幸い。）
ただ、今回改めて確認した事で前よりも理解できたと思う。

■きちんと計画を意識した行動ができていなかった
模擬PJではチームメンバーとして参加したのですが、私自身が上手く回れたかどうかが疑問。
特に、最後は自分的にはやりたい放題だったのではないか（今思えばですが）とも少し思っています。
ものは最終的にはまずまずの所まではできたと個人的には思っていますが、最初のコンセプトや計画からみるとどうなのだろう？と思いました。
この辺りは他の方の感想も聞いてみたいところです。

■「作る」事に注力しすぎてしまった。
迫る時間の事もあり、話を聞くよりも「作る」事に力が入りすぎていいました。
都度、ユーザーレビューが入っていた為、希望から大きく逸脱したものが出来上がる事はなかったと思っていますが、最初にユーザーの話をもっと聞いていればもう少しユーザの好みのものが、手戻り少なく作れたのだろうなと感じました。
この辺りは会の最後の方にあったsergeyさんのお話の中でもあったので、今後気をつけていきたいところです。

■短い時間で焦って実装
3分で６人が「さいころを振る→ブロック選定→組み立て」の流れを順番に行った為、本当に時間がなかったです。
その為、やる事がそこまで明確ではなかったときはどう実装すべきなのか？という部分で時間が取れずに大変な事になってしまっていた部分もありました。

一日間をおいてから考えてみたのですが、個人的には全て一人で行うよりも、都度ベアを組んで行った方が効率がいい感じがしました。
【メリット】
・ぞろ目回避
・現場で考える(組み立てる)時間は二人分以上
【デメリット】
・取得できるブロック数が半減(2回振れるところが1回しか振れないため)

やる事（使用するブロックの選定、組み立てる具体的な内容等）が決まっているのであれば一人で行った方がメリットが大きいかもしれないですが
そうでない場合は二人で行った方がじっくり考えることができる、独りよがりにならずにすみそうであるという点では良かったかもしれません。

謝辞

会場提供をしてくださいましたvoyage group様、この会を企画、主催してくださいましたすくすくスクラム様（今回は@ebackyさん）また、特別ゲストとしていらしてくださいましたsergeyさん、本当にありがとうございました。

vimでそれなりに快適にphpの開発が出来るようにしてみる・その2

昨日の続きで、vimプラグインをいくつか追加してみました

・Source Explorer
Source Explorer (SrcExpl) - A Source code Explorer for viewing definition(s) and contextual info : vim online
・Trinity
Trinity - An IDE: the Trinity of taglist, NERDtree and SrcExpl : vim online
・NERD tree（上記のTrinityに同梱されています）

昨日はあれこれ悩みながらやっていた分、
今日は昨日と比べるとさくさくと出来た気がします。
何となくですが。

何となく、IDEっぽい感じで使えるようになった感じです。

...細かい話的な続きは、やっぱり「後で書く」ということで

vimでそれなりに快適にphpの開発が出来るようにしてみる

仕事の都合上、vimでphpの開発を行うようになったので
vimでそれなりに快適に開発が出来るような環境設定を行ってみます。
まあ、自分なりなので。

ひとまず、vimrcに簡単な設定（set numberとか）を書く事と
Taglistを入れるところまでやってみました。

...細かい話的な続きは「後で書く」ということで