情報処理安全確保支援士になった

www.ipa.go.jp

www.ipa.go.jp

なってみました（個人情報は晒していません）．

なぜ？

一言で言うと，「士業」という職（？）を経験してみたかったから．

今まで，日本のIT業界には国家資格はいくつかあったものの，名称独占の認められる「士」のつく職はありませんでした*1．
また，在野のエンジニアでいるのも別に悪い気はしないのですが，ちょっとまわりの人間と差をつけるための箔をつけたいという下心のようなものがあったのも事実です．
ちょうど有資格者に含まれていたということもあり，軽い気持ちで取ってみようかなと．

あと，情報セキュリティについてわりと本気で学んでみたいという気持ちもありました（ウソじゃありません）．
一口に情報セキュリティと言っても，「怪しい内容のメールを開かない」のような非常にローテクなものから，CTFで扱われるようなガチガチのリバースエンジニアリング*2までいろいろあります．
自分は前から，特定のプログラミング言語や技術スタックを突き詰めるタイプのエンジニアというよりは，広く浅い知識で世渡りしていく感じが向いているんだろうなぁと思っていました．
こうした国家資格であれば，幅広く知識をつけられるのではないかなと思ったのも動機の1つです．

「3年で15万」の更新/講習料，高くない？

まだ払い込んではいませんが，正直そんな気はしてます…

現実的に有資格者の数から考えると，4,000人強という数は本当に少ない気がします．
たぶんみなさん様子見してるんでしょうね…

個人的に期待しているのは，講習の内容そのものというより，そのへんを通して横のつながりのようなものができるかなぁというところです．
自分自身セキュリティにそこまで詳しいわけではないので，ぜひ詳しい人におんぶにだっこしたいものです．

これからの流れは？

とりあえず1年以内をメドに，オンラインの講習と集合研修の2つを受ける必要がありそうです．
内容については知らされていないので全然わかっていませんが，ここらへんの難易度等を見て，今後の身の振り方を考えていきたいと思います．

*1:正確に言うと技術士（情報工学）があるけれど

*2:たぶんこの資格では扱われないですよね…

最近読んだ本

今年の1~3月ぐらいで読み終えた本を晒しておきます．
ここに挙げているものはすべて（シリーズ物については全巻）読了したものです．

改訂版　日本統計学会公式認定　統計検定2級対応　統計学基礎

改訂版 日本統計学会公式認定 統計検定2級対応 統計学基礎

統計検定2級の公式テキスト．

www.toukei-kentei.jp

統計学は以前から勉強したいと思っていたので，とりあえず大学教養レベルぐらいの知識は欲しいと思って少しづつ勉強している．
一応目を通したが，数式や図による説明が少ないのと，結論だけを示してそこに至る過程を示していないことが多く，検定試験のテキストとしても統計学の解説本としても中途半端な印象だった*1．

日本統計学会公式認定 統計検定 2級 公式問題集[2014〜2016年]

日本統計学会公式認定 統計検定 2級 公式問題集[2014〜2016年]

代わって，こちらの公式問題集は，実際の検定の問題とその（簡単な）解説を並べているだけなので非常に読み進めやすかった（まだ全部読めてないけれど）．
もっとも，解説自体はそこまで詳しくないので，適宜他の教科書等で補っていきたい．

検定自体はいつ受けよう…？

夜行

夜行

直木賞ノミネートもされた森見登美彦の作品．
正月の実家ぐらしがあまりにもヒマだったので読んでみた．

10年ぶりに再会したかつての英会話スクールの仲間が，それぞれに起こった不思議な出来事を話していく，という連作形式の物語．

序盤の不気味ながらもゆっくりとした物語進行から，クライマックスのどれが夢でどれが現実かわからなくなるようなめくるめく展開には驚かされた．
1つ1つの話にはいわゆる「キレイなオチ」みたいなものはないのだが，それがさらに物語の不気味さを加えている．

「夜は短し歩けよ乙女」や「四畳半神話大系」などで作者のことを知っている人にも一度読んでもらいたい．

know

know (ハヤカワ文庫JA)

「ビッグデータ」を話題にしたSF小説があると聞いて興味を持ったので読んだ．

