サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
Switch 2
qiita.com
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? しらせ君 しらせ君は、弊社で働いているアシスタントです。僕の身の回りのいろいろなことをしてくれます。 しらせ君の業務一覧 メールチェック(1時間に1回) 緊急性の高いメールのSlack通知 その他のメールの既読化 ニュース報告 海外のテックニュースの収集 #randomに概要を報告 xに投稿 スケジュール管理 カレンダーの色分け 調整中予定のリマインド 会食予定の妻への通知 郵便物管理 バーチャルオフィスに届いた郵便物の画像を解析して内容を報告 議事録管理 議事録の自動保管、前回議事録のサマリー作成、次回のミーティングで通知 論文管理
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 不確実性の多いソフトウェアプロジェクトでは、単純な「いつ終わる？」ではなく、「どの確率でいつ終わる？」という問いが鍵になります。この記事では、確率分布を用いて納期予測の難しさや不確実性を捉え直し、スコープクリープやベロシティ安定化の重要性を考察します。 また、スクラムのようなフレームワークを採用したチームにおいて、モンテカルロシミュレーションを用いて終了確率を予想するWeb上で使えるツールを開発し、誰もが使える形で公開しました。 これらを用いて、単なる点の見積もりから一歩進んだ、現実的かつリスクを見据えたビジネス上のコミュニケ
qiita.com/hirokidaichi
はじめに ChatGPT APIが出たので早速さわってみました。せっかくなので何か便利なものをということで自分向けに使えそうなツールをつくっていたら 良いかんじに動作したのでご紹介します。 つくったものは、「ChatGPTを用いた自然言語によるシェルコマンドランチャー」です。百聞は一見にしかずと言うことでまずは動作するところをみてください。 概要 wannaコマンドは、ChatGPTを用いた自然言語によるシェルコマンドランチャーです。自然言語によって、bash scriptを生成し、名付けし、管理できます。 コマンドライン上での操作は簡単に多くのことを行うことができるため、非常に便利です。しかし、多くのコマンドやオプションの組み合わせを覚えておくのは熟練したプログラマでもむずかしく、Google検索やmanコマンドなどを駆使して思い出しながら実行することも多くあるでしょう。 たとえば、「こ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 事業としてソフトウェア開発を行う企業にとって、自分たちの開発チームの生産性が十分に高いのか、あるいはそうでないのかについては大きな関心があります。 そのこと自体は、何かを計測し、改善するというのは営利企業としては健全です。一方で、ソフトウェアエンジニアリングの世界で「生産性の高さ」だと主張できる汎用性の高い指標は存在しません。こういった状況の中で、「生産性」を巡る議論は経営やビジネス部門とエンジニアチームとの間で繰り広げられ、場合によっては大きな不和や不信感につながることも珍しいことではありません。 今回は、エンジニアの開発生
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #はじめに 前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。 今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。 そして、組織における効率
はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回：技術的負債はなぜ生じるか。 第2回：ソフトウエア開発を「制御」する意外な処方箋 第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。 第1回：技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債（あるいはレガシーシステム）はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
はじめに マイクロサービスアーキテクチャは、独立してデプロイ可能で疎結合サブシステム群によってサービス開発を行うというアーキテクチャパターンです。現在のソフトウェアサービス開発では欠かすことができない考え方です。 従来では一定のコストが掛かり、またパフォーマンス上の問題もあったため、必要に応じての分割には難しい側面も多かったのですが、様々なエコシステムの発達によってわずかな機会費用で実現できるようになってきました。もちろん分散システムとしての本質的な難しさやアーキテクチャの移行の本質的な難しさは解決したわけではありませんが、手軽にコンテナレベルで分割された様々なサービスを作成することのコストは急速に下がってきました。 これらが、うまくサブドメイン境界によって分割されることで、ある開発チームが知らなければならない情報が制限されるため、スピード感のある開発力を維持しながら開発組織のスケールでき
はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマ
はじめに ソフトウェア開発のチームの生産性や健全性というものは、内部の体感的として理解できるものの、外部の人間からは見えにくいものです。こういった情報の非対称性は開発チーム外の人々との関係の中での問題の原因になってきました。 また、複数の開発チームやプロダクトを束ねるEM、CTOや、管理職にとってそれぞれの状況を客観的な数字やグラフで可視化することは、全体的な戦略を考える上でも重要な参考情報になります。ですが、アンケートやプロジェクト管理を増やすほど、どんどんと開発メンバーに負担をかけてしまうことになり、計測のし過ぎによる疲れなども誘発してしまいます。 本稿では、gitリポジトリのログ情報から、いくつかのグラフを生成し、チームの状況を可視化するためのツールgilotを作成したので、その目的と意図、そして使い方、注意点を解説します。 アプローチ方法 gilotのアプローチは、git logの
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40k
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに ソフトウェアと組織経営をめぐる問題で避けては通れないのが、「技術的負債」と言う言葉です。一般には、「早さ」を求めて構築されたシステムの構造的な課題が、徐々に蓄積し、債務であるように徐々に開発速度そのものを遅くして行くと言う現象のことを意味しているように捉えられます。 これは、技術組織を持つ経営者や、ソフトウェアエンジニアではない発注者にとっては理解しにくいものです。またソフトウェアエンジニアであっても「古くなってしまったコード」や「わかりにくコード」全般のことを技術的負債と呼び、それをもって何かを説明したかのように考えてしまう
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされ
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
はじめに ソフトウェアエンジニアリングマネージャ（以下、EM）に求められる責務は、多岐にわたっています。 流動性が高いITの業態である一方、日本型メンバーシップ雇用と米国型のJD型雇用との隙間にあって、責務と権限の曖昧な状況の中に置かれることも少なくないように思われます。 このような状況下で、メンバーからも経営からも双方にそれぞれの考える理想的なマネージャであることを求められることもしばしばあるようです。結果として、マネージャの休職など精神的なストレスも高さが問題になっています。 また、ソフトウェアエンジニアにとって、プログラミングにおけるスキルとくらべ、マネジメントに対するそれのモビリティ（会社を変えても有効であると思える程度）が低く見えると言ったことから、ソフトウェアエンジニアにとってキャリア形成に効きづらいのではないかと考えてしまうことも自然なことです。 その結果、ソフトウェアエンジ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こちらの記事は、技術評論社に寄稿させていただいた「エンジニアリング組織論への招待」をご紹介するための文章です。Qiitaにも再掲しておきます。 アジャイルって何だ？ 「ウォーターフォールよりもアジャイルのほうがいいのか？」そんな言葉をIT企業の経営者から聞くことがあります。2000年代の後半くらいから、日本国内においてもアジャイル型の開発プロセスが注目を浴びて、多くの企業が実践するようになりました。 ところが、世界各国に比べて日本のアジャイル型開発の普及率は依然として低く、理解度も進んでいません。流行っているからやってみようと
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。 はじめに 拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。 この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。 しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明
権力格差が大きい国の文化圏では、権威勾配が大きくなります。また、個人主義であるほど自己主張がしやすくなるため、意見が生まれやすくなります。男性主義的であると、女性から男性への意見をしづらいと感じる社会であることを意味しています。また、不確実性忌避の傾向が高い国では新しいことや常識の外にあることを受容する力が弱くなり権威勾配が大きくなる傾向があります。 文化的権力格差 Q. あなたの職場では職位を尊称として使うか？たとえば、「〜〜部長」「〜〜課長」など。年少の同僚を「〜〜くん」や呼び捨てするなどの傾向はあるか？ Q. あなたの職場では上長の発言に疑義があっても明確な理由がなければ、反論すべきでないという風土があるか？ Q. あなたの職場では年齢が若い人は年齢が上の人の意見に反論すべきでないという風土があるか？ 年齢や権威に対してものが言えなくなる文化が強い場合、実際の職位の乖離を大きな権威勾
はじめに 本稿は、拙書のエンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリングに関する参考となる書籍を企画意図とともにあげていく試みです。できる限り、専門書ではなく平易な文体の書籍を参考としてあげていきますので、このあたりを深掘りしたいなと思ったら、その箇所のみの参考書籍を併読していただけるとより理解が深まると思います。 Chapter 1 思考のリファクタリング 第１章は、「仕事」と「学力テスト」という２つの違いを論じながら、１６世紀から２０世紀初頭にいたるまでの科学哲学の歴史を辿っていくというのが「裏テーマ」となっています。そこから、「知識を得る」とは何かということを浮き彫りにし、それこそが<エンジニアリング>であると論じるということが本書を通じた論理展開の骨子です。 そのため、直接の参照ではありませんが、科学という概念が西洋社会でどのように生まれてきたのかとい
デリゲーションポーカーを作った プランニングポーカーみたいに権限委譲を促進するカードゲーム、「デリゲーションポーカー」をいきおいでつくった。さらにLINEスタンプも作った。 カードゲーム販売ページ LINEスタンプ販売ページ デリゲーションポーカーの元ネタはこちら参照 権限と責任の話 経営者マインドが足りない！の欺瞞 よくネットで炎上しがちなひとが「経営者マインドが従業員に足りない！」というようなアメリカ人には大和魂がない！的なそりゃそうだろとしか言いようのない言説を口にします。 この表現はさておき、このような言説を口にしてしまう背景には何があるでしょうか。このような人はきっと自分の会社の従業員にもっといろんなことを任せていきたいと思っているのでしょう。 ところが、そのような期待値をしっかりと部下に対して伝えることができていないため、メンバーも自分自身の成長のタネがどこにあるかわからずに、
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 本記事では、そのなかで触れている二人の人物がパーティのためにカレーを作るという話を紹介します。きっとどこかで見たこ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #はじめに 最近は年を取ってきたのか、様々な人にマネジメントの考え方やソフトウェアアーキテクチャの設計についてのメンターリングをすることが多いのですが、その時に必要なのはやはり説得力です。僕は基本的には欲望に弱い人間なので、すぐに欲望のままに行動します。それは主に知識欲と食欲です。そのため、２０歳からどんどんと太っていき、才能がないと突破できないとされる１００kgの壁も悠々と突破するような人間ができあがりました。 すると不思議なもので、声が聞こえてくるのです。 「こいつ、マネジメントとかいってるけど、セルフマネジメントできておらんやんけ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未
「わかった？」は意味のない言葉 似たようなことでいうと、メンターは何かを教えた後に「わかった？」と確認してしまうことがあります。このとき、メンティが「わかりました」と答えたとして、何か意味があるでしょうか。先ほどの「心構え」と同様に確認しても観測できないことを問いかけている状態になってしまいます。 そうではなく、具体的に「今言ったことを、ひとりで試しにやってみて」とか「以下の話を図に書き起こしてみて」とかアウトプットを要求しない限り、わかったかどうかなんてわかりません。 学生時代に私は塾講師をしていたのですが、課題のプリントを生徒たちに渡して、「わからなかったら手を上げて」と言ってたのですが、そのときは誰も手を上げられなかったという体験があります。そのあと、どうしたらいいんだろうかと考え、「問題を解く手が止まったら手を上げて」と伝えるようにすると、手を上げてくれる生徒が現れました。 抽象的
次のページ
このページを最初にブックマークしてみませんか？
『@hirokidaichiのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
