長い休載を経て、HUNTER X HUNTERが連載再開された。喜ばしい。
が、ストーリーを思い出せない。大きなところは、なんとなく思い出してきた。詳細なところが思い出せない。制約が多かったはずなので、細かい設定が思い出せないとわからないところが多い。とはいえ、大まかなところを思い出してきたのが恐ろしい。人間の連想からの記憶の想起ってすごい。
さて、今度はどのくらい続くのだろうか。月連載で長く掲載でもいいのだけど。
長い休載を経て、HUNTER X HUNTERが連載再開された。喜ばしい。
が、ストーリーを思い出せない。大きなところは、なんとなく思い出してきた。詳細なところが思い出せない。制約が多かったはずなので、細かい設定が思い出せないとわからないところが多い。とはいえ、大まかなところを思い出してきたのが恐ろしい。人間の連想からの記憶の想起ってすごい。
さて、今度はどのくらい続くのだろうか。月連載で長く掲載でもいいのだけど。
デザインについてと、障害への対応と、考えることができる本だった。示唆は多いけれど、結論を出しているわけではない、そこがいいのかも。障害に対するデザイン的な解決にパターンは決まっていないわけで、だからこそ、いろいろなことができるとも言える。
本としては、そんなに堅い内容ではなくて、障害の部分を抜きにしても、デザインのグラフィックが多くて、楽しい。扱っているものが障害に関係するものもあれば、そうでないものもある。面白いというか、考え方の世界が広がるというか、そういうもの。即物的に何かを得られるわけではないけれど、ちょっとだけ視野が広がるというか、そういう見方もあるのか、ってこと。
それから本の中に、下記の文がいろいろと表している。
筆者は、本書に含まれるアイディアが単なる記述にとどまらず、実例によってより良く表現されるようになってほしいと願っている。これらの緊張関係を解決する数多くのさまざまな方法は実例によって最もよく伝わるだろうし、ひとたびデザインが障害と出会うことになれば、理論よりも実践によってより良く表現されるだろう。
デザインと障害が出会うとき
また逆に、デザインは影響を吸収し続け、そうすることによってそれらを変異させ、新たな情報のみならず、人びとや素材、媒体、そしてアイディアを新たに取り組みつつ自分自身を再創造していく。
(中略)
デザインがデザインにインスピレーションをもたらすのである。デザインが障害と出会うとき、その出会いはデザインそのものを変えることになるだろう。(P.379)
出会うことで変わることがいろいろとある。そう思える。
読了。何かを得られるという内容の本ではなくて、読むことによって、自分の行動を見つめなおすタイプの本。原題の「FOUR THOUSAND WEEKS」である4000週間が、一番考えさせられるところ。人生は、週に換算すると、4,000週しかないということ。効率的な時間の使いかたでなく、何をやるかという選択の方がよいということ。何かをやるためには、何かを捨てる(諦める)わけで、考えさせられるわけだ。
本の内容的には、短い人生の使い方というところで、いろいろと書かれている。まぁ、読めば思うところはあるだろうし、それは人によって違うわけだ。さくっと読めるので、読んでみた方が早いとは思う。ベストセラーになっているのはなぜかわからない。
もう1つの発見は、週刊誌は全部で3,000刊程度しか読めないってこと。ONE PIECEは1,000話以上連載していて、1話からジャンプで読んでいることを考えると、なかなかの期間を占めている。連載終了まで読み切れるだろうか、という別の心配事を考えてしまった。
やっと読了した。「DIAMONDハーバード・ビジネス・レビュー22年8月号」は、特集が「できる人が 辞める会社 活きる会社」でとても興味を惹かれた。特集ページも長かったので、読み終えるのに時間がかった(途中で積ん読になったのも要因だが)。
この特集は面白く、いろいろと考えさせられた。会社への定着は「仕事内容への愛着」であり、「信頼」でもある。通常の従業員をつなぎとめる要因は、これであるのだけど、スター人材はこれでだけでは足りない。「優れた人材にとって大事なのは、報酬よりも自分が特別だと感じられることである」「スター社員の人材管理の秘訣は、彼らを個人として高く評価していると感じさせること」というのが重要だという。なんというか、肌感覚としてわかる。ある程度までは、報酬で報いいられるだろうけど、組織としての枠があるので、報酬にも限度がある。そうなると、やはり、認められるという感覚が重要だ。組織に必要だと思われているとか大事にされているとか、そういうことがさらなる愛着につながるわけだ。これが崩れると、報酬がよくても、やる気が削がれる。ここではない、どこか別の場所でもいい、と思ってしまう。度が過ぎるとやりがい搾取のように見えるが、ある程度は必要だと思う。
日本の場合、スター人材を留まらせるための「報酬よりも自分が特別だと感じられる」は、なかなか難しい。特別扱いと、特別と感じられることは、イコールではないのだが、ここの幅が難しい気がする。大企業の場合、ある程度の役職以上であれば、必然的に「特別」っぽくなる。役職がなかったりすると、優秀でも特別扱いはしないという、なんというか平等っぽいところがある。そうすると、どれだけ特異点なことをやったとしても、認められなかったりする。当然、裁量権もないわけで、なにもせず周りに埋もれていくか、外に飛び出し(転職)てベンチャーにいったりする。スター人材を育てていくのは、かなり難しい気がする。
非常に面白い特集だったのだが、振り返ってみると、自分自身も思うところはいっぱいある。良くも悪くも、いろいろと考えさせられた特集だった。愛情をベースに考えて、その上での扱いの部分を考えると、自分の中でモヤモヤしていた原因はわかった気がする。一部のマイナス要素が影響しているわけだ。おすすめできる内容だけど、劇薬でもあるような特集だった。
読み物として、楽しかった。どっちかというと、ベンダー選定に対する共感という方がしっくりとくる内容だった。こういうことある、というのがあっちこっちにある。まぁ、選定時にやっていることもそんなに違わない。正解かどうかは別にして、そういうことがよくあるというのが多い。
あまり気にしたことはなかったのだが、56ページにあった「楽してとれた案件は、そこそこの戦力を割り当てたり、下請けの協力会社に丸投げしたりします。「顧客は厳しくない」「失敗しても許してくれる」というイメージを、最初に与えてしまったからです。ベンダーの緊張感がゆるむのです。」というのは衝撃的だった。これは、考えたことがなかった。楽をさせると舐められるのか、と思うと切ない。まぁ、同じページにある「RFP(提案依頼書)で要求レベルが高いと、ベンダー側が提案する「体制」が変わります。相応に「レベルの高い人材」を組んできます。これが非常に大きいのです。」の方をやっているから、楽な状況がないからかもしれない。ただ、継続的なところだと、いきなり質の悪い担当が割当てられたりする。それも気の緩みなんだろうか。
ベンダー選定の過程は、しっかりと書かれているので、どういうことをやるのか、どういうことを気をつければよいか、見るポイントはどこか、などなど、そういうところは参考になると思う。ちゃんとベンダー選定をしていると普通のことが書かれてある。そういうことが地味に大事だったりする。
今日、過去のライブの「TM NETWORK CAROL TOUR FINAL CAMP FANKS!! ’89」がYouTubeでライブ配信でされた。
https://www.110107.com/s/oto/page/TMNETWORK?ima=5349
この当時は、TM Networkは知らず、Get Wildなどが好きなだけだった。あとから好きになり、CAROLツアーは見てみたいと思っていた。20数年たって、当時のライブがみられるとは夢にも思わず。たのしかった。CAROLのストーリーに合わせた演出もいいし、みていて本当に楽しかった。YouTubeのコメントの嵐はすごかったな。みんなよくやるなぁ、って思いながらライブをみていた。
そして、ギターの松本さん、やっぱり最高。このころの音源の曲は本当にいい。
ライブ音源のCDと、ライブ映像がほしくなってきた。どうしよう。
春から読み始めて、途中で積ん読になって、読むを再開したりやめたり。やっと、「システム運用アンチパターン」を読了した。
ベストプラクティスではなく、これはよくないというアンチパターンで運用まわりの効率化などを解説している。「DevOpsで解決する」というのはついているけれど、DevOpsが何かを知りたいのならば、別の本がよい。
こういうのあるとか、これは確かに駄目パターンとか、これは良さそうとか、いろいろある。パターンで説明されているので、共感できるものもあるし、組織文化の違いとかも感じる。そして、途中で読むのを止めたりしているので、内容が曖昧になっているのも多い。パラパラとページめくりながら、参考になりそうなものを探すのが良さそうだ。
春から積ん読になっていた「エンジニアなら知っておきたい システム設計とドキュメント」を読了した。
運用設計書の項目と、非機能要件の項目の部分が気になって買って、そのままになっていた。とりあえず、項目の答え合わせはできた。なかなか、これらのドキュメントを扱った資料はないので、役に立つ。ちょっと文量は少ないが、項目レベルで列挙されていればいいので問題なし。
それから、1章から3章は、各種資料からプロジェクトやドキュメントの傾向が書かれているので、なるほど、という感じ。開発に必要なドキュメントの種類と概要をさらっと知るにはいいかもしれない。フォーマットなどの細かいところを求めるのならば、別の本だが必要なドキュメントの把握ならばいい。
やっと積んであったSoftware Desginの2022年8月号を読み切った。
Web APIの作り方は、ここらへんは明るくないので、なるほど、こういう感じで進めればよいのか、というところ。HTTPやHTTPSで通信していれば、なんでもWeb APIなので、なんとなくで、なんちゃってWeb APIっぽいものは作ってみたことはある。世の中は、どうやって作っているのか(まぁ、OpenAPI基準で作っているところは多くないのかもしれないけど)知らなかったので、よかった。仕様自体を、OpenAPI準拠で書いてしまえば、楽はできそうだ。まぁ、その時のプロジェクトで受け入れられるかどうかはわからないけど(それはドキュメントの保守にかかるスキルを確保し続けるという意味で)。
それから、「現在のDNS事情とセキュリティ」の記事もよかった。DNSSECのところまでは追いかけられていたけれど、HTTPSレコードが追加されるのは知らなかった。DNSまわりの一通りのセキュリティを読めたのはよかった。インターネットの名前解決の基盤だから、いろいろと追加もされているし、互換性も保つ必要があるし、本当に大変だ。クライアント側というか企業内のDNSも考えると、新しいものについていくのも大変だ。どこかで企業内DNSサーバも最新までアップデートしたい。