ありとあらゆるものが「情報」で構成され，その膨大な情報を処理するための「電子葉」と呼ばれる装置を脳に埋め込むことが一般的となった近未来の冒険活劇．
物語の内容自体はよくある「俺（のことが好きな女の子）TUEEEE」なのだが，「持っている情報量」と「その処理速度」がすべてを制するという設定がIT系SF好きの自分としては興奮せざるを得なかった．
1巻完結なので展開も早く，先が気になって一気に読み終えてしまった．
SF初心者にオススメ．

いちばんカンタン！株の超入門書　改訂版

いちばんカンタン!株の超入門書 改訂版

株を始めたくなったのでとりあえず買ってみた．

銘柄の探し方から買い時，チャート分析など，内容自体は非常にわかりやすく解説されていて，「ふーんなるほど」とは思えた．
たぶん，ちゃんと株を始める人たちは，これで外観をつかんで他の入門書に進んでいくのだと思う．
読んだ後すぐに実践したくなったので早くNISA口座出来てくれ．

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

達人に学ぶDB設計 徹底指南書

だいぶ前の翔泳社Kindle40%引きセールで買ったまま長い間積読だったが，旅行でヒマだったので読んでみた．

大きく分けて，正規化，ERモデリングなど，大学の情報系学部で学ぶようなリレーショナルデータベースについての基礎理論の解説部分と，実際にデータベースを運用する際に必要な（グッド，グレー，バッド）ノウハウの解説部分で構成されている．
一応大学ではデータベースを勉強していたので読んでいてあまり詰まる部分はなかったが，基本的な知識の復習と，「この設計なんかダメそうだけどなにがダメなんだろう」について自分の中で整理ができたように感じる．
特定製品についての話は少なく，（特に前半部分は）IPAのデータベーススペシャリスト試験の内容に近いので，副読本としての利用も可能ではないかと思う．
個人的には，スキーマ設計についてはそこそこに，インデックスやデータ型定義の設計ノウハウについてもう少し補足してもらいたかったところ．

嫌われる勇気

嫌われる勇気―――自己啓発の源流「アドラー」の教え

一度心理学を勉強してみたかったので読んでみた．

読んでみた感想としては，「自己啓発本としてはよかった」という感じ．
特に，「トラウマなど存在しない．自分の今の状態の原因を過去に求めるのではなく，今自分がどうなりたいかを考えて行動しろ」（意訳）という部分はなかなか刺さった．
加えて，アドラー心理学を学んだ「哲人」と自分に思い悩む「青年」の対話形式で書かれていることも特徴的である．
「青年」による反駁によって，単なる意見の押し付けにならず，かつより読み進めやすくなる構成になっていた．
ところで，本書中でも述べられているように，本書はアドラー心理学そのものではなく，原案の岸見一郎氏の考えを取り入れた「岸見アドラー学」について説明しているものであることにも注意．

心理学の本としては学びはあまりなかったように感じるので，もっと学術寄りの本にも手を出してみたい．

*1:端的にいうと「文字ばかり」

昨年やったことと今年やりたいこと 2017

去年のやつ↓ lethe2211.hatenablog.com

なんかもう松の内も終わってしまっていますが，毎年目標を立てることは重要だと思いますので，今年もやりたいと思います． 学生時代と違い，特に毎月大きな変化があるわけでもなくなってきたことと，ちゃんとやったこと/やりたいことにフォーカスしたいという思いから，去年までとちょっと形式を変えてみました．

昨年やったこと

写真

カメラをはじめた．
買ったのは型落ちの一眼レフ．
最近はどこかへ旅行に行くたびに持ち歩くようにしている．

Canon デジタル一眼レフカメラ EOS Kiss X7 レンズキット EF-S18-55mm F3.5-5.6 IS STM付属 KISSX7-1855ISSTMLK

写真をやっていて感じるのは，「写真はひとつの事実を写すものではなくて，その人の考えが全面に出る芸術である」という（，言ってみれば当たり前の）こと．
ファインダーに切り取られた景色を見ると，その前に自分の目で見たものとはまったく違うことに気づく．
明確な作画意図と技術，後はちょっぴりのセンスで，ただのスナップ写真だったものがイケてる写真になっていく過程が本当に楽しい．
まだまだにわかなので，上手い人のアドバイスを聞いて上達していきたい．

山登り

「ヤマノススメ」に影響を受けて，友人とともにはじめてみた．

ヤマノススメ　1 (アース・スターコミックス)

