技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も
"技術的負債"論の道案内 - アーキテクチャの資本コストと情報の非対称性 - Qiita
はじめに ソフトウェアと組織経営をめぐる問題で避けては通れないのが、「技術的負債」と言う言葉です。一般には、「早さ」を求めて構築されたシステムの構造的な課題が、徐々に蓄積し、債務であるように徐々に開発速度そのものを遅くして行くと言う現象のことを意味しているように捉えられます。 これは、技術組織を持つ経営者や、ソフトウェアエンジニアではない発注者にとっては理解しにくいものです。またソフトウェアエンジニアであっても「古くなってしまったコード」や「わかりにくコード」全般のことを技術的負債と呼び、それをもって何かを説明したかのように考えてしまうことはままあります。 これらに起因して、双方のコミュニケーションが破綻してしまうこともよく見られる景色です。 技術的負債の経済効果は毎年マイナス12兆円 このような構造的な問題をはらむ技術的負債は、老朽化したレガシーなシステムとして、事業の組織改革を遅らせて
半年で40kg痩せた！ダイエットでわかるリーンなプロジェクトマネジメント手法 - Qiita
はじめに 最近は年を取ってきたのか、様々な人にマネジメントの考え方やソフトウェアアーキテクチャの設計についてのメンターリングをすることが多いのですが、その時に必要なのはやはり説得力です。僕は基本的には欲望に弱い人間なので、すぐに欲望のままに行動します。それは主に知識欲と食欲です。そのため、２０歳からどんどんと太っていき、才能がないと突破できないとされる１００kgの壁も悠々と突破するような人間ができあがりました。 すると不思議なもので、声が聞こえてくるのです。 「こいつ、マネジメントとかいってるけど、セルフマネジメントできておらんやんけ」 これは全くの幻聴なのですが、そういった幻聴を聴くくらいには心に内臓脂肪が溜まってきていました。 そんなタイミングと「胃痛を空腹と勘違いし回鍋肉を食べた結果、胃痛が加速する」という経験を経て、ちょっくらダイエットでもして見るかと考えるようになりました。 さて
エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた！ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン（あるいは権威勾配に関する一考察） 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生
日本にアジャイルが普及しづらい本当の理由〜不確実性に向き合うマネジメント論〜 - Qiita
はじめに こちらの記事は、技術評論社に寄稿させていただいた「エンジニアリング組織論への招待」をご紹介するための文章です。Qiitaにも再掲しておきます。 アジャイルって何だ？ 「ウォーターフォールよりもアジャイルのほうがいいのか？」そんな言葉をIT企業の経営者から聞くことがあります。2000年代の後半くらいから、日本国内においてもアジャイル型の開発プロセスが注目を浴びて、多くの企業が実践するようになりました。 ところが、世界各国に比べて日本のアジャイル型開発の普及率は依然として低く、理解度も進んでいません。流行っているからやってみようと始めた企業も流行りが変わると今度はリーンだとか、今度は○○だといったように新しい方式を導入してみては失敗するところも珍しくありません。 アジャイル開発の専門家ですと名乗る人の話を聞いてみても、それが何なのか、けむにまかれたような説明をされてしまい、いまいち納
心理的安全性ガイドライン（あるいは権威勾配に関する一考察） - Qiita
はじめに 「心理的安全性」とは、「対人リスクを取っても問題ないという信念がチームで共有されている状態」であるとか、「自分のキャリアやステータス、セルフイメージにネガティブな影響を与える恐れのなく、自分を表現し働くことができること」というような定義がなされています。 心理的安全性という言葉はともすれば、ただ快適で居心地のよい職場という意味にも聞こえます。そのため、ぬるま湯で緊張感のない関係性のことを「心理的安全性が高い」と言うのではないかと考えても不思議はありません。 そのため、友人関係のようにプライベートの時間を長く共有する関係になることが、心理的安全性が高いのだろうと考え、飲み会やバーベキュー、慰安旅行などを企画してみたりとプライベートでも遊ぶ機会を増やそうと考える人もいるでしょう。 いわゆる「アットホームな会社です」とアルバイトの求人記事に書かれているような状態です。こういった求人内容
経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 - Qiita
デリゲーションポーカーを作った プランニングポーカーみたいに権限委譲を促進するカードゲーム、「デリゲーションポーカー」をいきおいでつくった。さらにLINEスタンプも作った。 カードゲーム販売ページ LINEスタンプ販売ページ デリゲーションポーカーの元ネタはこちら参照 権限と責任の話 経営者マインドが足りない！の欺瞞 よくネットで炎上しがちなひとが「経営者マインドが従業員に足りない！」というようなアメリカ人には大和魂がない！的なそりゃそうだろとしか言いようのない言説を口にします。 この表現はさておき、このような言説を口にしてしまう背景には何があるでしょうか。このような人はきっと自分の会社の従業員にもっといろんなことを任せていきたいと思っているのでしょう。 ところが、そのような期待値をしっかりと部下に対して伝えることができていないため、メンバーも自分自身の成長のタネがどこにあるかわからずに、
コミュニケーション能力の正体と「カレー作りの寓話」 - Qiita
はじめに Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 本記事では、そのなかで触れている二人の人物がパーティのためにカレーを作るという話を紹介します。きっとどこかで見たことのあるコミュニケーションが繰り広げられていると思います。このカレー作りの寓話から、コミュニケーション能力の正体に迫っていきましょう。 パーティに来るみんなのためにカレーを作りましょう。そう言って、ボブとエバは2人でカレーを作り始めた。 ボブは、どんなカレー
新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 最近、メンター制度として新入社員や若手のメンバーに対して、先輩をつけて相談事に乗ってあげたり、仕事のサポートをしたりといったような教育プログラムを組む企業が増えています。このメンターという役割は、ちょっとした訓練が必要だったりするのですが、このあたりの研修や訓練をせずにいきなり明日からメンターね！なんてことがままあります。
[翻訳]なんでGoってみんなに嫌われてるの？ - Qiita
原文：http://npf.io/2014/10/why-everyone-hates-go/ 酔っぱらった勢いで訳出してるので、違ってたら修正リクエストください。 訳者の１行でわかるサマリ それって、Goのシンプルな言語哲学が、ML系言語好きのアイデンティティを挑発しちゃってるからじゃないの？ いや、実際みんなって訳じゃないんだろうけど。最近、なんてGoをみんなそんなに批判的なのかって言うquoraの質問が出たもんで。（わるい、普段はquoraへのリンクを張らないんだけど、それがこの記事のきっかけだからね。）この質問への回答を見るまえにもう、僕には、次みたいなことが書かれていることがわかってた： Goは70年代に立ち往生した言語だ Goは40年間に及ぶプログラミング言語研究の成果を無視してる Goはブルーカラーの凡夫のための言語だ Go使いはJava1.0で仕事しても大丈夫なんだろう。
![[翻訳]なんでGoってみんなに嫌われてるの？ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/290e884f832cc0b4d5652f43acc1c1955770e415/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJUUzJTgxJUFBJUUzJTgyJTkzJUUzJTgxJUE3R28lRTMlODElQTMlRTMlODElQTYlRTMlODElQkYlRTMlODIlOTMlRTMlODElQUElRTMlODElQUIlRTUlQUIlOEMlRTMlODIlOEYlRTMlODIlOEMlRTMlODElQTYlRTMlODIlOEIlRTMlODElQUUlRUYlQkMlOUYmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWJlNDhiNDc2NmJhMDQ5NWJlNmU1YWQyY2M5N2U4OTdl%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBoaXJva2lkYWljaGkmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTZkY2M3ODIzNmM4ZDk1YjM0YzY2YTE3MDNlNjg0NmY5%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-UmVjdG9y%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D44878a8c4d934702b087eca70b3ce537)
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 - Qiita
はじめに もうすっかり年末なので、これから2015年にかけてアプリケーションアーキテクチャがどのようになっていくのかという個人的な考え/妄想や背景について、「リアクティブ」というキーワードをもとににまとめてみたいと思います。 Google Trendsを見ると"reactive programming"という言葉は2010年前後から、ゆっくりとバズをし始め、現在も上昇を続けています。 また、仕事としては、2010年ごろから大規模なWebサービス開発において、フロントエンド、バックエンド、アルゴリズム改善といった様々な箇所で、リアクティブプログラミングの要素を取り入れながら、アーキテクチャの改善を進めてきました。そのため、こういったアーキテクチャがコード品質の維持や安定性の向上、実際的で複雑な問題の解決にも適応可能であるということを実感として持っています。 近年、そういった要素が様々なツール
あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに この記事は数百万行の動的型付き言語のWebアプリケーションのリファクタリング、アプリケーションアーキテクチャの再設計の経験を基に、有効だと思われる考え方やアプローチを抜粋して紹介するものです。言うまでもなくあらゆるコードベース、アーキテクチャにおいて有効なものとは限りませんので、各々の環境や状況から適切に判断してください。
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし
新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 この記事について この記事は、新人向けの研修内容を再編集してお送りします。 この記事の内
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
