ヤフー時代の部下から突然メッセンジャーが。 「以前宮坂さんが緊急対応時に残して頂いた言葉を今度セミナーで使っていいですか?」 と。 リーダーの仕事はいっぱいあるけどなかでも大きな仕事の一つは重大事故の発生の時の陣頭指揮。平時は部下で回せるようにするのがマネジメントだけど、危機の時まで部下にまかせるわけにはいかない。 お恥ずかしながらヤフー在職中の22年で何度か重大事故を起こし関係者の人に多大な迷惑をかけてしまった。その度にその陣頭指揮をとった。 結果的にヤフーのなかでもっとも深刻な事故対策をやった人の一人じゃなかろうか。そのなかからノウハウ的なものがたまってきたものを部下にメモしておくってあげたものを彼は覚えていてくれたらしい。 彼いわく危機対応の時にすっごく役にたって指針になったといってくれて送ってくれた。 ひょっとしたら他の人にも参考になるかとおもって(若干訂正してますが)ここに残して
●相続税申告最新実績件数 22年:1863件 23年:2204件 ●相続ご相談最新件数 24年8月:547件 | 相続に強い税理士・司法書士・行政書士が対応
エンジニアにとって、正解が分かりづらいマネジメント業務ってとっつきづらいんですが、その良き羅針盤となってくれるテキスト「re:Work」の紹介です。 「エンジニア天国な会社にしたい。したくない?」 「したい。けど、どうやって?わっしょい的な雰囲気で?」 今年の6月あたり、クラスメソッドAWS事業本部コンサル部で合宿を予定しているんですが、その合宿でやるネタを考えているときに知ったのが、この「Google re:Work」。 正解が見えづらい組織運営において、「良いチームとはなにか?」「採用で気をつけるべき点」「ビジョンがもたらす効果」など、マネジメントの頻出課題をギュッと凝縮して詰め込んだこのコンテンツがむっちゃ有用だったので、紹介します。 Webコンテンツとして完全無料なので、今マネジメントで悩んでいる人も、これからマネージャー目指そうとしている人にも参考になる点多いと思うので、一度気軽
これはイース通史の中で、イースとは直接的には関わりのないエピソードなのだけど、ハドソンが『イースⅠ・Ⅱ』の許諾を取る上では、大きな問題になった…と思われる『ファザナドゥ』のエピソードだ。 まず『ファザナドゥ』という作品について、簡単に説明しておきたい。 『ファザナドゥ』はファルコムの大傑作ソフト『ザナドゥ』を、ハドソンがファミコン用に移植したゲーム、ということになっている。 「ということになっている」というのは、発売されたゲームが、まるで別物だから。 ここで名誉のために書いておくと『ファザナドゥ』は、まあまあ出来がいいRPG要素の入ったアクションゲームだ(RPG要素の入ったと書いているのは経験値による成長サイクルがないのでCRPGとは呼び難いから)。 ただアイテム名やモンスタ―名、それとも称号に共通しているものがある以外は、何一つ『ザナドゥ』と共通点がなく、「どうして『ザナドゥ』の名前がつ
予想していた技術的な勉強法というより、エンジニア、ビジネスマンとしての生き方や、成功するための方法論を20代に向けてMatzさんが伝えてくれたのでまとめます。(自分なりの解釈も少し入ってます) とてもためになる講演でした。個人的には特に前談2、3、4、5、6がためになりました!! Matzさんありがとうございました! 講演内容 前談1. テクノロジーとは人を幸せにするためのもの 前談2. 若いうちから頑張ろう 1.学生と社会人の"勉強"の違い 2.なぜ勉強するのか? 3.勉強についてのTips(what, where, when, how) 4.とにかくアウトプット 5.成功するためのTips 6.最後に3つのアドバイス ※Ex)で書いている具体例はMatzさんが使われたものをそのまま使ってます。 前談1. テクノロジーとは人を幸せにするためのもの 本来人を幸せにするためのテクノロジーが人
はじめに ソフトウェアエンジニアリングマネージャ(以下、EM)に求められる責務は、多岐にわたっています。 流動性が高いITの業態である一方、日本型メンバーシップ雇用と米国型のJD型雇用との隙間にあって、責務と権限の曖昧な状況の中に置かれることも少なくないように思われます。 このような状況下で、メンバーからも経営からも双方にそれぞれの考える理想的なマネージャであることを求められることもしばしばあるようです。結果として、マネージャの休職など精神的なストレスも高さが問題になっています。 また、ソフトウェアエンジニアにとって、プログラミングにおけるスキルとくらべ、マネジメントに対するそれのモビリティ(会社を変えても有効であると思える程度)が低く見えると言ったことから、ソフトウェアエンジニアにとってキャリア形成に効きづらいのではないかと考えてしまうことも自然なことです。 その結果、ソフトウェアエンジ
.LC0: .string "%d\n" main: push rbp mov rbp, rsp sub rsp, 16 mov DWORD PTR [rbp-4], 1 mov DWORD PTR [rbp-8], 2 mov edx, DWORD PTR [rbp-4] mov eax, DWORD PTR [rbp-8] add eax, edx mov esi, eax mov edi, OFFSET FLAT:.LC0 mov eax, 0 call printf mov eax, 0 leave ret …何が書かれているか分かりませんね。 というわけで、今回は最終的に、このアセンブリがなんとなく読めるようになることを目標にします。 それでは前提知識を説明していきます。はじめに、アセンブリなどの用語の説明をしていきます。 2. 前提知識 用語説明 まず、それぞれの言葉を説明しま
はじめに こちらの記事は、技術評論社に寄稿させていただいた「エンジニアリング組織論への招待」をご紹介するための文章です。Qiitaにも再掲しておきます。 アジャイルって何だ? 「ウォーターフォールよりもアジャイルのほうがいいのか?」そんな言葉をIT企業の経営者から聞くことがあります。2000年代の後半くらいから、日本国内においてもアジャイル型の開発プロセスが注目を浴びて、多くの企業が実践するようになりました。 ところが、世界各国に比べて日本のアジャイル型開発の普及率は依然として低く、理解度も進んでいません。流行っているからやってみようと始めた企業も流行りが変わると今度はリーンだとか、今度は○○だといったように新しい方式を導入してみては失敗するところも珍しくありません。 アジャイル開発の専門家ですと名乗る人の話を聞いてみても、それが何なのか、けむにまかれたような説明をされてしまい、いまいち納
AWS サポートでは、お客様の課題の解決を効率的かつ迅速に行いたいと常に考えています。本ページでは、お客様が技術的なご質問をサポートケースに起票いただく際に、早期解決に役立つポイントをまとめました。例文も掲載していますのでぜひご参照ください。 なお、サポート全般についての一般的な情報は、AWS サポートをご参照ください。 サポートレベル毎の技術サポートへのアクセスについては、AWS サポートのプラン比較をご参照ください。 基本情報の入力について サービス/カテゴリー お問い合わせ内容に最も近い項目をご選択いただくことで、適切な回答が早期に得られる可能性が高まります。 お問い合わせ言語 日本語を選択します。英語での技術支援をご希望の場合には English を選択します。 連絡方法 多くの場合、Web を推奨します。連絡方法の詳細については、連絡方法(Web、電話、Chat)の選択についてを
【連載】TVアニメ『ゾンビランドサガ』本渡楓×田野アサミ×種田梨沙×河瀬茉希×衣川里佳×田中美海 座談会|最終回後だからこそ語れる作品へのアツい想い【SAGA:12】 さくらの復活とフランシュシュの熱い絆に感動しつつ、最後の最後でまた伏線を張って思わせぶりに終わった『ゾンビランドサガ』。インタビュー連載の最後も、前回に続き、源 さくら役の本渡 楓さん、二階堂サキ役の田野アサミさん、水野 愛役の種田梨沙さん、紺野純子役の河瀬茉希さん、ゆうぎり役の衣川里佳さん、星川リリィ役の田中美海さんのフランシュシュメンバー6人です。 最終回にひと言申したいと熱っぽく語り合う中で、キャラと作品への愛があふれまくりの座談会をご覧ください。 ※※※第12話のネタバレを含んでいます。本編視聴後にご覧いただくことをお勧めします※※※ <連載バックナンバー> □【SAGA:00】宮野真守×本渡 楓 □【SAGA:01
いわゆる退職エントリ。興味のない人は閉じるボタンを。 11月末で日本経済新聞社を退職した。2年8ヶ月という短い期間だったが、素晴らしい経験をさせてもらった。 やっていたこと 日経に入社して、日経電子版のwebを新しくモダンなアーキテクチャで作り直すプロジェクトの立ち上げから参画した。これは現在r.nikkei.comというドメインから配信されている。 r.nikkei.com 結局退職までこのプロジェクトがメインの仕事になったわけだが、最後まで全く飽きることはなかった。技術的な面で飽きずに働けるということはエンジニアにとって簡単なようでいて難しいことで、それができたのは最初のアーキテクチャの設計が優れていたこと、特定のフレームワークやライブラリに過度にロックインさせないポリシー、新しい取り組みにどんどん挑戦していけるカルチャーや環境(これは単純に人手不足という話もあるかもしれない)があって
アクシアでは2012年の9月で残業をやめました。2012年の10月からはずっと残業ゼロです。もともと残業まみれの超絶ブラック企業でしたので、残業をやっていた頃となくしてからは、全く別の会社に生まれ変わりました。 先日こんなブログを読みました。 「残業しないで定時帰り」を23ヶ月間続けた記録【人生を取り戻す】 私のように経営者として会社の残業をゼロにしたのではなく、従業員の立場としてご自分の残業をなくした方がその経験を書かれた記事で、大変興味深い内容でした。残業のある会社で「残業はやらない」と決意し、それを実行することはとても大変なことだったと思います。 上記は従業員の立場として残業をやめた記録を綴ったブログ記事ですが、このブログ記事に倣って、経営者の立場として会社の残業をゼロにした記録を本日の記事に書いてみたいと思います。 なぜ残業をゼロにしたのか なぜ残業まみれだった会社の残業を突然ゼロ
はじめに 学校で習わないが(習う学校もある)、現実に必要になるプログラミング技術に、低レイヤプログラミングなどと呼ばれるものがある 厳密な定義は聞いたことがないし、おそらく存在しないとは思うが、大体のみんなの共通認識として、 「高級プログラミング言語を使わないプログラムを書き、OSで抽象化されないデバイスの機能を使う」といったような認識があると思う。 筆者の経験から言わせてもらうならば、低レイヤプログラミングに関する知識は、プログラミングにおいてあらゆる場面で、常に、少しずつ役立てられる知識だと言えると思う。 普段はRubyやPHPなどを書いてる人であったとしても、メモリが足りなくなった場合や、デバッガを使っている場合、性能が足りなくなった場合など、 厳しい環境におかれた時に低レイヤプログラミングに関する知識が必ず役に立つ場面が来ると信じている。 また、役に立つかどうかは置いておいても、「
はじめに この記事は、Why Every Software Engineer Should Write Articlesを翻訳したものです。今まで、記事やブログを書くことに時間を使うことに懐疑的だったのですが、この記事を読んで腑に落ちるものがありました。 アウトプットしたほうがいいのは分かっているけど、めんどくさい、時間が勿体無いなどと思っている方にはぜひ読んでもらいたい記事です。 英語を日本語に直訳すると不自然で読みにくくなるため、主張を壊さないことを前提に意訳します。ミス等あれば指摘ください。 なぜ全てのエンジニアが記事を書くべきなのか? 近頃、コンピュータサイエンス産業は複雑かつ急速に進化しており、複雑な技術やコンセプトを簡単な方法で説明するという事がより重要になってきている。 ブロックチェーン・機械学習・深層学習・データサイエンス・分散システム・量子コンピューティング・ビッグデータ
当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。 9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。もちろんないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。 1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。 その中で、日本ディジタルイクイップメント(DEC
なんかこのブログに記事書くの、ほんと久々だなと思うんですが。 最近ずっと思ってたことがあったので、つい勢いで書きなぐってしまいました。若干炎上商法かもしれませんが、まぁたまには?いいや。 長文ですがお付き合いください。特に、ソフトウェア工学の研究している皆さん。 昨日、とあるソフトウェア工学のシンポジウムにて、機械学習モデルをWebサービスにデプロイするためのハンズオン、という企画がありました。 僕が運営委員やってるMLSEとの共同企画で、僕は発案者の1人ですが、当日は1人の参加者として中に混じっていました。 4人グループに分かれての作業だったんですけども、僕以外の3人は、いずれもソフトウェア工学の研究をしている修士の学生さんでした。 で、ハンズオンも後半になって「Dockerの使い方」の演習になったのですが、その3人ともDockerに触ったことがなさそうな雰囲気でした。いちいち確認したわ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く