趣味のひとつに過ぎなかったパソコンを仕事にしてしまったので，パソコンを使わないアウトドア系趣味をひとつぐらいは持ちたいと思っていたが，運動が得意でなく，友達も多くない自分にはなかなか厳しいと思っていた．
山登りは，基本的にやることは歩くだけなので，アウトドアの中でも比較的入りやすかったように感じる．
去年は北鎌倉，三つ峠山，霧ヶ峰，大岳山などなど，ゆるふわながらもそれなりに登れたように思う．

ランニング

体力づくりも兼ねて，住処周辺の河川敷を週2回ぐらいのペースで走っている．
とりあえず一定のペースを保ったまま5km走れるようになるぐらい持久力をつけるのが目標だったが，これまでの運動不足はそう簡単に治らないらしく，まだそこまでには至っていない．
継続していきたい*1．

声優ハッカソン

今思い出しても悔しい．

lethe2211.hatenablog.com

アメリカ出張

サンフランシスコに6泊8日の出張に行ってきた．
出張と言っても，目的が学会参加だったのでどちらかというと見学の部分が強かった．
少し抜け出して見に行ったシリコンバレーやスタンフォード大学がよかった．
行く前はぼっち旅行を覚悟していたが，同僚が一人ついてきたり，行った先で大学の先生と後輩に会うなど，縁にも恵まれたいい旅だった．

TOEIC スコア900

出題形式が変わる前に一回受けておこうと思って受けてみたら取れた．
最初の受験で取った800から点数が伸び悩み続けたが*2，現職で日常的に英語を使うようになって受けてみるとやはりリスニングパートが圧倒的に楽に感じた．
いちおうこれで会社的にもこれ以上TOEICを受ける義務がなくなったので，もう一生受験しないような気がしている．

ネットワークスペシャリスト試験

2年越しの悲願（笑）．

lethe2211.hatenablog.com

今年やりたいこと

PJM

今年は入社3年目を迎える年になる．
そろそろただ言われたことをやるだけでなく，自分のやりたい方向性を自分で定めて仕事ができるようになりたい．
最近，技術者としての自分を客観的に見ると，コーディング一辺倒ではなく，ある程度設計やインフラまわりの知識をつけて人を指導していく方が向いているように感じている．
小さなプロジェクトからプロジェクトマネージャを経験していって，最終的には一人でプロジェクトを切り盛りできるようになりたい．

設計

技術面では，デザインパターンなどの設計指針に強くなりたい．
実際にサービスを動かす上では，教科書には載らないような多数のバッドノウハウが出現する．
それでも，アーキテクトが設計指針に理解があれば最悪スパゲティにはならないと，他のプロジェクトを見て感じた．
また，自分が考えていることを他のメンバーにどう伝えるかについても考えていきたい．

各種資格試験

自己研鑽という意味でもボケ防止という意味でも，年間一つか二つは資格試験を受けるようにしたい．
最近興味があるのは，技術士（情報工学），統計検定（2級），システムアーキテクト試験，弁理士あたり．
全部必ず受けるというわけではないが，スキあれば積極的に狙っていきたい．

筋トレ

常日頃から自分はやせにくい身体だと思っていたが，筋肉量が少なく基礎代謝を上げられないことが原因なのではないかと思うようになった．
走り込みで体力の下支えはしつつも，腹筋，背筋と腕の筋肉あたりをつけていきたい．
ジムに通うのが理想なのだろうか…

株

株もやりたいやりたいと言いながら全然できていなかったのでバックログに入れたい．
今のところすごくカネに困っているわけではないのだが，ある程度若いうちに投資に手を出して泣きを見ておきたいという気持ちがある．
加えて，株を勉強することで社会にもっと興味を持てるのではという期待を持っている．

小説

いつからか忘れたが，自分で小説を探してきて読む習慣がなくなってしまっていた．
最近また読み始めたい欲が出てきているので，ミステリ，SFあたりの有名どころから攻めていきたい．

抱負的な何か

今年は「自分がやりたいことを（タイミングを逃さず）実行する」を目標にしたい．
去年の自分の思考と行動を思い出すに，「自分はこうあるべき」という理想像は徐々に思い描け始めているが，それに向けてすべき行動が伴っていない気がした．
モノゴトにはタイミングがあり，せっかくすべき最善の策を考えついても，タイミングを逸してしまっては意味がない．
うまく行った例，行かなかった例を鑑みながら，自分の方向を修正していくようにしたい．

---

目標を文書化することも重要ですが，口だけにならないようにはしたいものです…

*1:ランニング始めて体重5kg落とした

