糞コードという言葉で傷つく人には、「このコードメンテできないので全部書き直していいですか」と言おう。多分受ける傷は何一つ変わらない。
無慈悲か
ランタイムとしてdockerを使わなくなるだけでローカルでのDockerの利用に影響するわけじゃないから落ち着けと。
今年はDDDのアドベントカレンダー盛り上がってなさそう
AI（Artificial Intelligence）研究は拡大し、全体を俯瞰的に捉えることが難しくなっている。また、AI研究の成果を用いた多数のシステム（AIシステム）が実社会で活用され始めており、AIシステムとAI技術との対応も把握が難しくなっている。そこで、これから活躍するAI研究の初学者、およびAI活用を狙う異分野の研究者・実務者をターゲットとしたガイドとして、AIマップβ 2.0を作成した。本AIマップβ2.0は、2019年に発刊したAIマップβの発展版であり、AI課題マップと、AI技術マップの2種から構成される。概要を以下に示す。
【AI課題マップ】
AIシステムによる解決が期待される多数の課題を整理した課題カード群と、それらの関連性を示す課題関連マップで構成した。異分野研究者・実務者が自分の課題を念頭に、AI活用の観点から課題を整理・深堀りする時の支援を目指した。初学者には、課題群の全体像を把握し、目標を定める助けとしてほしい。なお、既にAIシステムの事例集や、産業別の応用解説が書籍等で広く提供されている。本マップはそれらを代替するものでは無く、既存情報では得難い、課題群への広い視野と、課題とAI技術との関連性の情報を提供する。
【AI技術マップ】
AI技術マップは、2019年に発刊した「AIマップβ」の改訂版である。人工知能学会 論文誌編集委員会の協力により、キーワードを精査し、人工知能学会の論文キーワードとの共通化を図った。 これにより最新の研究キーワードが追加された。また共通化により、今後発刊される学術論文をキーワードで辿ることが可能となる。異分野研究者・実務者に対し、研究や開発情報収集の道標として役立つものと考える。初学者は自分の研究分野の位置づけを知り、学習を進める助けとしてもらいたい。
両マップは、相互に補完しながら、課題と技術の組み合わせを整理する役割を担っている。AI課題マップとAI技術マップを行き来しながら、研究やシステム構築の目指すべき姿を探索してもらいたい。
本資料ではその他に、研究会マップと、みんなでつくるAIマップを収録した。研究会マップは2019年版の更新である。みんなでつくるAIマップは、日本科学未来館が作成した、一般の人のAIに対する受容性を調査した資料である。
いわゆるネ申エクセル問題について、機械可読にするためにセルの結合をやめろと言っている人たちは、服のサイズに体を合わせさせた大日本帝国陸軍と同程度に間違っている。ユーザにとって見やすく親和性の高い様式をソフトウェア技術の稚拙さのために放棄させている。機械に人間を合わせさせている。
なので、セル結合などを使わせないことをリテラシー教育など称して威張り腐ってユーザに押し付けるのは大間違い。むしろリテラシーが足りないのはソフトウェアの都合を人間に押し付けるソフトウェア技術者のほう。リテラシー教育だと威張る前に、まずはソフトウェア技術の稚拙さを詫びるべきなんだ。
神Excel資料、見やすいと感じたことが一度もないのだが。
「限られたスペースに頑張って詰め込みました！」という程度の意味しかないので別にユーザーに親和性があるわけでもなく、作成者の自己満足以上のサムシングは無いのでは。
ウェブサービスを作るには技術指向の人間とサービス指向の人間両方必要で、技術指向の人間揃えても綺麗に動くだけの無を作りをがち、サービス指向の人だけで作ると一瞬で破綻して新機能追加できなくなる
雑でも力技でもとにかく動けばいいんだ指向の人が残した負の遺産を、後から入社した人が「どうすんだこれ...」って頭抱えるのがIT業界の慣例である
素晴らしさ。あとは何でもExcelで作りたがる「なんでもExcel屋さん」も迫害していこうな。
非同期ジェネレータ(aync generators)を使ってJavaScriptで実装されたコルーチンによって、アプリケーションの動作を宣言的に記述できることです。
ふーむ...良さそうな気配がある
・型検査で検出できることを確認するテストは書かない
・独自の型で宣言的に制限できるていることを確認するテストは書かない
・独自の型で表現できることをコメントに書かない
・独自の型で記述で、測定可能な怪しげな個所を機械的に検出する
・独自の型を正しく記述し、読み直し、レビューする
Spotifyでは、2014年まではOKRを採用していました。Googleなどで大きな成果を上げたOKRは、日本でも昨今導入が進んでいます。しかし、SpotifyはOKRをやめ、Spotify Rhythm（スポティファイリズム）という独自の目標管理フレームワーク（戦略フレームワーク）に移行しました。
OKRが悪いと言うよりは「アジャイル組織のように変化に適応していく組織だと、OKRは少し重すぎる」という理由でやめたようです。
Data：
展望を示す定量的、定性的なデータ。解釈を入れてはいけない。
Insights：
データの解釈と何を学んだか。
Belief：
データの解釈に基づいて、問題領域に対してどういう方針を取るか。
Bet：
方針に基づいて何を優先事項とするか。
ドイツ拠点のEmteria（エムテリア）は、Androidの公式プロジェクトであるAndroid Open Source Project（AOSP）の制約から生まれたスタートアップだ。AOSPは、産業用のアプリケーションで使うには十分な機能を備えておらず、カスタマイズして機能を追加する必要がある。そして、一部の産業ではいまだにWindows CEのような古いプラットホームで券売機などを動かしている。
emteria.OSは、チケット読み取り装置やレジ、券売機、スマートホームのコントローラー、ビデオ会議システム、警報システムなど、顧客が必要とするものなら何でも動かすことができる。最適化されたブランディング、セキュリティアップデート、そして継続的なサポートも受けられる。同OSはすでに7万5000社超が導入している。
ふむふむ、面白そう
有線LANは速くなるだけではありません。デジタルガジェットを含むさまざなま電子機器のインターネット接続を実現しようとする概念「IoT（Internet of Things、モノのインターネット）」を牽引すべく、これまでにないさまざまな機能をイーサネット経由で提供する仕組みが検討されています。IoTのインフラとしての有線LANを活用、つまり「有線IoT」をイーサネットで実現しようというわけです。
その標準規格のひとつが「IEEE 802.3cg（10BASE-T1）」。伝送距離可能な距離は1kmと、通常の有線LAN（理論値で最大100m）を大きく超えます。通信速度は最大10Mビット／秒と低速ですが、最大50Wもの給電が可能で、コンセントのない場所やバッテリー充電の難しい場所にも設置できるメリットを得られます。2芯／1ペアという簡素なケーブルで済むこともポイントです。
これは面白い
面白そう。時間が空いたら触ってみたい。
Red Hat は、OpenShift から Docker エンジンを取り除いただけではありません。Red Hat Enterprise Linux 8 からも docker コマンドと Docker コンテナーエンジンを完全に取り除きました。RHEL 8 には Docker が含まれず、Red Hat のサポート対象外になります (ただし、他のソースから引き続き取得は可能です)。
RHEL 8ではDockerをサポートしないからpodman使ってねということらしい
責務を意識して適切にツールを採用していくと、以下のメリットが得られます。
- 特定のCIツールを過度に学習する必要がなくなる
- 特定のCIおじさんだけではなく開発者全員がメンテナンスできるようになる
- CIツールとエンジニアから共通のスクリプトが実行される
- その結果、スクリプトがメンテされる状況を維持できる
- 別のCIツールに移行できる
なるほど、これは確かに
簡単にまとめです。
- .goのファイル数が100未満であれば、フラットパッケージ、オススメです
- パッケージもシンプルにして、同時に極力Struct, Interfaceを排除した
- handler(Endpoint) –> usecase –> repositoryといった流れで制御フローが流すことが世の中多そうだが、endpoint側にロジックを実装、repositoryは無くして直接db層の関数を呼び出した。初期化はdb.goにdbのclientを初期化してそれを使う
- modelになるべくロジックを寄せたた
- testはhandlerの関数単位で行う
- DB層をインターフェースを経由せずに扱うことはLocalStackなど外部モックサービスを利用すれば問題にならなかった
上記によって色々柔軟性は失われたかもしれませんが、少なくてもコード量はグッと減り開発スピードの向上に寄与できるかもしれません。
Clean Architectureに盲目的に従おうとする人が多い中、いい感じに取捨選択できていて素晴らしい。
Clean Architectureは「Javaで」「最大限柔軟に」を目指したひとつのサンプルだから全てを模倣する必要はないというのに。
やっぱ、システム開発においては、基本的に金使って急に人増やしたりどこかを買収したりしてシステムそのものを入手したからといって、それだけで物事が良くなる可能性はほぼ0であるという事と、それをやるとむしろかかる時間が増える、ということを非開発者に理解してもらうのは大変だよなあ……。
大学卒業後、未経験で業界知識もなく、何も分からないままとりあえず内定が出たSES企業に入社しました。ある現場に配属され、半月ほどは定時で帰宅できていたのですが、途中から雲行きが怪しくなり、月の残り半分だけで合計労働時間が350時間を超えたんです。それからは２徹、３徹や休日出勤は当たり前に。
結果的に自分自身も体調を壊し、合計２回病院送りになってしまいました。
ええ。実際私も最初に転職活動を始めた時、転職エージェントに登録して10社ほど面接を受けましたが、ことごとく落ちてしまいました。
その時担当してくれていたキャリアアドバイザーからは、「退職理由が『つらい』だけでネガティブすぎる」「Web系の自社開発に行きたいというけれど、スキルが足りていない」とフィードバックを受けました。
私が長時間労働で必死に戦って得たスキルは本当に何の役にも立たなかったんです。ただ健康を害しただけで、成長していない。絶望感でいっぱいになりましたね。
そうですね。あと今振り返って思うのは、「SESが全部悪いわけではない」ということです。
退職当時はSESを悪魔のように感じていましたが、退職してからこれまでに、尊敬できるSESの経営者や、楽しく働いているエンジニアをたくさん見てきました。それに、所属していたSESについても、私は健康を害して辞めてしまいましたが、実は私の同期は誰も辞めてはいないそうです。単に私の性格や体質にいただいた案件内容と合わなかったというだけで、他の人、他の案件はそうではなかったのかもしれない。
アジャイルが合わないものとしては、例えば、プラットフォームのインフラを制御するコードのデプロイみたいなものがある。これはリリースサイクルが１か月以上かかることもざらで、失敗したときの影響度はとんでもない。ライブラリや、extension なら、あるバージョンがバグがあっても、古いバージョンに固定すればいいだけだし、修正もPushしたら終了だ。しかし、プラットフォームのインフラを制御するコードとなると本番でのテストすら難しく、テストのためのインフラをデプロイするのすら大変であり、時間もかかる。かかわっているチームが多ければ、こっちがインターフェイスでミスをすれば、その修正のサイクルが長くなる。だから、失敗したらリリースが、２か月先とかになりかねないので、慎重にテストしたり、しっかりテストケースを作ったりコードを書いたり設計を何度も行き来して見直したりする。検証するべきものが見えたら、それを自動化したりする。
Servoはアプリケーションと組み込みの両方で機能するように設計された、オープンソースの高機能レンダリングエンジンで、開発にはMozillaが支援するプログラミング言語のRustが用いられています。レンダリングやレイアウト、HTML解析、画像復号といったタスクを独立して並列処理することにより、Servoはページの読み込み時間を高速化しているとのこと。
ところが11月17日にServoの公式ブログで、ServoがMozillaの手から離れてLinux Foundationに引き継がれることになったと報告されました。Servoプロジェクトはプロジェクトを導く役員会および技術運営委員会を新たに設置し、従来と同様に高機能かつ安全なレンダリングエンジンを提供するため、技術運営委員会がコミュニティをサポートするとのこと。
Mozilla、開発者リストラしちゃったもんな
PerlからPythonへ。
参加登録はしてたけど、当日完全に忘れてたので助かる
要件定義は業務を作って回してる人がやるべきその人にしかできないは真だけど、実際は上は「下に任せてる」下は「上に言われてやってる」、「前任者に言われた通りにやってる」前任者はもう居ない、で誰の意思でもなく業務が作られてたりする
「これ、やる意味あるの？」っていう業務改善活動は大事なのだ。面倒だし嫌がられるものではあるけれど。
というような事をすることになったのでメモ。
要するにアプリケーションのディレクトリに app.yaml を置いて、 gcloud app deploy すればよいのね。
IP制限はファイアーウォール的なものがあるのでそれを使うと。
k0sは、「100% upstream vanila Kubernetes distro」（100％純正で色付けのないKubernetesディストリビューション）であり、kとsのあいだのゼロは、k0sのさまざまな以下の特徴を示していると説明されています。
- Zero Friction：なめらかに導入できる
- Zero Dependencies：OSに依存せずシングルバイナリで提供
- Zero Overhead：余計なオーバーヘッドなく軽量に動作する
- Zero Cost：無料のオープンソースで提供
- Zero Downtime：クラスタのアップグレードなどはダウンタイムなく自動処理
おぉ...？
最近見たAPIのエラーメッセージ↓
{apiId: "xxx", errorCode: "00001",errorMessage: "xxxxx error."}
これでは情報量が少な過ぎる。
一応このAPIではエラーコードからエラーの詳細を確認できるエラーコード定義表が提供されていたのだが、それとて精々「○○の項目が不足しています」程度の情報量しかなく、それならエラーメッセージにその旨書いてあれば十分だったのでは？？ というお気持ちが生じた。
この事例から考えるに、別途エラー定義表を提供するぐらいならばAPIのエラーレスポンス自体に十分な情報を持たせた方がAPI開発者・API利用者共に無駄な調査や開発が減ることが予想できる。
したがって、APIのエラーレスポンスとエラーメッセージは極力リッチな情報を持たせるべきであるとの結論に至った。
・大量の逐次コミットをする
・バッチを分割して疑似的な並列インサートをする
・全てのカラムにINDEXを付ける
・シーケンスナンバーをPKにする
・カーディナリティが低いカラムにインデックスを指定する
・Update文を多用する
・大量にカラムがあるテーブルを作る
・クライアントサイドJOIN, クライアントサイドでフィルタ
JavaScript向けAPIにダミー値が入るという話はどうなってるんだろうか？
よくわからんが、結局↓のページを参考に判定処理を書けばいいか...
おもしろそう
Pythonの生みの親であるグイド・ヴァンロッサム氏（64）が、米Microsoftに入社すると自身のTwitterアカウントで発表した。
おっ
↓流行ってるものを否定するのではなく、流行っていないけれどステキなものを発見したいよね。伊藤若冲を再発見したジョー・プライスさんみたいに。
ドキドキするだろうな。
冬の夜に、手を暖めながら、絵を見る。今、これの価値を知っているのはオレだけなんだと思いながら。
「愚直にオブジェクト指向プログラミング」という言葉を見かけて、もにょっている。
プログラミングにせよ設計にせよ、そんなに愚直なものと思ったことはないので。
僕にとっては、どちらも、知的飛躍を含む、ちょっとアクロバティックな運動だ。
なぜ「愚直」みたいな言葉を使いたくなるのか、興味深いところではある。
自分が現状やっていることを誇りたい心情。でも、他のアプローチや見方があることも、うすうすは知っている。そんなところか。
ある種の防御。
今までの人生で「自分は愚直っスから」というヤツに何人か出合ったけれど、実際に愚直であったり謙虚であったりしたためしがないんだよね。
人の言うこと聞かないだけで(笑)
ほら喰い付いちゃった...
流行っているものが自分には理解できない時に、短絡的に理解したことにするには、低次元とか言って切り捨てるのが手っ取り早いのかもなあ。
それをわざわざ公言するのは、自分が何か人より特別と認めてもらいたいからか。
理解できないものを低次元といって済ませるのはありがちかなあ。
それを公言したがるのはお人柄w。
杉本先生の悪口はよくない
そうだったんだ。
最近はソースコードはgit、それなりサイズならHTTP(S)、大容量ファイルになるとオブジェクトストレージという感じだから全く使わなくなってたなぁ
システム間連携でたまにあるかな？ ぐらいか。
ファイルを開いた瞬間渋い顔になってしまうやつだ。
ならばCSVで...！ と思ってCSVをもらうと明らかにExcelで開くことを想定したヘッダやフッタの付いたCSVが届いてやっぱり渋い顔になってしまうのだ。
単に馴れ合ってるだけというチームは結構多い印象
馴れ合ってるだけならまだしも、表面上馴れ合いながら影で陰口合戦になってるところは最悪さがある
この記事のイメージ画像でやってるみたいにGKEクラスタとGLBを別個に立ち上げたい。
目論見としては↓みたいな感じ
できないはずはないと思っているのだが。
一日16時間、週7日勤務が二ヶ月続いて外注プログラマーが夜逃げした朝、「○○さん逃げたよ」と笑うタコ部屋連の爽やかな笑顔。今から思えば逃げた外注が正気で僕たちの方が狂っていた。人が狂うときは集団まとめて狂い、その中で正気を保つ者は異端として糾弾される。安っぽいSF短編みたいな話。
経緯
令和２年１１月２日（月）、当センター職員から「ふくいナビにアクセスできない」との指摘があり、サーバー管理会社であるＮＥＣキャピタルソリューション（株）福井営業所（以下、「ＮＥＣキャピタルソリューション」という）が確認した結果、クラウドサーバー上のデータが完全に消失していることが判明しました。
本件の原因
当センターは、ＮＥＣキャピタルソリューションと本年１０月３１日まで、クラウドサーバーの賃貸借契約を結んでおり、１０月１３日にその契約を更新していましたが、ＮＥＣキャピタルソリューションの社内手続きの瑕疵により更新手続きがなされておらず、貸与期間が終了したとしてデータが削除されたものです。
被害の状況
（１）システムの消失
ふくいナビシステムの全プログラムが完全に消失した状態です。システムの再構築は可能ですが、相当の期間が必要で再稼働の時期は現時点では未定です。
（２）登録データの消失
当センターおよび利用者が登録した全データ(バックアップデータを含む）が完全に消失し復旧が不可能な状態です。
消失したデータには、県内商工支援機関等のイベント情報などウェブ上に掲載されていた情報のほか、メールマガジンやメーリングリストの利用者が各自で登録したメールマガジン等の送信先アドレスや過去の配信内容も含まれています。
（３）情報の漏えいについて
利用者の情報漏洩はありません。
今後の対応等
今回ご迷惑をおかけした利用者および関係者の皆様にお詫びするとともに、当センターのウェブサイトにも状況を掲載し、状況の周知に努めます。
本件により、利用者の連絡先等のデータも消失しているため、すべての利用者にご連絡が行き届かないことが考えられます。お困りの方への対応は、以下のお問い合わせ先で対応します。
すごい
サーバーって構築だけじゃないんだよ。構築なんて誰にでもできるレベルなんだよ。維持、保守が主で、それを怠っている。しかもO氏のサービスは一応顧客情報を保持しているサービスである。正直、RoRを使うほどのものではないが、彼はそれしか学んでいないんだろう。RoRには脆弱性が伴う。そういったことも知らずに、「自分は初心者だから」と何年も言い訳して、何も学ばずにサービスを作り続けている。
ふくい産業支援センターは五日、運営するネット配信サービス「県産業情報ネットワーク『ふくいナビ』」が一日から使用できなくなったと発表した。ネットの情報を保管する「クラウドサーバー」を賃貸するＮＥＣキャピタルソリューション（東京都）が契約の更新手続きを怠り、サーバーのデータが完全に消失したためで、復旧は不可能という。利用者の情報漏えいはない。再稼働の時期は未定。
同社はサーバー機器を所有せず、機器の使用権を賃貸している。センターは二〇一五（平成二十七）年から五年間の契約を結んでおり、先月末で契約が終了するため、先月十三日に単年契約の更新を行った。しかし、同社がサーバー機器管理者への使用権更新手続きを怠ったため、貸与期間は終了したとしてバックアップデータを含む全データが削除された。
ふくいナビは県内企業の情報収集や発信、相互交流の支援を目的に一九九九（平成十一）年に開設。サービスは▽県内公的機関の産業・企業支援情報の提供▽メールマガジン（メルマガ）の発行▽メーリングリスト−などがある。主な登録データは産業・企業支援情報が二百件、メルマガ発行が八十三件。月間アクセス数は十五万件。
すごい
Read系とWrite系で別の実装方針を持つことは、心理的一貫性に反するから最初は抵抗あるけど、そうした方が保守性の高いアーキテクチャを維持できるので（思考を）切り替えていくしかない。
『レガシーコード改善ガイド』によると，単体テストに関する特徴として
・実行に0.1秒もかかる単体テストは，遅い単体テストである
・次に当てはまるものは単体テストではない
1.データベースとやり取りする
2.ネットワークを介した通信をする
3.ファイルシステムにアクセスする
4.実行するために特別な環境設定を必要とする（環境設定ファイルの編集など）
大枠で同意する。しかし，テストの中で一時ファイルを生成するタイプのファイルシステムアクセスはユニットテストに含んでいても許されるのではと思う。
一時ファイルの生成処理をモック化することは可能だし、実際にファイル作成するとなるとファイルの作成成功/失敗がテストしづらくなるから、やっぱりユニットテストでは実際にファイルを作成するべきではないかな。
２～３年前のスタートアップ投資ブームを覚えているだろうか。
ベンチャーキャピタルや個人投資家の投資意欲が旺盛だった時代。豊富な投資資金は審査基準の引き下げにつながり、学生が十数ページのパワポで１００万円単位の投資を得たり、十番煎じの後発企業に億円単位の金が流れ込んだりした。
その億円単位の出資を集めた会社は、何をしたのだろうか。そしてその後どうなったのであろうか。そのビフォーアフターを５つずつまとめてみた。
１．役員報酬や待遇を上げたがる
３０代や４０代に月給２０万円で働けとは言わないし、財務戦略の一環で社長が自社株買いをすることもあるので、そのために収入を増やして貯蓄するのはまぁ分かる。
ただ、「年収１０倍」「社長宅のタワマンを社宅に」「ハイヤーと契約」「出張でビジネスクラス（正価）や高級ホテルを利用」というのはどうかと。「贅沢がしたい！」と言い切ってくれればまだ気持ちが良いが、「安全リスクを考慮」「出張中でのネットワーキング」との言い訳は非常に残念。じゃあそれの目標を数値化しましょうとは言わず、「ああ、こいつは残念なヤツだ」と思うのが大人のやさしさ。
これは、利益率低下という直接的な悪影響に加え、社員が呆れて退職したり、不正行為（社長が月給２５０万なのに、俺は２５万ではやってられない）に発展することもある。
２．若い社員を増やしたがる
スタートアップの社長が採用するのは、社長より年下のことが多い。若い社員はマネジメント経験が少なく、プレイヤーばかり集まってしまう。マネージャーが少ないと、社員は士気が上がらず、サボるようになる。売上にはならないが会ってくれるお客さんのところに行くようになり、社内会議の資料作成にこだわるようになる。直行直帰やダラダラ残業も増加する。スタートアップ程度の組織は、本来社長のマネジメントで回るはずであるが、スタートアップの社長は得てして外出が多いので気づかない。
３．広告費を使いたがる
メディアに増資の記事が載った瞬間に、広告代理店からの営業が殺到する。もちろん出稿先を厳選した上で、費用対効果を見ながら徐々に広告を出すのであれば問題は無い。接待やら芸能人の紹介やらで付き合う代理店を決め、そのまま一気に数千万円の年間契約を結んだりする。そうすると費用対効果の悪い広告や、イベントへの協賛が増えてくる。
余談だが、「社長とユーチューバーとの対談をYoutubeにUPして、会社の魅力をPRしましょう」という提案が近年増えたと思うが、これは再生数の水増しが可能だからではないかと邪推している。
４．知名度の高い街に広くてきれいなオフィスを構えたがる
Ｂ２Ｂで来客も少ないのでどこにあっても良いはずなのに、恵比寿とか六本木とか渋谷にこだわる。１～２駅ずらせば賃料はグッと下がるのに、それをしようとしない。「同業者とのシナジー」とか「採用への効果」とかの言い訳が、これまた残念。最近は都内のオフィス不足が顕著で保証金は１０か月超が多く、また、内装もこだわることが多いので家賃の３０倍ぐらいの金額が一瞬で飛んでいく。
ちなみに業績が悪くなってから縮小移転をしようとしても、凝った造作の原状回復費や引越代、移転先の保証金などで動くに動けなくなり、「詰む」ことも多い。
さて、増資から１～２年経ったが、予定通りの売上が上がらない。
費用は予定通りか、予定以上のスピードで出ていく。ここからが後半選だ。
１．コンサルや社員研修に頼りたがる
どこかでコンサルや社員研修を見つけてきて、それを全社員に受けさせるようになる。もちろん良いコンサル、良い研修であれば効果は出るが、社長は内容を精査したり、カリキュラム設計に関わるわけではないので、基本的に他社の焼き直しパターン。もちろん成果は出ずに、費用だけ出ていく。体育会系研修や精神論的研修、スピリチュアル系研修（本当にある）の場合、社員がドン引きして辞めていくことも多い。
２．広告費をさらに使いたがる
起死回生で広告費にぶち込んだ。売上は上がるも利益が出ていない。いや、売上が上がるのは良い方で、中にはフォロワー数だけ増えて売上にはほとんどつながらないケースもある。代理店は「継続的に出稿することで、見込み顧客の意識に刷り込み云々」と言いながら、接待攻勢を強化してごまかす。接待の場には芸能人が来たりもする。でも利益は出ない。
３．新規事業として日銭商売を始める
売上を補うために、ネットショップや社長の講演業、自社オフィスのまた貸しやコワーキングスペース化（賃貸契約上良いのか？）など日銭商売をするようになる。もちろん急に売上が増えるわけではない。他業種の商売舐めすぎ。そもそも貴社は「何業するから投資して欲しい」って言ってたっけ？ネットショップの受注業務や、コワーキングスペースの受付を担当させられるようになった社員が白けて辞めていくことも多い。
４．粉飾し始める
社長が友人知人にアカウント開設や資料請求を依頼したり（←許せる）、社長が架空アカウントを発行したり架空の接触見込顧客（一度だけ会ったレベルの見込顧客リスト。名刺交換程度）リストを作成するようになる（←許せない）。
そうして、アカウント数や接触見込顧客数は伸びているが、売上が付いてこないと株主に説明するようになる。売上や利益の粉飾は、知識が無いのか、ビビってるのかやらないケースが多い。だいたい社員または元社員から株主へのチクりでバレる。人望がない。
５．株主への説明会に出てこない
定期的な株主への説明会に出てこないか、出てきても話さない。代わりに話すのはいつの間にか増えたＣＦＯ。だいたい前職は都銀。総会抜きで役員増えた？と思って確認すると役員ではなく「執行役員ＣＦＯ」。この条件を受け入れて転職する時点で非常に残念。まれに優秀な人が居るので唾をつけておくと、将来起業したり、自社に引き抜けたりできる。
株主だって、鬼じゃないんですよ。
ちゃんと節制ある経営を行ってダメだったら諦めますし、その社長が次に何かやる時は出資をしますから。出資金を自由気ままにバカスカ楽しいように使って、最後はとんずらって言うんじゃ許しませんって。
あと、タイトルで「選」の使い方が間違っていますが、釣りということでご容赦ください。
以上、最後までお読みくださり、ありがとうございました。
皆さんのご経験も、共有していただければ幸いです。
20201103追記
・たまたま見つけたけど、なんで一年越しでバズってるの？
・ここ半年、コロナを理由に廃業するところが増えたけど、「理由が出来て良かったね」とは言わないのが大人のやさしさ（2回目）
Amazon Web Services（AWS）は、数週間以内にDockerコンテナイメージをパブリックに公開できる新たなコンテナレジストリサービスを発表すると明らかにしました。
いい流れだ
僕が書いているコードは、それなりにオブジェクト指向チックだと思っているが、値クラスやエンティティや集約やリポジトリなどはわずかで、多くはそんなカテゴリーに属さないクラスたちだ。そして後者の方が生き生きと振る舞っている。だから、こうした概念を中心に据えた設計論を僕は信用しないのだ。
値クラスやエンティティという概念が無意味だと言うのではない。
概念を、これは値、これはエンティティと振り分けることが設計の中心課題ではないということ。
GitのコミットはIDを持つからエンティティとも言えるし、不変だから値とも言える。
しかしいずれにせよGitの設計とあまり関係ないよね。
設計って、概念をそういう型とか枠に当てはめていくパズルではないと思う。設計の最後の方で、そういうパズルがちょっと出てくるにしても。
このように既存の方法論にマウントとって気持ちよくなりながら代替案も示さず、再現性の無い我流手法を自画自賛するようになってくると「あぁ、この人は本格的に終わってしまわれたんだなぁ」という趣き深さがある。
それなりにお歳を召していると周囲の人も一々諌めてくれなくなるので仕方のないことであるのだが。
とにかく優しい、というか優しすぎて優しいと甘いを取り違えているとも感じました。時には強く叱るのも優しさであり、許すことのすべてが美徳というわけではありません。それを受け入れるか受け入れないかは相手次第だと思いますが、優しさと甘さを取り違えた結果、相手を駄目にすることもあるのでそれは一個人としてもよろしくはない。あなたは何人分の人生を背負うつもりなんですか、と問いたい。その先に繋がらない一時的な甘味なんて毒でしかないんですよ。
設計ボロボロでもトランザクションスクリプトのコピペスキルとif文ねじ込み腕力つければ、簡単にベロシティを出せるからなあ...
そういうのは UnitTest でカバレッジ100%を課して自分から去ってもらうように仕向けるしかない。
結局のところ、情報が整理しきれない人ほどExcelを好む傾向がある。その場しのぎに走り易い人ほどPower Pointを好む傾向がある。
友人が「受託の水を飲みすぎた」って表現してたのすごくわかって、受託ループって抜け出すの難しいのよね。確実に対価が入ってくるお客さんが目の前にいるのに、それを断って「自社サービスに注力します」というには相当の覚悟がいる。
Googleの昔の20%ルールのような何か自律が必要なんだろうなぁ。
もちろん経営的に「受託を受け続けることのできる体力をつけるために企業を拡大して仕組み化する」というのも正解なんだけど、フリーランスや個人経営レベルの会社をしてると「あと何年受託し続けれるかな」というところはあるんだろうなぁと思う。
ひとつの会社に縛られたくない、だけど長期的にサービスにコミットしたいというジレンマあるある
- タイトルに日付をつける
- 補足・修正内容をコメントに書く
- 定期的に見直すタイミングや担当が決まっていない
- バイネームの記載がある
- 文章が冗長
- 全員見れるべきものが見れない
- スクショの過度な多用
分かりみが深い。
他にも「対象読者を絞れていない」だとか「過剰な図」とか色々あるので自分でもまとめてみたい。
昔からX.Orgは色々言われていたし、Waylandの方が有望ならみんなそっちに流れるよなぁと