  |
はてなキーワード: 領域とは
──日本電産といえば、買収した五十数社すべてをほぼ1年以内に黒字化させてきた会社ですね。
再建に向かう際、永守重信社長から真っ先に言われるのが、意識改革、企業カルチャーを変えろ、です。再建メソッドに対する受容マインドをまず上げておく必要がありますから。そしてA3の紙を1枚ポンと渡される。日本電産芝浦の再建のときは「1年以内の売上高倍増」、そしてたった1行「営業マン1人当たり訪問件数月100件」と書いてあった。月20件だったのを100件に上げれば、引き合いは増え受注件数は増え、売上高は上がる。従業員全員をやる気にさせる、そこを徹底するカルチャーにするのです。
日本電産のスピード感覚はハンパなものじゃない。会社全体にスピード感が行き渡り浸透している。見積もり作成に1週間もかけるな、より早く、ライバルよりも断然早く。他社なら1カ月かかる試作品も1週間で仕上げろと。ライバルはついていけなくなり次々脱落していった。最終的には精密小型モーター世界シェア80％を達成するわけですが、競合が消えても手を抜くことがない。会社のDNAとしてしみ付いているわけです、スピード感覚が。
そして会社の機関車は営業、開発・工場は支援部署。市場にいちばん近い部門が会社を引っ張れと。
──本書でもその営業強化策に紙幅を割いていますが、中でもフォローの重要性を強調されていますね。
川勝宣昭（かわかつ のりあき）／1942年生まれ。早稲田大学商学部卒業後、日産自動車入社。中近東アフリカ事業本部部長、南ア・ヨハネスブルク事務所長など歴任。98年日本電産にスカウト移籍。取締役経営企画部長（M＆A担当）を経て、日本電産芝浦専務、日本電産ネミコン社長歴任。2008年経営コンサルタントとして独立。（撮影：梅谷秀司）
トヨタ自動車がなぜあれほど強いか。トヨタは「カンバン方式」などメソッドの宝庫です。でもそれと同等以上にフォローの強さがある。未達に対して徹底的な再発防止策を講じる。日本電産にも未達を許さないカルチャーがある。未達しないための準備を重ねる。売上高計画達成が微妙なときに、未達は不可というカルチャーが浸透してると、どうしたらいいか必死で考えますよね。既存領域でまだ拡販余地はあっても、新規客の訪問をかけようとか。あるいはまったく違う提案をしてみようとか。営業マンがどんどん考える営業マンになります。それが大事で、それがフォローの重要性なんです。
強化策のひとつに、週次管理があります。1週ごとに月末着地見込みをにらんで、未達の可能性があれば挽回策を練る。着地をブレさせない。
私がいた頃の日産自動車の年度方針発表会は、業績未達の説明に精緻な図表を作成し、いかに納得させる他責要因ストーリーを組み立てるかに心血を注いでいました。ところが日本電産では、過年度説明は1欄、○△×のみ。簡潔クリアに説明して、大半は新年度目標に向かってどう戦うかの作戦説明に割かれていた。経営者の「未達をしない体質にする」という決意とマネジメントスタイル、組織の中にどれだけフォローの仕組みを組み込んでいるかの違いを見る思いでした。
1週ごとに全社で行うフォロー管理の仕組みが、社員の日常業務管理力を向上させ、後戻りしない体質を作っていたんです。まさに日本電産の看板である「すぐやる、必ずやる、できるまでやる」を体現している。言い換えれば、スピードの文化、必達の文化、フォローと徹底の文化が浸透していた。
組織体質を変える一番の早道は
その第一歩が、まず訪問件数を100件に上げろ、なわけです。整理・整頓・清掃・清潔・しつけの「5S」もしかり。まず実践の場で形、行動から入らせる。それを繰り返して固め、思考様式を変えていくことが、組織体質とカルチャーを変える一番の早道です。会社の改革は人の改革ですから、着慣れた服を脱いで新しい服に着替えてもらわなきゃいけない。それは着づらいし着たくないかもしれない。でもそれじゃ変化はない。韓国・中国のような、コピーも速い一点突破・集中型ガムシャラ経営が台頭するレッドオーシャン時代には、スピードと徹底を身につけないと蹂躙（じゅうりん）されてしまう。
そうです。本を書くに当たっていちばん思いを込めたのが企業カルチャーの変革についてでした。なぜ皆がこぞってトヨタをまねてもトヨタになれないのか。問題は企業カルチャーなんです。トヨタ流の「なぜ？」を5回繰り返すフォローの文化なしに、いくらカンバン方式を入れても定着しない。かつて日産も研究し尽くして導入したけどダメでした。GMもダメだった。どちらも苗が生き生きと育つための土壌改良をしていなかったから。それと同じことです。
どの会社にも必ず問題意識が高く改革に前向きな少数派の“火種社員”がいるものです。経営者は彼らをまず自陣に引き込みタッグを組んで、彼らを改革のモデルとすることでその他大勢のヒラメ社員に新しいカルチャーを浸透させていく。私の経験上この方法がベスト。社長がいくらガナリ立てても変わらない。
──明日から実践できる作戦満載の本ですが、特に重視した点は？
『日本電産流「V字回復経営」の教科書』（東洋経済新報社／318ページ）上の書影をクリックするとアマゾンのサイトにジャンプします
課題を図表で「見える化」し実践メソッドを紹介すること。日本電産時代に、病巣はどこなのか、どうメスを入れるべきか、レントゲン写真が欲しくて、多様なパターンの図表や見える化マップを独自に創作し用いてきました。見える化することで、改善への切り口がわかります。自社の現実を図表化して見せるとみんな乗ってくる。たとえば市場構造に対し当社の顧客構造はズレている、というのが1枚の図表で明らかになる。
最初は中小企業の経営者を念頭に置いていましたが、だんだんとマネジメントの進化を求める管理職にも伝わる本がいいと思うようになった。それで改革メソッドを提案する章は、オリジナルの2面パレート図などを駆使し厚みを持たせました。営業に回るべき100件をどう選ぶかもきちんと分析・抽出できるようにした。自分で言うのも何ですが、見えていなかった部分の見える化をハンパなく提案したつもりです。
「ここまでやれば必ず変えられる！」がこの本の宣伝文句。日本電産時代の買収先の再建、独立してからのコンサル活動を通して、会社は変えられるという変なクソ自信がついちゃいましたね。独立する際に永守さんに書いた「たった7年在籍しただけの日本電産で学んだものは、三十数年いた日産の数百倍以上だった」というのは本当の気持ちです。
2022年の年明けからパフォーマンスが極端に落ちてクビを切られそう。
外資系のプレイイングマネージャーポジション。部下はいない。年収は8桁。
育休は複数回取得して、育児や家事は生活の一部として妻と二人でこなしている。
パフォーマンスが落ちた理由は複数あるが、まず2021年に転職して力を入れすぎて燃え尽きた。
継続的に結果を出すためのプレッシャーに負けた。年末年始の休暇の後に気持ちを戻せなくなった。
そして同じようなことを8年くらいやっているので飽きた。
解決すべき問題は次々に立ち現れるのだが、学びや評価が減ってきて面白さを感じられなくなってきた。
他の国にいる同じチームのメンバーが今までに比べて群を抜いて優秀なので、自分の存在意義が薄くなった。
とあることがきっかけで今後の人生をかけて何がしたいのか考え始めた。
ひとつの目標としていた年収とポジションを獲得できたところで次の目標を見失った。
今まで楽しいと感じていた仕事が急に色褪せて面倒に思えるようになってしまった。
矢継ぎ早に進んでいく周りの仕事が他人事のように思えるようになってしまった。
人生の折返しを意識したことで、焦りやもどかしさをよく感じるようになった。
とにかく何か情報を収集しないと落ち着かず、結果として現実逃避することが増えた。
保育園の送り迎えや食事の支度をしたり、子どもと過ごしていたりすると無心になれる。
その代わり時間があっという間に過ぎて、毎日がただ始まって終わるだけの感覚が強くなる。
子どもが寝静まった後にゲームをしたりして過ごすのだが、満たされない欲求みたいなものが残る。
表現は好きだ。文章を書くのも、絵を描くのも、映像を作るのも、身体表現も好きだし得意な方だ。
それを仕事にしている人が羨ましい。しかし、それを仕事にするためのコミットがどうしてもできなかった。
生活や待遇への打算、プライドが最終的に自己実現よりも優先された結果、ここまできて何か焦りを感じている。
仕事の専門領域はとてもニッチで、日本の中ではある程度来るところまでは来たと思う。
ゆっくり解説で人生が好転した増田のようにアウトプットを始めるのもいいなと思うが時間も目標も今はない。
年齢特有の悩みなのかもしれないが、クビになるリスクと隣合わせのところまで来ている今、なんとかしたい。
誰かアドバイスください。
先日のモスバーガーのトム・ブラウン超合体CMになんか否定的だったので、識者の俺が音MADの楽しみ方を教示しよう。
最初に言っておくが強烈なハイコンテクストが特徴の文化なのでNot for meと思った瞬間に立ち去るように
そしてなんと教材にもってこいの28秒！ この音MADに出会えたからこの増田書いてるまである
各ソースは現時点では見なくてよい
では動画を見ましょう。
タイトルとトラック、特徴的な文字演出からこの動画が「神っぽいな」の音MADということがわかる。
そしてアニメ（もしくは原作小説）を知っていると、画像のキャラクターが結婚相手に高い理想を抱いているシーンを想起する。
まずここで視聴者にコンテクストがロードされる。この作品への向き合い方が決定される。
あまりにもロマンチックな理想の独白が「神っぽいな」のワードとシンクロする
しかしアニメの音声だと思いこんでいた矢先の「高学歴 高身長 高収入」の3連打によりなんだこの音声(音源)は！？の驚きと遭遇する
追い打ちのように音声のリリックはオフボーカルのサビ部分にカッチリとはまり込み、リズムが気持ちよくなる
作中世界にあるはずもない「ママ友とのランチとヨガとネイルサロン代」の登場により感情は更に加速される
ネタとしての異常性という部分ではもちろん、作中婚活期のロキシーの境遇からすればあまりにも遠い理想に胸が締め付けられる。
そして続く「山崎賢人と阿部寛と坂口健太郎を足して割らない」、素材の爆発力である。
まず感情として、割らないで大丈夫なのか、1人で十分じゃないかの不安感が脳裏をよぎる。
そしてその場合顔は3つなのか？ それはもう阿修羅なのでは？ 阿修羅って神っぽいなと脳のシナプスが一気につながる
そういやケルベロスも顔3つだな。犬っぽいな。ぽいじゃん。脳内の連想ゲームは危険な領域へ突入する
そして化け物「顔の青年に迷宮の奥底で偶然助けられるんです」と原作の展開に帰ってくる
この作品は投げっぱなしではなく、非常に練られた展開という満足感が気持ちよさに変換される
しかしここで終わらない
最後の最後で内容がいきなりYouTuber「syamu game」氏の名言に変化する
「コイニハッテンシテ 素敵なことやないですか」あまりにもの急カーブ、脳はsyamu氏のコンテクストをロードする
そして最後の音声「理想たかっ！」、BGMでは「憧れちゃうわ！」に重なる。歌詞を考えると関西弁のダブルミーニングも想起する
そしてsyamu氏が登場することにより同氏の「おい！それってYO！」という名言も脳裏によぎる。
この動画で描かれていないことまで、沢山のシナプスがつながったと思う。この音MADの素晴らしさが理解できただろう。
非常に素晴らしい音MADでした。
音声素材の強すぎる力を見事に制御しきっていますし、動画のエフェクトも最小限に留めています
とはいえそれは手抜きではありません。
素材の発掘力は音MADの肝ですし、楽曲のPVのオマージュは極めて精緻で丁寧さが伺えました。
キャラクタや楽曲、syamu氏の持つコンテクストのシナジーがキマったシナプス感涙の作品でした。
その性質ゆえに表社会に出ることは稀ですし、件のCMが音MADではない、そうだとしても劣っていると批判が一部でなされる理由もわかっていただけたかと思います。
ここまで聞いてくださってありがとうございます。
それでは最後にトトトトトム・ブラウン、ぱちんこCRおどれまさのりファイアーの作者で知られる零氏がRTしたツイートの引用を持って終わりにしたいと思います。
ご清聴ありがとうございました。
音MADが表沙汰になってることに対して賛成派も反対派もいる様子ですね
僕としては「音MADという手法」は表沙汰になっていいが、「音MAD界隈のネタ」は絶対に表沙汰になるのは絶対にやめてほしい派です
トトトトトム・ブラウン
業界の規則とかが曖昧なのはいいけど、刑法が曖昧なのはダメでしょ
増田が何を嫌っているのか知らんけど、俺が嫌だと思ってるのは、市場がどう発展するのか分からないのに、行政機関が先回りしてその動きを封じていること
例えばマイニングのブロックチェーン業界、日本は金融庁が世界で初めて暗号通貨に関する法律を作った
これから起こるであろうことを先回りして規制したわけ。こういうことはやっちゃダメだよーって
新しい領域というのはどう発展するか予測できないから、遊びを残しておかないといけないんだけど、行政機関が現状の情報だけを頼りに、ここに進んじゃダメです、とやった
コインハイブの件も、賛否両論、やっていい事なのかどうかコンセンサスもないのにいきなり逮捕した
市場が発展するまでもう少し待っておくべきだった
【追記】追記編と初手編、日常用語編、国際編、人物編、二眼の説明を加えた。
anond:20220131231934にインスパイアされてやってみた。
省力のために一部wikipediaからの引用も交えながら独自の解説を記した。
一手で隅をほぼ専有できてしまう反面、中央から遠く発展力やスピードに欠ける。
江戸時代以前の古くから打たれている手であり三々よりは中央に近く、星よりは地に近いバランスの取れた手。
隅を占めるのに二手かかるのが欠点。
４・４の地点で碁盤の目印のある部分のこと。
後述の昭和の新布石時代からよく打たれるようになった手。それ以前は置碁くらいでしかあまり見られなかった。
地に甘いというのは、相手に三々に入られるとほとんど地を奪われてしまうためである。
碁盤において、この地点がもっとも高い地点であり、端は地面という概念となっている。
後述の厚みが確定地ではない未来への投資であるのに対し、序盤から陣地になる可能性が高い場所を実利という。
実利をとれば厚みを作られ、厚みを作ると実利をとられるという表裏一体な関係にある。
盤上において影響力を及ぼすことのできる、しっかりと連絡して眼形の心配もない強力な石の集団である。
「厚み」は「薄み」に対する対義語である。囲碁で「薄い」というのは連絡が十分取れていない形、眼に不安がある石のことであり、相手に攻撃される可能性を持っている状態を指す。
これに対して強力な「厚み」は相手からの攻撃を受ける可能性が低く、周囲に近づいた敵の石に対して攻撃するための基盤となる。また、相手が近づいてこなければ大きな模様や地を形成する拠点となる。
大きな地になりうる可能性のある勢力圏のことを指す。多くの場合、隅から辺、中央へ広がるものを呼ぶ。
手の順番や形を変え、定石等と比べることで本来の形に対して余計な石があることなどを評価し、効かし効かされを判断する。
1933年（昭和8年）に呉清源と木谷實が発表した、中央・速度を重視する新しい囲碁の布石のスタイル。それまでの小目を中心とした位の低い布石に対し、星・三々で隅を一手で済ませて辺や中央への展開速度を重視し、中央に雄大な模様を構築することを主眼とする。その斬新なスタイルと、これを駆使した呉・木谷の活躍により社会現象とも言えるブームを巻き起こした。
またAlphaGoの台頭以後、新布石時代に負けるとも劣らない布石の変化が囲碁界を席巻している。
例えば星への三々入りを序盤に行うの「ダイレクト三々」は相手に厚みを与えるため不利と言われていたがそれが平然と行われるようになった。
隣り合った隅・辺・隅の星を占める布石である。辺を打たず、隣り合った隅の星を占めるのは二連星と呼ばれる。中央に大きな模様を張ることを主眼としたスタイルで、武宮正樹が有名な使い手である。
安永流ともよばれる。星・小目・辺の星脇を組み合わせた配置である。
小目からシマリを省略して星脇へヒラく手法は、江戸時代初期に本因坊道策が使用している。
本格的な中国流の開祖は安永一とされ、中国には陳祖徳が広めたとされる。1965年の日中囲碁交流の際に非常に注目され、日本に逆輸入された。
右上空き隅、小目、相手の星へのカカリから星脇へのヒラキまでの一連の配置を指す。下図下辺の黒の配置がミニ中国流である。右上隅の着点は必ずしも決まってはいないが、星との組み合わせが最もよく打たれる。平成期に流行した構えだが、すでに400年ほど前に本因坊道策が試みていた。このため道策流とも呼ばれる。
序盤早々、周囲にまだ石がない段階で、相手の星に対して直接に三々に打ち込んでいく手段を指す。かつては全く考えられていなかった戦法だが、AlphaGoなどの人工知能がこの手を打つことから注目され、人間の棋士の間でも広く採用されるようになった。ダイレクト三々の名称は、2018年5月から河野臨によって週刊碁の連載のタイトルに使われ、定着した。
囲碁の基本的な手筋のひとつである。アタリの連続で、逃げる側は盤がある限りは逃げることができるのだが、盤の端まで到達してしまうとどうにもできず、石を取られてしまう状態をいう。逃げきれるつもりでこの手順に入ると非常に大きな被害を受けること、シチョウアタリという攻守が全く逆転する危険な変化があることから、「シチョウ知らずに碁を打つな」という格言もある。
シチョウの追いかける先に相手の味方の石がある場合シチョウが成立しないので、この手を選ぶことが多い。
相手の石にフタをするように斜めに置き動きを封じる。
一旦相手のふところに石を打ち、一度は取られてしまうが取った後の姿がアタリになっていてすぐに相手の石を取り返すことができる。
漢字表記では「追い落とし」となる。 ツグ手を打っても引き続きアタリになり、取られてしまう状態をいう。別名をトントン、ツギオトシ、バタバタとも。
相手の石にも自分の石にも触れないような位置に、文字通り「置く」ように打つ手のこと。動詞では「置く」となる。多くの場合一線や二線など辺の低い位置の、敵陣の急所に打つケースを指す。
相手の二団以上の石を同時にアタリにし、二眼を確保する手段。文字通り相手を押しつぶすイメージであることからつけられた。着手禁止点を利用して生きる手筋である。
相手の石をアタリにし、自分の石を相手に取らせた上でもう一度相手をアタリにする一連の打ち方を指す。途中、さらに捨て石なども交えることもある。多くの場合、相手を凝り形にし、自分が形を整える目的で打たれる。また、攻め合いの場面で相手の手数を詰め、攻め合い勝ちに導く手筋としても用いられる。また、あまり効果のないシボリを「西洋シボリ」と称することがある（前田陳爾の造語）。
ある石のダメが詰まることで、各種の不都合が生じる状態を指す。「ダメの詰まりは身の詰まり」という囲碁格言があるように、不必要にダメを詰めてしまうことは身の破滅につながり、碁において戒められる事柄のひとつである。
駄目については後述。追記編を参照。
ヨセ（終盤のこと）において相手の陣地を侵食するための鮮やかな手筋。
一見繋がってないようなところに打つのだが、見事に繋がっていて相手の地をかなり減らすことができる。
盤上にある石の一団は二眼（空間が２つ）ないとゆくゆくは駄目（呼吸点）が詰まり必ず取られてしまう運命にある。
これはルールとして定められているというよりは、石は呼吸点を有してないと取られる、着手禁止点には打てないという２つのルールから導かれる定理のようなものである。
2つ眼があると、駄目が最低でも2つある状態と着手禁止点が2つある状態が存在するため、着手禁止点を同時に2つ塞ぐことはルール上できないので必ず取られない最強の存在となるのである。
この取られない石の状態のことを「生きている」と言い、この「生きている石」の内側の領域が陣地となる。
この石の生き死にさえ理解できれば、初心者の、どっちがどっちを囲んでるのか、これは内側も外側も囲んでると言えるのではないか、という疑問は消えるだろう。
相手にそこを継がれると眼となる部分に先行して打って欠け目にすること。
「打って欠く」（打ち欠く、あるいは内欠く）の意
相手にそこに打たれると完全な二眼ができてしまう部分に先行して打てなくする、相手の石の一団を殺す必殺の手。
隅に打った既存の石から陣地を確保するためにもう一手かけて領域の守りを固める手
ふたつ隙間を空けて打つ手
●┼┼┼
┼┼┼★
●┼┼┼
自分の石の斜めひとつ空けた場所に置くこと。●から見て★の手のこと。
●┼┼
┼┼┼
┼┼★
相手の石の隣にくっつけて置くこと
相手の石を挟むように置くこと
相手の石の斜めに置くこと
相手の石のつながりを断つように斜めに打つこと
相手の石がそれ以上侵入してこないようにせき止める位置に置く石
相手の石を押すように平行に打たれる石
目外しへのカカリから発生する定石を指す。派生する変化型が多く、複雑な戦いになることから、大斜百変、大斜千変とも呼ばれる、難解定石の代表的なもの。天保頃より特に研究が進み、現代でも多くの変化が生まれ続けている。
小目への一間高ガカリに下ツケする形から発生する定石を指す。最初から接触戦となり、また変化型が多い難解定石の代表の一つ。石が接触しながら戦いになっていく様を「ナダレ」と形容された
小目への一間高ガカリに二間高バサミして生ずる一連の変化を指す。難解で未解明部分も多く、また変化型が多いために誤ると自らも傷を負うところから、村正にちなんでこの名が付いた。大斜、大ナダレとともに三大難解定石とされる。
竹の節のような並び。
一間空けて2：２で平行に並んだ形で、その間をどちらかを相手に打たれたらもう片方で繋がれるので絶対に切られることがない。
仏教用語ではひとつの宇宙が始まって終わるまでの途方も無い長い時間のこと。
囲碁においては、どちらかが譲らない限り永遠に循環してしまう特別な形があり、その形をコウと呼ぶ。
コウの形で石を取られた側はコウをすぐに取り返してはならず、一手別の場所へ打つ必要がある。
通常、白石はハマグリのくり抜きによってできているがそれが語源か。しらんけど
冒頭で説明。
限られた局面、特に序盤においてある程度決まった一連の手の応酬のこと。
定石は手練の碁打ちの長い研鑽、研究により成り立つもので、お互いに必然の手を打ち、双方ほぼ互角のワカレとなるのが定石の前提である
どちらの陣地にもならないどうでもいい地点の事を指すことから日常用語に転じた。
または、石から出ている呼吸点（全部塞がれると相手に取られてしまう）のこと。
囲碁において死活問題とは、相手の石を殺す、あるいは自分の石を活かすための問題（クイズ）のことである。
現代では上手（うわて）が白を持つが平安時代期には強いほうが黒を持っていた。
そのため
と転じたと言われている。
自分が第三者となった視点で戦いを見ると手がよく見える、あるいはそう錯覚すること。
一目は一子（石ひとつ）の意。
囲碁においては強さに差がある場合、相手より多く先に石を置いた状態で始めることから、相手の実力を認め敬意を示す意味に使われるようになった。
手を省くこと。
力を抜くことではなく、相手の打った手に付き合わず、その場所よりも価値の高い場所へ向かうことを言う。
囲碁にはいくつかルールがあり、基本的には江戸期～昭和期まで囲碁の第一人者であり、世界に囲碁を広めた日本のルールが用いられている。
日本ルールは盤上の囲った陣地（目）のみをポイントとするのに対し、中国ルールではそれを含め置いた石の数もポイントになる。
この２つの大きな違いは、日本ルールが自分の陣地に自分の石を置くことがマイナスとなるのに対し、中国ルールではマイナスにならない点である。
このことが死活に関わる局面や終盤の局面での手入れ、手抜きにおいて大きな違いを生む。
日本ルールでは曲がり四目と呼ばれる形が出現した場合、手を入れるのがマイナスになるためそれが死であることの証明を用いないと議論が生じる。
そのため中国ルールのほうが初心者に優しく、コンピューターにも優しい。
他には日本ルールでも中国ルールでも禁止されている自殺手がOK！というルールもある。
碁打衆を保護、「御城碁」の基盤を築く。近世囲碁の発展、振興に絶大な貢献。（日本棋院表彰ページより引用）
永禄2年（1559年） - 元和9年5月16日（1623年6月13日）
江戸幕府における囲碁の最高位だけにとどまらず、将棋の最高位も得た二刀流。
大橋宗桂との将棋対局は将棋の現存する最古の棋譜でもあり将棋界においても重要な人物の一人。
正保2年（1645年） - 元禄15年3月26日（1702年4月22日）
手割りや布石など、数々の発明を生んだ天才棋士。史上最強という呼び声も高い。
文政12年5月5日〈1829年6月6日〉 - 文久2年8月10日〈1862年9月3日〉
ヒカルの碁で著名。
1874年（明治7年）6月24日- 1940年（昭和15年）1月18日
またタイトルとなる前の、「名人は一世に一人」の終身名人制時代の最後の名人でもある。
引退後に本因坊の名跡を日本棋院に譲渡し、選手権制の本因坊戦創設に導いた。2008年囲碁殿堂入り。
「オマ●コ」発言など、昭和の棋士らしい数々の破天荒なエピソードが有名。
棋聖 6期 (1977-82)
名人 2期 (1962・70)
天元 1期 (1975)
きわめて個人的な目的を達成するために必要なソフトウェアやシステムってあるはずだけどほぼみんな勉強して自作してるよな。
そこの潜在的な需要を掘り下げて提案して制作までするような流れができれば、
改良やら保守の需要も見込めるしカネになりそうな気がするんだけど。
よくＩＴが土方やゼネコンに例えられるけど巨大ビル建設や集合住宅（汎用性の高いプログラムコピーを法人・個人へ大量配布）
の分野ではそうだけど一戸建ての注文住宅みたいな領域は未開拓でみんなログハウスを自分で建ててる感じだよな。
まぁ請負サイトとかで個人間で受注したりってのはみられるけどそこを大規模にやってる企業とかないし。
(追記)
エロサイト巡回の効率化を巡る日曜朝っぱらの思い付きに思いのほかトラバ＆ブクマ集まったな。みんなサンキューな。
潜在需要の掘り起こしが難しいってのが大きいよな。「顧客が本当に求めていたもの」ってやつよな。
アキネイターとかで考えてることスパッて当てられたりするし何を考えてるかを当てるＡＩみたいのが進化したら
そこんところよろしくやってくれそうな気がする。
あとはやっぱコストに見合うかどうかってのが一番よな。
特注のソフトでものすごく生活が便利になって、その機能に見合うコストを払うのが当然って文化が盛り上がって行かないとなって気がする。
そもそもVtuberって金投げるに値するコンテンツちゃうやろ。
…
１年後か２年後にまた見返しておもろいなって思えるもんか？承認欲求や流行という文脈から切り離しても評価できるもんか？
お前がスパチャとか言って投げた合計金額を５年後か１０年後かに提示されて「経験としてこれだけの金や時間を費やした価値があった」って肯定できるか？他人にその価値を説明できるか？
価値は時代や状況に普遍じゃない。高級ホテルで飲んだコーラは都会で飲むコーラとは価値が違う。体験はその人がどんな状況にいるかに大きく左右される。
価値が変わりにくいエンターテイメントはあるが、そちらの方が優れているという理由はない。手堅い投資先というだけに過ぎない。
お前が絶対的価値を信じるあまり、祭りに乗り損ねている間に、他のみんなはそのノリを楽しんでいる。瞬間にしかない興奮は他では味わえないし、感謝の気持ちもその場所にしかない。丁寧なフィードバックもある。だからコスパは結構高い。
趣味のコスパについて、それを語るのを忌避する人は多いけど、俺はそういう視点はキライじゃないな。
小説や漫画のような従来型のエンターテイメントは、コミットすればするほど体験の価値は上がる。
だけどこちらが投入できる資源はほとんどが時間と集中力だ。情熱のエネルギーや想いをつぎ込む手段がほとんどない。即売会に行って作者に感謝するとか、グッズ買うとか、間接的でロスが多い。時間のない現代人にとって、スパチャにみられる贈与経済はコミット手段の革命であり、情熱解放の未開の領域だ。
Vtuberのほとんどは承認欲求とか性欲とかそういうもんを煽って金集めてる賎業をオタク向けにチューニングしただけで本質は同じ賎業やん。
いや賤業なんてない。職業に貴賎はない。
ここにも重要な認識のズレがある。スパチャに込めてるのは応援したい気持ちだよ。楽しい時間をありがとう、という感謝だし、純粋な賞賛なんだ。だから実感をともなった確信を持って、完全に肯定できる。
ちょっと聞いてくれよ。
俺アラサーのリーマンでさ、オミクロンがこんな感じになるちょっと前に、職場で「去年と今年の新卒入社って歓迎会やれてないよな」て話になってさ、でも大々的にやるのも憚られるよねってことで、同じ部署・ごく少人数で、歓迎会って名目も今更感だし普通の飲み会って感じでやろうぜって流れなったんだよ。でアラサーの俺が年齢・社歴的に当然だろと幹事役になったわけ。
で、後輩（２年目）に、そういうことになったから、〇月〇日にどこそこで飲み会やるから来ない？ とメールした返事が
「いいですね」
今にして思えば、ここで明確に参加と意思表示していなかったのがヤツのテクニックであった。
当日
ヤツは現れなかった。LINEは既読にならない。あいつ来ないの？ 来るんじゃないの？ なんで？ と同僚・上司達から問い詰められる俺。いや「いいですね」とは返信あったんですと説明する俺。そうかー、じゃあ来るはずだよなー、何かトラブルでもあったのかなー、と周りがなんとなく心配し始めた頃、LINEに返信があった。
「いいですねとは言いましたが参加するとは言ってません。その場に行ってないことで察してください。私は職場の飲み会的なものが嫌いなので一緒に飲みたくありません」（要約）
もうね、ブチ切れですよ。でもこんなの周りにそのまま言うわけにもいかないから「急に体調悪くなっちゃったみたいです」と説明する俺。飲み会自体はまあごく普通に特に何もなく終わったが俺は絶賛モヤってたわけですよ。帰りの電車で、流石に一言いうべきと思ってLINEしたわけよ。
俺「参加したくないならテキトーな理由で断ってくれればそれで良かった。こちらとしてはいきなり来ないお前を心配した。来ないなら来ないと連絡があって当然ではないか」（要約）
ヤツ「事前に断ると都合の良い日とか探られそうで嫌だった。心配かけたことは申し訳なく思うが察して欲しかった。てゆーかあなた察し悪いので私はあなたが嫌いです。もう誘わないでください」（要約）
もうね、ブチ切れですよ。いや俺を嫌いなのはいいよ、申し訳ないあんま心当たりないけど嫌われる何かをしたんだろうよ。正直に言うがそのYシャツを盛り上げて自己主張してる巨乳についつい目線が行ってしまったことはあったよ。なるべく見ないようにしてるつもりだけど！ 飲み会に来ないのもいいよ。今時、そういうの嫌いな奴に参加して欲しいと思わないし、一々誘わねえよ。
ただ意図的に曖昧な返事をした上で「行ってないことで察しろ」は社会人以前に人としてどうなんだよ。ホントムカついたからスッキリしたくてそのままソープに行きました。
久々にフリー凸からパネル指名したら、ルックスは良いんだけどガッツリ墨ってた上に超タメ口接客の嬢でめっちゃ萎えた。違うねん、俺はもっとこう……プロっぽい接客が好みで……いやタメ口でも良いんだけどだったらもっと素人っぽい感じであったりフレンドリーな雰囲気を作ってほしいんや。この嬢、これはもう接客になってないというか「失礼」の領域やんけ。露骨になめくさった態度取りやがって。金で相手してもらってるだけの縁だが、そこにも最低限の礼儀みたいなもんがお互いあるやろがクソが。腹が立ったのでホスラブの店舗スレにその嬢をほめたたえるレビューを投稿。騙される奴バーカバーカ。
はあ、むなしい。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
しかしさぁ、ちょくちょく情報聞き出そうって連中なんなのかね。昔の友人だったり同窓が突然連絡してきたけど、どうも競合くさいじゃないの。後役所のアンケートだとか。
新しいことはある。劣化コピーなら簡単にできるだろう。劣化コピーゆえにうまく行かないだろうが。
それでも様々な立場を使って起業どうですか？と聞いてくる。実現も困難だから圧力かけてきたり期間迫られる要件もある。
けどまあ、株として金を入れなかったのは正解だな。のらりくらりでやっていける。
と同時に、サブカルでホント作るの楽しすの領域になってる連中は楽しそう。まあ、なかなか気に入られるものを作れずに苦労しているのも一部見て取れる。
だけど、気に入られなくてだめだってのは、どちらかといえば根詰めたり、気にしすぎて疲れすぎるとだめだっていうのを感じる。気に入られないからだめなんじゃないよ。疲れすぎるとか、気にしすぎることのほうが問題なんだよ。
疲れすぎてネガティブになることさえクリアすれば、徐々にファンが増えていく。食っていけるほどではないけど、少なからずのファンがいて作って楽しすなのは見て取れる。
根を詰め過ぎなければ趣味楽しすでいいじゃない。
サブカルでやってる連中に僕の真の姿を見せればすごいことやってるんですね！とかは、言ってくれはするだろう。まあ、表に出せばそのぐらいの反応は得られるのはわかってるし。
飯食えなければ仕方ないし、弱いって時点で足元見られたり、引っ掻き回したりされる悪趣味な人形遊びでしかないとわかったけどな。
世界の外側を見てみたんだ。そうしたら急に妖怪に管理された人間生活が惨めに思えてな。まあ頑張るけど、やめるかもしれない。
君たちのやってることはほんと素晴らしい。ちょっと金を出すぐらいしか僕はできないけど、ホント趣味楽しすで楽しんでいってね！
------------------------------------------
昔の人が満足してたとは思ってないよ。そりゃ昔だってもっとこうならいいのにって思う人はたくさんいるでしょ
自分以外の誰もが持ってるように見えてしまうというか、見える範囲が広くなってしまったのではという感想よ。
みんな持ってるように見える・何を持っててどう楽しんでるのかがよく見える、だから余計に諦めきれないんじゃないかなと思ったわけ。
ジョーカーになれとかもね、羨ましいから持ってるやつを害するていう思考は自分には理解できない。別に害したところで自分の手に入るわけじゃなし。余計虚しくなりそう。まあ理解できないのものを理解する必要もないし、それがどうしても自分の人生に必要だって人もいるんだろうが。
そもそも人生が平等だって思想が蔓延りすぎたと思うんだよな。んなわけないじゃんって感じ。
クローズドになっていくというか、場がどんどん区切られていくのかなあとは自分も思う。そっちの方がいいよな、知ることは大概苦痛を生むと思ってるから。
------------------------------------------
結局『自分には手に入らないものがある』というある種の分別というものは、見えないからそう思える側面があるのだと思う。
ネットつーか今ここで想定してるのはTwitterとかインスタなどの、他人の日常を手軽に覗き見できるツールについてなんだけども、こういうものが発達するとぼんやりしてた世界が鮮明に、それこそ手に取るように見えてしまって、見えてしまったからこそ『自分もああなりたい』の欲望がいや増すのであろうなと思うわけである。
これまで見えてないし想定もしないし諦めるしかなかったものが、可視化されることで『自分の手中にないことがおかしい』までいってしまうんだろうな。
普通に生きてりゃみんな何かしら天秤にかけた結果諦めるようなことを繰り返してるわけだし、どうしても手に入れたければがむしゃらにやって、それでも無理なものは無理だったりするわけだ。
楽な仕事で一攫千金とか、モテる努力はしないが彼女彼氏を持っていないことが許せないとか、そういうのって『無理なもんは無理』の領域だと思うんだよなあ。
でも検索ワードひとつ入れたら普通にそれを手にした人々が、なにやら楽しそうにしているのがめちゃくちゃいっぱい出てくるもんだから現状がおかしいという認識になるんではなかろうか。
自分は化粧したくないし痩せるのもめんどくさいし、毛を剃るのも怠い、その上性格が悪いので、よっぽど気にしない上で自分を好いてくれる人が出現するという奇跡が起きない限りパートナーを持つことは諦めている。まあでもそんなもんじゃん。顔面もブスの類だしね。彼氏欲しいなあと思っても、現状をどうにかする努力と彼氏欲しい欲を天秤にかけたら努力したくない方に傾くんだわな。
仕事もそう、いい歳して大したスキルもなければ愛想がいいとか政治が上手いとかそういうわけでもない、その辺にいるただのおばちゃん。自慢できることなんてほぼない。早く死んじゃいたいけど親より先に死ぬのはさすがに……あと痛いのも怖いのも苦しいのもやだな……という消化試合っぷりである。心残りがあるとすれば積読くらいのもん。