*2:800-900の壁は多くの人が悩んでいるらしいことをどこかで聞いた．ここらへんからは単なる要領の良さだけではなく，普段からどれだけ英語に触れているかが問われてくる気がしている

ネットワークスペシャリストになれました

というわけで，3度目の正直というやつで合格できました．

情報セキュリティスペシャリスト（SC），データベーススペシャリスト（DB），ネットワークスペシャリスト（NW）試験の3資格に合格することは，自分の大学院生時代の目標でしたので，2年遅れでようやく達成できたことになります．

せっかくですので，合格までの経緯を軽くまとめておきたいと思います．

2014年秋試験

ウチのブログのアクセス解析を見てみると，こちら↓

lethe2211.hatenablog.com

の記事が一番閲覧されているようなのだが，この年のNW試験は午後2が4X点という特に残念でもない点数で落ちてしまっており，「ネットワークスペシャリスト試験を受けてきた（合格できたとは言っていない）」という状態が長く続いていた*1．

2015年秋試験

また，去年も試験を受けてきたわけだが，この時期はちょうど仕事の忙しい時期と重なってしまって勉強時間が十分に取れなかったのと，午後2で完全に問題選択を誤り，5X点*2で落ちてしまった．

2016年秋試験

そこで，「今年は一念発起，気合い入れていこう！」となったかというと，そうでもなく…

2016年8月上旬

特にネットワークについて継続的に勉強していたわけではないが，「受かるまで受け続けよう」という謎のやる気はあったため，せっせと申し込む*3．
この時期に海外出張があり，その準備等があったため，この時点では特に何もせず．

9月

謎の開発案件が降ってきて仕事が忙しい日が続いたが，ちょこちょこ午後試験の過去問を解きはじめる．
3回目ということで，過去問もある程度やり尽くしてしまっている感があり，どちらかというと解に至るまでのプロセスの確認と，解いていく上での疑問点の解決に注力した．

以下，使った問題集．

ネスぺの剣25 ~ネットワークスペシャリストの最も詳しい過去問解説 (情報処理技術者試験)

ネスペ 26　道　?ネットワークスペシャリストの最も詳しい過去問解説 (情報処理技術者試験)

受験者の中でも評価の高いネスペシリーズ．
過去問（午後試験）1年分について非常に詳しい解説を施してある．
個人的に，「なぜその解答になるのか」だけでなく，「なぜその解答以外の解答にならないのか」についての反駁が行われている点がよいと思う．
反面，基礎技術についての解説書ではないので，その点は他の本などで追いついておく必要がある．

情報処理教科書 ネットワークスペシャリスト 2016年版

前年までの2年間で，そもそもネットワークについての基礎が足りていないと感じていたので新たに購入，したのだが…，どちらかというと過去問から見た視点での要素技術の解説に終止していた印象．
体系的に知識を得るための資料が欲しかったので，少し購入目的とズレてしまっていた感はあった．

ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識

これも名著として有名．
こちらは試験対策本ではなく，ネットワークの基礎技術についての解説本．
ユーザがブラウザからURLを叩いてHTMLが返ってくるまでを旅に例え，それぞれのレイヤで何が行われているのかを詳しく解説している．
分量はあるが，わかりやすさを気にかけているのか，非常にすいすいと読み進められた．
これを読んだからといってすぐに問題が解けるようになるわけではないが，体系的に勉強がしたいのであれば読むべきだし，副読本としての使い方も十分にアリだと思う．

以下，参考にさせていただいたサイト．

www.infraexpert.com

NWの試験範囲について，必要最小限な分量での解説が施されている．
ある程度ネットワークの知識がある人なら，ここを見てある程度知識をつけた上で過去問演習をすればなんとかなってしまうのではないかと思う．

10月

このあたりから，午前試験対策を始めた．
といっても，特に参考書等を買ったわけでもなく，過去問をやるだけ．
今年は午前1免除が失効していたため，午前1についても勉強する必要があったが，結局3〜4年分解いてイケそうなことを確認できたのでやめた．

試験当日

午前1

試験終了の時間を間違えて焦ったが問題自体は普通に解けた．

午前2

午前2は試験範囲が非常に狭く，過去問さえ覚えればほぼ同じ問題しか出ないのでいつも印象に残らない．

午後1

無線LANは勉強していなかったので問1，3を選択．
なんとなく近年はメール送信に関する出題が増えてきている気がした．
手応え的には7割程度．

午後2

