この漫画が好き2022
毎年年末年始、前年に読んだ漫画の中でお気に入りのものを発表していたのですが、去年は引っ越しや大学院入学、結婚といろいろ慌ただしく、記事を書くのが遅くなってしまいました。 悲しいことに最近本当に漫画を読めておらず、おそらく去年購入した漫画は100冊に満たない程度だと思います。
今年、来年の漫画ライフがどうなるか今から心配ですが、隙間時間に少しずつ読んでいけたらいいなと思っています。
鍋に弾丸を受けながら
世界中の食事を現地に行って楽しむ漫画。本人が体験されたことがベースになっているため情報がしっかりしていて臨場感があって楽しい。 いろいろと危険な地域のほうが食事がうまい（あるいは死ぬほどおいしくない）！という主張の強い漫画。出てくる料理全ておいしそう。いつか食べに行きたい。特にブラジルのフルーツとパレスチナのスイーツ。
異世界ありがとう
転生ものなのだけれど、冒険の楽しさみたいなのが溢れてて好き。 ちょっとファンタジー入ってる広大な世界でMMORPGとかしたくなる。そんな時間はどこにもないんだけど…。
クレバテス
魔獣が子どもを拾って勇者と世界を旅する話。 作りこまれた世界観を感じる。そしてとにかく絵がうまい。
野人転生
異世界転生ものは基本的に成功者になっていく話が多いんですけど、野人転生に関してはつらさを乗り越えるものが多い。 ほかの異世界転生では「強い！すごい！仲良くして！」と主人公を認めてくれる、あるいは協力的な人が周りにたくさんいる状態にすぐなるが、実際にはそうはならないだろう、という考えが根本にあって読みごたえがある。
隣のお姉さんが好き
ラブコメディー。 人が何を考えているのかを知ることは難しく、それゆえにその人の本質を好きになるというのは難しい。 「好き」とか「本当の自分」って何なんだろうな～みたいなことを考えさせられる。
平和の国の島崎へ
妙な魅力があるんですけど、これはなんだろうなあ。うまく言語化できたときにまた追記します。
バキの作者である板垣先生の自衛隊時代のエピソード。結構おバカなエピソードが多い。自衛隊のトレーニングって本当に大変なんだな～。
一橋MBAに合格しました
一橋大学大学院金融戦略・経営財務プログラムに合格しました。
春から社会人大学院生として仮想通貨に関連した研究をしながら経営学修士（MBA）の取得を目指す予定です。なお、私が現在考えている手法では大規模な計算が必要であることが予想されるため、大学院生が研究用途で使える無料ないし低コストの計算資源に心当たりがあればぜひ教えていただきたいです（マイニングしたいわけではありませんのでご安心ください）。
今回畑違いの分野の大学院受験をする中で、多くの方に相談に乗っていただき知恵をお借りしました。それに対する恩返しというには小さいかもしれませんが、今回私がどのように受験の準備をしたかをここで共有することで、本プログラムを受験する方の参考となることを願っています。
今回私がMBA取得を目指す理由は大きく三つあります。一つは将来的に起業するため、二つにエンジニアとしてドメイン知識を広げるため、そして最後にアカデミックな興味のためです。一橋大学の本プログラムは金融、経営学一般の講義と併せてデータの分析を元に判断する力を養うことを重視したカリキュラムを提供しており、またアカデミックな成果のある教員が多く所属しています。これらの特徴が私の希望と合致していることから本プログラムを進学先として選びました。
本プログラムは秋期、冬期の2回選考がありますが、私は昨年11月末にMBA取得を目指すことを決めたため必然的に冬期の選考を受験することになりました。例年秋期のほうが枠が多く、相談に乗っていただいた教員の方も「冬期は難しいよ〜」と笑っておられたので、受かる確率を少しでも上げたい場合は秋期を狙うと良いようです。
スケジュール
本プログラムは研究計画書による一次試験、そして面接による二次試験があります。以下にスケジュールを示します。
12/14 入試説明会
1/4-1/13 出願期間
2/3 一次試験の合否発表
2/12 二次試験
2/20 最終的な合否発表
一次試験について
一次試験では研究計画書が合否を左右します。このため、研究計画書は可能な限り良いものを書く必要があります。
例年、一次試験の前に入試説明会が開催されているようなので参加されることを強くお勧めします。私が参加した説明会はZoom上で行われ、教員の方に選考基準など非常に重要な情報を詳細に説明していただきました。また匿名での質問も気軽に行うことができました。当時の私のメモを共有します。
計画書について：
- 新しさや面白さも重要だけど、「2年間で実現可能な計画」であること！
- 夢ではなくて「計画」。実現可能かどうかが一番重要
- どのような調査、検討、勉強をしているか。これが見られる
- 勉強できること、の範囲で収まっているかが重要（自分へのメモ：シラバスなどで見られそう）
- 特定の企業やデータに基づくというよりは、汎的な手法のほうが指導しやすい（自分へのメモ：つまりそうあれ）
- 修論を書く、というのを意識したものにしてほしい
計画書の評価：
- 書類審査に重要。一次は計画書に書いてあることがすべて
- 論文書けそうかな？という観点で見る
- ポテンシャルを感じさせてくれ。
- 変に背伸びしてるな？というのは…。入門書しか目を通してないのかな…？みたいなのは落ちます。
- これはわかる、これはわからないの基準をきちんと設けてくれればいい。
- 英語の論文も読んでいるとかは重要。ただし本当に読んだかの確認はしますよ！
- 理解できている水準で書いてもらえればいい。
- 英語のスコアや成績だったりも加味するけど、勉強したいという熱意が感じられるかが重要
- 「ちゃんと考えて、調べて勉強して、自分の強いところ弱いところを示して、それで何ができるかを書いてもらえれば。努力の跡が分かればよい」
出願時のコツ：
- 「私は募集要項を満たしている！」ということを示せるように作る
- 周りに見てもらう
- 今後どうしていきたいか、キャリアについても考えておく
- 読めない論文については国立図書館に行って論文を読んだりするといいかも
出願者の傾向：
- 秋3倍、冬3－4倍
- 金融が3ー5割、ほか事業、商社、コンサル、ベンチャーさまざま。外国1割くらい。
- 「こういう業種に勤めているけど大丈夫？」→ 大丈夫。不利になることはない。
この説明会の情報をまとめると、一次試験はざっくり言って「あなたがどれだけ努力（準備）できるか、そして努力の方向性を知っているかを見せてくれ」という試験と言えそうでした。また所属する企業によって選考の合否が左右されるといったことはなく、あくまでMBAに通うことに苦言を呈されたり講義に出席できなくなったりしないかの確認程度のようでした。
さて、上の選考基準からもわかるように一橋大学は論文を書かせることを強く意識しています。このため、私は論文が書けます！ということをアピールする研究計画書を作成する必要があります。
良い論文を書くために必要なのは良いテーマですが、良いテーマを考えるためにはその業界のドメイン知識、例えば人々が何について関心を持っているか、どういった問題に悩んでいるのかを知っておく必要があります。
しかしながら、私は金融については知識が全くなく、どういった研究がなされているのかすらわからないという状態からのスタートでしたので、書店に行って経済、経営学部の大学生向けの書籍を探し、一日で読めるものを何冊か読むことで基本的な単語や概念の習熟に努めました。また最新の研究にキャッチアップするため、The Journal of Financeといったトップジャーナルの受賞論文などを中心に一日1から2本のペースで読みました。計画書を書くまでに26本をざっと読み、そのうち13本を精読しました。論文の管理にはNotionを利用しました。私は主に通勤時間を利用してこれらの準備を行いました。また、夜寝る前に友人らに論文の内容を共有することを意識し、論文読みを習慣づけました。
仮想通貨にテーマを固めたのは12/28です。ある友人が「仮想通貨ではこんな現象があるんだよね」とたまたま持ってきてくれた雑談のネタを膨らませたものがベースになりました。仮想通貨についてもざっくりとした理解しかしていなかったため、テーマが決まったあとの年末年始は仮想通貨関連の論文や書籍、ノードのリファレンス実装を読んで過ごしました。
研究計画書を実際に書き始めたのは1/11の夜からです。どの程度仮想通貨の技術的な面に踏み込んで記述するかで迷走してしまい、第一稿を読んだ研究者の友人には「こんな辞書みたいな研究計画書は初めて見た」と言われ、1/12の夜から書き直しを行いました。技術的に正しくあろうとして詳細に書きすぎた結果テーマ自体がぼやけてしまうのでは本末転倒だと考えなおし、審査員に技術面で疑問を持たれた場合は口頭で説明すればよいと割り切って、ほぼすべての技術的な内容を削りました。結果的に自身の興味や検討している手法について簡潔に伝えられる文章になったと考えています。研究計画書については複数の友人に目を通してもらうことが非常に重要だと実感しました。
一次試験の結果は2/3ごろに郵送で届きました。
なお、一橋大学は研究計画書とともに志望動機なども併せて送る必要があるのですが、その中の質問で下記のようなものもあり興味深かったです。この質問の意図については入学後に聞いてみようと思います。
＊Q4．音楽、絵画、彫刻、建築、文学、哲学、スポーツなど、あなたが興味を持ち、評価するも のがあれば、簡潔に記してください。（400 字以内）
二次試験について
二次試験に関しては特別な準備はせず、自分の計画書や引用した論文を読み直し、それらを簡単に要約できるようにしておいたくらいです。私の解決したい問題に対して別のアプローチがあるのではないかと犯罪捜査系のジャーナルを読んでみたりはしましたが、特に有益な情報は得られませんでした。なお、これに関しては先行研究を網羅的に調べたかといった観点での質問があった場合には有効な対策だったかもしれません。
二次試験の面接時間は15-20分程度で、希望する指導教員と、分野的に近い教員の2名に面接していただきました。終始穏やかで、圧迫を感じるような質問や態度は感じられませんでした。むしろ私の言葉足らずな点を補完していただいたような感覚でした。
質問は下記のようなものでした。
名前と受験番号を。 研究計画書の内容を要約して。 XXXというデータが必要のようだが、それはどのように取得するのか。 本プログラムに期待することは。 志望理由からジェネラルな経営学が学べる大学院の方が適しているかもしれないがなぜ一橋大学を選んだのか。 研究を広げてXXXについても考慮して良いと思うがどうか。 人文系の学問は理系のアプローチとは大きく異なるがどう考えるか。 家が遠いが通学可能か。
これらの質問には、研究計画書を本当に本人が書いたのか、先行研究は十分に理解して引用しているのか、ミスマッチが起きないかという点を確認する意図が見受けられました。また、研究を広げてみてはどうかという質問については2年間で終わらせるのはあまり現実的ではないサイズの拡張でしたので、タスクの大きさを把握できているのかを判断する意図もあったのかもしれません。面接の最後に「先行研究もよく調べてあるし、計画書も問題ないですね。」とおっしゃっていただけたので報われました。
今後について
金融、経営学といういままで接点のなかった分野を体系的に学べる貴重な経験を楽しみにしています。またNAIST時代の心残りとしてジャーナルという形で成果が出せなかったというものがあり、一橋大学では絶対にジャーナルを出したいです。
金融、経営学の論文を表層だけ掬った者の感覚として、この分野にはまだまだ情報科学の手法が浸透しておらず、情報科学を持ち込むことで業界にそれなりの貢献ができそうだと感じました。また、扱うテーマもかなり多様で、現実世界と繋がった莫大なデータを扱える点は金融、経営学ならではの楽しみだと思います。この分野楽しいよ！おいでよ！と自信を持って人を誘えるようになれるよう精進していきたいと思います。
謝辞
今回の受験でも、様々な方にご協力いただきました。この場で感謝を述べさせていただきます。
- お忙しい中推薦状を用意してくださった中村教授
- 突然のDMでの相談に乗っていただいたSさん
- 夜な夜なの論文読み雑談に付き合ってくれた友人Y
- 計画書絶句太郎の友人M
この漫画が好き2021
お久しぶりです。前年に引き続き、2021年もコロナウイルスの一年でしたね。 来年こそはコロナウイルス以外の話題が出る一年になってくれるといいなと思っています。
では早速2021年に僕が読んだ漫画の中でベストを紹介していきたいと思います！
かげきしょうじょ！
僕の中での今年の漫画といえばこれ！ アニメ化されたのを知って軽い気持ちで読み始めたんですけど、こんなに素敵な作品を読まずにずっと放置していた自分に感謝しちゃいましたね。 それぞれのキャラクターはそれぞれ「自分はこうありたい」という信念があって、そのありようがかっこいいんですよね。理想を追いかけるのって大変だよね。自分ではどうしようもない理不尽なこともたくさんあるし。 健やかに成長してくれ頼む～。
クプルムの花嫁
職人の街、燕三条で生活しているカップルの話。 これはなんていうか幸せにイチャイチャしてるカップルを後方保護者面して見守る漫画ですね。かわいい。かわいいんですわ。 かわいすぎて燕三条で作られたおちょこ買っちゃいましたもん。
この世界は不完全すぎる
開発中のゲームのデバッガーの人たちがゲームの世界に閉じ込められてしまい、現実の世界へ戻る手立てを探すという話。 実際のゲームで発生する様々なバグによって問題が発生したり、逆に利用して事態を切り抜けたりする。 ゲームに閉じ込められちゃった系にありがちなトンデモ設定はなく、「あー、そういう仕様だったらそうなるかもしれないね」と思わせてくるようなバグの設定だったりして、エンジニアの端くれとしても読んでいて面白い。
ふたりエスケープ
漫画家と無職が同棲している日常をただ眺めるだけの漫画。日常っていうか、漫画家が締め切りに追われる中無職と二人で現実逃避するだけの最高にゆるい漫画。最高。
この漫画を出すのはずるいかなと思ったんですけど、久しぶりに読んでやっぱりすごい作品だったので挙げます。 この作品は命の大事さを訴えているみたいなレビューをよく見るし、自分もそうなんだと思っていました。 けど改めて読んでみると、患者を見殺しにしたり高額な請求をしたり、かと思えば無料で治療をしたりとむちゃくちゃです。 何度か読み直しているのですがブラックジャックの思想にまだ自分が納得できるほど一貫性は見出せていません。 でもこういうキャラクターの思想について読者にぼんやりとでも考えさせてくるこの作品はやっぱりすごい。
焼いてるふたり
BBQ好きのメガネ男子がクールビューティー系女子と結婚生活を送る話。いやふたりともかわいすぎるんですねえ…。 出てくる料理もいつもおいしそうで自分も試してみようかな～って思っちゃう。
以上が今年の漫画です。2022年もすてきな漫画ライフになるといいですね！
この漫画が好き2020
いつの間にかもう師走ですね。 2020年はコロナウイルスの影響で世界中が大変なことになっていましたし、個人的にも今年は転職したりと変化のある年だったように思います。
そんな中でも漫画は変わらず生み出され続けてましたね。感謝…！！！！！
というわけで今年の漫画を振り返っていきたいと思います。
スキップとローファー
今日はこの作品の話がしたかったんですよ。今年読んだ作品の中で一番好き。 石川県から進学のために東京に来た高校生の話なんですけど、何に対しても一生懸命でいっぱいいっぱいの主人公が本当にかわいくて愛おしい。涙が止まらない。眩しいぜ…。 周りの人たちとの交流も最高なんです。読んで欲しい。本当に。
夏目アラタの結婚
連続殺人鬼が隠した遺体の場所を知るために犯人と関わっていくというストーリーなんだけど、これもすごい作品。 なにが事実なんだろう、なぜ殺人が起きたんだろうと気になってしまって新刊が待ち遠しい…！
あさこ
いわゆるおねショタ。主人公は既に大人になっていて、物語は回想という形で進む。 主人公の初恋の「お姉さん」であったあさ姉が何者だったのか、なぜ主人公はあさ姉に「失望」したのかという謎を掘り起こしていく話。 ちょっと苦さもあるんだけど、いい作品。
フリクションガール
僕は趣味でボルダリングをするのだけど、好き！って言えるボルダリングや登山の漫画ってあんまりなかった。 この作品は面白い。ボルダリングを楽しんでいる人が描いてるんだろうなと思う。雰囲気的にはゆるキャンよりちょっとストイック、という感じ。 この作品は強くお勧めしたいです。
余談だけど、ボルダリングや登山系の漫画でいえば孤高の人の"1巻"が好きなんですよね。誰か1巻の流れのままのアナザーストーリー描いてくれませんか？読み終わって「なんで？？？なんで世の中こんな辛い？？？」とならない漫画をお願いします。本当に。
埼玉の女子高生ってどう思いますか？
埼玉の女子高生がゆるーく埼玉のご当地を巡ったりローカル話を繰り広げる話。埼玉いいじゃん、行ってみようかなって気持ちにさせてくる。
SA07
姫サーの姫がイラストレーター専門学校に進学する話。 姫、自分に正直でちょいちょい健気でかわいい。 最近、ブルーピリオドとか星明かりグラフィクスとか、美術系の作品は良作が多い気がする。
よふかしのうた
友人曰く「（ナズナは）可愛いとこある女だと俺だけは気づいていた」。僕もそうだと思ってました。かわいい。
せんせいのお人形
この作品、Kindleだと3巻で打ち切りのように終わってしまっていて、続き全てを読むのであれば comico で見るしかない。 この僕にKindle以外の電子書籍を買わせたのは君が初めてだよ…。僕の内なるアインも「やるじゃない（ニコ…）」って言ってました。
リビルドワールド
ロストテクノロジー拾い集める系。銃夢的な雰囲気がないでもない。僕は好き。
ヴァンピアーズ
ストレッチ
アキリさんのちょっと影のある百合は無敵です。
以上が2020年で読んだ中でお気に入りの作品です。それでは皆さん良いお年を。
この漫画が好き2019
既に2020年となってしまったが、2019年のうちに読めてよかったなと思っている漫画をいくつか紹介させていただく。 残念ながら昨年はそれほど漫画を読むことができなかったのだが、それでもいい作品に出会えたことは喜ばしいことである。
チェンソーマン
2019年に読んだ漫画の中で一番独特だった。 僕は面白いと思うけど、人は選びそう。 ドロヘドロというよりはZETMANのような雰囲気…なのだろうか。
はい全員かわいい。今日も世界が美しい。
数字であそぼ。
天才と言われていたのに大学に入学して最初の数学の授業で挫折していきなり2留してしまった男の話。 動物のお医者さん的な緩い大学キャンパスライフの雰囲気。
異世界おじさん
異世界転生系の作品の面白さはピンキリなのだが、この作品は他とは一線を画している。 俺TUEEEでありながら俺TUEEEにありがちなストーリー展開ではないというか。
北欧貴族と猛禽妻の雪山狩り暮らし
雪国の貴族が元軍人の妻を娶る話。えっかわいい。二人が。
徒然日和
なんで3巻で終わってしまったのでしょうか。 まだまだ続くと思っていたのに急に終わらせないでください…つらい…。
狼は眠らない
一応異世界系の作品という扱いになるのだろうか。 異世界系の漫画は画力でだいたい面白さがわかる気がしている。 多分この作品を描いている人はこの作品がちゃんと好き。
小学生ってこんなマインドだよな、というのを思い出させてくれるというか、著者の人生を読者に再現させてくれる。
ヴラド・ドラクラ
ドラキュラのモデルとなったワラキアの君主ヴラド3世を中心とした歴史系。 即位した時点で国としては結構オワコンな状況だったのをなんとか立て直していく話。
ショートショートショートさん
一巻で終わりなんでしょうか…是非続きが読みたい。そしてこれよく見たら今年の1月発売じゃないですか。
マイ・ブロークン・マリコ
突然、親友が自殺した、しかもそれをニュースで知る。という始まり。 人によっては訳がわからない作品という評価になるのかもしれないけれど、シイノの薄情なところとか、マリコの面倒くさいところとか、僕は結構好きだ。
最近はWeb上に漫画が公開されていたりして、素晴らしい時代になったと思う。 実際公開されている作品を読んでからKindleで購入するパターンが結構あって、作品を探すのに大変役立っている。
ただ、問題はこれらのサービスがRSSなどに対応していない場合があることだ。 新しい話が出てもそれに気付けなければ読むことができない。しかし巡回し続ける暇もあるわけではない。 ということでkeeptrackdという自動巡回ツールを作成した。
https://github.com/delihiros/keeptrackd
このツールは、登録したURLを巡回し、前回の巡回の結果との差異を見比べて、もし新しい話などが出ていれば通知を行うという物だ。 keeptrackdはプラグインによって対応するWebサイトを増やせるよう設計されている。 プラグインは誰でも簡単に作成することができるので試していただければ嬉しい。
この漫画が好き2018
前年に続き、Kindle内の漫画の数の増加がとどまることを知らず、ついに2,000冊が見えてきた。
いったいいくら使ったんだろうな…と遠い目にならなくもないが、ランダム買いを続けたことでいい作品にもたくさん出会うことができた。 ここでいくつか好きな漫画を紹介させてもらい、財布から散った諭吉達への手向けとしたい。
座敷娘と料理人
青年が座敷に住み込んで神様に料理を作るという話。今年読んだ漫画の中で一番好きかもしれない。 作品全体はほのぼのしている一方妖怪と人の物悲しい関わりの描写もあり、今市子の百鬼夜行抄を思い出した。
座敷娘と料理人 1巻 (デジタル版ガンガンコミックスONLINE)
- 作者: 佐保里
- 出版社/メーカー: スクウェア・エニックス
- 発売日: 2018/10/22
- メディア: Kindle版
- この商品を含むブログを見る
高校女子サッカー部の話。マネージャー含めたチームメンバーそれぞれがサッカーを楽しんでいて読んでて泣ける。 さよならフットボールという作品の続きでもある。さよならフットボールを読まなくても、本作の話はわかるし全く問題とはならない。
- 作者: 新川直司
- 出版社/メーカー: 講談社
- 発売日: 2016/08/17
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
どうにもこうにも
主人公は新人漫画大賞を受賞した期待の新人だったけど、その後は全くうまくいかず担当編集に「もうネームは送ってこないでいいから」とまで言われてしまう。しかしとあるきっかけで専門学校の先生として採用されることになる。 結構心が痛む話もあるんだけど、全体としてふふっと笑えるコミカルな漫画。全3巻ですっきりまとまっていて読みやすい。
どうにもこうにも 1巻 (マッグガーデンコミックスＥＤＥＮシリーズ)
- 作者: 日下直子
- 出版社/メーカー: マッグガーデン
- 発売日: 2018/11/05
- メディア: Kindle版
- この商品を含むブログを見る
ブルーピリオド
美大受験を目指す高校生の話。主人公が作品制作に真摯に向き合っている姿がいい。いろんなところで他人との能力差を感じたりするよね…。
- 作者: 山口つばさ
- 出版社/メーカー: 講談社
- 発売日: 2017/12/22
- メディア: Kindle版
- この商品を含むブログを見る
推しが武道館いってくれたら死ぬ
タイトルで敬遠していたものの、読み始めたらめちゃくちゃ面白くて何回も読み直して徹夜した。 登場するアイドルそれぞれがそれぞれのアイドル像を持っていてかっこいい、そして可愛い。 推しを応援する主人公達も必死で応援してて、愛を感じる（現実でやったら完全にアウトなレベルだけど）。 笑えるしかっこいいし泣ける。
推しが武道館いってくれたら死ぬ(1) (RYU COMICS)
- 作者: 平尾アウリ
- 出版社/メーカー: 徳間書店（リュウ・コミックス）
- 発売日: 2016/02/29
- メディア: Kindle版
- この商品を含むブログを見る
主人公がレース界で上の世界を目指すモータースポーツ漫画。 モータースポーツをするにはお金がかかるが、少年カペタは金銭的に恵まれていないためカートの新調もおぼつかない。 そんな状況でもレースで勝つため手を尽くして戦う姿が格好いい。
- 作者: 曽田正人
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- 購入: 1人 クリック: 1回
- この商品を含むブログを見る
はじめアルゴリズム
少年が数学者の元で数学を学ぶ話。数学が好きでも苦手でも楽しめそうな漫画でおすすめ。
- 作者: 三原和人
- 出版社/メーカー: 講談社
- 発売日: 2017/11/22
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
新世紀エヴァンゲリオンピコピコ中学生伝説
エヴァンゲリオンの新作出ないじゃん！ずっと待ってるのに！という方におすすめ。 色々どうでもよくなるギャグ漫画。
落ちてるふたり
高校生の主人公の隣人は、ヨユーヨユーと言いながら講義に行かず単位を落とし留年する大学三年生。 二人がゆるい隣人付き合いをする話なんだけどほのぼのしてて好き。
- 作者: 西原梨花
- 出版社/メーカー: 講談社
- 発売日: 2018/07/09
- メディア: Kindle版
- この商品を含むブログを見る
僕と君の大切な話
ラブコメ。主人公達があまり噛み合わない会話を続けるだけなんだけど一つ一つは共感もできてふふってなる。
- 作者: ろびこ
- 出版社/メーカー: 講談社
- 発売日: 2016/03/18
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
違国日記
親を亡くした中学生が叔母に引き取られるところから始まる。キャラクターそれぞれが自然な感じがして好き。 人がしたことや言ったことって、本人が思っているより大きな影響を他人に与えることがあるよなーと読みながら思った。多分著者が意図した訳ではないと思うけど。
- 作者: ヤマシタトモコ
- 出版社/メーカー: 祥伝社
- 発売日: 2017/11/22
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
高校時代の友達の本棚にあった漫画。当時はそれほど面白く感じなかったけど、改めて読み直した結果徹夜。
- 作者: 山田芳裕
- 出版社/メーカー: 講談社
- 発売日: 2012/09/28
- メディア: Kindle版
- 購入: 2人 クリック: 2回
- この商品を含むブログ (1件) を見る
以上が今年読むことができたお気に入りの漫画だった。 来年もまた楽しい漫画に囲まれますように。
サービスに障害が発生したらどうしたらいいの？
どれだけ対策しようとサービスに障害はつきものですが、障害が発生したら損害が出るしユーザに謝ったりしないといけませんよね。 そういう非常につらい状況の中、障害からできるだけ早く復旧し、原因を究明して同じ障害が再び起きないよう対策を実施しなくてはならないわけですが、じゃあどうやったら効率的に調査できるの？という点についてまとめてみました。
障害つらいけどみんなで生きていきましょう。
なおこの記事は所属とか関係なく個人の見解であり云々ということを最初にお伝えさせていただきます。働き始めるとこういうところが心配になっちゃうんですね…。
あともっとこうしたほうがいいんじゃない？というご指摘があれば記事の内容を変更を検討しますのでぜひご連絡下さいませ。
障害は発生します
前提
まず前提としてですが、どれだけ信頼性の高さを謳っているハードウェアを使っても壊れる時は壊れますし、ソフトウェアには不具合があります。 ハードディスクは容量いっぱいになるし、OOM Killerはいつだって包丁を研いでいるし、データベースは操作ミスで全部消えることだってあります。 だから残念ながら障害が発生することは根本的に避けられません。 またユーザは原因についてはあんまり関心がありません。例えデータセンターにUFOが突き刺さったことが障害の原因だったとしても、重要なのはガチャが引けなくなったことです。 「オレのせいじゃないのに…」という気持ちは痛いほどわかりますが、何が原因であったとしてもサービス自体への影響を小さく抑えられるように頑張る必要があります。
事前の対策
ではどのような対策をしておけばいいのでしょうか。 例えばだいたいの場合において、バックアップとシステムの冗長化は非常に有効です。 定期的にデータのバックアップをしておけば、少なくともバックアップした時点までは復旧できるし、うまくシステムを冗長化しておけばシステムのコンポーネントのうち1個くらいに障害が発生しても何事もなかったかのようにサービスが継続できます。多分。 つまり原理的に障害の発生が避けられないなら、もう障害が発生することを前提としてシステムを設計しようよ、というわけです。
「冗長化するということはコストが上がるってことでしょ？」という疑問は当然だと思います。 趣味で動かしているサービスとかだったら普段のランニングコストは抑えたいし、障害が発生しても「メンゴメンゴw」で済みます。 だからやりすぎればいいってもんじゃないという点については完全に同意です。 けど、エンタープライズならサービスが止まればサービスの信頼も落ちるし冗長化するために必要なコスト以上の損害が出るかもしれません。 なので、動かしているサービスの性質や、万が一障害が発生したらどれくらい損害が出るかを元に、どれくらいのダウンタイムが許されるのか、どの程度のデータの損失まで許されるのかといった見積もりをしてシステムを設計する必要があります。
復旧時間の短縮
障害が発生したときの対応を事前にチーム内で決めて共有しておくことで障害発生時の復旧を早めることができます。 復旧を優先するならその手順に従えばよいし、調査をする場合は何を見れば何を確認できるのかを事前に確認しておくことが重要です。 障害の影響度によって、とにかく復旧を急ぎたいのか、原因を調査するかは変わってきますので、この辺りの判断もできるだけ早く行いたいし、ベンダーのサポートに調査を依頼するときもこの辺の方針を一言入れておくだけで良い対応案を提案してくれるかもしれません。 また、あらかじめベンダーのトラブルシューティングや「よくあるご質問」のページへのリンクを共有し流し読みしておけば障害発生時に「あ、これもしかしてあれかな…」と手がかりが得られる場合があります。
システムの構成がどうなっているかについてもチーム内で共有しておくと原因調査に役立ちます。
システムの障害は、そのシステムに詳しい人がいる時だけに発生するとは限りませんから、文章としてシステムの構成を記録して残しておきます。
例えば、サーバのハードウェア構成とか、アプリケーションの正しい状態はこうだ、そしてそれらはこのコマンドを打てば確認できる、というような文章が共有されていれば、「そもそもこれは不具合なのか？」「何が期待される動作と異なっているのか？」といった点をすぐ判別することができます。
サーバが一般的でない構成となっている場合は、その背景についても共有しておきます。
変な設定になっていたりすると「こいつが原因なんじゃね？」という偏見観点で調査をしてしまいがちですが、背景が納得できるものであればうまく切り分けができるかもしれません。
また背景がわかっていたら後々もっと良い構成を取ることができるようになるかもしれませんしね。
テスト
システムのテストもしておきます。 障害に対する準備ができたと思っても、実際に障害が発生した時にうまく対応できなければ効果がありません。 一部のコンポーネントを落としてもサービスが継続するか、ネットワーク通信が遮断されても他のエンドポイントへ切り替わるか、バックアップからの復旧にはどれくらいの時間がかかるのかなど確かめておくと、いざという時に慌てなくて済みます。
メトリクスとログ
障害に対応するためには当然ながら障害が発生したことを検知しなければなりません。 サービスは動いているのか？ネットワークに問題はないか？ハードウェアに異常は発生していないか？パフォーマンスは足りているのか？といった観点でチェックを定期的に行なって、異常な状態となったことをできるだけ早く検知します。 また、検知したときに自動的に復旧したりフェイルオーバーする仕組みを取り入れておけば、人が作業する時間を短縮できるのでそのぶんダウンタイムを減らせます。
最後に、ログは非常に重要です。できる限り取りましょう。 こいつがないと一体何が起きていたのかわからず大体の場合迷宮入りすることになります。
障害が発生したときの事前の準備はとても大事です。面倒ですけど頑張りましょう…。
障害が発生したら
障害が発生したら、まず何が起きているのかや影響はどれくらいなのかを確認し、復旧か原因調査のどちらを優先するかを判断していきます。
復旧を優先するのであればバックアップからデータの復元を行なったり、スタンバイへ切り替えを行ったりすることになります。 ただ、原因がわからない以上復旧しても再発する可能性はあるので、復旧を優先したとしても原因究明は必要です。
じゃあどうやって調査していくの、という点ですが、まずはどのような障害が発生していたのか？の詳細を確認していきます。 障害が発生していた、ということは何かを元に障害と判断したということなので、メトリクスなりログなり、ユーザからの問い合わせなりを確認します。
障害調査に必要な情報
障害調査を行う上では、以下のような情報が重要になります。 この辺の情報は時間が経つにつれ記憶が曖昧になったり、取得ができなくなったりするので、できるだけ早い段階で記録しておきます。 ベンダーのサポートに調査を依頼するときもこの辺の情報を要求する場合が多い、というか必須なので、できるだけ少ない往復で解決したいのであれば初回の問い合わせでこの辺の情報と合わせて、どこまで調査したかを伝えるのが良いです。
- 事象の詳細
- 事象の発生日時。いつからいつまで発生していたのか、今でも発生しているのか
- 何を元に障害と判断したか
- エラーメッセージ
- システムログ
- アプリケーションログ
- 各種メトリクス
- OSやアプリケーションのバージョン
- システムの構成
- ネットワーク周りなら通信相手の環境など
- 再現性。同じような環境でも発生するのか、そのマシン固有なのかなど
- 心当たり（直前にシステム構成を変更したりパッケージのアップデートを行ったなど）
事象の詳細って何？
事象の詳細や日時については、例えば「SSH接続できない」という事象でも「他のマシンからは接続できるけど一部の環境からは接続できない」のか、「マシンへの疎通性がそもそもないのか」で全然違うものなので、できるだけ詳しく記録します。 ssh -vvvの出力はどうなっているのか、サーバ側のsshdは正常に起動しているのか、そのマシンで動いている他のアプリケーションは動作しているのか、ファイアウォールの設定はどうなっているのか、/var/log/secureはどうなってる？そもそもネットワークに繋がっているのか…といった感じで、色々確認していきます。
判断の根拠
何を元に障害と判断したか、というのは、だいたいの場合エラーメッセージだったりログだったり、メトリクスに異常な値が記録されているから、という答えになるかと思います。 障害の発生を判断するためには、「本来あるべき形」というものがわかっている必要があります。 「メトリクスが変に見えるから障害」というのは早計な場合があって、例えばストレージへの書き込みやネットワーク通信の量に異常に大きい値が記録されていても、実はバッチ処理を裏で動かしていただけだったり、アクセスの量が増えただけかもしれません。 CPU使用率が跳ね上がっていても、実はアプリケーションが正常に動作しているだけで、サービス自体には影響がなかったかもしれません。 この辺の判断は難しいので、複数のメトリクスを見つつサーバのキャパシティを大きくしたりしてどのように変化するかなど確認していく必要があります。
調査
実際の作業としては、事象が発生していた日時のログとそれぞれのメトリクスを眺めながら、相関らしいものがあるか、謎のエラーメッセージがあるかなどを頑張って見つけていくことになります。 Linuxであれば、syslogや/var/log/messages、/var/log/secure、/var/log/ntp.log、sysstatの結果、WindowsならApplication.evtx、System.evtxなどのログを取得します。 ipmitoolが使える環境なら、ハードウェア側に問題があったかなどを確認することもできますので設定しておきましょう。 OS上のログだけではなく、例えばZabbixなどの記録があればそれらも含めて何が起きていたのかを精査していきます。
OSやアプリケーションのバージョンに依存して発生する不具合もあります。 この辺りも記録して、似たような事象が報告されていないかを公式フォーラムなどで確認します。 それと使っているアプリケーションのバージョンはできるだけアップデートしましょう。 古いバージョンを使い続けることは、とりあえず動くという意味で楽ではあるのですが、セキュリティ上のリスクがあったり機能の制限があったりしてだんだん不便になってきます。サポートもいずれ切れます。 バージョンがものすごく古くなってから最新のものにアップグレードするコストは大きくなりがちで、そうなると「もう移行無理です」みたいな状況になるかもしれません。色々なしがらみがあって大変だろうとは思いますが、マメにアップデートできるよう頑張りましょう。 なおバージョンを変更する前には必ずバックアップをとって不測の事態に備えておきます。
システムの構成や通信相手の環境が原因で発生する障害も少なくありません。 エラーから「こいつが原因じゃね？」とサーバ側の設定を疑っても問題が見られない場合は、もうちょっと広い視点を持って、例えばアプリケーションが利用するAPIサーバとは正常に通信できていたのか、社内のネットワーク設定やファイアウォールに変更がなかったかといった観点で見直してみましょう。
それでもわからないとき
以上を実施したけど全然わかんねえ、という場合は各ベンダーの技術サポートにぶん投げてみましょう。 もしかしたら何かいいアドバイスをくれるかもしれません。なお技術サポートはだいたいの場合サポート範囲があるので、その範囲内での質問にしましょう。 あとサポートも人間なので、できるだけ紳士的に問い合わせましょう！
原因究明したら
原因がわかったらなんらかの対応が必要になります。 まずユーザへ影響があったなら、早めに謝罪をします。また、可能な範囲で影響範囲と当面の事象のワークアラウンドについてアナウンスをします。 その次に、サービスへの影響度とコストから、そもそもこれは対応が必要なのか、どのような対応を行なっていけば良いかという点について考えていきます。 対応が完了し次第、事象から得た教訓と対応をドキュメントにまとめて一旦収束…という形にしたいですね（願望）。
「なんか障害起きてたけど全然わかんねえ、どうしたらいいんだ」という場合は、なぜ切り分けができなかったかということを考えて、それを元に再発した時に調査できるようログの設定やメトリクスの追加をしておきます。 また、何度も障害が発生するのであれば、障害が発生していた時の共通点を見つけるために発生日時やログ、メトリクスを収集しておきます。 いつか原因わかるといいですねって感じですが、気長に頑張っていきましょう。
頑張っていきましょう
だいたい上のような対応になるかと思いますが、何か「変じゃないこれ？」みたいな部分があったらお知らせいただけると幸いです。 障害はつらいけど一緒に頑張っていきましょう。
