タグ

ブックマーク / qiita.com/hirokidaichi (14)

  • なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita

    はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な

    なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
  • "技術的負債"論の道案内 - アーキテクチャの資本コストと情報の非対称性 - Qiita

    はじめに ソフトウェアと組織経営をめぐる問題で避けては通れないのが、「技術的負債」と言う言葉です。一般には、「早さ」を求めて構築されたシステムの構造的な課題が、徐々に蓄積し、債務であるように徐々に開発速度そのものを遅くして行くと言う現象のことを意味しているように捉えられます。 これは、技術組織を持つ経営者や、ソフトウェアエンジニアではない発注者にとっては理解しにくいものです。またソフトウェアエンジニアであっても「古くなってしまったコード」や「わかりにくコード」全般のことを技術的負債と呼び、それをもって何かを説明したかのように考えてしまうことはままあります。 これらに起因して、双方のコミュニケーションが破綻してしまうこともよく見られる景色です。 技術的負債の経済効果は毎年マイナス12兆円 このような構造的な問題をはらむ技術的負債は、老朽化したレガシーなシステムとして、事業の組織改革を遅らせて

    "技術的負債"論の道案内 - アーキテクチャの資本コストと情報の非対称性 - Qiita
  • 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック - Qiita

    エンジニア組織を強くするためのを出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 最近、メンター制度として新入社員や若手のメンバーに対して、先輩をつけて相談事に乗ってあげたり、仕事のサポートをしたりといったような教育プログラムを組む企業が増えています。このメンターという役割は、ちょっとした訓練が必要だったりするのですが、このあたりの研修や訓練をせずにいきなり明日からメンターね!なんてことがままあります。

    新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック - Qiita
  • もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita

    はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo

    もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita
  • Go言語のsliceについての個人的メモ - Qiita

    type slice struct { head int, tail int, data []interface{} } のようになっていて、先頭と最後へのポインタと配列へのポインタを持っていて、hoge[1:5]のようにslice演算をするとheadとtailだけ書き換えて、データはそのまま。 また、append関数はdataのキャパシティを超えた場合にreallocのようなことをしてデータ容量を拡張する。 package main import ( "fmt" ) var P = fmt.Println func main() { a := []int{1, 2, 3, 4, 5, 6, 7, 8, 9, 10} b := a[0:5] a[0] = 100 c := append(b, 200) //aの6つ目のデータを上書き P("a", a) //a [100 2 3 4 5 2

    Go言語のsliceについての個人的メモ - Qiita
  • 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 - Qiita

    はじめに もうすっかり年末なので、これから2015年にかけてアプリケーションアーキテクチャがどのようになっていくのかという個人的な考え/妄想や背景について、「リアクティブ」というキーワードをもとににまとめてみたいと思います。 Google Trendsを見ると"reactive programming"という言葉は2010年前後から、ゆっくりとバズをし始め、現在も上昇を続けています。 また、仕事としては、2010年ごろから大規模なWebサービス開発において、フロントエンド、バックエンド、アルゴリズム改善といった様々な箇所で、リアクティブプログラミングの要素を取り入れながら、アーキテクチャの改善を進めてきました。そのため、こういったアーキテクチャがコード品質の維持や安定性の向上、実際的で複雑な問題の解決にも適応可能であるということを実感として持っています。 近年、そういった要素が様々なツール

    2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 - Qiita
  • あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ - Qiita

    エンジニア組織を強くするためのを出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに この記事は数百万行の動的型付き言語のWebアプリケーションのリファクタリング、アプリケーションアーキテクチャの再設計の経験を基に、有効だと思われる考え方やアプローチを抜粋して紹介するものです。言うまでもなくあらゆるコードベース、アーキテクチャにおいて有効なものとは限りませんので、各々の環境や状況から適切に判断してください。

    あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ - Qiita
  • ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習

    最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識がになりました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない!vs. 現場に任せてくれない!の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン(あるいは権威勾配に関する一

    ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
  • エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita

    システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた!ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン(あるいは権威勾配に関する一考察) 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生

    エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
  • 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita

    あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし

    新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
  • 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 - Qiita

    エンジニア組織を強くするためのを出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 この記事について この記事は、新人向けの研修内容を再編集してお送りします。 この記事の内

    新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 - Qiita
    clavier
    clavier 2014/05/10
  • よくわからないので実装して理解するRubyのメソッド解決順序 - Qiita

    いままであまり気にする機会がなかったので、深く考えたことなかったのだけど、Rubyのメソッド解決順序はどのようになっているかということについて、疑問に思いいろいろ試してみた。ソースを読めばいいんだろうけど、いろいろ試しながら実装していけば理解できるだろうと思い立ち、なぜかJavaScriptで実装してみた。 メソッド解決順序(MRO) メソッド解決順序とは、hoge.fugaのようにメソッド呼び出しをしたときに どのクラスから順番にmethod名を探すかという順序のこと。 これらに影響を与えそうな要素は以下 継承 モジュールのinclude モジュールのprepend 特異クラス 特異メソッド method_missing こんなものだろうか。 クラスオブジェクトに対して、ancestorsメソッドを呼べば、 どのような順序でmethodの探索がなされるかがArrayとして帰ってくる。 c

    よくわからないので実装して理解するRubyのメソッド解決順序 - Qiita
    clavier
    clavier 2014/05/03
  • そろそろ理解しておきたいのでDockerのソースコードをビジュアルに読む! - Qiita

    まずはツールの紹介 昨今、注目を浴びているアプリケーションコンテナを作ったり管理したりできるDocker。 そろそろ中身も理解しておきたいところ。特に最近はlibcontainerというのができて、lxc依存すら切り離されているとの噂。 ただ、結構ソースコードの量も大きくなっているので(2014/4月現在 テストコード除いて70000行弱)、 さっと大まかに理解するためのツールを書いてみました。 このツールはgoのastからパッケージの間の依存関係を読んで、graphvizの解釈するdot言語に吐き出すツールです。 たとえば、最近話題のgo-xslateの全体像をつかもうと思ったら、 のようにすることで、 拡大 こんな感じにパッケージ間の依存関係を図示することができます。 これだけでも何となくどんな構造になってるかわかってきそうですね。 不安定性の表示 govizにはdot言語の出力の他に

    そろそろ理解しておきたいのでDockerのソースコードをビジュアルに読む! - Qiita
  • MVCの流れを簡単にまとめてみる - Qiita [キータ]

    理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。 これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。 これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。 安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存しないようにするという原則だ。MVCアーキテクチャでは、GUIアプリケーションの安定関係をModel > View > Controllerの順でとらえている。データ処理や業務要件というのは安定しており、UIパーツもまた比較的安定している。それらを統合してア

    MVCの流れを簡単にまとめてみる - Qiita [キータ]
  • 1