昨年同様，問題選択に窮したが，直前にIPsecの勉強をしたのでえいやで問2を選択．
結果的にはこれが正解で，結構ヤマが当たった．
帰った後自己採点してみた結果的には6割5分ぐらい*4．

結果

うひぃ，ギリギリ…

反省点

そもそもなぜ3年もかかってしまったのか．

• 広範囲な知識の必要性
  そもそも，試験範囲がなかなかに広い． OSI参照モデルの7層全てとその周辺技術から出題があり，ネットワークが本職のエンジニアであっても，すべての内容についていくのは困難なのではないだろうか． 最初に過去問に当たったときに感じた，「どこがわからないのかわからない！」という感覚は，単純な暗記量の少なさによるものだったのではないだろうかと，今になって感じる．最悪正規化とERモデリングだけできればなんとかなってしまうDB試験，コクゴができれば短期間の勉強でも合格できるSC試験と比較しても，学習曲線が非常に緩勾配で，長期間の根気強い勉強が必要となる気がした． 午後試験を大きく分類すると，レイヤ3以下（スイッチ，配線に関する出題）と，レイヤ3以上（主にIP，DNS，HTTPなどの技術に関する出題）に分かれているので，どちらかにヤマを張って勉強するのはアリだと思う．

• 新技術への対応
  上に関連するが，ネットワーク周りの技術は進歩が目覚ましく，NW試験でも様々な要素技術が出題されている． 情報処理技術者試験は，多くの人にとって初見の内容を扱う場合，既存の知識を応用して解けるように問題が設計されているのだが，そのあたりで知識の底の浅さが露呈してしまっていた． また，少し前の試験ではよく出題されていたIP電話の問題が減った代わりに情報セキュリティに絡めた出題が増えるなど，数年で出題傾向も変わっている． NW試験の過去問だけでなく，SC試験の過去問に手を出してみるのも有用かもしれない．

• ネットワークについての知識・実務経験不足
  これは試験そのものというより自分の問題． 学生時代もWeb系の開発経験はあり，現職もアプリケーションエンジニアではあるが*5，ネットワークについて体系的に学ぶ機会がなかった． 学生時代のプログラミングというと，（実サービスとしての運用でもしない限り）「動けばおｋ」というものがほとんどであり，「Webのチュートリアル記事を見てそれをそのままコピペした」といったものがほとんどであった． また，現職でもネットワーク担当の仕事とアプリケーション担当の仕事は分業されており，「権限管理」の名のもとにネットワークを直接的に触る機会はほぼない*6． この手の勉強には実機を触るのがいちばんよいのだろうが，その機会に恵まれなかったのが一因だと思う． 最近であれば仮想環境上にネットワークを構築するのも以前より難しくなくなってきたらしいので，少しずつそういう学習も進めていければいいと感じた．

---

次は何を取りましょうかねぇ…*7

*1:地味に「ネットワークスペシャリスト」でググると上記記事が検索上位に出てきてものすごく恥ずかしかった

*2:適当に埋めた部分が多かったが，問題そのものが結構難しかったのか，採点は甘めに感じた．情報処理技術者試験では，合格率調整のための得点調整は結構なされる（と思われる）ので，問題が難しいと思ってもやはり諦めてはダメだと思う

*3:余談だが，早く申込みを行うと現住所に近い会場に行けるという噂があるので，申し込むならできるだけ早い方がいいかもしれない

*4:個人的にはイーサネットのMTUを勘違いしていたのがつらい

*5:現在の上司氏はアプリケーションエンジニア出身だが非常にネットワークに強く，その点でも頼られている．このような，「もう一つの強み」を持てることがエンジニアとしての市場価値の向上につながっていると感じる

*6:さわるコマンドと言えばせいぜいpingとdigとnetstatぐらい

*7:友人からも「資格マニア」と呼ばれるようになってきていますw

Web APIプラットフォームの設計をやってみた

お久しぶりです… また4ヶ月放置してしまいました．

現在関わっているプロジェクトで，Tech LeadとしてイチからWeb APIプラットフォームを1本書く，ということをやっています． 初めての経験だったので，いろいろ回り道もありましたが，なんとか軌道に乗りそうなところまでは持っていけたかと思います．

メモとして，やったことと今考えていることを残しておこうと思います．参考になれば幸いです．

業務要求

