並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 2039件

新着順 人気順

アジャイル開発の検索結果1 - 40 件 / 2039件

  • エンジニアの"有害な振る舞い"への対処法 - Qiita

    本記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニアや上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用(難しい人というラベリングを特定個人に適用する使い方)が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40%低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz

      エンジニアの"有害な振る舞い"への対処法 - Qiita
    • ミルクボーイがアジャイルを説明したら

      序章駒場「最近、うちのおかんがシステム開発に興味を持っててなぁ、名前は忘れたらしいんやけど、迅速に開発できて、仕様変更にも対応できる、素晴らしい開発手法を取り入れてるところがあるらしいんやわ〜。」 内海「そんなもんアジャイルに決まってるがなぁ〜! 今やシステム開発と言えば、アジャイル。素早く変化に対応できるってゆーのが特徴なんよ。そもそも名前が “迅速” を意味する英語やねんから、アジャイルに決まってるがなぁ〜。」 チームの人数駒場「最初、オレもそう思たんやけどな、なんでも 40 人ぐらいで開発してるらしいんやわぁ〜。」 内海「ほなぁ、アジャイルちゃうかぁ…。アジャイルでは 5〜9 人ぐらいが推奨されてるからなぁ〜。40 人もおったら、とてもやないけど、コミュニケーションが成立するとは思われへんなぁ〜。効率の悪い伝言ゲームになるのは目に見えてるからなぁ〜。おかん、他にもなんか言うてなかった

      • 【資料公開】目標設定の基本

        みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと

          【資料公開】目標設定の基本
        • ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話(前編)

          ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話(前編) アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク(Dmytro Yarmak)氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入

            ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話(前編)
          • 要件定義~システム設計ができる人材になれる記事 - Qiita

            はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの?」 「要件定義ってなに?」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に4つも壁が存在するのです。 そのため、本記事では実装(プログラミング)を開始する前に必要となる、 『企画~設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装(プログラミング)に使用する時間

              要件定義~システム設計ができる人材になれる記事 - Qiita
            • 実践要件定義入門以前 - 勘と経験と読経

              最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作

                実践要件定義入門以前 - 勘と経験と読経
              • プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0

                TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案(やってよかったこと) 1stスクリーニング(やってよかったこと) コミュニケーション チームへのリスペクト(やってよかったこと) 話す <<< 聞く(改善余地あり) 即決する(やってよかったこと) 自分で各論まで見る(やってよかったこと) 発散→収束でディスカッション(改善余地あり) イラストで話す(改善余地あり) 日次ミーティング(やってよかったこと) 議事録を書く(改善余地あり) 得た情報を共有する(改善余地あり) 想定納期を示す(改善余地あり) カレンダー招待&日程確約コメントを転記(改善余地あり) プロセス管理 仮説

                  プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
                • プロジェクトリーダーというお仕事 - Qiita

                  概要 そろそろ年度末だし、新年度からプロジェクトリーダーとしてやっていく人もいるかと思うので、プロジェクトリーダーはどういうことをしないといけないかと、心得的なものを投稿しようと思います。今業界全体的にリーダー不足になってるんで、プロジェクトリーダーという役割について興味持ってくれる人が増えると嬉しいです。 ※ここでのプロジェクトとはシステム開発等IT関連のプロジェクトを指すものとします。 軽く自己紹介 2013年頃から7年くらいプロジェクトリーダーとして請負業務などの仕事をしてきました。最近はプロジェクトマネージャーも兼ねてやっていたり、うまくいっていないプロジェクトにコンサルとして入って立て直すというようなこともしています。 レジュメ https://www.resume.id/branch まずは結論から プロジェクトリーダーの使命 「担当するプロジェクトを成功へと導く」 「プロジェ

                    プロジェクトリーダーというお仕事 - Qiita
                  • ミルクボーイがUIとUXの違いを説明したら|広野 萌

                    挨拶内海「どうもお願いします。ありがとうございます。今、NFTアートをいただきましたけどもね。ありがとうございます。こんなんなんぼあってもいいですからね」 駒場「いきなりなんですけどね、うちのおかんがね、好きなIT用語があるらしいんやけど」 内海「そうなんや」 駒場「その名前を忘れたらしいねん」 内海「IT用語の名前忘れてまうってどうなってんねん。あれやろ、IT用語ゆうたらどうせ、デザイン思考か、アジャイル開発か、リーンスタートアップやろ!」 駒場「俺もそう思ったんやけどちゃうらしくてな、いろいろ聞くんやけど、全然わからへんねん」 内海「そうなん?」 駒場「うん」 内海「ほんだら俺がね、おかんの好きなIT用語、一緒に考えてあげるから、どんな特徴言うてたかとか教えてみてよ」 定義駒場「おかんが言うには、製品やサービスとの関わりを通じて利用者が得る体験及びその印象の総体やって言うてた」 内海「

                      ミルクボーイがUIとUXの違いを説明したら|広野 萌
                    • わずか数年で400億円も売り上げを伸ばしたカインズ ホームセンターのDXで、まず「顧客戦略」に着手した理由

                      多くの企業がデジタル戦略を進める中で、「IT=外部委託」から、「デジタル組織の内製化」へと舵を切り始めています。しかし、内製化の実現には投資計画や組織づくり・文化づくり、経営層と現場の意識改革、採用・育成など、あらゆる領域の変革が必要です。株式会社メンバーズ主催のセミナー「カインズを支えるデジタル内製化組織の作り方」では、200名以上のデジタル部隊を内製化したカインズの先進的な取り組みを紹介します。開発からマーケティングまで行うデジタル組織の立ち上げから今後の戦略まで、立役者である同社CDOの池照直樹氏が語りました。本記事では、いきなりデジタルを推進する前に、最初に実施した「顧客戦略」について解説します。 ・2記事目はこちら ・3記事目目はこちら 企業のデジタルシフトが進む中で注目される「内製化」 西澤直樹氏(以下、西澤):みなさん、こんにちは。株式会社メンバーズの西澤と申します。本

                        わずか数年で400億円も売り上げを伸ばしたカインズ ホームセンターのDXで、まず「顧客戦略」に着手した理由
                      • エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita

                        本記事は、Engineering Manager Advent Calenderの1日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ

                          エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
                        • Pythonで仕事をする人のための書籍まとめ2021 - 学習, 業務効率化, アプリ開発からデータサイエンスまで - Lean Baseball

                          2020年も多くの素晴らしい技術書がたくさん出ました. その中でも(昨今のトレンド・流行りも手伝ってか)Python本の多さ・充実度合いは目立つものがあります. (このエントリーを執筆した12/19時点で)Amazonの本カテゴリで「Python」と検索すると1,000件以上出てきます*1. これだと目的の本にたどり着くだけで疲れそうです. このエントリーでは, 主にPythonを学びたい・現在使っている方 手元の業務を効率化したり, RPAっぽいことをやりたい方 エンジニア・データサイエンティストとして業務や趣味・個人開発をされている方 を対象に, 今そして来年2021年に読んでおきたいPython関連書籍(と抑えておきたいサービス) をエンジニアでありデータサイエンティストである私独自の視点で紹介します*2. なおこのエントリーはこのブログで例年執筆している「Python本まとめ」の2

                            Pythonで仕事をする人のための書籍まとめ2021 - 学習, 業務効率化, アプリ開発からデータサイエンスまで - Lean Baseball
                          • プログラミング言語の入門が終わったら何の勉強をすればいいの? - きしだのHatena

                            JJUG CCC 2022 Fallで「Javaの入門が終わったら何の勉強をすればいいの?」という内容で発表を行いました。 基本的なものが作れるようになったけども、イマイチプログラムが組めないというときに、何を勉強すればいいかをまとめました。 入門が終わって作りたいものがあれば作っていきましょう、業務で言われたものが作って行こう、でもなんだかちゃんとしたものが作れないな、もっとちゃんとしたものを作りたい、次のステップに進みたいというときに勉強していく感じです。 資料はこちらです とりあげた本についてまとめておきます。 開発作業について 概要 プログラミング言語 アーキテクチャ ミドルウェア ネットワーク デプロイ 理論 開発手法 開発プロセス まとめ フレームワークは入門でやってる前提です。Java入門書「プロになるJava」ではJavaの基本から簡単なDB操作、Spring Bootまで

                              プログラミング言語の入門が終わったら何の勉強をすればいいの? - きしだのHatena
                            • 「なぜ」と聞かずに理由を引き出す!「詰めてる」感を減らす言い換えテク - Qiita

                              こんにちは。KDDIアジャイル開発センターのサービスデザイナー よねみちです。 生成AIを用いたto Bプロダクトのスクラム開発や、お客様のDX・新規事業創出のきっかけとなるデザインスプリント支援などを行っています。 はじめに レビューや会議で誰かが「詰められてる」様子、心にきますよね。自分がやられるのはもってのほかですが、周囲で発生するだけでも心がすり減ります。。 特に、何か問題が発生したときや、参加者間の誤解が解消できないときに「詰め」が生じがちです。 質問する側の、焦りや不安から「なぜ?」「どうして?」「つまり?」と質問マシーンになってしまう気持ちも理解できるのですが。 問い詰めてしまい心理的に不安全な状況に陥ると「ミスを隠そう、自分が責められないようにしよう」と回避する力が働きはじめ、結果として「正確な状況がわからない」「適切なアクションが取れない」といったチームとして重大なリスク

                                「なぜ」と聞かずに理由を引き出す!「詰めてる」感を減らす言い換えテク - Qiita
                              • ITエンジニアが投票した「ITエンジニア本大賞2022」ベスト10発表。「シェル・ワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など

                                ITエンジニアが投票した「ITエンジニア本大賞2022」ベスト10発表。「シェル・ワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など 「ITエンジニア本大賞」は、仕事の役に立った本、初学者におすすめの本、ずっと手元に置いておきたい本など、おすすめの本をITエンジニアがWeb投票で選ぶイベントです。 主催は翔泳社ですが、対象となる書籍は出版社を問わず技術書、ビジネス書全般となっています。刊行年も関係なく、これまで大賞に選出された書籍を除き、この1年を振り返っておすすめしたい書籍が対象となります。 今回発表されたのは技術書部門とビジネス書部門それぞれのベスト10です。現時点では50音順に並んでいます。 このなかから特に投票の多かった技術書3冊、ビジネス書3冊について、同社が2月17日と18日に開催する「Developers Summit 2021(デブサミ20

                                  ITエンジニアが投票した「ITエンジニア本大賞2022」ベスト10発表。「シェル・ワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など
                                • ChatGPTでstep by stepもロールプレイもやめたらプロダクト開発で使える精度になったよ|MRYY

                                  プロダクトマネジメントのコーチをしています。プロダクト開発の中でもGPT4を使うケースが増え、相談されることが増えてきました。 ChatGPTのGPT4を用いた際の、専門家として信用できる精度で推論させるための工夫の一部を紹介します。精度が必要な専門職かつ中級者向けになると思います。「機密情報の入力をどうさけるか」といった運用の話は今回はしません。 やったことと起きたこと一通り論文を読んで試したり、試行錯誤しました。 その結果、専門家として業務レベルで使える程度のものができるようになってきました。 クライアントのプロンプトを添削する仕事も増えつつあります。副作用として、日本語なのに日本語と感じられない自然言語に目覚めてきました。この片鱗についてお話しします。 分かったこと分かったこととして、精度を業務レベルで用いるためにまずはじめにとりくむことは下記です。 ・接待モードを切る ・指示の質が

                                    ChatGPTでstep by stepもロールプレイもやめたらプロダクト開発で使える精度になったよ|MRYY
                                  • 架空企業「オニギリペイ」に学ぶ、セキュリティインシデント対策

                                    架空企業「オニギリペイ」に学ぶ、セキュリティインシデント対策:徳丸浩氏が8つの試練を基に解説(1/3 ページ) ECサイトやWebサービスでセキュリティインシデントを起こさないためには何をすればいいのか。2019年12月に開かれた「PHP Conference Japan 2019」で徳丸浩氏が、架空企業で起きたセキュリティインシデントを例に、その対策方法を紹介した。 ECサイトやWebサービスを提供する会社で発生したセキュリティインシデントに関するさまざまなニュースが後を絶たない。どうすればこうしたインシデントは防げるのだろうか。 『体系的に学ぶ安全なWebアプリケーションの作り方』(通称:徳丸本)の筆者として知られる徳丸浩氏(EGセキュアソリューションズ 代表取締役)は、2019年12月に開かれた「PHP Conference Japan 2019」のセッション「オニギリペイのセキュリ

                                      架空企業「オニギリペイ」に学ぶ、セキュリティインシデント対策
                                    • エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく|mtx2s

                                      組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ

                                        エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく|mtx2s
                                      • ITエンジニアが投票した「ITエンジニア本大賞2020」ベスト10発表。「ドラゴンクエストXを支える技術」 「ダークウェブの教科書」など

                                        ITエンジニアが投票した「ITエンジニア本大賞2020」ベスト10発表。「ドラゴンクエストXを支える技術」 「ダークウェブの教科書」など ITエンジニア本大賞は、ITエンジニアに読んでほしい技術書・ビジネス書を選ぶイベントです。 これまで正式名称が「ITエンジニアに読んでほしい!技術書・ビジネス書 大賞」で通称として「ITエンジニア本大賞」と呼ばれていましたが、今回から「ITエンジニア本大賞」が正式名称となりました。 「ITエンジニア本大賞」の主催は翔泳社ですが、対象となる書籍は出版社を問わず技術書、ビジネス書全般。刊行年も関係なく、この1年を振り返っておすすめしたい書籍となっています。 今回発表されたのは技術書部門ベスト10とビジネス書部門ベスト10です。このなかから特に投票の多かった技術書3冊、ビジネス書3冊について、同社が2月13日、14日に開催するイベント「Developers S

                                          ITエンジニアが投票した「ITエンジニア本大賞2020」ベスト10発表。「ドラゴンクエストXを支える技術」 「ダークウェブの教科書」など
                                        • 取り返しのつかない我がエンジニア人生よ

                                          ここには年に1回くらい殴り書きしてるんだけど、史上最大に気持ち悪いおじさんの自分語りになってしまった。というか長すぎ。誰が読むんだ、これ。 自分は33歳、妻と未就学児1人の計3人で、人口100万人以上のそこそこの地方都市に暮らしている。 会社は子会社系のSIer。新卒で入った。これがまあ、ネットでよく馬鹿にされるような典型的な時代遅れの会社だった。 正直、入社時は「エンジニアとして働く」「会社の安定性」の両方が満たせそう、ぐらいの浅はかな考えだった。で、実際のところ大企業である親会社の盾もありまあ、安定していた。競争原理が働かず仕事は嫌でも降ってくる。給料は年功序列で上がっていき、昨年の年収は大体月20時間の残業で600万だった。世間的にはそこまで高いとは思わないんだけど、この会社の外での自分の市場価値を考えれば高いと思っている。 一方でエンジニアとしてはそりゃもうひどい環境だった。10年

                                            取り返しのつかない我がエンジニア人生よ
                                          • コード品質はやはりビジネスに影響を与える - mtx2s’s blog

                                            私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト

                                              コード品質はやはりビジネスに影響を与える - mtx2s’s blog
                                            • 誰も教えてくれないSIの本質、SIerの世界観

                                              本記事について 国内の IT 業界について、ネット上では「SIer」VS「Web系」の構図がしばしば見られる。本記事は前者、SIer の世界観をひとりの当事者として雑多にまとめたものである。記事としては読み物、特にポエムの類。 対象読者 以下を想定する。 ITエンジニアまたはその卵で、 SIerを知らないWeb系の人 SIerに入社した新人や中途入職者 SIerにてSEまたはマネージャーして働いている者 SIerにてSEではないが裏方で働いている者(開発、研究、調査、教育、管理など) 学習や就労の初歩として参考にしてもいいし、議論やキャリアのダシに使っても良いだろう。 筆者について 吉良野すた: https://stakiran.github.io/stakiran/ 国内の大手 SIer に勤めるサラリーマン。現場には出ておらず、裏方で支えてメシを食べている。SI にも IT にもさほど

                                                誰も教えてくれないSIの本質、SIerの世界観
                                              • 目標設定の基本

                                                NTT Com Open TechLunch #7「エンジニアリングマネージャー と 目標設定」の登壇資料です。20分くらいの短いセッションなので網羅的ではありません 2. 吉羽龍太郎 / Yoshiba Ryutaro アジャイル開発、DevOps、クラウドコンピューティング、インフラ構築自 動化、、組織改革を中心にオンサイトでのコンサルティングとトレーニン グを提供。Scrum Alliance認定スクラムトレーナー(Regional, CST-R) チームコーチ(CTC) / 認定スクラムプロフェショナル(CSP) / 認定スク ラムマスター(CSM) / 認定スクラムプロダクトオーナー(CSPO) 2

                                                  目標設定の基本
                                                • 「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に

                                                  Search, watch, and cook every single Tasty recipe and video ever - all in one place! News, Politics, Culture, Life, Entertainment, and more. Stories that matter to you.

                                                    「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に
                                                  • 「ドキュメントの書き方」を体系的に学んだことがないエンジニアへ 書籍『エンジニアのためのドキュメントライティング』の概要

                                                    インフラエンジニア向けの書籍を取り上げ、著者と出会い、楽しく本を知り、仲間を作る場所である「インフラエンジニアBooks」。ここで、『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の翻訳を担当した岩瀬氏が登壇。まずは、本書籍の概要について話します。 本セッションの対象者と、セッションのゴール 岩瀬義昌氏:ご紹介いただきました、岩瀬と申します。よろしくお願いします。『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』は、もともと『Docs for Developers: An Engineer’s Field Guide to Technical Writing』という洋書だったんですが、その翻訳をして、今回この機会をいただいています。 余談ですが、APC(株式会社エーピーコミュニケーションズ)さんが「カプセルト

                                                      「ドキュメントの書き方」を体系的に学んだことがないエンジニアへ 書籍『エンジニアのためのドキュメントライティング』の概要
                                                    • アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021

                                                      アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか? という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準(37号告示)関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応

                                                        アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021
                                                      • 市場は「なんかいい感じにしてくれる」エンジニアを求めているのではないか - 毎日がもふもふ

                                                        エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。 ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて?どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。 高い技術力よりも「いい感じ」力を求めている エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。 しかし、実際には開発プロジェクトの失敗

                                                          市場は「なんかいい感じにしてくれる」エンジニアを求めているのではないか - 毎日がもふもふ
                                                        • "言われたことしかやらないのはダメ"という日本の考え方は独特→海外委託で衝突する原因やマネジメントの機能の話へ

                                                          syacyo @syacyo_twit みずほの件がお昼のニュースで取り上げられてたけど『言われたことしかやらないような担当者の意識を改革する』って言ってた。 これは日本独特の考え方。日本以外の作業者は普通は言われたこと以外はやらない。なので欧米はマネジメント層が優秀だし高給。 syacyo @syacyo_twit 日本は精神論、根性論を盾にマネジメント層が圧力をかけて作業者がなんでもかんでも気を利かせて動くように強要する文化ができあがってしまっている。 本来はマネジメントする側が綿密に各自の作業内容を分担して、それ以外はやるな、とまで指示するのが正しい姿なのよ。 syacyo @syacyo_twit だからオフショア開発で外国勢に作業依頼したときに成果物が酷くてなぜ◯◯していないんだ、と問い合わせると オフショア『それは指示されていない』 と普通に返ってくる。 これで怒る日本人は自ら

                                                            "言われたことしかやらないのはダメ"という日本の考え方は独特→海外委託で衝突する原因やマネジメントの機能の話へ
                                                          • 要件定義~システム設計ができる人材になれる記事 - Qiita

                                                            はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの?」 「要件定義ってなに?」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に4つも壁が存在するのです。 そのため、本記事では実装(プログラミング)を開始する前に必要となる、 『企画~設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装(プログラミング)に使用する時間

                                                              要件定義~システム設計ができる人材になれる記事 - Qiita
                                                            • GPT-4時代のエンジニアの生存戦略 - Qiita

                                                              GPT-4時代のエンジニアの生存戦略 ※ この記事の内容の一部はこちらのイベントでお話したことと重複します。 はじめに 2023年3月1日にOpenAI社よりChatGPTのAPIが公開されました。 さらに14日にはGPT-4が登場し、その翌々日にはMicrosoft 365 CopilotでGPT-4をOffice製品に搭載することが発表されるなど、AI領域で大きな変化が起きています。 変化の速度の速さと変化量の大きさにより、私自身も追いつくのが精一杯な状態です。 個人的には、iPhoneの登場時以上の衝撃を受けています。 人類の歴史上、過去3回AIブームがありました。Generative AIが4回目のブームになります。 そして、特に日本においては顕著なのですが、AIへの過度な期待とそれへの失望の繰り返しがここ数十年にわたって繰り返されてきました。 直近だと数年前のDeep Learn

                                                                GPT-4時代のエンジニアの生存戦略 - Qiita
                                                              • システム開発に銀の弾丸はないが「金の弾丸」ならある『人が増えても速くならない』

                                                                例えばソフトウェア開発において、 人が増えても納期が短くなるとは限らない 見積もりを求めるほどに絶望感が増す 納期をゴリ押すと、後から品質はリカバリできない これを見て、「だよねー」「あるあるw」という人は、本書を読む必要はない。 プログラミングは人海戦術で何とかならないし、「厳密に見積もれ」というプレッシャーは見積額を底上げするし、納期が優先されて切り捨てられた品質は、技術的負債として残り続ける。経験豊富なエンジニアなら、大なり小なり、酷い目に遭ってきただろうから。 だが、これらを理解できない人がいる。 要員を追加して、手分けしてやれば一気に片付くはず 厳密にやれば、見積りバッファーはゼロにできる 品質のことはリリース後にじっくりやればいい ……などと本気で考えている。これは、ソフトウェア開発とはどういうものか、特性を知らないからだ。こんな無知な人間が経営層にいたり、顧客の代表となった場

                                                                  システム開発に銀の弾丸はないが「金の弾丸」ならある『人が増えても速くならない』
                                                                • 転職活動の面接でいただいた質問集 - Qiita

                                                                  この度転職活動を行って無事内定をいただいたので、記念に面接の中でいただいた質問をまとめてみました。 某大手金融のフィンテックエンジニアに転職します!! 転職活動当初は、レガシー、ジョブホッパー、経験少でダメ出しの嵐🍃 でも諦めずNuxt+Firebaseでのサービス開発、マイクロサービス化ポートフォリオ、CTFの取組、GitHub毎日コントリビュート、個人活動も頑張って内定頂けて本当よかった😁 — bindingpry (@bindingpry) November 19, 2021 基本的に技術面接では、履歴書や実務経験の技術、ポートフォリオで扱っている技術、自分で口にした技術を深ぼられることが多かったです。 そこはしっかり技術を扱えるだけでなく説明できるようにすることも必要だと思いました。(自分は最初ボロボロでしたが笑) また正社員の面接では技術と同等に、仕事への姿勢、性格、事業への

                                                                    転職活動の面接でいただいた質問集 - Qiita
                                                                  • プロダクトマネジメントを学ぶための推しの書籍

                                                                    プロダクトマネジメントを学びたい人、プロダクトマネージャーにおすすめの書籍です。 以下、記載した書籍のリストです ## Product Management ### プロダクトマネジメントを広く理解する 「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」オライリージャパン (2020/10/26) https://www.amazon.co.jp/dp/4873119251/ 「プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで」翔泳社 (2021/3/3) https://www.amazon.co.jp/dp/4798166391/ 「INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント」日本能率協会マネジメントセンター (2019/11/1) https://www.amazon.co.jp/dp/4

                                                                      プロダクトマネジメントを学ぶための推しの書籍
                                                                    • ラバーダッキング法とは?悩みや問題解決に効果的な実践方法をご紹介!

                                                                      ラバーダッキングとは問題解決手法の1つに、「ラバーダッキング」というものがあります。IT用語的にいうと「ラバーダック・デバッグ」とも呼びます。ラバーダックはゴム製のアヒルの玩具で、幼児がお風呂に浮かべて遊ぶ姿を見たことがあると思いますが、あのアヒルの玩具です。そんなものが問題解決にどう役立つのか信じられない方もいますよね。 ここでは、ラバーダッキング法を活用した問題解決方法について紹介していきます。 やり方は非常にシンプルです。 ・机の上など、目につくところにラバーダックを置きます。(ラバーダックが入手できなければ、小さなマスコットキャラクターでも可) ・現在、頭を悩ませていることをラバーダックに向かって、声を出しながら話します。 ただこれだけのことですが、声に出して悩みを説明する過程で、「何について悩んでいるのか」「その解決策は何か」ということが次第に見えてきます。 IT系のエンジニアな

                                                                        ラバーダッキング法とは?悩みや問題解決に効果的な実践方法をご紹介!
                                                                      • 【資料公開】マネジメント向けアジャイル開発概要

                                                                        みなさんこんにちは。@ryuzeeです。 2020年1月20日にとある企業の経営レベルの方向けにアジャイル開発の概要について説明した際の資料を公開します。 自社で経営者の方やマネージャーの方にアジャイル開発がなぜ必要なのかを説明する際の参考になれば幸いです。 (スライドはこちらからもご覧いただけます:https://slide.meguro.ryuzee.com/slides/101) 本資料は、なぜ今アジャイルが必要なのかという点をまず理解していただけるようにコンテキストのすり合わせに主眼を置いています。 経営者やマネージャーの方にとってはスクラムの具体的なやり方といった手法部分はあまり関係なく、それによって組織がどういう影響を受けるのか、組織としてどんな取り組みをすべきなのかが分かることが重要なためです。 単一チームや小さなプロダクトでアジャイル開発をするのと、組織的にそれをスケールし

                                                                          【資料公開】マネジメント向けアジャイル開発概要
                                                                        • 要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経

                                                                          タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す

                                                                            要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
                                                                          • デザインに活かせるフレームワーク20|金 成奎

                                                                            久しぶりのnote投稿です。今回は自分の勉強がてら、UX・情報設計・アジャイル開発など、デザインに関わる様々な局面で知っておくと役立つフレームワークを集めてみました。 有名なものからデザイン以外にも使えそうなものまで幅広く選んでいますので、気になるものがあれば改めて実作業に生かすなり、掘り下げて研究するなり、資料に生かすなりしてもらえると良いのではないかと思います。 (ちなみにここでいう「フレームワーク」とは共通して用いることのできる考え方や思考の型や枠のようなもので、いわゆるCSSフレームワークの類ではありませんので、その点ご了承ください) 1.UXの5段階モデル まずは有名なUXの5段階モデル。アメリカのUXデザイナーであるJesse James Garrett 氏が著書『Elements of User Experience(ウェブ戦略としての「ユーザーエクスペリエンス」)』にて提唱

                                                                              デザインに活かせるフレームワーク20|金 成奎
                                                                            • 転職活動の面接でいただいた質問集 - Qiita

                                                                              この度転職活動を行って無事内定をいただいたので、記念に面接の中でいただいた質問をまとめてみました。 某大手金融のフィンテックエンジニアに転職します!! 転職活動当初は、レガシー、ジョブホッパー、経験少でダメ出しの嵐🍃 でも諦めずNuxt+Firebaseでのサービス開発、マイクロサービス化ポートフォリオ、CTFの取組、GitHub毎日コントリビュート、個人活動も頑張って内定頂けて本当よかった😁 — bindingpry (@bindingpry) November 19, 2021 基本的に技術面接では、履歴書や実務経験の技術、ポートフォリオで扱っている技術、自分で口にした技術を深ぼられることが多かったです。 そこはしっかり技術を扱えるだけでなく説明できるようにすることも必要だと思いました。(自分は最初ボロボロでしたが笑) また正社員の面接では技術と同等に、仕事への姿勢、性格、事業への

                                                                              • ユニコーン企業のひみつ

                                                                                「ユニコーン企業のひみつ」という本を読んだ。 本旨は、成功したスタートアップ企業、所謂ユニコーンの開発手法や組織は、エンタープライズ系開発を主としている企業とは違うものですよ、という話である。 そしてそれらの企業が具体的にどういうやり方で彼らのプロダクトを開発しているのかを書いている。 ちなみにタイトルにユニコーン企業とあるけれど、別にユニコーン(評価額10億ドル以上の未上場企業)に限った話ではなく小さなスタートアップからGoogleのような既に上場して随分経っている巨大企業まで共通した話だと思う。著者もとくに区別しているわけではなく単にSpotifyで働いた経験から書いたからそのようなタイトルにしたというだけみたいだ(Spotifyもすでに上場しているので厳密にはユニコーンではない)。まあスタートアップは立ち上げのタイミングでは組織も何もないので、タイトルにあるユニコーンというのは、一応

                                                                                  ユニコーン企業のひみつ
                                                                                • SIerで幸せな技術キャリアを築くために - Qiita

                                                                                  この記事はNTTコムウェア Advent Calendar 2021 20日目の記事です。 NTTコムウェアの古西です。AI・データサイエンス推進室で技術マネージャをしています。 システムインテグレーター、略してSIerは、顧客のためにITシステムやサービス・ソリューション・プロダクトを開発・運用する会社です。一部自社サービスがあるものの、特定の顧客企業に対してシステムを提供することが多いです。 ネット上では「SIerはオワコン」1と言われることもありますが、私自身は入社のときに「人と技術を仲介する仕事がしたい」と言って仕事をしはじめてから約25年間、SIerで顧客や自社の人と技術を仲介する仕事をしてきました。私がこれまでの経験から「SIerで幸せな技術キャリア」を築くために意識したほうがいいと思うことを、若年層とベテラン層にわけて3つずつ、書いておこうと思います。 若年層(20代~30代

                                                                                    SIerで幸せな技術キャリアを築くために - Qiita