プロフェッショナルファーム出身者のピープルマネジメント術は、大抵の会社ではアテにならないと思っており、もっと世の中は"意識が低く、昇進に興味もなく、適当に仕事をやってさっさと帰りたい部下"で溢れており、そういう部下だけで構成されるチームをどうまとめ上げるか？という観点が抜けている
コンサルのパワーポイントは物事を分類&階層化して二次元に射影してるんだよね。
その射影の軸を彼らは「切り口」と呼ぶんだけど、射影なのでかなり情報量が減る。
霞ヶ関のパワーポイントは射影をせずに難しいものを難しいまま扱っている。キュビズムみたいなもの。だから普通の人にはわからない。
いつも夫を応援してくださりありがとうございます。夫に代わり、妻が投稿させていただきます。
夫はかねてより病気療養中でありましたが、8月23日に家族に見守られ永眠しました。頑張って生き抜き、穏やかな最期でした。
生前親しくしてくださった皆様、お世話になりまして、本当にありがとうございました。
R.I.P
故人ブログがまたひとつ
Mojoは現時点でダウンロード時にユーザー登録などが要求されるものの、無料で利用可能です。
ただしMojoはオープンソースとして開発されてはいません。同社は将来的に標準ライブラリなどをオープンソース化する可能性はあるとしながらも、Mojo全体のオープンソース化は明言していません。また、同社がMojoをどのように商用化するのかについての計画も示されていません。
[...]一番聞かれる質問第一位は、「結局EMって何する人なんですか？」 です。一口にEMって言っても、なんか人によって得意な領域が違っていたり、大事だと思うポイントがバラバラなので、この疑問を持つのはそりゃそうだよなあ、とは思います。というわけで、このエントリーではEMは何する人なのかを明らかに・・・と思ったのですが、一言で語るのはやっぱり難しいなと思っています。なので、なぜ僕がEMという役割を説明するのが難しいと思っているのか、を書いていきます。
[...]これらのことから、マネージャーの一種であるEMは、開発チームの成果を安定化させる(継続的に最大成果を出すと言って良いかも)ために、メンバーの持っていないスキルを埋める役割として機能していることが大事だと言えます。
技術課題が大きければ大きい程、開発のスペシャリストとしてのスキルセットが要求され、直接的にチーム課題を解決していくことが要求されます。一方で、メンバー構成や文化によって、技術課題がメンバーである程度やれるようになってくると組織課題の比重が重くなり、一般的なマネージャーとしてのスキルセットが要求されるようになります。
ドメイン駆動設計に言及する記事や書籍は多くありますが、それぞれ着目する側面が異なったり色々なコンテキストから言及されています。
おそらくそれが原因でドメイン駆動設計が何であるかをぼやけさせ、正体のわかりにくい概念になっているように思えます。
そこで今回は色々な観点から整理し、ドメイン駆動設計とは何であるのか、その正体を考えていきます。
Explain complex systems using visuals and simple terms.
Whether you're preparing for a System Design Interview or you simply want to understand how systems work beneath the surface, we hope this repository will help you achieve that.
複雑なシステムをビジュアルと簡単な用語を使って説明します。
システム設計面接の準備をしている場合でも、単にシステムが水面下でどのように機能するかを理解したい場合でも、このリポジトリがそれを達成するのに役立つことを願っています。
当社（株式会社NTTマーケティングアクトProCX）が利用するコールセンタシステムの運用保守業務を担うＮＴＴビジネスソリューションズ株式会社（以下、ＮＴＴビジネスソリューションズ）において、同システムの運用保守業務従事者（ＮＴＴビジネスソリューションズに派遣された元派遣社員）がお客さま情報を不正に持ち出し、第三者に流出させていたことが判明いたしました。
不正に持ち出されたお客さま情報は、当社へテレマーケティング業務を委託いただいていた一部のクライアントさまのお客さま情報であることを確認しました。
クライアントさま並びにクライアントさまのお客さまへ多大なご迷惑とご心配をおかけしておりますことを、深くお詫び申し上げます。
1. 概要
当社が利用するコールセンタシステムを提供するＮＴＴビジネスソリューションズの同システムの運用保守業務従事者（ＮＴＴビジネスソリューションズに派遣された元派遣社員）が、システム管理者アカウントを悪用のうえ、お客さまデータが保管されているサーバへアクセスし、お客さま情報を不正に持ち出し。
（1）不正に持ち出された件数
お客さま数：約900万件 クライアント数：59（現時点判明分）
※今後新たな情報が判明いたしましたら、随時公表してまいります。
（2）不正に持ち出されたお客さま情報の内容
クライアントさまよりお預かりしたお客さま情報（氏名/住所/電話番号等）
2. 本件に関する対応と再発防止策
当社及びＮＴＴビジネスソリューションズは、今回の事案を厳粛に受け止め、クライアントさまのご不安の解消に向け て対応いたします。
まず、本テレマーケティング業務については、システム面および運用管理面から緊急的な対処策を講じ、新たに不正な情報持ち出しが生じることを抑止しました。さらに、今後、お客さま情報を取り扱う全業務について再点検を実施することで、個人情報管理体制の一層の強化を図ってまいります。加えて、当社及びＮＴＴビジネスソリューションズの従業員に対して、これまで以上に情報の取り扱い・保護に関する教育の充実を図り、個人情報保護の重要性に関わる当事者意識の醸成を図ってまいります。
NTT西日本グループのNTTマーケティングアクトProCX（大阪市）は10月17日、マーケティング業務を代行するためにクライアントから預かっていた顧客情報900万件が不正に持ち出されたと発表した。コールセンター用システムの運用保守を依頼していたNTTビジネスソリューションズ（同）の元派遣社員が、第三者に情報を流出させていたという。
少なくとも、NTTマーケティングアクトProCXがクライアント59社から預かっていた顧客情報（氏名、住所、電話番号など）が持ち出された。元派遣社員はコールセンター用システムの管理者用アカウントを悪用。データが保存されていたサーバにアクセスし、情報を持ち出したという。
2社はすでに「緊急的な対処策を講じ、新たに不正な情報持ち出しが生じることを抑止した」といい、今後は情報管理体制を再点検する他、情報の取り扱いに関する社員教育を充実させ再発防止を図るとしている。
リソース情報
リソース情報は、プロダクトやシステムの現状を表現するミュータブルな情報であり、プロダクトやシステムの成長に合わせて常に変化していきます。例えば、システムの変化に応じて運用手順書は常にアップデートされていきます。つまり、あらゆる情報をリソース情報としてそのままドキュメント化してしまうと、それだけ多くのドキュメントを運用・保守する必要が発生します。
イベント情報
イベント情報は、あるプロダクトやシステムの意思決定に関するイミュータブルな情報です。その後、そのプロダクトやシステムがどのように変更されたとしても、その当時における意思決定そのものが遡及的に変更されるわけではありません。また、あるリソース情報に関するドキュメントを書く場合、イベント情報の積み重ねとして表現することで、書き手にとっての運用・保守のコストを低減し、読み手にとって過去の変遷をたどりやすくなります。
イミュータブルドキュメントモデル
つまり、ストック情報をドキュメントとして表現する場合、まずイベント情報をドキュメント化し、次にそれらのドキュメントを参照する形式でリソース情報をドキュメント化することで、下記のメリットを享受することができます。
- 読み手は、あるストック情報について、過去から現在に至るまでの変遷とその理由を辿ることができるようになる
- 書き手は、過去に書いたドキュメントのうち、リソース情報に関するドキュメントの鮮度だけを気にすればよい
ここで、この考え方およびこれを実践するためのドキュメント運用手法を「イミュータブルドキュメントモデル」と命名します。
イミュータブルドキュメントモデルでは、書き手は次の運用フローに従ってドキュメントを執筆します。つまり、書き手はストック情報をドキュメント化する場合、「ある決定の検討を開始した時」から「ある決定について合意した時」までの間、イベント情報のみをドキュメント化し、その決定について合意された時にリソース情報のドキュメントへ反映します。
さて、この運用フローを見た読者の方は「かなり重厚な運用フローだし、イベント情報だってドキュメント化するハードルは低くないよなあ…」と感じたのではないでしょうか。実際、PRDやDesign Docsは優れたドキュメント手法ではありますが、その実践は容易ではありません。そこで、筆者は次のような流れでイベント情報を書き上げていくことをおすすめします。
- 個別の意思決定ごとに、「承認された日」「背景」「決定されたこと」「決定による影響」のみをドキュメント化する
- より俯瞰的なドキュメントが必要だと感じたら(かつ、まだ力尽きていなければ)、それらをまとめてPRDやDesign Docsとしてドキュメント化する
カラムナフォーマットとは、データベースの分析用途に利用されるファイルフォーマットの種類の一つです。大量のデータを扱う際に効率的に圧縮してストレージコストを下げたり、計算時に必要なデータだけを取り出して計算コストを小さくできる設計がされています。
行指向フォーマットは、行方向に連続してデータを格納するため、一つの行をまとめて操作することの多いOLTP処理に向いています。従来のデータベースはもともとこの行指向フォーマットが利用されてきました。
ストレージ技術などの発展により、DWH用途での利用を行うようになって、注目されるようになったのが列指向フォーマットです。列指向フォーマットは、列方向に連続してデータを格納する方式で、列単位でデータを取り出す分析用途に向いています。
主要なOSSのカラムナフォーマットのライブラリとしては、ParquetとORCがあります。
ParquetはTwitter社とCloudera社が、2010年のGoogleの論文Dremel: Interactive Analysis of Web-Scale Datasets（以下Dremel Paper）におけるデータレイアウトに関する内容をOSS実装したもので、ORCはもとはApache Hiveのためのフォーマットとして実装されたという背景の違いがあります。
カラムナフォーマットでは、データ型やカーディナリティ等の特性に応じて、様々な符号化方式から決定木等によって各列に最適なエンコード方式を選択します。これらの符号化技術自体は、行指向フォーマットでも利用されるものですが、カラムナフォーマットでは、型が同じデータが並んだり、規則的にインクリメントするデータが並ぶなど、符号化によるデータ圧縮が効きやすいというメリットがあります。
上述したとおり、カラムナフォーマットにはクエリパフォーマンスをあげるための仕掛けが施されています。ただし、フォーマットはあくまで最適化しやすいデータ形式であって、それらを活かし切るかどうかは実際に処理を行うクエリエンジン側に依存します。
# パターン1
def function(cond):
if cond:
return 100
else:
return 0
# パターン2
def function(cond):
if cond:
return 100
return 0
やあ！id:cockscombです。日々の生活に役立つちょっとした知識を紹介していきます。最近は、Apple WatchやPixel Watchみたいな、ナントカWatchのリリースが多いですね。でも今日紹介するのは、WatchはWatchでも、Docker Compose Watchです。
Docker Composeは、複数のコンテナを扱った開発に用いる道具で、コンテナを活用した開発では当たり前に使われている。そのDocker Composeに、ファイルの変更を監視してコンテナの再構成を行わせるのが、Docker Compose Watchだ。Docker Compose 2.22以降で利用できる。最新のDocker Desktopにも付属している。
これは便利そう
金融機関どうしの送金システムに不具合が発生し、500万件を超える振り込みの処理が遅れた問題で、金融庁は多くの利用者に影響が及んだ事態を重く見て、システムを運営する全銀ネット＝「全国銀行資金決済ネットワーク」に対し、法律に基づいて原因や再発防止策などの報告を求める「報告徴求命令」を出す方針を固めました。
全国銀行協会の関連団体で一般社団法人の全銀ネットは、金融機関どうしの資金をやりとりする「全銀システム」の運営を担っていますが、今月10日に不具合が発生してから12日復旧するまでに2日かかり、500万件を超える振り込みの処理が遅れるなど利用者への影響が広がりました。
「全銀システム」にこうした不具合が発生したのは1、973年に稼働を始めてから初めてのことです。
金融庁は多くの利用者に影響が及んだ事態を重く見て、全銀ネットに対し、資金決済法に基づいて、原因や再発防止策などの報告を求める「報告徴求命令」を出す方針を固めました。
金融庁は今月9日までの連休中に全銀ネットが実施した更新作業に問題があったと見られることから、更新作業の方法やバックアップの態勢、それに不具合が発生したあとの対応についても問題がなかったか詳しく調べる方針です。
また、不具合が発生した今月10日が資金決済が集中するいわゆる「五・十日」だったことが混乱を招いたという指摘もあることから、システムを更新するスケジュールに無理がなかったかどうかなど、利用者への影響が広がった背景についても調べる方針です。
全国銀行資金決済ネットワーク（全銀ネット）は10月10日、全国銀行データ通信システムの不具合を巡り、すでに受け付けた振込の対応方針を変更した。当初は「バックアップ手段を用いて、受付済の取引については、本日中の着金を予定している」と説明していたが「現在、バックアップ手段を用いて、振込取引の処理を実施している」と発表文の表記を改めた。
全銀ネットは「バックアップによって、本日受け付けたものの作業を進めてているが、量が多くて本日中に対応しきれるかの見通しが立たなくなった。そのため正確な表記に改めた」と説明した。
全銀ネットは同日、システムの不具合で三菱UFJ銀行やりそな銀行など11行で他行宛の振込ができない状態になっていると発表。同日午後4時半時点ごろには原因は調査中、復旧時期は未定としながら「受付済みの振込は本日中に着金する」と発表していた。同日午後7時50分現在も原因や復旧時期などは明らかにしていない。
全銀ネットのトランザクション数を考えるとリランとか悪夢でしかないだろうな...
興味を引いたセッションがあればアーカイブされてから見るかも。
本記事では、成果データの集計処理におけるBigQueryのクエリ実行処理のユニットテストをGoで実装した取り組みと、その際の工夫についてご紹介します。
前項で示したように、複数のテストケースが存在していると、別のテストケースで用意したデータを参照してしまい、意図した結果とならないという問題が起きます。テストケース同士の関連やデータの競合について考慮しながらメンテナンスしていくのは難しいため、テスト用のヘルパーを用意してテストケースごとにテーブルを作成・削除するという方法をとりました。
Ruby on Railsの作者として知られるDavid Heinemeier Hasson（DHH）氏は、Dockerコンテナに対応したアプリケーションのデプロイ自動化ツール「Kamal 1.0」をリリースしました。
Kamalはアプリケーション（群）の構成とデプロイ先のサーバ（群）のIPアドレスなどの基本的な情報を設定すると、あとは仮想マシンやベアメタルサーバ、クラウドのサーバインスタンスなどにDocker環境の構築からアプリのデプロイ、トラフィックの切り替えまでを自動的に行ってくれる、デプロイ自動化ツールです。
Ansibleで同じことできそうだが。
Redpanda は Kafka 互換のイベントストリーミングプラットフォームです。
Redpanda | The streaming data platform for developers
ロゴは Red Panda(レッサーパンダ)になっています。
JVM で動作する Kafka と異なり C++ で書かれており[1]、シングルバイナリで実行可能です。ZooKeeper のようなリソース管理サービスなどにも依存しません。
Kafka に比べて6倍のコスト効率が謳われています。
Kafka はブローカー、スキーマレジストリ、ZooKeeper などのサービスを個別にデプロイする必要があります。Redpanda はこれらの機能が1つのバイナリになっています。そのため以下のような利点があります。
- デプロイの簡素化: Kafka では相互依存する複数のサービスの開始・停止など複雑で非効率なプロセスが必要
- 管理の簡素化
- エッジ/IoT への展開: フットプリントが小さいことでランタイム環境の範囲が広がる
- CI/CD での高速な起動・シャットダウン
- 障害からの回復力の向上
NATS.ioも触ろうと思いながら放置してしまっている。
オープンソースで開発されている軽量なアプリケーションサーバ「NGINX Unit」（エンジンエックス ユニット）が、最新のバージョンである「NGINX Unit 1.31」でサーバサイドWebAssemblyにテクノロジープレビューとして対応し、WebAssemblyランタイムを搭載したことを明らかにしました。
NGINX UnitがサーバサイドのWebAssemblyに対応することで、開発者はWebAssemblyに対応したさまざまな言語で、瞬時に起動し高速な実行が可能なWebアプリケーションの開発が可能になります。
オラクルはJavaをサーバレス環境で実行するのに最適化した技術「GraalOS」を発表しました。
同時に、Oracle Cloudのサーバレス実行基盤である「Oracle Cloud Functions」でGraalOSの機能を提供することも発表されました。
GraalOSは名称にOSと付いているものの、LinuxやWindowsのようなOSではなく、Javaをデプロイする新たな技術とその基盤を指します。
具体的には、同社が提供しているJava実行環境である「GraalVM」のコンパイラを用いてJavaをコンパイルしてネイティブバイナリを生成し、それをサーバレス基盤にデプロイし実行することで、サーバレスアプリケーションの瞬時の起動と高速な実行などを実現するというものです。
ネイティブバイナリを実行することで、コンテナ技術を用いた従来のサーバレス実行基盤のコールドスタートで生じていたような、例えばJavaVMの起動待ち時間などが本質的になくなります。
これにより、ほとんどすべての場面で数十ミリ秒以内にアプリケーションが起動すると説明されています。
いつだってプレスリリースは建前だ。本音は別のところにある。それを紐解くカギがOpenTofuのGitHubのContributorsにある。左から所属先を見てみよう。
env0のエンジニア、env0のエンジニア、Spaceliftのエンジニア、env0のエンジニア...
env0やSpaceliftは上記であげたLinux Foundationのアナウンスで、今後5年間にわたりフルタイム開発者を雇用することを宣言した企業のうちの一つだ。私にはあまりなじみがない、これらはどういった企業だろう？
env0、Spacelist、これらの企業はいずれもIaCのマネージドサービスを提供している。多種多様なIaCの実行基盤をワークフローという形で束ねて提供するサービスを展開してる。
かくして、ライセンスの変更により、env0やSpacelift等、Terraform Cloudのライバルになりえたマネージドサービス企業はことごとくTerraformを使えなくなったわけだ。そりゃ困るよねと。
そこでOpenTofuを発足させたわけだ。要はビジネスの都合である。
今回の騒動は、純粋にTerraformに対してオープンソースソフトウェアの精神からコントリビュートしてた開発者もないがしろにしたことは事実だ。だが、正直OpenTofuの発足メンバーがその精神を声高に訴えるのは正直違うよねっていうのが所感である。
職場のひとと
について議論した
結構かっちりやるところだとこのコードはNGみたい
if（$foo == CONST_NUMBER）｛
return true
｝else ｛
return false
｝
素人がみて
あんま訳わからんコード書かんようにすると、こうならんかな、とはおもう
見つけたら瞬時にリファクタリングしちゃうので私はここでは働けない…
せめて、可読性を意識したいなら
$fooMatches = $foo == CONST_NUMBER;
return $fooMatches;
可読性というか「詳細設計で分岐が出てきたらコード上でも分岐が出てこないとおかしいやろ」という強迫観念めいたものの存在を感じることがある
やはり詳細設計は悪なのか
Raspberry Pi財団は2023年9月28日、人気の主力製品シングルボードコンピュータRaspberry Pi® 新製品シングルボードコンピュータ「Raspberry Pi® 5」を発表しました。
「Raspberry Pi® 5」は2023年9月28日現在、工事設計認証（いわゆる技適）未取得のため、株式会社スイッチサイエンス（本社：東京都新宿区、代表取締役：金本茂）では、工事設計認証の取得及び表示などの対応が実施された後の販売開始を予定しています。
「Raspberry Pi® 5」は、「Raspberry Pi® 4」と比べてCPU性能は2～3倍、GPU性能も向上、Raspberry Pi®独自開発のI/Oコントローラー「RP1」の搭載により、カメラ/ディスプレイ/USBなどのインタフェース機能が向上し、新規にPCIe 2.0が利用できるようになりました。また、電源ボタンを標準搭載、別売りのHAT接続によるM.2コネクタのストレージの搭載が可能になりました。
各種コネクタなどのフォームファクタがPi 4から変更されているため、多くの既存ケースやPi 4用のPoE HATなどは利用できません。電源は5 V/ 3 Aでも動作しますが、その場合四つのUSBポートからの電流は合計600 mAに制限されます。5 V/ 5 AのPDを認識した場合、1.6 Aまで自動的に上昇します。
技術書、3,000円くらいが平均だとして100冊で30万。読めてたら一ヶ月で余裕でお釣りくるし、続けなきゃ減衰するとはいえ単発じゃないんだよね。ただその元手が読んでない頃はなかったりするだろから補助は必要だと思うけど。
3000ゾーンと5000overゾーンみたいなのがあると思ってて、読み方もなんか違う。
であと1000-2000くらいのもあるんだけど、この辺は短期的な立ち上げにはいいんだけど長期にはあまり寄与しなくて、数読んでもあんま意味ない感じ。感じ。あくまで感覚。
以前は月に一万円を固定費として書籍代に割り当てていて、毎月2〜3冊技術書を買っていた時期があった。
昔は一万円分購入すると1000円分ポイントバックするオンライン書店があったので三ヶ月で3000ポイント貯まって、オマケで3000円ほどの技術書が買えたりもした。
そういう生活を数年していると技術書だけで300冊超えの蔵書が出来上がり、引っ越しの度に引っ越し屋を泣かせる事になるのだ。
流石に最近はもう完全に電書オンリーになってしまったが。
ITmediaでも取り上げられていますが、NTTドコモが自社サービスのドコモ口座のドメインをうっかり世に流してしまい、騒動になっています。
ただでさえ、フィッシング詐欺や著名人なりすまし広告が横行しているこの状況で、そのまんまのが放流されたら大変なことになるんですが、大丈夫なのでしょうか。
この話を何故口を酸っぱくして書くかというと、個人情報保護法を含めた情報法の界隈では、通信村では相応に厳格な運用がされているもののはずが、サービスレベルにまで落ちた途端にかなりイージーに、お見合いポテンヒットみたいなやらかしが平気で発生し、さらに外部指摘があると関係先に「問題ありませんから」ともみ消しに来てるってのが最高にマズいし、その程度のマインドだから土管から一ミリでも地上に出ると事業が上手くいかないのだという典型例になるんじゃないかと感じるからなんですよ。
INSERT INTOをする複数のSQLクエリがあり、INSERTするレコードの取得に複数のテーブルを参照しているような場合、 その依存関係をひと目で確認できるグラフが欲しいです。 ですがPowerPointなどで自分で作るのはさすがにご勘弁願いたいということろで、 やり方を調べていた所、Pythonのパッケージ依存関係可視化のツールを使うというアイディアに行き着きました。
テーブルの依存関係を、PythonのPackageの依存関係を可視化できるPyreverseを使用して行ってみました。 別にテーブルに限った使い方に限定されるわけではないので、 複数の要素の依存関係を可視化したい用途に使えると思います。
テーブルの依存関係をPythonモジュールの依存関係に置き換えて可視化するアイデア
自分だけが使う or 一時的な確認に使うみたいな限定的な用途なら手軽だし使い勝手よさそう。
一応いっとこ。
世の中の人は基本的に競プロに対して詳しくないし、知らないのが当たり前なので、誰かが事実を教えてあげることまでは良い事だけど、それをバカにしたりするのとかはあんまりしないようにね。知らないジャンルは無言を貫く以外の選択肢が許されないSNSはあんまり楽しくないからね。
他人の無知をバカにするタイプの人間はお育ちが悪そうで関わりたくないものであるな
Linux Foundationは、HashiCorpのインフラ構成ツールであるTerraformをフォークしたプロジェクト「OpenTofu」のローンチを発表しました。
HashiCoprは今年（2023年）8月、それまでMozilla Public License v2.0（MPL2.0）のオープンソースライセンスで提供していたTerraformを含む同社製品のライセンスを、商用利用に制限があるBusiness Source License v1.1（BSL1.1）に変更すると発表しました。
参考：HashiCorp、全製品のライセンスを商用利用に制限があるBSLライセンスに変更すると発表
このライセンス変更に反発し、ライセンス変更前のTerraformをフォークしたプロジェクト「OpenTF」が9月初旬に立ち上がります。
しかし「OpenTF」の名称はHashiCorpの商標を侵害する懸念が残るとして、新たな名称の募集がGitHubのIssue「New name for the OpenTF project #296」として行われていました。
ここで「Tofu」はどうかという提案があり、Issueを見る限りほぼ満場一致の形でこの名称の採用が決定しました。
仕事をしているとたまに「〜していただけたら幸いです」「ご教示ください」といった言い回しに出くわすことがあります。所属している組織の文化によっては違和感を感じることなくスルーするでしょうし、仮に若干の違和感を感じたとしても「その人はそういう人なのだ」としてやはり流してしまう人が多いと思います。
しかし、私はわりとかなりの頻度で「それは望んでいる態度ではないのです」ということを伝えます。たとえば、「ありがとうございます。〜でいいと思います！あと、同僚なので『これでお願いします！』くらいのノリで行きたいです！」というような返信をしたりしています。言葉使いは信頼関係から来るシグナルなので、そこをきっかけにそもそも信頼関係を築けるようにしていくというのも並行してやりますが、それも含めて組織の前提を『社交儀礼としての糖衣を取り去り、相手を信頼してストレートな要求をしてもいい組織だ』という基本的な信頼へ置きたいというのを伝えていくようにしています。
言葉使いに遠慮があると、どうしてもマーケットやユーザーへのベストを考えたときに、周囲に対してタフな要求をするということの難易度が上がり、最短でマーケットへ価値を届けるというのが難しくなります。そこで
- 私たちの組織ではまず最短でマーケットへ価値を届けるのが一番重要なことで、同僚はそこに向けて一緒に困難へ取り組む仲間だというスタンスで居たい
- そのときに、遠慮や過剰な丁寧さは不要で、それよりも目の前の課題をどうクリアしていくかを率直に話せる関係性を大事にしましょう
という主旨を理解してもらうようにしています。
モジュラモノリスにおいてトランザクションはどうあるべきなのかについて整理している資料が少ない気付きがあったので「簡易的に」整理しました
すごく強い会社を見てて思うのは「一人当たりの粗利」「人件費」みたいなものに囚われない圧倒的な利益。むしろ全社員遊んでても利益がやってくる文化。そういう所の方がかえって社員が創造的な仕事をやりだして業績が伸びるという。
人件費削減やら一人当たりのパフォーマンスの追求やらやり始めた会社は、余裕を失くし保守的になり、ジリ貧になっていくのはよく見る。
なんかすごい事やってる会社というのは、そもそも「時流に乗ったビジネス」だとか「そう簡単には破綻しない強固な仕組みの上に乗っている」みたいな分厚い地盤があって、それを支える兵隊とその余剰リソースでひたすら研究や開発が行えるから俗に言うイノベーションを起こせるわけで。
今期の売上でアップアップしている会社はそもそもそんな浪費はできないというだけの話である。
ビジネスロジックが全てストアドプロシージャとして実装されていて、テストは実際に動かして確認するしかないが、テストデータは不足しているし、そもそもどうなれば充足したと言えるのか？ を誰も回答できないプロジェクトがあったが、当然の如く大炎上した後、打ち切りになっていた。
セキュリティつよつよ案件で特権ID管理システム使ったら、"ほぼ同時に接続すると他人とセッションが入れ替わる"という不具合に遭遇し問いあわせたら「仕様です」との回答。
富士通の住民票といい、もしかしてジャパニーズトラディショナルカンパニーって排他制御・ユニークIDの概念が無いのでは…？
技術が分かる人間がいない元請け＆技術力は無いが役員同士が仲良しの馴染みの下請けのタッグが仕事をして大変なことになってる事例は多々あるので、本当にそういう事はあるのかもしれない。
LPWA (Low Power Wide Area) の無線通信規格LoRa対応デバイス「Lo-Fi」がKickstarterに登場し、人気を集めている。 photo
Lo-Fiは、Wi-Fi／Bluetooth接続をサポートする無線通信モジュール「ESP32-S3-WROOM-1」とLoRaモジュールを搭載し、最大5km離れたデバイスとの通信が可能なデバイス。Wi-Fi接続により、IoTエコシステムとのシームレスな統合が可能。土壌の水分や温湿度をモニタリングするスマート農業や、空気や水の質、天候を監視する環境モニタリング、ホームオートメーションといったIoTアプリケーションの構築を支援する。
SIer（子請、孫請含む）から、ユーザー企業の情シス部門に転身するのは、いつぞやの人気ルートだった。けど、恐ろしいほどのリテラシーの低さや、事業部門の発言力を目の当たりにして闇堕ちする人が続出したんだよなあ。1年にユーザー側の担当者が4回変わったことがあるよ。表情が暗い人が多かった。
自社サービス提供してる企業に入ってみたらマーケと開発の発言力が圧倒的にマーケに掌握されていて、開発は使い勝手のいい社内下請けになってるってケースもよく見た。
開発も長期的視野を持つことを止めて脳死で目の前のタスクをこなす方が楽みたいなところもあったものだが。
とはいえ、自分自身も会社やプロダクトの未来に全く興味が無いので社内下請けの立場に特に不満は無かった。
エンジニアというものは気に喰わないことがあればスッと別の会社に流れればよいだけなので、企業戦略や組織に一々感情を動かす必要などないのだ。
考えてみればITエンジニアの歴史ってのは、北海道の開拓時代ととても似てる。過酷な作業を乗り越えて今の台地がある。今は素敵な場所だけど、開拓民の血と汗と涙があったから。
1970〜80年代生まれのITエンジニアの先達が「プログラマは所詮賤業。マネジメントこそ至高。お前もプログラミングなんてさっさと卒業してマネージャーになれ」というマネジメント至上主義の風潮に抗って、エンジニア（プログラマ）として価値を出し続けたからこそ、ITエンジニアに人権が付与され、転職市場でも「企業を選ぶ側」に立てるようになった事を忘れてはならない。
勿論、それを可能とする下地（高速ネット回線の普及、PC自体の高性能化、WEBサービスの爆発的普及etc）があったのは事実ではあるけれど。
謎に細かく指定されるエビデンスを誰が見ているか追跡したところ、
という結果を得たことがあった。
Modular社はPythonの高速なスーパーセットだと同社が位置づける新言語「Mojo」を、ローカル環境で実行可能にするコンパイラなどのツール群を公開しました。
Modular社は、コンパイラ基盤として広く使われているLLVM、Swift言語、GoogleがAI処理のために設計したCloud TPUなどの開発に関わってきたChris Lattner氏が共同創業者兼CEOを務める企業です。
その同社が5月に初めてMojoを発表した際に、MojoはAI処理を高速に実行するための言語だと説明しました。
MojoはPythonとの互換性によって既存のTensorFlowやPyTorchなどをそのまま利用可能。
そのうえで、より高速な処理を実現することで、AI処理の開発や実行のコスト削減などを実現するとしました。
へぇー