あまり詳しいことは書きませんが，現在開発中のAPIは，いわゆる決済業務系Web APIとして，主に社内のサービスから使われることを想定しており，かつそこそこの量の秒間リクエストが来ることが想定されます． 最終的には，現在稼働中のAPIを置き換える形で，開発したAPIプラットフォームを使うことを目的としています．

議論の結果，今回の業務要求として，

• 最低5年程度は現役で使い続けられること
• 知識の乏しい開発者が短い時間でAPI開発を始められること
• 運用が比較的スムーズにできること
• トラフィックをスムーズにさばけること
• 障害に強く，復旧も早いこと
• 他サービスからの利用が容易であること（API利用者が容易に開発を進められること）
• セキュリティ対策ができていること

といったことなどが挙げられました．

ちょうど，エンプラ系のガチガチのシステムと，スタートアップなどの「とりあえず動けばなんでもいい」ようなシステムのちょうど中間，ぐらいのイメージでしょうか．

アーキテクチャの検討

業務要求を受け，これを具体的な設計に落とし込んでいくことを行いました． いろいろ悩んで議論したのですが，最終的にはこんな感じになりました．

• URL設計においては最近流行りの（？）RESTfulアーキテクチャを採用する
  • 既存APIではRPCを採用していたが，似た挙動をするAPIが乱立する，そのAPIが参照系なのか更新系なのかがわかりにくい，といった問題があった
  • RESTfulを採用した結果，URLが宣言的になり，リクエストを見るだけである程度何をするAPIなのかが明確になるというメリットがあった．反面，URLのパス設計が難しくなったのと，ログを設計する際に，どのパスがどのAPIに対応しているのか何らかの形で保持しておく必要がでてきた
• URLについては，主流のWeb APIにならってバージョニングを行う
  • 度重なる業務要求の変更に対応するため
• リクエスト，レスポンスの形式にはXML，JSONを用いる
• WebフレームワークにはSpring Bootを用いる
  • 実績，ノウハウ面からJVM言語（というかJava）を開発言語として使うことは最初から決まっていた
  • 自分としては，将来Scalaを使用することを見据えてPlay Frameworkを使いたかったが，Playにはまだ枯れていない部分があることと，これまでの実績があったことからSpringを選ぶこととなった
• 将来のマイクロサービス化を見据え，（パッケージ構成も含め，）サービスはできるだけ疎結合に保つ
  • 現状はまだ開発の1stフェーズであるというところと，マイクロサービスアーキテクチャがどこまで流行るかが未知数ということから，一度ひとつのデプロイ可能jarで作成し，いつでもサービス分割が可能な形を保つこととした
• キャッシュにはRedisを用い，キャッシュ層はサービスとして分離する
  • インメモリKVSならなんでもよかった
  • Redisを使用したのは，実績があるのと，ドキュメント類が充実していたため
• DBは変更の対象外とする
• Docker+Kubernetes+JenkinsのCI/CD環境を用いて，開発者はコードをGitリポジトリにpushするだけでデプロイまでが自動で行われるようにする
  • アプリ側としては，開発環境に依存する設定項目をできるだけ減らし，（DB接続情報などを除き）環境間での差分を最大限減らすことを目標とした
• ログに関しては，Elasticsearch+Fluentd+Kibanaでの集約，解析を可能にする
• Junitによる自動ユニットテスト，Cucumberによる自動end2endテスト，SonarQubeによるコードカバレッジ測定など，テストとそれに関連する機能についてはできるだけ自動化を行う

全体的に，「Web系にしてはオーソドックスだなぁ」という構成にはなっているかと思います． 人の出入りが激しく，自分もいついなくなるかわからないので，とにかく「わかりやすさ」を重視したつもりです*1． そういった制約の中でも，Dockerをベースとした運用環境など，「イケてるしこれからもしばらくは使われそうなもの」については，積極的に導入するようにしています．

今後検討したいところ

• 不正利用の検知，将来のデータ分析に向け，独自のクライアント認証システムを導入する
  • OAuth2など，一般に使われる認証，認可アルゴリズムの適用も考えていたが，今後，社外からAPIをコールされるようになる可能性がかなり低く，多くの場合クライアントにとってこういった作業は手間となるため，見送ることとなった
• ドキュメントの構成管理
  • 既存のAPIは，ドキュメントをPowerPointなどで作成しており，ドキュメントが散逸する，仕様変更の反映がなされないなど，構成管理に大きな問題があった
  • できれば，ドキュメントはソースコード中のJavadoc等と同期させるようにし，開発者の責任で適宜更新させるようにしたい
  • もっとできれば，ドキュメントとAPIのテストページをまとめてしまいたい*2
