並び順

ブックマーク数

期間指定

  • から
  • まで

321 - 360 件 / 8430件

新着順 人気順

アジャイル開発の検索結果321 - 360 件 / 8430件

  • テスト駆動開発のはじめの一歩|t_wadaさんに聞く1人で始める自動テストのコツと考え方 - Agile Journey

    アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発(TDD:Test Driven Development)です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分

      テスト駆動開発のはじめの一歩|t_wadaさんに聞く1人で始める自動テストのコツと考え方 - Agile Journey
    • プログラミングを難しくする要素って何だろう - Magnolia Tech

      以前noteに書いた記事からの転載 エクスポートできないので、定期的に少しずつ転載していきます。 いつかちゃんとしたスライドに書き起こしたいとおもいつつ、まだ手がついていないけど、この記事に書いている「プログラミングは、コードと、データと、改修の歴史の3つの要素が絡み合う」を分解していきたい。 コードと、データは本質的には不可分だし、その結びつきを分解できないように密に結合させているのが、改修の歴史なんだ よく「データの寿命はコードよりも長い」と言われるけど、受け継がれたデータは、当たり前だけどそれが作られた当時のコードに強い影響を受けていて、不可分だし、暗黙のうちにコードの特性を引き継いでいる。 つまり、例え直接的にはコードが無くなったとしても、コードの影響が無くなるわけではない。 そして、それらの蓄積が歴史となって、全体を形作っていくんだ。 だから、データとコードの寿命は同じくらい長い

        プログラミングを難しくする要素って何だろう - Magnolia Tech
      • チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog

        近年のソフトウェアプロダクト開発組織の活動単位としてよく言われるのは、「少人数で安定したチーム」であろう。表現は違えど、どの文献でもそのように述べられる。 それでは、「少人数」と「安定」の2つの要件を満たせば高パフォーマンスなチームが設計できるかと言えば、そんなはずもない。他にも要件があるはずだ。 そこで、チームに共通して必要だと考える要件を、設計に関わったこれまでの組織から抽出して言語化し、原則としてまとめてみた。それが、「安定」「アトミック」「非兼務」「少人数」「流動性」「イテレーティブ」の6つだ。 初期に携わった組織には欠けていた要素もあるが、何度も失敗を重ねるうちに見いだしたものだ。組織設計のプラクティスとしてよく聞くものもあるが、いずれも実体験を経て必要だと感じたものばかりである。 なお、本記事で取り上げる6つのチーム設計原則だけでは、組織設計として不十分だ。チームにどういった機

          チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog
        • ベロシティを上手く使って 技術的負債を計画的に解消する

          【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発Developers Summit

            ベロシティを上手く使って 技術的負債を計画的に解消する
          • キーボードとアジャイル開発 - mixi engineer blog

            やぁ、たんぽぽグループの森本だよ。 先日の昼休みにnaohiro.ohgataから「キミのblogは文章が短すぎるんだよ。もっと読者を楽しませなきゃ」と言われたんだ。naohiro.ohgataは皆が一目置いているJavaScriptのスペシャリストで、僕も尊敬 している。だから今日は翻訳シリコンバレーっぽい口調で書いてみようと思う。 僕が初めてキーボードというモノを触ってから30年以上たっていると思う。その時はキーボードには何の興味も無くて、コンピュータに命令を伝えるためのただの付属品だった。もちろんタッチタイピングなんかできなくて、自己流でポチポチとキーボードを打ってたんだ。今思い返すと笑っちゃうんだけど自分ではそれなりに早いつもりでいまさらタッチタイピングを覚えるなんてバカらしいとか思ってた。実際まわりの人も似たようなポチポチタイピングで、その中では一番早くてちょっとしたもんだと勘違

              キーボードとアジャイル開発 - mixi engineer blog
            • Atomic Scrum 個人の生産性を最大化する方法

              デブサミ2021の登壇内容 チーム開発における原則としてScrumは浸透しつつあります。一方で個人単位の行動管理・タイムマネジメントについては方法論が確立されていない状況があります。今回は、Scrumの原則を個人単位の行動管理に適用した上で、実装事例としてNotionを活用した方法を紹介します。

                Atomic Scrum 個人の生産性を最大化する方法
              • 【資料公開】プロダクトバックログ Deep Dive

                みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 今年もスクラム実践者の祭典であるRegional Scrum Gathering Tokyoが、2022年1月5日〜7日までの3日間開催されました。 このイベントで「プロダクトバックログ Deep Dive」というタイトルで発表しましたので、資料を公開します。 スクラムガイドでも、プロダクトバックログという単語の登場回数は非常に多く、それだけ重要だということが分かります。 一方で網羅的にまとまっている資料が日本語ではあまり存在しなさそうなので、今回用意してみました。 内容については、過去にこのブログで説明している箇所も多数ありますが、1箇所にまとめたことに意義があるということでご了承ください。 みなさんのお役に立てば幸いです。 内容に関するご意見やフィードバックは、T

                  【資料公開】プロダクトバックログ Deep Dive
                • プログラマ念能力の系統 - ローファイ日記

                  個人的に勝手に考えてる奴 放出系(フロントエンド) UIとかユーザ体験とかに強い。JavaScript好き。HTML/CSS、あとゲームのクライアント作る人もここに入る 強化系(アプリケーション) ビジネスロジックをコードに落とすのが好きな人。フロント〜アーキテクトまでをつなぎ込んで形にするのが好きな人。なんかRubyとかPerlとかLL系が好き。ここは割と雑多…… 変化系(アーキテクト) データベースとか構成とか設計するのが好きな人。ER図とかデプロイメント図とか図が好きな傾向がある 具現化系(インフラ) 一度デプロイされたシステムをお守りしたり改善したりチューニングしたりする。低レイヤで頑張る人もここっぽい? 特質系(QA) いわゆるテストエンジニア。良いコードとは何かを決めてそれを確実に作れるような各種環境を整備、ツッコミをしていく人たち 操作系(アジャイル・開発手法) 特に上のフロ

                    プログラマ念能力の系統 - ローファイ日記
                  • 「高校生になって初めてスクラムを始めました」~「ストーリー」で何を作るかまとめよう

                    「高校生になって初めてスクラムを始めました」~「ストーリー」で何を作るかまとめよう:かんばん!~もし女子高生がRedmineでスクラム開発をしたら(1)(1/3 ページ) 本連載は、ちょっととぼけた女子高生の姉妹が今注目のアジャイル開発手法であるスクラムとプロジェクト管理ソフトの「Redmine」を使って、システム開発をするというフィクションです。

                      「高校生になって初めてスクラムを始めました」~「ストーリー」で何を作るかまとめよう
                    • ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )

                      はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ

                        ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
                      • 国内の開発者が使っている言語、1位C、2位VB、3位Java。アジャイル開発は2割が採用、半数以上がウォーターフォール。IDC調べ

                        国内の開発者が使っている言語、1位C、2位VB、3位Java。アジャイル開発は2割が採用、半数以上がウォーターフォール。IDC調べ 調査会社のIDC Japanは、「国内ソフトウェア開発者の実態調査」を発表しました。それによると、国内のソフトウェア開発者が最も使用している言語は、1位がC言語で19.8%、2位がVisual Basic で17.5%、3位がJavaで14.2%だそうです。

                          国内の開発者が使っている言語、1位C、2位VB、3位Java。アジャイル開発は2割が採用、半数以上がウォーターフォール。IDC調べ
                        • 開発現場のノウハウをもっと共有して、ハッカー文化を企業に根付かせよう

                          日本のオープンソース会の重鎮(そして自称プロのよっぱらいでもある)楽天技術理事のよしおかひろたか氏が、はてなダイアリーの未来のいつか/hyoshiokの日記で「IT産業には民族誌が必要だ」というエントリを書いています。このエントリにはとても共感するところがあります。 よしおか氏は以前から、ハッカー中心の企業文化を日本に根付かせたいという意志をもってさまざまな活動をされていて、今回の「IT産業には民族誌が必要だ」という意見もそれを実現する要素の1つです。 ではなぜ民族誌が必要だとよしおか氏が書いているのか、本題に入る前に、よしおか氏が言う「民族誌」とは何なのかを、今年の2月にデベロッパーサミット、通称デブサミでよしおか氏が行った講演「ハッカー中心の企業文化を日本で根付かせる」のスライドから少し読み解いていきましょう。 ハッカー中心の企業文化を根付かせるために この講演でよしおか氏は「良いソフ

                            開発現場のノウハウをもっと共有して、ハッカー文化を企業に根付かせよう
                          • 「プログラマーとして食っていける気がしない」 圧倒的実力差に絶望も味わった、きょん氏のキャリア変遷

                            「スクラムフェス仙台」は初心者からエキスパートまでさまざまな参加者が集い、学び、楽しむことができるアジャイルコミュニティの祭典です。ここで登壇したのは、kyon_mm(きょん)氏。スペシャリストになれなくても成長する方法について話しました。全3回。1回目は、kyon_mm氏が勉強に目覚めたきっかけと、転職後に味わった絶望について。 デロイトトーマツコンサルティング合同会社・執行役員のkyon_mm氏 kyon_mm氏:kyon(きょん)と申します。私はソフトウェア開発やアジャイルコーチなど、いろいろな文脈で仕事をしてきたのですが、今日はそこにおけるスキルアップや、学習の仕方をテーマに話していこうかと思っています。 今日の話のベースになっているのは、2015年に仙台で開かれた「レッツゴーデベロッパー」というイベントで話した、「ザ・ジェネラリスト」というものです。「ザ」と付けたのが本当にヤバい

                              「プログラマーとして食っていける気がしない」 圧倒的実力差に絶望も味わった、きょん氏のキャリア変遷
                            • エイプリルフールに便乗しているサイトまとめ2018年版

                              By mera 毎年おなじみのエイプリルフールが今年も始まってしまいました!何が本当で、何がウソで、何がネタで、もしかして実はマジなのか?という境界線がガラガラと音を立てて崩壊し、いろいろな意味で予測可能、しかし回避不能になってしまうという日です。 ◆エイプリルフール記事が更新される度にすぐ知る便利な方法 GIGAZINE編集部はエイプリルフールに便乗していろいろと仕込みまくっている各サイトを4月1日0時~24時まで、文字通り24時間はりついてリアルタイム更新し、この記事にまとめ続けます。どんどん記事末尾に更新内容が追加されていき、時間の経過とともにギガを消費しまくる恐るべき長さになっていくという仕組みです。「ページを再読み込みして、追加があるかどうか確認するのが面倒!」という場合は、GIGAZINEのTwitter公式アカウント・Facebook公式アカウントに随時、更新通知の投稿をしま

                                エイプリルフールに便乗しているサイトまとめ2018年版
                              • 「アジャイル開発ってのに取り組むことになったんだけど、何を読んだらいいの?」という質問を受けたので答えてみた | DevelopersIO

                                事業開発部の塩谷 (@kwappa) です。 いきなり家庭の私事で恐縮なのですが、今朝出がけに妻からタイトルのような質問を受けました。 そのまま「Slackにリンク投げといてね!」と言い残して出て行ったので(我が家では家庭の連絡にSlackを使っています)、やっきになってぺたぺた貼ったリンクをご紹介しようと思います。 といっても、アジャイル開発の経験がある方ならお馴染みのものばかりです。「あーなるほど」と納得していただけたら幸いですし、「これも読んどけ!」という推薦もお待ちしています。 「まずはこれを10回読む」 …と最初に貼ったのが「アジャイルソフトウェア開発宣言」 (Agile Manifesto)です。すべての始まりですから、ここを読まなければ始まりません。ほんとうは「100回読む」と書きたかったのですが、のっけからハードルは上がるし感じ悪いしなので自重しておきました。 しかし、表面

                                  「アジャイル開発ってのに取り組むことになったんだけど、何を読んだらいいの?」という質問を受けたので答えてみた | DevelopersIO
                                • FigmaとNotionでUML・経理処理・デザインまでAll in oneな仕様書を書いて、更新・共有を楽にしてる話 - Qiita

                                  前提としての情報 単に「Figmaで要件定義のためのUMLも、外部設計のためのデザインも、内部設計のためのERDも全部つくるよ〜〜」という話をすると、ERD書くならデザインツールなんて使わないで、DBMSから自動生成できるツールとか使った方がいいじゃん、みたいな疑問が出るのは重々承知なので、そもそもこの形式に落ち着いた前提事項を書いておきたいと思います。 ご興味がなければ読み飛ばしてください。 筆者の仕事範囲 さて、冒頭で「事業会社でデザイナーとPMの狭間みたいな仕事をしてます」と書きました。キャリアの背景的には受託のPMっぽい仕事(厳密には違うんですが、本旨ではないので割愛します)→事業会社のインハウスデザイナー→現職という感じで、外渉から手を動かす所まで、必要ならなんでもします。 ざっくりいうと、機能の起案をして、経理などの関連部署に相談して、WBS引いて、UML書いて、画面遷移図書い

                                    FigmaとNotionでUML・経理処理・デザインまでAll in oneな仕様書を書いて、更新・共有を楽にしてる話 - Qiita
                                  • プログラマブルなインフラ、Ruby、JavaScriptなどが重要なテクノロジと評価される。ThoughtWorksのレポート

                                    プログラマブルなインフラ、Ruby、JavaScriptなどが重要なテクノロジと評価される。ThoughtWorksのレポート オブジェクト指向やアジャイル開発などを広めてきたMartin Fowler氏が所属し、アジャイル開発のコンサルティングなどを行っている企業としても知られているThoughtWorks。同社は、IT業界内のさまざまなテクノロジーの中から、重要性を増しつつあるテクノロジーや、逆に影響力を失いつつあるテクノロジーなどを紹介するレポート「Technology Radar」を不定期に公開しています。 そのTechnology Radarの2011年1月号が公開されました。いままでPDFバージョンしかなかったのですが、今回はHTML版も公開され、より見やすくなっています。 Technology Radarは、開発技法を対象とした「Techniques」、ツールを対象とした「T

                                      プログラマブルなインフラ、Ruby、JavaScriptなどが重要なテクノロジと評価される。ThoughtWorksのレポート
                                    • 東京都初のアジャイル型開発はいかにして導入され、実践されたか – 調達、スクラムの工夫、展望を聞いた - Agile Journey

                                      「初!都庁職員、アジャイル型開発に参加する」 東京都デジタルサービス局デジタルサービス推進部の公式note(2023年1月公開)には、かつて“試みたことのない開発手法”であったアジャイル型開発を東京都が採り入れ、複数のソフトウェアを開発した経緯が綴られています。 これまでAgile Journeyでは、さまざまな組織、企業のアジャイル導入事例を紹介してきましたが、それぞれの組織がそれぞれのモチベーションを持ち、課題に向き合いながら、導入に取り組んできました。では、それが自治体の場合では? 東京都がアジャイル型開発を導入し、運用していくための動機、準備、事業者との契約の方法、そして実践のありようを、東京都デジタルサービス局の石川秀之さん、下家昌美さんに聞きました。 コロナ禍で浮き彫りになった、「迅速」の重要性 「システムをアジャイル型開発で作ってみませんか」メールで呼びかけ、アジャイル型開発

                                        東京都初のアジャイル型開発はいかにして導入され、実践されたか – 調達、スクラムの工夫、展望を聞いた - Agile Journey
                                      • Udemyで夏のビッグセール開催! 話題の生成系AIからプロダクトマネジメントまで、新たな得意分野を見つけよう - はてなニュース

                                        ※夏のビッグセール、およびキャンペーンは終了しました。ご応募ありがとうございました。なお、Udemyの講座修了者を対象とした「学習応援キャンペーン」は9月30日まで実施中です。 オンライン学習プラットフォーム「Udemy」では、2023年8月22日(火)から夏のビッグセールを開催します。対象の講座が1,200円から購入可能と、なかなかチャレンジできなかった新しい領域を学習するにはとってもお得なチャンス。 今回のセール対象講座から、ChatGPTやMidjourneyといった話題の生成系AI、その基礎となる大規模言語モデル(LLM)の入門や実装を扱う講座といった人気のトピックに加えて、アプリケーション開発やプロジェクトマネジメント、さらには英語学習など、ステップアップを目指すITエンジニアにオススメの中級から上級の講座もピックアップして紹介します。 Udemyで勉強を始めたいけれど、いろいろ

                                          Udemyで夏のビッグセール開催! 話題の生成系AIからプロダクトマネジメントまで、新たな得意分野を見つけよう - はてなニュース
                                        • チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する|mtx2s

                                          依頼、調整、合意、承認、etc. こういったコミュニケーションがチーム境界を越えて頻発すると、ソフトウェアプロダクト開発のフローは遅々として進まなくなります。いずれも、機能追加や機能改善を進める上でのクリティカルパスを引き伸ばす要因を生み出すからです。 機能追加や機能改善といったひとつひとつの開発は、アイデアを生み出し、それを価値に変えるまでのフローです。フローが進む過程で、組織内の様々な人の手で、様々なタスクが実行されます。その全てを1つのチームで完結することは、プロダクトの規模が大きくなるほど困難になり、より多くの人々が関わるようになります。そこに、チーム境界を越えた「依頼、調整、合意、承認」といったコミュニケーションが発生するのです。 開発フローのクリティカルパスを悪化させるこのようなコミュニケーションの頻度をどれだけ減らせるか。組織設計、チーム設計で最も注視すべき観点の1つは、そこ

                                            チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する|mtx2s
                                          • 自己流オブジェクト指向プログラミング&Javaお奨め本2007年版 - カレーなる辛口Javaな転職日記

                                            http://d.hatena.ne.jp/JavaBlack/20050909/p1の改訂.*1基本的に改訂版への差し替えと一部の新刊の追加程度になっている. お奨めのJava&オブジェクト指向プログラミング関連の書籍/参考文献リスト.初心者向け入門書や参考書から上級者向けの専門書まで,オブジェクト指向だとかJava言語とかの初心者〜中級者が学習をすすめる上での参考にすることを想定して作っている. 初心者向け勉強の手引き:http://d.hatena.ne.jp/JavaBlack/20070825/p1 オブジェクト指向プログラミング とりあえず初心者なら「オブジェクト指向プログラミング入門」「オブジェクト指向における再利用のためのデザインパターン」と,あと「リファクタリング―プログラムの体質改善テクニック (Object Technology Series)」くらいかな.ただしリフ

                                              自己流オブジェクト指向プログラミング&Javaお奨め本2007年版 - カレーなる辛口Javaな転職日記
                                            • 大規模アジャイル開発の実態~ セールスフォース・ドットコムの作り方(前編)

                                              クラウド上に構築したアプリケーションをサービスとして提供するセールスフォース・ドットコム。同社は千人以上の開発者を抱える開発部門全体でアジャイル開発手法を採用し、開発を行っています。 アプリケーションのメジャーアップデートは年3回。クラウドで提供しているサービスという性格上、もしもアップデートにバグがあればそれは全ユーザーに対して大きな影響を与える可能性があります。バグがないこと、性能低下を起こさないこと、品質管理はパッケージソフトウェア以上に重要です。 同社はどのようにしてアジャイル開発手法を採用し、品質を重視した開発を進めているのか。2月17日に行われたデベロッパーズサミット2011で、株式会社セールスフォース・ドットコム CTO 及川喜之氏のセッション「salesforce.comの作り方 どのように世界最大規模のアジャイル開発を実現したか」で詳しく紹介されていました。 同社の開発手

                                                大規模アジャイル開発の実態~ セールスフォース・ドットコムの作り方(前編)
                                              • サイボウズ kintoneチームの「改善」大公開! 新人も巻き込んだスクラム導入の成果とは?|ハイクラス転職・求人情報サイト AMBI(アンビ)

                                                サイボウズ kintoneチームの「改善」大公開! 新人も巻き込んだスクラム導入の成果とは? 連載「若手エンジニア、どんな活躍してますか?」第4回は「kintone」「cybozu Live」などを運営するサイボウズ編です。「チームワークあふれる社会を創る」を理念として掲げるサイボウズで、若手エンジニアはどんな活躍をしているのか、伺いました。 若手エンジニアのための情報メディア「エンジニアHub」。連載「若手エンジニア、どんな活躍してますか?」第4回は「kintone」「cybozu Live」などを運営するサイボウズ編です。「チームワークあふれる社会を創る」を理念として掲げるサイボウズで、若手エンジニアはどんな活躍をしているのでしょう。 取材に応じてくれたのは、若手プログラマの前田浩邦(まえた・ひろくに)さんと、メンター役だった天野祐介(あまの・ゆうすけ)さん。2人が属するkintone

                                                  サイボウズ kintoneチームの「改善」大公開! 新人も巻き込んだスクラム導入の成果とは?|ハイクラス転職・求人情報サイト AMBI(アンビ)
                                                • 伊藤淳一氏が「一番下手くそエンジニア」から脱出した4つの方法。2023年版ITエンジニアの生存戦略【後編】

                                                  TOPコラムキャリアを創る思考法伊藤淳一氏が「一番下手くそエンジニア」から脱出した4つの方法。2023年版ITエンジニアの生存戦略【後編】 伊藤淳一 1977年生まれ、大阪府豊中市出身。株式会社ソニックガーデンのRailsプログラマ、およびプログラミングスクール「フィヨルドブートキャンプ」のメンター。ブログやQiitaなどでプログラミング関連の記事を多数公開している。将来の夢はプログラマーをみんなの憧れの職業にすること。主な著書に「プロを目指す人のためのRuby入門 改訂2版 言語仕様からテスト駆動開発・デバッグ技法まで」(技術評論社)などがある。 前回では、筆者がプログラマとして入社したSIer時代のエピソードと、そのあとに入社した外資系企業での社内プログラマとしてのエピソードを書いてみました。IT業界に入って間もないエンジニアさんや、これからの自分のキャリアを考え始めたエンジニアさんに

                                                    伊藤淳一氏が「一番下手くそエンジニア」から脱出した4つの方法。2023年版ITエンジニアの生存戦略【後編】
                                                  • JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文 - プログラマの思索

                                                    JAXAにおけるスーパーコンピュータ活用課でのチケット管理ステムの経験論文がPDFで公開されていたのでメモ。 【参考】 ※参照リンクを修正しました。 JAXA Repository / AIREX: CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント akipiiさんはTwitterを使っています: "気になる。RT @g_maeda: なんだこれ ? CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム : Redmineの事例と利用のヒント https://t.co/9QlySYSzZk" MAEDA, GoさんはTwitterを使っています: "@akipii @y503unavailable @takenory JAXAの資料のPDF見つけました https://t.co/msKI89zsCh" akipiiさんは

                                                      JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文 - プログラマの思索
                                                    • InfoQ: ドメイン駆動設計・開発の実践

                                                      ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく

                                                        InfoQ: ドメイン駆動設計・開発の実践
                                                      • マインド・マップとUMLを使った要求分析支援(前編):@IT

                                                        マインド・マップをご存じでしょうか? 最近、日本でも新しい「メモ技術」として注目されるようになってきた記法です。この記事では、このマインド・マップという記法が、ITの現場でうまく使えないだろうか、というアイデアを紹介します。特に、IT分野で標準化されているUMLをうまく補完するツールとして、要求分析という上流工程をまず取り上げたいと思います。 「顧客の言葉を集めること」の難しさ ITシステム開発において要求分析を行う場合、現在ではUMLを使ったオブジェクト指向による概念モデリングや、ユースケース分析が主流になってきています。しかし、UMLには強い制約(記法の意味と文法)があり、誰でもすらすらとまとまるものではありませんね。特に、顧客へのインタビューを行う場面では、その場でUMLにまとめるというのは至難です。そこで、顧客との対面場面ではとにかく「顧客の言葉を集める」ことに徹し、それをメモ(イ

                                                          マインド・マップとUMLを使った要求分析支援(前編):@IT
                                                        • オブジェクト指向プログラミングは終わった - Qiita

                                                          追記: 振り返りを書いてみました~ -- ここから元記事 別題: 抽象化って言葉もう。。 社内の記事にて、オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) | アラン・シャロウェイ, ジェームズ・R・トロット, 村上 雅章 |本 | 通販 | Amazonを紹介してもらいました。 取り上げられた、共通性/可変性分析の解説を見て、はっと思うことがありポエムを仕立てました。 共通性/可変性分析 共通性/可変性分析については、書籍を読むかググって頂けると良いですが、社内記事が良かったので引用させて頂きます。 問題領域にある概念を見つける(共通性の分析) その流動的要素を洗い出す(可変性の分析) 流動的要素を見ながら、その概念が持つ責務を果たすための抽象的側面(≒インタフェース)を導く 各流動的要素の実装上の観点から、インタフェースが適切かどうかを見極め、補正する オ

                                                            オブジェクト指向プログラミングは終わった - Qiita
                                                          • 【資料公開】スプリントプランニング Deep Dive

                                                            みなさんこんにちは。@ryuzeeです。 8月26日に新刊『エンジニアリングマネージャーのしごと』が発売になったのでぜひよろしくお願いします。 2022年8月26日〜27日までスクラムのコミュニティイベントであるScrum Festが初めて仙台で行われました。 このイベントで「スプリントプランニング Deep Dive」というタイトルで話をする予定だったのですが、急遽体調不良となり、代わりに弊社の@miholovesqに登壇してもらいました。 ただ、資料をそのままにしておくのも勿体ないので、こちらで公開します。 スクラムガイドの複数回の改訂で、スプリントプランニングにも何度か変更が加わっています。 ところが巷のブログなどを読んでいると古い知識をベースにしていたり、特定のツールの従来からの仕様に引きづられた運用になっていたりするのを多く見かけます。 ということで、今回スプリントプランニングに

                                                              【資料公開】スプリントプランニング Deep Dive
                                                            • エンジニアが転職する時に考えることを採用面接官をしてる立場から書いてみた - Qiita

                                                              エンジニアの転職メモ を読んで、刺激を受けたので書いてみました。 非常に共感しました! 自分的にちょっと気になるところ+αを書こうかなと。 書かれたことは会社的な方針ではなく、個人としての観点です。 自分誰よ とある企業で採用の一次面接に呼ばれたりする現場のエンジニアです。 Javaエンジニアです。Scalaもたまに書いてました。 転職回数は片手では足りないくらいの回数をしています。 最近はエンジニアマネジメントの比重が多く、ほとんどコード書いてないです。 コードは書いていませんがレビューや調査では読んだりします。 アーキテクチャ、フレームワーク選定、インフラ方針などの決定権は持っていて、 ビジネスバランスを取りながら実装の方針などを決めます。 採用面接官のエンジニアは現場エンジニアが多い 人事によるピックアップとは別 前提として技術力はエンジニアしか判断できないと思っています。 でも、採

                                                                エンジニアが転職する時に考えることを採用面接官をしてる立場から書いてみた - Qiita
                                                              • 「契約もアジャイルに」、中堅SIerの新たな挑戦 - @IT

                                                                2010/12/07 「アジャイル」といえば、ソフトウェアの開発手法として近年注目を集めてきた。半年や1年といったプロジェクト期間で完成品を作る「ウォーターフォール型」ではなく、2週間程度の短いサイクルで、途中経過であっても実際に動くものを見ながら開発を進めるスタイルだ。事前にシステム要件を定義しづらい場合や、市場変化が激しい場合などに柔軟に対応できる。 アジャイルは開発スタイルの実践を指すが、これを受託開発の契約形態に当てはめようという企業が登場して注目を集めている。中堅SIerの永和システムマネジメントは2010年11月11日、初期費用0円、月額利用料15万円からという、まったく新しい契約形態による受託開発のトライアルサービスを発表した。永和システムマネジメントに話を聞いた。 こう語るのは永和システムマネジメントサービスプロバイディング事業部の木下史彦氏だ。アジャイルといえば、開発の方

                                                                • モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた - Goodpatch Tech Blog

                                                                  この記事はGoodpatch Advent Calendar 2022 18日目の記事です。 ソフトウェアエンジニアの 池澤です。 ここ最近はテクニカルディレクションとして仕事に関わることが増えました。その中で要件定義を作ったりデザイナーとエンジニアの橋渡しをする機会が多く、メンバーみんなが同じゴールを認識して制作できるようなより良い要件定義方法はないものかと探していました。 今回はそんな中で見つけたモダンな要件定義手法の一つ、RDRA(ラドラ)について、理解しやすくなるコツやカスタマイズしている内容についてお話しします。 なお、RDRAの詳細解説をするととても書ききれませんので、RDRA本体の詳細については公式サイト等をご参照ください。 RDRA(ラドラ)とは? 概要 RDRAのバージョン これまでの要件定義でよくある問題 期待される要件定義の姿 公式サイト おすすめの学び方 実際のRD

                                                                    モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた - Goodpatch Tech Blog
                                                                  • メルカリの社内技術研修 ”DevDojo”の研修資料を公開します! | メルカリエンジニアリング

                                                                    この記事は、Mercari Advent Calendar 2022 の23日目の記事になります。 こんにちは!メルカリ Engineering Office チームの@aisakaです。 メルカリのエンジニア組織は、メンバーが相互に学び合い、メンバー自身が自走し、成長できる組織を目指し、「互いに学び合い、成長し合う文化」の醸成を行っています。 こうしたメルカリの「互いに学び合い、成長し合う文化」を体現する仕組みの一つが、社内技術研修「DevDojo」シリーズです。この度、一部のDevDojoシリーズを外部公開することになりましたので、今日のブログではDevDojoとその内容をご紹介します。 DevDojo page in Engineering Website 技術研修DevDojoとは DevDojoは技術開発を学ぶ場として、「Development」と「Dojo(道場)」をかけ合わせ

                                                                      メルカリの社内技術研修 ”DevDojo”の研修資料を公開します! | メルカリエンジニアリング
                                                                    • 徳丸先生が『安全なWebアプリケーションの作り方』第二版を語る会 - Qiita

                                                                      安全な Web アプリケーションの作り方 ブログ枠で入り込みました。 2018年9月10日(月)19:00~20:30 @ EGセキュアソリューションズ株式会社 Connpass から引用: 弊社代表 徳丸の著書であり、ウェブエンジニアのみなさまのバイブルとして親しんでいただいております『安全なWebアプリケーションの作り方』。6月21日に待望の第2版が発売されました。 今回の勉強会では少しカジュアルに、『安全なWebアプリケーションの作り方』第2版執筆にあたっての想いや、初版との違い、お勧めの読み方等を著者徳丸自らがお伝えします。 さらに、第2版で新規に追加された以下の脆弱性のデモもご覧いただきます。 表紙 初版の表紙と第二版の表紙で微妙に向きが変わっている、特に意味はないけど。逆向きの矢印も検討したんだけど、座りが悪った。 初版(amazon) 第二版(amazon) 第二版で改訂しま

                                                                        徳丸先生が『安全なWebアプリケーションの作り方』第二版を語る会 - Qiita
                                                                      • AngularJSの便利なツール20選 | POSTD

                                                                        皆さんはAngularJSに興味がありますか? この記事では、AngularJSのための最適なツールと選りすぐりの情報をリストにまとめています。Angularを使ってアプリケーションの開発をする際には役立つ内容です。 Webアプリケーションを動的に設計したいWeb開発者の多くは、 フレームワークとしてAngularJSを選択するようになってきました 。AngularJSの開発者が新たにAngularJSプロジェクトを立ち上げる場合、本格的にWebサイトを開発しようとすると、非常に多くのツールが必要になります。 AngularJS初心者の場合は、まず始めに AngularJSの良書 を何冊か読むと良いでしょう。 私たちは、オンラインでAngularJSを学習するための、膨大な AngularJSのチュートリアル リストも作成しています。 AngularJSでWebアプリケーションを開発する際

                                                                          AngularJSの便利なツール20選 | POSTD
                                                                        • 第14回 関数脳のつくり方 Second Season ~モナドで悟りをひらく~

                                                                          大手SIベンダにてSEやPMやアーキテクトとして勤務したのち,株式会社豆蔵を経て,現在は合同会社シンプルアーキテクト代表社員であり,株式会社匠Business Placeのチーフコンサルタント。主に超上流のプロセスである要求開発やオブジェクト指向,アジャイル開発のコンサルタントとして活躍中。開発の現場にこだわり,開発の現場を少しでもよくしたいと日夜奮闘している。要求開発アライアンス執行委員。著書に『オブジェクト脳のつくり方』や『eXtreme Programming実践レポート』(ともに翔泳社発行。後者は共著)などがある。 Javaなど,オブジェクト指向や手続き型のプログラミングの経験はあるけれど,関数型のプログラミングは初めてという皆様のための,そして筆者自身のための「関数脳のつくり方」シリーズのSecond Season(First Seasonはこちら)。今回は「モナド」を取り上げま

                                                                            第14回 関数脳のつくり方 Second Season ~モナドで悟りをひらく~
                                                                          • 受託開発にアジャイルは適用できるか?

                                                                            3つの大事なこと まず全ての受託開発に適用できるかというと、それは難しいと考えています。 これまでクレイに発注いただいた開発で、次のような案件に適用してきました。 Webサービス スマートフォンアプリ プロトタイプ、研究開発 要件が曖昧だったり、仕様が変わりやすいもの、市場の変化が大きいものなどですね。 次に規模ですが大きくても3,4人で半年から一年程度の小規模な開発が多かったです。 ただこれまでいくつかのプロジェクトを進めてきて、向き不向き以上に大事なことがあるとわかりました。 特に次の3つが進めていくために大事なことと感じています。 クライアントにプロジェクトに責任を持って参加してもらう アジャイルに適した契約にする 開発プロセスを出来るだけ透明化する クライアントにプロジェクトに責任を持って参加してもらう 「クライアントにプロジェクトに責任を持って参加してもらう」とはどういうことでし

                                                                              受託開発にアジャイルは適用できるか?
                                                                            • テストエンジニアの面接の際にするとよい20の質問

                                                                              みなさんこんにちは。@ryuzeeです。 DZoneという海外のサイトで “The 20 Best Software Tester Interview Questions” (テストエンジニアの採用面接の際にすると良い20個の質問)がまとまっていたので紹介します。 ここにあがっている質問を必ずすべきかという話ではありませんし、完全な網羅性があるわけでもありません(カバレッジの話やブラックボックス・ホワイトボックスの話のような基礎的な質問も入っていないです)。 一方で、ある程度の規模になった組織においては、採用面接の質を向上させるために自分たちの組織で共通の質問集のようなものを用意しておくのはベストプラクティスの1つと言えます。 もちろん一度作ったらそれで終わりではなく、新しい質問を追加したり、いろいろな候補者から期待と違う回答があった場合には質問自体を見直すといったことも必要になってきます

                                                                                テストエンジニアの面接の際にするとよい20の質問
                                                                              • 最近感じる日本企業のITの問題と展望~「ソフトを他人に作らせる日本、自分で作る米国」を読んで : プログラマの思索

                                                                                【公開】第30回IT勉強宴会「最近感じる日本企業のITの問題と展望~「ソフトを他人に作らせる日本、自分で作る米国」を読んで」 【1】「ソフトを他人に作らせる日本、自分で作る米国」の著者である谷島さんが来阪されたのを記念に勉強会が開催されました。 数人が本の感想をメインに発表し、谷島さんに感想を述べてもらうという緩い勉強会でした。 いろんな議論がありましたが、詰まる所、「日本のユーザ企業がシステム開発を内製化するにはどうすればよいのか?」というテーマを巡る話だったと思います。 僕は、SIとユーザ企業の両方を経験した立場から、現状の日本のIT企業(SIとユーザ企業の両方)について、話しました。 【2】「日本企業はロールが多すぎる」という問題 【2-1】SIにしても、ユーザ企業にしても、日本企業は役職が多すぎる。 特に、管理職は部長、課長だけでなく、事業部長、PMO、○管理長、主査など色んな肩書

                                                                                  最近感じる日本企業のITの問題と展望~「ソフトを他人に作らせる日本、自分で作る米国」を読んで : プログラマの思索
                                                                                • 事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering

                                                                                  2022年度リクルート エンジニアコース新人研修の講義資料です

                                                                                    事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering