8ヶ月の育休を取る話
Autify で Senior Software Engineer をしています。
この度、2022年12月から8ヶ月間の育休を取りました。
なぜ長期育休を取ったのか
- 家族との時間が欲しかったため。子供はとても可愛いです。可能な限りお世話したくなります。
- 妻一人での育児大変そうなため。いくら可愛いとはいえ、一日中つきっきりでお世話していると大分精神に来ます。育休を取る前は基本的に妻が一人で面倒をみていて、週末や自分の隙間時間にちょっとお世話をする程度でした。一番大変なのは夜泣きのお世話で、私は金曜・土曜の夜、それ以外は妻が担当していました。夜泣きが激しいときはだいぶしんどそうでした。
- 仕事を休んでみたくなったため。思えばこんなに長期の休みを取ることは今までありませんでした。少し疲れているのもあり、仕事から離れて長めの休みを取るのも悪くないのではないかと思いました。
- 自分の時間の確保のため。仕事した後に子供のお世話だと、平日はほぼ自分の時間はありません。
育休を取るにあたり不安だった点とその対処法
- 収入。育休中は収入がガクッと減ります。国から育児休業給付金がもらえますが、普段の稼ぎの半分以下*1になります。家計的にはマイナスにはならないものの、大分影響は大きそうでした。幸い、会社から3ヶ月間は給与との同額*2が給付されるため、大分助かりました。国からの育児休業給付金は雇用保険から出ているため、12月まで育休を取るのを待たなくてはいけませんでした*3。
- キャリア。プログラミングの腕がなまらないか心配です。この際、競技プログラミングに手を出して見ようかと思っています。今まで使ったことがない言語でやってみようかと思っています。またいい機会なので Computer Science と英語を勉強したいと思います。更に余裕があれば副業を少しだけやろうと思っています*4。
- 仕事。3ヶ月くらい前までは、自分しか知らない部分が結構あり抜けたときの影響が心配でした。しかし、新しく入社してくれた方がものすごく優秀で、ペアプロしながらの引き継ぎ、ドキュメントの更新等により、自信を持って休暇に入れました。職場は育休自体にはすごく理解があり、育休を取ること自体で反対の反応などをもらうことは全くありませんでした*5。
実際取ってみてどうか
2022年12月12日時点で育休を取ってから1週間ほどでの感想です。
- とても良いです。子供のニコニコ顔が見れて幸せです。家族で毎日お散歩しています。
- 妻の負担もだいぶ減ったようです。夜当番も一日交代にしたので、睡眠時間もより多く確保できるようになっていました。
- 自分の時間は思った以上にできませんが、仕事をしていたときよりは圧倒的に余裕があります。
- 両手が空く時間は少ないので、大半は抱っこしながらになります。右手だけでできるゲームか、ウェブサイト、書見台をつかっての読書などができます。現在は、勉強系だと『英語のハノン』、SICP、ゲームだと Across the Obelisk 、Alina of the Arena などをやっています。ただ、進捗は芳しく無く想定よりも遅いペースですが、コツコツとやっています。今後はCSについてはこのリストをやっていくのと、本を数万円分買った*6のでそれを読み進めようと思っています。英語については『英語のハノンシ』リーズの他、English Grammar In Use や単語やコロケーションなどをやるつもりです。
- 格闘技のジムにほぼ毎日通っています。ジムに通う前から比べると、4ヶ月で7キロ体重がへりました。筋トレがソフトウェアエンジニアのトレンドになっていましたが、次は格闘技がくるのではないでしょうか？MMAだと怪我のリスク*7がありますがキックボクシングならあっても打撲くらい*8なので仕事にも影響はないと思います。普通のジムでの筋トレはつまらなくてやめてしまったのですが、こちらは継続して通えています。
子育てで便利だったもの
意外と便利だったものを紹介
- アクアクララ。ウォーターサーバです。熱湯が一瞬で出るのがすごい便利です。特に夜泣き時にすぐにミルクを用意できます。これを使う前は私一人だけでミルクの対応する場合は時間がかかり*9、その間子供はギャン泣きしてしまいかわいそうでした。
- ネムリラ。電動ゆりかごです。ご飯時でもぐずってしまう時など、これに入れてあげると落ち着くことがあります。赤ちゃんによって相性があるそうです。お店で買うよりAmazonで買うほうがです*10。
今後
育休はまだ始まったばかりです。現在は本当に取って良かったと思います。
取り終わった後、また振り返れればと思います。
書評『カオスエンジニアリング――回復力のあるシステムの実践』
meiko hori (@m3iq) | Twitter から献本いただきました！ありがとうございます！
カオスエンジニアリングについての説明から実践例、導入方法や応用などまとまった情報が集まっていました。
各章のざっくりまとめメモ
イントロダクション：カオスの誕生
- 「カオスエンジニアはテストではなく、実験の1つ」単にカオスをもたらすのではなく、本番環境の不安定さに耐える能力に自身を持つために行う。
自信があるならそもそもやらなくていいし、自信をつける他の良い方法があるならそれを使ってもいい。 - 予測不可能な複雑性に対しては、ユニットテストのように既知のロジックを検証するのではなく、 ブラックボックス的に、システムの一部を壊したとしてもシステムがの定常状態を維持できるかを試すことで自信をつける。
1章 複雑なシステムとの出会い
- 複雑な分散システムににおいては各コンポーネントそれぞれは最大限努力した上でも、どうしても予期できないエラーが起きてしまう。
例）ブッラクフライデーに備え、コードをフリーズしたことに起因する障害が起きた。何もしてないのに（から）壊れた事例。 - 複雑性を認める。シンプルに留めたくても機能を追加するたび、偶発的な複雑性（技術的負債）と機能自体の本質的な複雑性が増していく。
これを受け入れ、対処することが重要になる。
2章 複雑なシステムの舵をとる
- 動的安全モデル：開発者はコストや人的リソースについては直感的に考慮できるが、安全性（可用性・セキュリティ）についてはそうではない。そのままだと安全性が軽視されてしまうので、何らかの形で自然と考慮できるようになると良い。
- 経済的支柱：複雑性には、状態・関係・環境・可逆性の4つの要素があるが、ソフトウェアエンジニリングにおいては可逆性に最適化するのがよい。
3章 原則の全体像
- カオスエンジニアリングは「実験」：システムの定常状態に対し、現実に起こりうる変数を導入しても、定常状態が保たれるかを試す。
なぜ結合テストだけではだめかというと、テストはあくまで既知の要素に対する検証で新しい知識を生まないから。 - どんな変数を選ぶか：学びを最大化できる変数、ユーザー体験に直結する部分を検証する。
- 金融機関や医療機関は当初懸念を示したが、むしろカオスエンジニアリングを使うようになった。
主な懸念は「そうですね、たぶん娯楽サービスやオンライン広告にはいいかもしれませんが、私たちはオンラインで本物のお金を扱っているんですよ」といったところです。それに対してカオスチームは「機能障害が起きることはありませんか？」と問いかけたものです。
4章 Slackの惨劇シアター
- カオスエンジニアリングのSlackでの適用法が詳細な手順とともに紹介されている。きちんと計画し、開発環境をへて本番環境で実験を行う。目的は学習というところにフォーカスしていて、書記の重要さがたびたび言及されている。
5章 Google DiRT：災害からの復旧テスト
- Googleも似たことに2006年から取り掛かってきており、彼ら独自の原則と適応例をかなりきちんと整備している。
6章 Microsoftにおける実験の多様化と優先順位づけ
- Microsoftにおけるカオスエンジニアリングの方法論、また別の切り口の解説でどのようなテストをおこなうと良いかの参考になりそう。
7章 LinkedIn メンバーに対して配慮すること
- LinkedInの事例。いかに実験がユーザー体験に影響を及ぼさないようにしているか。リクエストのモックや「緊急停止ボタン」、ブラウザエクステンションでの実行など。
8章 Capital Oneにおけるカオスエンジニアリングの導入と進化
- オンラインバンクである Capital One での例。CI/CD回すのにさえ監査の対応が必要な中でもカオスエンジニアリングを実践する。
コンプライアンスと規制はカオスエンジニアリングの実践を後押しするのに役立ちます
9章 先見性を生み出す
- レジリエンスエンジニアリング：カオスエンジニアリングのゴールは何かを壊すことではなく、レジリエンスを高めること。
- どのようにカオスエンジニアリングを社内に導入していくか：自動化・ナレッジシェア、ゲームデーなど
10章 人間的なカオス
- 会社組織への応用：組織もまた複雑な分散システム。ならばカオスエンジニアリングを組織や人のコミュニケーションにも応用ができるのでは。
- 「事例1：ゲームデーをゲームする」：インシデントレスポンスのシミュレーションゲームを行う。誰か（例えば知識の単一障害点になりそうな人を）をわざと「休場」させてみる。
- 「事例に2：点と点をつなく」：チームメンバーを一時的に移動させ、異なるチームと数週間から数ヶ月過ごす。生産上のプレッシャーによる欠員への抵抗はあったものの、一部の開発エンジニアが運用チームの仕事をそのまま1年間続けることにするなど面白い結果になった。人気が出てむしろシステムの施工が難しくなった。
- 「事例3：基本的な想定を変える」：向上心に燃えるエンジニアへのメンターシップ。チームのヘルスチェック。
11章 ループの中の人々
- カオスエンジニアリング自体をどう自動化するか。どの部分をどのように自動化できるか。Fittts のリスト。
12章 実験の選択に関する課題（と、その解決策）
- どの部分を実験するかという選択を自動化できそう。初期の Chaos Monkey はランダムに探索していたが、組み合わせが広大すぎてあまりうまく行かなかった。
- そこから専門家が必要になったがトレーニングに時間がかかってしまう。
13章 カオスエンジニアリングの費用対効果
- カオスエンジニアリングによって得られる効能をどう計測するか。Kirkpatrickモデル（反応、学習、行動、結果）
- カオスエンジニアリングによって「反証」されたことによるKPIへの影響を測定する。
- ナレッジシェアやコミュニケーションの促進など目に見えない効果もある。
14章 オープンな心、オープンな科学、そしてオープンなカオス
- 協調的なマインドセット：「なぜシステムに改善が必要なのか思い知らせてやろう」という気持ちだと、他のチームの拒絶反応を招く。
「システムの改善を手助けしよう」というマインドセットなら一丸となってシステムの弱点を探求できる。
15章 カオスの成熟モデル（CMM)
- どうやってマネージャーを説得するか：インシデント発生直後がむしろチャンスになる。
- 成熟モデル：どういった段階を経てカオスエンジニアリングの導入が進んでいくか
16章 継続的ベリフィケーション
- CI/CD の上にさらにカオスエンジニアリングを継続的ベリフィケーション（CV）として乗っける。
17章 サイバーフィジカルで行こう
- サイバーフィジカルシステムとは、ハードウェアとソフトウェアが相互接続されたシステム（航空電子、自動走行車、工業制御など）
- 伝統的な「故障モードと影響解析」の手法では見落としてしまう部分をカオスエンジニアリングで補う。
- プローブ効果：観測システム自体が測定に影響してしまうこと。カオスエンジニアリングでもこれに気をつけなければいけない。
18章 HOPとカオスエンジニアリングの出会い
- HOP: Human and Organizational Performance（人間と組織のパフォーマンス）組織とプロセスを改善するアプローチ。5つの原則。
- カオスエンジニアリングをHOPにも応用できる。シミュレーションゲームの例。
19章 データベースにおけるカオスエンジニアリング
- TiDBという分散データシステム自体に対するカオスエンジニアリング。
CPU、メモリ、ネットワーク、ファイルシステムなどに故障を注入する。 - Schrodinger というカオスエンジニアリング自動化ツールを作り、継続的に実行する。
20章 セキュリティカオスエンジニアリングの事例
- セキュリティについてもインシデントに対して受動的に対応するのではなく、能動的に学べるとよい。
- セキュリティゲームデー、ChaosSlingr によるセキュリティカオスエンジニアリング。
21章 おわりに
- 直感的な考えは経験的に間違っていることもある。
- ツールそれ単体が回復力を生み出すことはないが、カオスエンジニアリングというツールをつかってシステムを改善しよう。
感想
カオスエンジニアリングを初めて聞いた時には、本番でわざと障害を起こすというセンセーショナルな説明を聞いて奇想天外なアイデアだな思ったものだが、この本を読んでむしろだいぶ成熟し、定着してきている考えだと感じた。
カオスエンジニアリングは、大規模で複雑な分散システムを運用する中、
起こる障害に対してただリアクティブにインシデント対応をするより、プロアクティブに対応してシステムをより強固にしたいという実際的なニーズから生まれた。
「カオスエンジニアリング」という名前自体は導入の妨げになっていないという話はあったが、「レジリエンスエンジニアリング」と言ったほうが意味がわかりやすくて抵抗感がないのかな、と思った。
個人的には10章が面白かった。本番環境で実験を行える様になる（または実験を行う必要性がでてくる）には早いという会社も多いと思うけど、インシデントレスポンスのゲームデーなどはより手軽にでき、学びが多そうだと思った。
14章のマインドセットの話もすごく良かった。カオスエンジニアリングに限らず、例えばコードレビューをするにしても、間違いを探して指摘してやろうというより、より良いコードにできないかと考えのもと、コミュニケーションするほうが絶対に良い。
【書評】『事業をエンジニアリングする技術者たち』レビュー
キャンペーンで書籍をいただきました。 ありがとうございました。
事業をエンジニアリングする技術者たち Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち | 株式会社VOYAGE GROUP, 和田卓人 |本 | 通販 | Amazon
内容
Voyage Group の各事業へ、インタビュー形式でソフトウェア開発の進め方を聞いていく内容。
各章毎に異なる事業部が、どういった事業で、どのような技術を使っていて、
どういった部分に課題があり、どう解決してきたかが語られる。
簡単に各章をまとめると
- 第1章 fluct - 広告配信の舞台裏の技術者たち
SSP、10年もののシステムでの管理画面のリファクタリング - 第2章 Zucks - フルサイクル開発者の文化
アドネットワーク・DSP、fluct から切り離した別システムとしてのリリース - 第3章 VOYAGE MARKETING - 20年級大規模レガシーシステムとの戦い
ECサイト、レガシーシステムからの脱却・改善 - 第4章 VOYAGE Lighthouse Studio - 数十万記事のメディアをゼロから立ち上げる
ゲームメディア、新サービスの立ち上げ - 第5章 サポーターズ - 事業の成長を止めない手段としてのシステム刷新
就活サービス、システムリプレイス - 第6章 データサイエンス - エンジニアによるビジネスのための機械学習
Zucks、データ分析を事業にどう活かすか
総評
ソフトウェアの開発秘話みたいなのは、イベントで少し語られたり、人づてに聞くくらいのもので、
あまりこういった書籍の形ででてこないので貴重だと思った。
業界にいる人なら共感する点が多く読み物としても楽しめ、ソフトウェア開発の進め方としてもかなり参考になるものだと思う。
こういったノウハウみたいなものは価値がある分、会社内部でしか共有されない事が多いと思うが、
オープンソースと同じく公開することでその企業のアピールにもなると思うので、増えていってほしいと思った。
良かったところ
- 既存のシステムをビジネスの変化に合わせていくための手段に、漸進的な改善（リファクタリング）、構造的な改革（リアーキテクティング）、作り直し（リプレース）があるが、それぞれの事業でどういった状況でどういった理由でその手段を選択し、どうやってそれを進めてきたかが面白かった。
- インタビュー形式のおかげて、話を深堀りできたりツッコミが入ったりしていて、より立体的に読み解けたのがよかった。それこそ座談会に呼ばれて面白い話を聞けている感覚でよむことができた。
- こういった「改善」話だと、その状況を作ったシステムに対して悪口みたいなことを言ってしまうことがあるが、この本では前任者へのリスペクトが節々で感じられた。技術的負債は能力が足りなくてできるのではなく、その時その時の制約の中でなんとかやってきたもんだよね、という意識がよかった。
- 自分自身、広告配信システムの管理画面のリプレースしたことがあったので、共感できる一方、もっとこうしておけばよかったとか、そもそもあの判断どうだったんだろう、と振り返りができた。
注意しなければいけないと思ったところ
- この本の個別のプラクティスだけを切り取って参考にすると、大やけどするんじゃないかと思った。例えば、つよつよなエンジニアが自由に動ける環境は良いけど、ビジネスに興味ない人が新技術試したいだけで技術導入だけしたらやばいだろうな、とか。全体としてうまく動く仕組みをひっくるめて、エンジニア文化と呼ぶんだろうなと思った。
- ドキュメントについて、私も苦しんだけど、結構苦しんでるんだなーと思った。GitHubのIssueに経過含めて記述するのはいいけど、個々の機能知ろうと思ったときに検索大変じゃないか、全体像都度共有するといっても抜け漏れあったときにそもそも抜け漏れ自体気づけないのではないかなど。それこそエピソードでもあったが、普段の開発は順調に見えていても、いざリプレースとなったときに、あれ、仕様なんだったっけ？みたいに後々困るところがまさに負債っぽいなと思った。
- もっと失敗談みたいなのを聞けたら面白いなと思った。成功の要因は複合的でよくわからないことも多いが、失敗の原因は結構はっきりすることが多いから、参考になりそう（笑）
- 本にところどころコラムで用語を解説してくれるが、客観的な説明と主観的な説明が入り混じっていて、読み解くのに少し手間取った。
次に読む本
こういった開発の本あまりないから、もしあったら知りたい。
類書で思い当たるのは、古い本だが Windows NT の開発秘話（デスマーチ...）を綴った 『闘うプログラマー』 は読んで面白かった。
同人誌のような形式で紹介する本も何度か見かけたので、今後はそういった形で増えていくのかも知れない。
ポール・グレアムのエッセイ「如何にして熱心に働くか？」How to Work Hard まとめ
2021年6月に出たエッセイ
いい内容だったので簡単なまとめ
- なにかすごいことを成し遂げたければ、生まれ持っての能力や技能の習熟だけでなく、ハードワークが必要だ。
- ハードワークは単に長時間労働をするということではない。仕事の種類によるが、効率の出る限界の時間はある。自分自身に正直にならなくてはいけない。サボってもいけないし、長時間労働を自慢してもいけない。
- 多くの問題には中心的な難しい部分と周辺の易しい部分がある。ハードワークとは、中心部の難しくて野心的な問題に取り組んで行くこと。
- 人生において何をするかという問い自体もこういった問題の一つ。 ここでもハードワークが意味することは同じで、より難しくて野心的な問題に突き進むということ。
- 本当に何が中心的な問題なのか自体、しばしば間違っている。一般的に問題だと思われてることと、あなたが本当に問題だと思っていることが違い、あなたの方が正しいのであれば、 何か新しいことを始めるチャンスとなる。
- 野心的な問題というのはたいてい難しいものだが、難しさ自体を何をすべきかの指標にはしないほうがいい。他の人にとって難しい仕事でもあなたとって簡単なものが見つかれば、それに取り組んでみるべきだ。
- あなたが何に向いているかは、生来の能力以上にどんなトピックに興味があるかに依存する。
- 何に取り組むべきかを知る難しさは人によって違うが、映画のように自らの使命が天からのお告げのようにわかるということ少ない。
- ある分野でハードワークするだけでなく、その結果を判断する必要がある。もしハードワークしても結果がでないなら、分野を変える必要がある。ただ、どれくらいの間取り組めばいいのか、そもそも何が良い結果なのか、自体を知ることは難しい。
- 結局は自分が面白いと思って取り組めるかどうか。ここでも自分自身への正直さが重要になる。
『量子コンピュータが人工知能を加速する』まとめ
どんな本か？
日本の量子コンピュータ研究の第一人者が、量子コンピュータについて専門知識がない人向けに解説した本。
出版は2016年だが、知識がない人に向けてよくまとまっている。単に理論だけでなく、最近のビジネスの動きも同時に解説されている
第１章 「１億倍速い」コンピュータ
2015年12月に、カナダのD-Waveシステムズの量子コンピュータの性能が、従来のコンピュータに比べて1億倍高速であると発表された。
従来のコンピュータ：「０」と「１」のデジタル信号（ビット）によって処理を行う。
↕
量子コンピュータ：量子力学の特徴を使い、「０」と「１」の両方を重ね合わせた状態をとる「量子ビット」を使って計算をする。
- 「量子ゲート方式」：従来から長年研究されてきた技術。汎用的なコンピュータを目指しているが、商用化にはまだ遠い。
- 「量子アニーリング方式」：カナダのD-Waveが商用化した、新しい方式の量子コンピュータ。「組み合わせ最適化問題」に特化して計算できる。（将来的には汎用化）
組み合わせ最適化問題：宅配ドライバーがどのようなルートで回ると効率が良いかといった問題（「巡回セールスマン問題」）。カーナビや化学構造分析、機械学習に応用できる。
量子アニーリング方式とは：「自然現象を借用したアルゴリズム」（例：遺伝的アルゴリズム、シミュレーテッド・アニーリングなど）の一つ。アニーリングとは「焼きなまし」という意味で、金属を高温にしてからゆっくり冷やしていくと構造が安定する、という現象。従来型のコンピュータでもこれをシミュレーションして最適化問題の近似解を得てきたが、「量子焼きなまし現象」を使うことでより高速により高い確率で解を得る。
D-Waveはどのように計算しているのか？：ニオブ製の回路を絶対零度まで冷やすことで、右回りと左回りの電流が同時に存在する状態になる。これが「０」と「１」の2つの状態が重ね合わせになっていることを意味する。このような量子ビットを利用して量子ビット間の相互作用を及ぼす「イジング模型」（３章で詳しく解説）を作る。組み合わせ最適化問題をこのイジング模型の基底状態（最もエネルギーが低い状態）を探す問題に置き換えることで近似解を得る。
第２章 量子アニーリングマシンの誕生
量子コンピュータの理論自体は1965年にファインマンにより提唱されていた。
量子コンピュータが近年注目される大きな理由は2つ
- 従来型のコンピュータの性能限界：半導体の集積密度（CPUの処理性能）は18ヶ月で倍増するという「ムーアの法則」の限界。性能向上の代替案としての量子コンピュータ。
- 暗号技術の解読可能性：ショアによる量子計算での素因数分解を高速にするアルゴリズムの発見により、もし量子コンピュータが実現すれば現在使われている暗号が容易に解読できるようになる。
しかし、量子ゲート方式での量子ビットで実現する「０」と「１」の重ね合わせ状態は、僅かなノイズにより簡単に壊れてしまう。
＝＞数個の量子ビットを含むものしか作れず、実用段階には至らない。
量子アニーリングの理論は1998年に著者の西森と門脇により発表された。
D-Wave社は1999年にジョーディー・ローズらにより設立され、当初は量子コンピュータ関連の知財や量子ゲート方式の研究をしていたが、うまくいかなかった。
2003年にローズはエリック・ラジンスキーと出会い、ニオブの超伝導リングを使った量子コンピュータの作成に着手する。
そこで、西脇らとは別に量子アニーリングを研究していたMITのセス・ロイドらの協力のもと、量子ゲート方式ではなく量子アニーリング方式を採用する。
2007年に16量子ビットのチップが完成。
2011年に航空機などの開発をするロッキード・マーティン社が128量子ビット「D-Wave One」を導入。
2013年にグーグルとNASAが共同でD-Waveを導入。
グーグルも独自に量子コンピュータを研究し、2014年からは量子ゲート方式のハード開発を始め、2016年には量子アニーリング方式も開発。
アメリカ政府も情報先端研究プロジェクト活動（IAERPA）により2016年から量子アニーリングの研究に着手する。
第３章 最適化問題の解き方と人工知能への応用
アニーリングとは：「焼きなまし」の意味。焼きなましとは、金属の温度を上げた後、ゆっくりと冷やすことで内部を均質化させるための処理。
＝＞焼きなましを数学的なモデルにしたものを「イジング模型」という。
＝＞組み合わせ最適化を、イジング模型の基底状態を探す問題に置き換えることで解くことができる。
例）巡回セールスマン問題の場合：ビット格子状にならべ、横軸を訪問すべき地点、縦軸を順番とする。訪問した箇所を「１」、訪問していない箇所を「０」で表す。１つの行には「１が１つしか入らないようし（一度に行ける場所は一箇所）、１つの列にも１が１つしか入らないようにする（同じ場所には２回以上いかない）。地点間の距離は相互作用の強さで表す。例えばA地点とB地点が近いのならば、Bを表すビットから、その次の行のAを表すビットの相互作用を強くする。
ビットの数と相互作用を設定した後、計算を行う。それぞれの値にゆらぎを与えるなどして不安定な状態にした後、段々とゆらぎの影響を弱くして相互作用を強くすることで、全体の経路が最適化された状態に落ち着くようになり、これが答えになる。
セールスマン問題以外の組み合わせ最適化問題もこのイジング模型に落とし込むことによって計算できる（例：4色問題など）
従来はイジング模型において、温度を変数として熱をによりゆらぎを与える（シミュレーテッド・アニーリング）ことで近似解を得てきた。
＝＞量子アニーリングでは、熱による「０」か「１」かのゆらぎではなく、量子的な「０」と「１」の両方の可能性を持った重ね合わせの状態を使うことでゆらぎをあたえる。それにより、シミュレーテッド・アニーリングでは近似解（局所解）になってしまう場合でも量子トンネル効果によって厳密解を得ることができる。
＝＞D-Waveは上述の超伝導リングを使うことで「０」と「１」の状態を使えるようにした。ただ、現実には８つ量子ビットがユニットを組むようになっているが、他のユニットととのつながりが限定的になっていることにより、実用的な問題がときにくくなっている（キメラグラフ問題）
現在第三次AIブームが起きていおり、機械学習、深層学習が成果を上げているが、ここに量子アニーリングを用いることが可能である。
- クラスタリング：教師なし学習の１つ。データから特徴ごとにグループを作る。
- ニューラルネットワークの学習：教師あり学習においては、出力からニューロン間の重みを学習する。量子コンピュータでは、重みをビット間の相互作用として求められれば機械学習の学習と同じように使える。
- ボルツマン機械学習：ボルツマン機械学習におけるサンプリングに、量子アニーリングを使うことができるという。
第４章 量子コンピュータがつくる未来
北米ではハードだけでなくソフトでもベンチャーがいくつか出てきている。
例）1QBit：カナダの金融ポートフォリオ最適化、スケジュール最適化などのソフトウェアを開発
量子コンピュータの利点
- 「１億倍速い」処理速度：ただしどのような問題だと性能が出るのかが現在の研究テーム
- 低消費電力：スーパーコンピュター京の500分の1程度の電力消費
- 人工知能の加速：人工知能が応用できる、画像分析・自動運転・医療・法律など
第５章 量子の不思議な世界を見る
量子力学とは：非常に小さな世界での物理学。普通の大きさの世界を扱う「古典力学」とは常識が違う。
例）電子は「波」と「粒子」の両方の性質を持つ（二重スリット実験）。２つの状態が同時に重ね合わさる（シュレーディンガーの猫）。不確定性原理。
その中の１つに量子トンネル効果がある。
壁の向こうへボールを投げる場合、相応の速さがないとボールは壁を超えてくれない。
↕
小さな粒子の振る舞いを調べると、ごく僅かな確率で「超えるべきエネルギー」を出し抜いて壁の向こうへと行ってしまう。（量子トンネル効果）
量子アニーリングではこの量子トンネル効果を利用している。
シミュレーテッド・アニーリングの場合は最適化を探すために予め十分なエネルギーが必要だが、
量子アニーリングではトンネル効果を使って正しい解へと移動することができる。
この量子トンネル効果をいかに使えるかが量子アニーリングマシンでパフォーマンスが出るかの鍵となる。
「１億倍速い」性能がでたのも、量子トンネル効果が起こりやすい問題を解いたからこそ。
量子アニーリングマシン以外でも研究がすすでいる。
2015年にはグーグルが誤りを訂正する機能を備えた９量子ビットコンピュータを開発
第６章 日本が世界をリードする日はくるか
量子アニーリングについて、ハードでは北米が圧倒的に進んでいる。
一方で、量子アニーリングについてはソフト面ではまだまだわからない部分がたくさんある。
量子コンピュータ自体はまだまだ試作段階、D-Waveを使っている企業でも4, 5年後を見据えて投資している。
【書評】『オブジェクト指向設計実践ガイド』
総評
★★★★★
オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
- 作者: Sandi Metz,?山泰基
- 出版社/メーカー: 技術評論社
- 発売日: 2016/09/02
- メディア: 大型本
- この商品を含むブログ (6件) を見る
オブジェクト指向を用いた設計の勘所を書いた本。
正直、今まで読んだオブジェクト指向について本の中でもピカイチ。
オブジェクト指向を、概念的に捉えている人にぜひとも読んで欲しい本。
時々Qiitaとかに謎のオブジェクト指向ポエムが流れてくるが、
そんなの読んでる暇あったらこれを読んだ方がよい。
コード例とともに、どうしたら良い設計ができるのか、わかりやすく解説されている。
オブジェクトそのものやデザインパターンというよりか、どのようにメッセージや依存関係を管理するかに主眼が置かれている。
感想
以下、章毎にまとめ
- 第1章 オブジェクト指向設計
- 第2章 単一責任のクラスを設計する
- 第3章 依存関係を管理する（以下、TBW）
- 第4章 柔軟なインターフェースをつくる
- 第5章 ダックタイピングでコストを削減する
- 第6章 継承によって振る舞いを獲得する
- 第7章 モジュールでロールの振る舞いを共有する
- 第8章 コンポジションでオブジェクトを組み合わせる
- 第9章 費用対効果の高いテストを設計する
第1章 オブジェクト指向設計
設計をする目的は、変更を容易にするため。
「オブジェクト指向設計とは、「依存関係を管理すること」」（p. 19）
設計が悪いと一つの変更は他のプログラムに伝播し続けていき、一つを変更するとそれに関係するオブジェクトすべてに被害をもたらす。
設計の原則
SOLID
- 単一責任（Single Responsibility）
- オープン・クローズド（Open-Closed）
- リスコフの置換（Liskov Substitution）
- インターフェースの分離（Interface Segregation）
- 依存性逆転（Dependancy Inversion）
DRY
Don't Repeat Yourself
デメテルの法則
Low of Demeter
これらの原則を本書全体で扱っていく。
設計の能力のないプログラマー「はい、その機能は追加できますが、『すべてが壊れます』」 不必要に設計するプログラマー「いいえ、その機能は追加できません。『それをやるための設計はしていません』」
アジャイルの必要とする設計は、事前に完璧な詳細設計（BUFD : Big Up Front Design）を作ることではなく、
変更に強い適応性と柔軟性があるコードを作ること。
第2章 単一責任のクラスを設計する
クラスはどのように設計するべきか。
=>変更がかんたんな用にコードを組む
そのためには以下の性質（TRUE）が必要。 - 透過性（Tranceparent）：変更がもたらす影響が明白 - 合理性（Reasonable）：変更のコストは利益にふさわしい - 可用性（Usable）：元々予期しない環境でも再利用できる - 模範性（Examplary）：変更を加える人が、上記の品質を自然と保つコードになる
TRUEを達成するための一歩が単一責任原則
以下、自転車とギアの例でコードを交えて解説。
Gearクラスがある場合に、そのクラスはどこまで情報を知るべきなのか。
クラスが単一責任か見分け方。
データではなく、振る舞いに依存させる。
複雑なデータ構造の隠蔽。
メソッドレベルでも単一責任原則を当てはめる。
責任の隔離。
第3章
以降はまた時間のある時に書く。
次に読む本
オブジェクト指向についてもっとしるなら。
アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技
デザインパターンを知るのもオブジェクト指向の勉強になるし、現実的なプログラミングでもかなり有用。 増補改訂版Java言語で学ぶデザインパターン入門
【書評】『暗号解読 下』サイモン・シン
総評
★★★★★
- 作者: サイモンシン,Simon Singh,青木薫
- 出版社/メーカー: 新潮社
- 発売日: 2007/06/28
- メディア: 文庫
- 購入: 23人 クリック: 70回
- この商品を含むブログ (160件) を見る
第二次世界大戦後、暗号技術の発展はコンピュータを用いることで更に加速されていく。
サイモン・シンはとにかく話しがうまい。
単に技術の羅列ではない、エピソードがある。
感想など
- Ⅴ章 言語の壁
アメリカが第二次世界大戦中にナヴァホ語を暗号として用いていたのは面白かった。
未知の言語を暗号とし用いた例。
日本軍はこれを解読できなかった。
古代の失われた言語の解読も頭が下がる。
- Ⅵ章 アリスとボブは鍵を公開する
コンピュータを用いることで、データをスクランブルする能力は飛躍的に増大した。
その一方で、秘密鍵をどうやって相手に伝えるかという鍵配送問題は依然大きな問題として残っていた。
それに対して数学を用いて、公開鍵と秘密鍵を使うことで安全にメッセージを交換できるRSAが開発された。
コンピュータの原型、RSAと同じようなアルゴリズムは、アメリカの研究者が初めて開発したことになっているが、
実はイギリスも密かに同じ発見をしていたが、国家の利益のために隠蔽していたらしい。
国家の利益のため隠蔽していたそうだが、もしこれを公開して情報技術がアメリカではなくイギリスで花開いていたら
イギリスの覇権も長く続いたかと思うと、その皮肉には笑うしかない。
- Ⅶ章 プリティー・グッド・プライバシー
国家が犯罪者対策のため、暗号を解読する権利を持つべきか、
それとも市民の権利として暗号技術を持てるようにするべきか。
これは技術的というよりむしろ社会的な問題である。
古典的な論点ではあるが、近代以降は結局市民がエンパワーされることによって社会が発展してきたと思う。
- Ⅷ 章 未来の量子へジャンプ
こちらは、暗号技術の「未来」の話
量子コンピュータが実装されれば、コンピュータの処理速度が圧倒的に早くなり、
暗号が破れれてしまう。
2018年現在、量子コンピュータは着々と現実に向かってはいる。
量子コンピュータのプログラミングは煩雑すぎるし、PCは高いしでまだ実用的ではないが、
時間の問題かもしれない。
一方で、量子の性質を利用した、量子暗号も考案されている。
こちらも理論的には解読不能なのだが、まだまだ実用には程遠い。
次に読む本
ソフトウェアエンジニアだったらさらに技術的に踏み込んだことを知っていて良いと思う。