• Dockerコンテナベースでのローカル開発環境の構築
  • 「俺の環境では動く（動かない）」をゼロにしたい
  • まだ検討中
• 障害対応の方法
  • まだノウハウが足りない
• 開発フローの構築
  • 開発チケット起票からリリースまでをどう進めるのがよいか
  • ブランチ戦略，ChatOpsなど
• 他プロジェクトメンバへの教育
  • 特に，Spring自体への理解を深めることと，網羅的なテストケースの作成方法を理解することが必要
  • 最低限，どの開発者も，サービスロジックとコントローラ，そのそれぞれのテストを自力で書けるレベルまでには持っていきたい

---

こんなところでしょうか． やってみて思うのは，実際に業務で開発されるAPIには大きな制約が課されるということです． 特に，今回のAPIは想定ユーザが多く，いちから基盤を作り直すということだったので，5年後，あるいは10年後を見据えた形での開発が必要でした*3．

機会があれば，もう少し実装寄りの部分の解説をしたいと思います．

ではでは．

---

以下，参考にした本．

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

Spring徹底入門 Spring FrameworkによるJavaアプリケーション開発

*1:現状，開発者のレベルもマチマチなので，「保守され続ける」ことを考えると，こういった構成になるのもやむを得ないかと思います

*2:REST APIでは，Swaggerなどのツールで実現できるようだ

*3:チャレンジングではありましたが

最近読んだ本を晒しとく

お久しぶりです．
4ヶ月近く放置してしまいました…

とりあえずリハビリとして，読んだ本の感想とかを適当に並べてお茶を濁しておきたいと思います．

「Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)」

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

業務で既存のAPIを設計からリニューアルすることになったが，その過程での先輩とのディスカッションで，

先輩「どうせなら今時のイケイケなRESTful APIにしたいよね」
ぼく「あーRESTfulですね．はいはいあのRESTfulか…」

こんな感じで会話を終えた後，すぐにAmazonを検索して，名著との評価のあった本書を読むことに決めた．

タイトルだけからだと非常につかみにくいが*1，本書は，

• 最初にWebの歴史について触れた上で，
• HTTPの仕様とURI，HTML，JSONなどの関連技術について説明し，
• 現時点でのWebサービス設計のベストプラクティスとされるRESTについての説明と実際の設計手法につなげる

形で論を進めている．

基本的な計算機科学とWebの知識を持っている人がWebサービスを作っていくにあたって，どのようにリクエスト/レスポンスのインタフェースを設計していけばいいのか迷った時に本書は適していると思う． また，具体的なソフトウェア（Webフレームワークなど）の実装には（歴史の説明は除いて）全く言及しておらず，非常に普遍的な視点から知識を得ることができると思った．

「Junit実践入門 ~体系的に学ぶユニットテストの技法~」

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

これも，同じ案件でJunitをがっつり書く機会ができたので，ベストな方法論が知りたくて買った．

今まで「なんとなく」ユニットテストを書く機会はあったが，どのような観点でテストケースを作成すればよいのか，作成した各テストケースをどのようにクラスタリングすればよいのかについては，自分の中でまとまったものがなかった．

本書は，「なぜユニットテストを書くのか」といった基本のところから，テスト技法の紹介，4フェーズテスト（事前準備 -> テストクラス実行 -> 結果の検証 -> 事後処理）についての説明と来て，実際にJunitの機能の説明に移る．
ここまででも，今までなんとなくテストを書いていた自分には学びがあった．

機能説明の後は，テストダブル（いわゆるスタブ，モック），カバレッジについての説明から，TDDやBDDの説明が進む．
この辺については，抽象的な説明が続き，巻末の実例集を見ても，あまり実感がわかなかった．

全体的に見て，Junitの解説書としては十分な出来だと思う．
これに加えて，Mockitoの解説記事をいくつか読めば，現在のJunitを用いたシステムテストについてはほぼおさえられるのではないだろうか．

「どんどん話すための瞬間英作文トレーニング」

どんどん話すための瞬間英作文トレーニング (CD BOOK)

相変わらず英会話力に不安を抱えているのだが，最近特に気になるのが，「英語での発話（返答を含む）開始までにかかる時間」．

