[出典] プログラマが知るべき97のこと 当サイトはオライリー・ジャパンによる公式なサイトではありません。 個々のエッセイは「CC-by-3.0-US」によってライセンスされています。
誰かから方針を共有された時、なんだか納得できなくてモヤッとすることがある。そういう時に共有した側もされた側も不幸にならないためのお作法的な動き方があると思っていて、雑にまとめておきたい。 1. 初手でファイティングポーズを取らない 納得できないこと ≒ 背景がわからないことに対する不快感はすごくて、つい"強い"言葉を使ってしまいがち 相手も人間なので、そういった態度や口調は鏡のように反射してくる。そうすると物事を前に進めにくくなってしまう 一見して不合理な方針だと感じたとしても、その裏にはそれなりに込み入った背景がありタフな議論が積み重ねられていることも多い まずは深呼吸して初手でファイティングポーズを取りそうになるのを抑えて、「取りまとめありがとう」って感じで相手へのリスペクトを示すとよい 2. 何に納得できないか深掘りする 納得できない時、意外と自分でも何が問題なのかはっきりとわかって
前職を辞めるタイミングで、それまで個人事業主として細々と引き受けていた仕事(技術広報のメンタリングや顧問業)をまとめて会社を作ろうとしたらタイトルの通りだったよという話をします。 freee会社設立はいいぞ 基本的にはこれに登録して、この通りにやっていくと会社ができる。 (厳密には登記後に登記簿と印鑑証明関連で所轄の税務署へ行く必要はある) このfreee会社設立は本当にすごくて、全て無料で使えてfreeeに詳しい税理士を紹介までしてくれる。 流れとしては、サービスに登録するとすぐに電話がかかってきて面談日の設定がされる。初回の面談では、会社を作る背景やなにをしたいかをユーザー(自分)から説明、freeeの方から今後の手順を説明され、不明点に答えてくれるという超手厚いもの。 基本的にはサイトにあるものの情報を集めたり決めたりして、手順どおりにポチポチ進めていくと会社が出来る。不思議だ。すご
自然科学研究機構 核融合科学研究所 教授の高畑一也氏が、核融合発電の基礎知識について解説する本連載。第2回では、核融合炉/発電の基本的な仕組み、核融合炉に使われる主要装置について解説します。 連載の第1回では、地上で実現可能な核融合反応を提示し、この反応を実現するための条件、核融合発電の優位性と安全性について解説しました。今回は、実際の核融合炉(核融合反応を起こす場所)と発電の仕組みを解説します。核融合にはいくつかのアプローチがありますが、今回は磁場閉じ込め方式、そして第1世代といわれる重水素-三重水素(D-T)反応炉に話を絞ります。その他のアプローチについては、連載第3回で触れたいと思います。 超高温プラズマを閉じ込める磁場の容器 そもそも核融合炉で作られる1億℃の水素ガス(プラズマ)を金属の容器で閉じ込めることはできません。1億℃に耐えられる金属がないのは確かですが、それより数グラム(
はじめに「マネージャーは尊敬される人柄じゃないと無理ですよね」 「マネージャーは対人感受性がないと」 「そもそも、人として向き不向きがあるよね」 経営者の方と議論していると、マネージャーを誰にしようかと悩む時、あるいは自社のマネージャーについてコメントをする時、こういうご意見はよく伺います。 これらの問いに対して私の答えは「No」です。 マネジメントはフローもやり方もはっきりと言語化できる"業務"であり、そこにはマニュアルが存在します。訓練すれば誰でも一定程度のレベルで実行可能なものだと考えます。 今回は私が代表を務める会社、EVeMが提唱するマネジメント”業務”の実行方法「THE MANAGEMENT PATTERN」と、それを実行可能にする訓練方法について書きたいと思います。 マネジメントは"業務"であるドラッカーの言葉に「仕事を生産的なものにし、人間を活かすことが、マネジメントの役割
はじめに ソースコードをLLMに読んでもらうとき、単一ファイルだと楽なのですが、GitHubのリポジトリのように複数ファイルから構成されるプロジェクトだと困ってしまいますね。 リポジトリごとLLMに読んでもらえるようにいい感じにテキスト化できると良いですね。そんなソフトがありました。しかも2つ。 両方ともほとんどコンセプトは同じです。特に後者のgenerate-project-summaryは使い方も含めて、自分のやりたいことが、すでに開発者の清水れみおさんが以下の記事にまとめていました。 なので、あんまり書く必要ないのですが、せっかくなのでgpt-repository-loaderの使い方と、出力したファイルの別の活用方法について書いてみたいと思います。 gpt-repository-loaderでリポジトリをテキストに変換 使い方はREADMEに書いてあります。シンプルなソフトなので、
私の愛しいアップルパイへ 8月16日(金)、このTCP/IP網の片隅に新規サービスを産み落としました。「TaskChute Cloud 2」っていいます。 頑張って作ったトップページ去年の8月から本格的に作り始めて、1年間でようやく形になりました。これこそ"俺が考える最強のタスク管理・時間管理サービス"って感じです。 正直タスク管理サービスって有名どころは出尽くしてる感じですし、「いまさらー?」って感じだと思います。この手のサービスは西海岸からいくつも出てますし。 でも、今までの発想のタスク管理サービスって使いづらくないですか?もう実際の仕事に通用しなくないですか?って気持ちもあって、ちょっと違ったアプローチのサービスをガチで作ってみました。 そこそこ借金して1年かけて作りました小学生時代からの友人と作った役員2人だけの極東の極小の会社なんですけど、コロナとか異常な円安とかの影響もあって経
時間がない!!マネージャーの皆さん、マネージャーではないけれども割り込みタスクに忙殺されているみなさん、おはようございます。 先日、友人と会話しているときに「いつもレスが速いけど、どうやって処理してるのか」と聞かれました。何って…ただ目の前にきた問い合わせを素早く処理してるだけだが?と思いつつ会話を進めていくと、ああ自分がやっているタスクのさばき方は一つの技術なのかもしれない、と思い至ったので書き記しておきます。なお、基本的にはGTDの考え方でやってます。 前提:人間はシングルコアであるまず前提として、人間はシングルコアです。同時に二つ以上のことはできません。(じゃあギターボーカルはどうなるんだとかそういう話は今回のスコープじゃないので置いておきます。) では、シングルコアしかない人間は、どうやって割り込みタスクに対処すればよいのか。 簡単に捌けるもの(自分が知っていることに関する質問)で
生命の起源と人工生命の研究分野は、生命の本質とその発生過程を探求している。両分野とも、「非生命」の状態から「生命」がどのように生まれるかを問うている。生命が出現するほとんどの基質に共通する特徴の一つは、自己複製が始まると同時に、その系の動態が大きく変化することである。 しかし、自然界で自己複製体がどのように発生したかについていくつかの仮説はあるものの、自己複製体が出現するための必要条件については、まだほとんど解明されていない。 研究チームは、単純なプログラミング言語や命令セットを用いて、計算環境における自己複製能力を持つプログラム(自己複製プログラム)が自然発生する過程を詳細に観察し分析した。この研究の中心となったのは、「Brainfuck」(BF)という極めて単純な言語を拡張した「Brainfuck Family」(BFF)と呼ばれる言語環境である。BFFでは、64バイトの長さを持つ13
部下育成、トラブル対応、ハラスメント対策…近年は管理職の業務負担が増大し、「罰ゲーム化」の状況が深刻化しています。そこで今回は、『チームレジリエンス 困難と不確実性に強いチームのつくり方』著者の池田めぐみ氏に、管理職の負担を軽減しつつ、成果も上がる組織づくりの秘訣をお聞きしました。本記事では仕事を適切に任せる方法や、「マネージャー任せ」のメンバーの意識を変えるコツについてお伝えします。 部下育成、トラブル対応、ハラスメント対策…増える管理職の業務負担 ——ここ数年、「管理職の罰ゲーム化」といった話がよく聞かれるようになっていると思います。部下のマネジメントや後任者の育成、トラブル対応に加え、リスキリングやハラスメント対策など、管理職の業務負担が増大している現状が問題視されています。池田さんはこうした現状についてはどのような課題があるとお思いでしょうか。 池田めぐみ氏(以下、池田):私自身も
Amazon Web Services ブログ AWS Summit Japan 生成 AI で技能伝承!プロセス製造業デモのご紹介 こんにちは、元メーカー出身の Prototyping Engineer の鈴木です。 このページを開いていただいたみなさんは、きっと何らかの形で製造業に携わっていらっしゃると思います。ものづくり白書2023では、技能伝承に課題があることについて触れられていますが、みなさんの周りではいかがでしょうか。生成 AI はこの大きな課題を解決する可能性を秘めています。 この記事では、 AWS Summit Japan の製造業ブース内で展示される、プロセス製造業向け生成 AI のデモについてご紹介します。このデモはプロセス製造業を想定していますが、技能伝承は業態を問わない共通の課題のため、ぜひ多くの製造業に携わる方にこの記事を読んでいただき、また実際に AWS Sum
ソフトウェアは複雑さを増すばかりですが、人間の脳は限られた複雑さしか扱えません。ソフトウェアが思い通りに動くようするには、脳に収まり、人間が理解できるコードを書く必要があります。 本書は、拡張を続けても行き詰ることなくコードを書き、複雑さを回避するための実践的な方法を解説します。最初のコードを書き始めるところから機能を追加していくところまでを解説し、効率的で持続可能なペースを保ちながら、横断的な問題への対処やトラブルシューティング、最適化を行なう方法を説明します。自分のチェックリストからチームワーク、カプセル化から分解、API設計から単体テストまで、ソフトウエア開発の重要な課題に対する考え方やテクニックを紹介します。サンプルプロジェクトで使うコードは、Gitリポジトリの形で入手でき、試しながら学べます。 有効に機能するプロセスを選び、効果のない方法論から脱却する方法。チェックリストを使うこ
1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが
はじめに ※ (2024/03/14 16:33) 「インテグレーションテストの気軽な実行・変更ができない」節にて、データのクリーンアップを teardownで行うよう修正 EC開発-B グループの岡崎と EC開発-A グループの菊川です。2人とも普段は MonotaRO の EC サイトの開発に従事しています。 今回は、昨年11月に開催した、テストとリファクタリングのためのワークショップの中で行ったライブコーディングの準備をするにあたって困ったことについて記載します。 ライブコーディングでは、参加者全員の前で実際のプロダクトのソースコードをリファクタリングする、ということにし、それにあたって研修の運営メンバーでリファクタリングに取り組んでみました。ただ闇雲にリファクタリングするのではなく、研修では参加者に「どのような流れや考え方でリファクタリングをするか」を理解してもらえるように、運営メ
IDE大学協会の機関誌『IDE 現代の高等教育』が、2024年1月号において「危機を好機に」という特集を組みました。そこに私が『大学と日本の危機-再考』と題した記事を寄稿したところそれなりの反響を得たので、同協会の許可を得て、以下に記事を再掲します。以下の見出しの1と2がIDEに掲載した原文で、今回の塾長室だよりでは、さらに3と4を書き足しました。 『大学と日本の危機-再考』 1. ウサギとカメ イソップ童話の『ウサギとカメ』では、本来はウサギが速いのだが、油断や昼寝をしてしまい、結果的に地道に着実に休まずに進んだカメに負ける。ここで私たちは「カメのように真面目に進めばよいことがある」と教えられた。ところがものは捉え方である。米ディズニーのアニメでも同様に『ウサギとカメ』の話を取り上げ、それを観た米国の子供たちは「このウサギのように怠けると、本来負けるはずのないカメに負ける」と教えられたと
本来は親友に向けたマンションリフォームのアドバイスだが、LINEで送るには長すぎるので、増田の日記として公にさらしてみる。ブコメやトラバで有用な反論が得られるかもしれない。 祝1000user超え。いろんな意見が聞けて楽しい。おそうじ浴槽がみんなに届いてうれしい。 祝2000user超え。自分の知識がみんなの役に立ったようでうれしい。はてブ愛してる。 増田は建築士としてそれなりに経験値はあるが、住まいのあり方や価値観は本当に多様なので、N=1の意見として参照するぐらいがちょうどよい。 大前提適切な断熱壁と二重ガラス樹脂サッシが装備されていること。それがない建築が許されるのは安藤忠雄だけ。 既存のサッシが交換できないならインプラスなどの内窓をいれればよし。 風呂編おそうじ浴槽!これが言いたくてこの長い日記を書いているといっても過言ではない。 google:image:おそうじ浴槽 他の設備投
ITエンジニアが投票した「ITエンジニア本大賞2024」発表。単体テストの考え方/プログラマー脳/ プロジェクトマネジメントの基本が全部わかる、など 「ITエンジニア本大賞」は、仕事の役に立った本、初学者におすすめの本、ずっと手元に置いておきたい本など、おすすめの本をITエンジニアがWeb投票で選ぶイベントです。 主催は翔泳社ですが、対象となる書籍は出版社を問わず技術書、ビジネス書全般となっています。刊行年も関係なく、これまで大賞に選出された書籍を除き、この1年を振り返っておすすめしたい書籍が対象となります。 今回発表されたのは技術書部門とビジネス書部門それぞれのベスト10です。現時点では50音順に並んでいます。 以下は選出された技術書部門とビジネス書部門それぞれのベスト10を、Amazon.co.jpへのリンクと画像、概要で紹介したものです(アフィリエイトリンクは含まれていません)。正式
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く