もともとコミュニケーションには不安があり，日本語でも「あの，えーとですね…」からしか会話を始められない私だが，英語での会話だと，それにさらに2-5秒の「言いたいことを英語に変換する時間」が追加される．
こうなると，複数人の会話に入っていけないのはもちろん，一対一の会話ですら，相手に話し続けられてしまってコミュニケーションにならない．
この時間を短縮したいと思ったのが本書を買った動機．

本書に記載してある例文と対訳は，どれも中学英語で見たことのあるものばかり．
しかし，いざこれを「3秒で訳して発音しろ」と言われると，なかなか表現が出てこない．
また，「それっぽい」表現が出てきたとしても，"Does"になるべきところが"Do"になってしまっていたり，"more smarter"なる謎英語がでてきたり，自分の中に正しい英語を落とし込めているとは言いがたい．
「まず，中学英語レベルの表現を問題なく（素早く）引き出せるようになってから，英文法書にあるような例文を練習すると良い」というようなことが本書のまえがきに書いてあり，「なるほどな」と思った．

とりあえず2周ぐらいしてみたが，まだまだ英語ペラペラは遠いと感じる．

*1:本書をちゃんと題するなら，「HTTPとRESTアーキテクチャ」が正しいように感じる

声優ハッカソンに行ってきた

2/27，28に楽天株式会社主催で行われた，「声優ハッカソン」に行ってきました．

rakutenwebservice.doorkeeper.jp

apps.rakuten.co.jp

このハッカソンの売りは，「声優さんの声を自分たちの作ったアプリに使える」ということ．

自分もアプリを開発したことは何度かあるのですが，一素人が「声優さんに声を当ててもらえる」という機会に恵まれることはなかなかなく，声素材を集められずにアイデアを断念する，といったこともそれなりにあったように思います．

このハッカソンなら，声優さんにあんなことやこんなことを言ってもらうことができる！

「これは参加するしかないだろう」ということで，妄想膨らむ大学の同期と参加を決めました*1．

作ったもの

声優ハッカソン20160227 チーム16（Blind Busters!!）中間発表スライド / レテ さん - ニコナレ

自分たちのチームが作ったのは，「ブラインドバスターズ！」という，「声優さん演じる妖精ちゃんの指示を聞きながら見えない敵を倒していく」アクションゲーム．

最初に議論を進めていくうちに，スイカ割りに着想を得て，「声優さんに指示を出してもらって，その気持ちいい声を聞きながら楽しめるアクションゲームがあれば面白いのではないか」という話になりました．

例えば，前から敵（プレイヤーには見えない幽霊）が襲ってくると「右によけて！」って指示してくれる感じ．

ハッカソン前から，デザイン面，ゲーム性の議論など，少しづつ準備をすすめ，本番に望みました．

感想

「声のプロである声優さんに時間をいただいて，こちらの欲しい音声を収録してもらえる」というのは，開発者冥利に尽きるものがありました．

正直，声が入っているか否かで，アプリとしての完成度が5倍は違いました．

また，ハッカソンそのものとはあまり関係なくてアレですが，声優さんの生声録音の現場に立ち会わせてもらうことができたのが本当にいい経験でした．

収録直前に出した原稿にもかかわらず，こちらが指示したキャラ設定をちゃんと考えて，ほぼ一発撮りでセリフを撮り終えてしまう声優さんの凄さに感動しました*2．

残念だったのは，プレゼン中，PCからの音声の出力ができずに，アプリのデモができなかったこと．

こんなケアレスミスでせっかくの機会をフイにしたのは初めてで，正直クソがつくほど悔しかったです．

後で再チャレンジの機会をいただきましたが，「事前の接続チェックは大事」という，プレゼンの基本を痛感させられました*3．

---

僕のレベルの低い質問にも嫌な顔せず答えてくれたチームのみなさん，このような素晴らしい機会を与えて下さった主催の方々，そして，音声を収録していただいた菅沼千紗さんをはじめとする，今回ご協力いただいた声優のみなさま，本当にありがとうございました！

*1:決して声優さんと写真を撮りたかったとかそういうのではないです

*2:その後，余った時間で仕事についても少しだけお話させてもらいました．噂には聞いていましたが，声優，厳しい職業なんですね…

*3:受賞を逃したことよりも，やったことを出しきれなかった不完全燃焼感が自分の中であまりにも許せなかったので，再チャレンジタイムに真っ先に手を挙げました．その瞬間，たしかに「自分にもまだこんな情熱が残ってるんだ」と感じ，それに関してだけは自分を褒めてやりたい気分です．