５年やって分かった要件定義に必須な５つのスキルとその上達方法 - みんなのシステム企画
「要件定義のスキルを上げたいけどどうしたら良いかわからない」 こんなふうに悩んだことはないだろうか。 要件定義ではかなり幅広いスキルが求められる。さらに要件定義の対象は毎回異なるため、具体的なレベルでスキルを言語化するのがかなり難しく、どうしてもスキル定義が「コミュニケーションスキル」や「ビジネス理解スキル」といった抽象的な言葉になりがちだ。 そこでこの記事では、要件定義を第一線で実行してきた私が、要件定義を構成するスキルを以下の５つに分解し、それぞれの向上のための方策も可能な限り具体化した。 ・論理的に物事を整理するスキル ・ビジネスの数字を理解するスキル ・業務のフローを理解するスキル ・要求を具現化するスキル ・要求を達成するために必要な機能を洗い出すスキル それでは一つずつ見ていこう。 １ 要件定義をするために必要な5つのスキル この章では、要件定義に必須なスキルとそれがなぜ必要な
最初から強いやつの特徴 - Qiita
はじめに どんな仕事でも強い人は存在する。 でも最初から強い人は珍しい。 これは、web 業界に身を置いてみて、信じられないくらいムキムキになっていった人たちを見てきた私が送る こうしたら強くなれるかもしれない？指南書である。もしエンジニア職に興味があるのであれば、一考になるかもしれない。 最初から強いやつの特徴 平日の稼働時間以外も勉強 or 開発する 土日も勉強 or 開発する 公式ドキュメントをちゃんと読む 以上のような当たり前のことは、最初から強い人じゃなくてもやるので特徴に入れません。 1. 読解能力が異常に高い 国語の力です。 これは、ちゃんとドキュメントに書いてあることが理解できると同義です。 そしてこれが本当に大事です。 強い人に質問すると必ず「ん？ Docs 読んだ？」って聞いてきます。私は (...読んだわ！) って内心思ってますが、それは読んだだけです。内容をちゃんと
20年間ソフトウェアエンジニアとして働いて学んだ20個のことまとめ
By Sergey Galyonkin ソフトウェア開発企業・Simple Threadの創設者であるジャスティン・エセリッジ氏が、ソフトウェアエンジニアとして20年活動した経験を基に、学習において重要なポイントやコーディングにおいて意識するべきポイントなどを20個にまとめて公開しています。 20 Things I've Learned in my 20 Years as a Software Engineer - Simple Thread https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/ ◆1：自分がまだ多くを知らないことを自覚する エセリッジ氏は、たとえ何十年間ソフトウェアエンジニアとして働いたとしても、それぞれのエンジニアが持つ知識には違いがあり、他のソ
「未経験で自社開発やってる会社に行きたい」という方に伝えていること。｜おざまさ
有名企業のエンジニアから実務が学べるオンラインコミュニティ「TechTrain」を運営している小澤と申します。 サービス開始から2年弱が経ち、現在約2,000名のU30のエンジニアを目指す方にご利用いただいています。（いつもありがとうございます🙇♂️） 私自身もキャリアアドバイス（漠然とした悩みを一緒に言語化したり）と、リクルーティングアドバイス（企業への紹介や面接練習）を担当させていただき、サービスの中で少なくとも500人以上の方とお話させていただきました。（前職でもエンジニア採用を7年半やっていたので、わりと沢山のエンジニア・エンジニアを目指す方とお話させていただきました。 今回はそのなかで、未経験者や駆け出しエンジニアのみなさんに普段面談でお伝えしていることをまとめてみます。 ※決して上記の方がエンジニアを目指すことが悪いわけではなく、応援しているのですが、ここ数年誰かが何かを布
プログラムを教えて理解されない場合は教える技術の不足 - きしだのHatena
プログラムが組めるとプログラムが教えれると思いがちだけど、教えることは別の技術です。 教えてもなかなか理解してくれないとき、プログラミングに向いてないとさえ言う人もいますが、教える側の教える技術の不足です。 教えることも技術のひとつだと気付けば、教えてもなかなか理解してくれないときに技術の不足であるということにも思い至れると思います。技術の不足であると気付けば、改善もしていけます。 そして教える技術というのは、インストラクショナルデザインという名前で系統だてて整理されています。 たとえばそのまま「インストラクショナルデザイン」など、タイトルにインストラクショナルデザインが含まれた書籍もたくさん出ています。 インストラクショナルデザイン―教師のためのルールブック 作者:島宗 理発売日: 2004/11/01メディア: 単行本 他にも、タイトルにはインストラクショナルデザインとついてないけどイ
天才プログラマーの「締切に対する考え方」に、感銘を受けた。
わたしは、ビジネスノウハウ本が嫌いだ。大嫌いだ。 個人で効率化できる部分なんてかぎられているのに、「お前が努力すれば成果を出せる」的なのが気に食わない。 それなら先に、ムダな会議を減らせって話だ。 ……というひねくれ者のわたしだが、とある本に出会って、自分でもちょっと戸惑うくらい感銘を受けてしまった。 どうやらわたしは今まで、”2流”のビジネス書しか知らなかったらしい。 Windows95の基礎をつくった天才プログラマーが語る、3つの仕事術 わたしが手に取ったのは、『なぜ、あなたの仕事は終わらないのか』という本だ。 ふだんこういった本はあまり読まないけど、kindle Unlimitedで読めるし、評価が高かったから、気まぐれでダウンロードしてみた。 著者は中島聡氏。 1960年北海道生まれ。早稲田大学高等学院、早稲田大学大学院理工学研究科修了。 高校時代からパソコン系雑誌『週刊アスキー』
【SIer新人向け】研修では教えてくれないノウハウ集 - Qiita
「ようこそ 魔境 SIerへ！」 はじめに この記事は、SIer（Systems Integrator）に入ったシステム開発未経験者の新人さんたちへ送る、研修では教えてくれないノウハウ集です。 実際、弊社の長い研修では実務に使えそうなことをあまり教えてくれませんし、ノウハウは現場の人の頭にしかない状態なので、新人さんは暗中模索で仕事を覚えていくことになります。 それも非効率なので、実際に私が２年半1で失敗したこと、やってきてよかったこと（ノウハウ）を体系化したので共有します。 新人さんは、これを参考として、使えるところだけ今後の業務に持っていってください。 （本当はガッツリ社内向けに書いたものなので、一部汎用的でない表現がありますがご了承ください。） 目次 業務面 技術面 プライベート面 の三本柱でお送りします。 対象読者 SIerの1,2年目相当であり、学生時代に契約のあるシステム開発を
新人プログラマのうちに身に付けたい習慣、考え方（この半年で学んだことと反省） - Qiita
新人プログラマのうちに身に付けたい習慣（この半年で学んだことと反省） はじめに 半年よりちょっと前に未経験からプログラマになりました。 プログラマと言っても、この約半年間はほとんど研修を受けさせていただいていた感じなので、偉そうなことは言えません。 しかし、この約半年で反省したことや学んだことを自戒の念も込めて、まとめました。 主体的に学ぼう 能動的に自ら学び、自走しましょう。 新しい技術を学ぶということは非常に楽しいことです。 すごい先輩方は大抵、新しい技術を身につけるためにその技術を学ぶことを「その技術を勉強した」というよりも、「その技術を使って遊んでみた」と表現している気がします。つまり、必要だからしょうがなく学ぶのではなく、半ば趣味として新しい技術で遊んでいたら、身についたーという感じでしょう。 教えてもらって学ぶという姿勢ではなく、自ら楽しいから学ぶ(=その技術で遊んでたら身につ
よりよいプログラマになる10の黄金則 - YAMDAS現更新履歴
10 golden rules for becoming a better programmer | codeshare.co.uk .Net Web Developer Blog by Paul Seal この手の記事には食傷気味だが、学ぶべき教訓には学んだほうがいいわけで、果たしてここではどんな10個のルールが示されているのか。 同じことを繰り返さない（コードのリファクタリングの勧め） 変数には、それがどんな型かではなく、それが何のためにあるか分かる名前をつける メソッドには、それが何をするか明確に分かる名前をつける マジックナンバーや文字列リテラルは使わない 可能であれば、メソッドはそのアプリの他の部分に依存性を持つことなくテストできるよう書く 助けを求めるのを恐れない（やってることを他人に説明するプロセスが問題解決につながることもある） ボーイスカウト・ルールに従う（バグのあるコー
良いエンジニアの定義
今年は転職して働く環境が変わり、自分のエンジニアとしての能力が足りないと痛感させられることが何度もあった。しかしそれは技術力が足りないというよりも、もっとほかのもののように思えた。良いエンジニアとは何なのかについて、今年一年で考えたことを書いてみたい。 良いエンジニアとは何だろうか。技術力が高ければ当然に良いエンジニアと言えるのだろうか。そもそもエンジニアに必要なスキルとは何だろうか。技術力がまず挙げられるだろう。良いエンジニアは当然に高い技術力を持っていて生産性が高いはずだ。 技術力に加えて、プロジェクトマネジメントのスキル（以下プロマネ力と省略）も必要なのではないだろうか。これまでの自分の経験を振り返るに、技術的に秀でたエンジニアはプロマネ力も兼ね備えていることが多いと感じる。技術力が高いエンジニアはプログラミングの能力が高いので、組織や開発体制を「プログラム」する能力が培われるのかも
エンジニアが勉強し続ける理由 - mike-neckのブログ
これはほとんどネタです。 ここ最近、マルクスを再読していました。貧富の格差、貧困の問題とかワーキングプアーなどがニュースになっていることを見るにつけ、マルクスが気になっていたからです。マルクスが資本論を書くための準備していた時期の『経済学・哲学草稿』などに、貧富の格差、ワーキングプアーといった今とまったく同じ問題が記述されていたので、マルクス経済学は超克したとかいいつつ、実は全く何も超克していないのだと思いつつ有ります。 時折、話題になる労働に関するテーマなどがあり、それらについてもマルクスの著書ですでに述べられていることがあったりします。 例えば、エンジニアが勉強し続けることについてです。 今年、このことの元になった記事はこれだと思います。 101回死んだエンジニア: 業務時間外で勉強をしなければいけない理由 簡単にまとめると、技術者は技術だけが武器であり、それが通用しなくなると歪んだ環
よく言われるけど、業務時間外に勉強しない人はITエンジニア失格なの？ - paiza times
Photo by Indi Samarajiva こんにちは、谷口です。 「ITエンジニアは業務時間外にも勉強をすべきなのか」という問題について、皆さんはどう思われますでしょうか。 少し前には、こちらの記事も話題になりましたね。 業務時間外で勉強をしなければいけない理由：101回死んだエンジニア：エンジニアライフ 今回は、そんなITエンジニアの業務時間外での学習について考察していきたいと思います。 ■企業からの「教育」と自分でする「学習」 業務で必要な知識等について、企業側もある程度は「教育」をすることがあるかと思います。特に新卒の場合、新人研修として業務知識を学ぶ期間が多くの企業で設けられているかと思います。仕事で必要な業務知識に関しては、企業の研修を受けるだけではだめなのでしょうか。 まずは、「教育」と「学習」の概念について考えてみましょう。 「教育」とは、組織の求めるスキルを個人に習
開発スピードをあげるには - パルカワ2
「開発スピードをあげろ！」と言われる事は多々ある。 実際にチームの開発スピードが遅かったとしたら、それは開発チームがなにかしらの問題を抱えている事になる。それに対して、偉い人達は「とりあえず開発者を増やせばスピードがあがるはず！」と人を追加する。しかし、根本的な問題は解決していないので、大きくスピードは上がらない、もしくは逆に遅くなってしまう事がある。 開発にかかる時間をざっくり分解すると「仕様決め」「コードを書く」「検証」の3つに分ける事が出来る。つまり「仕様決め」「検証」を効率良く進めて「コードを書く」時間を増やす。また「コードを書く」事自体を効率良く進める事が、開発スピードを上げる事だと考えられる。なので、3つのフェーズの問題点とそれらの解決方法を考える必要がある。 例えば、「仕様決め」の問題点は 仕様が決まらず、MTGの時間が長い 仕様を決める人がいない 誰かに確認する事が多い 開
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
What's New in SQL2016 CTP2 Release - MSDN Blogs
In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...
ある程度の年齢を迎えたプログラマが抱える悩み - bkブログ
ある程度の年齢を迎えたプログラマが抱える悩み ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。 この問題のひとつの解決策は、プログラマ以外の仕事のポジション（たとえば管理職など）に移ることですが、他のポジションには向いていない、まだまだ現役でプログラマをやりたいという場合にどんな戦略があるか考えてみました。なお、後述するように、以下に挙げた戦略は相反するものではなく、組み合わせが可能です。 エキスパート戦略 この分野ではトップクラス、というレベルの専門性を身につけ、その分野に特化してキャリアを築くという戦略です。たとえば、ネットワークやセキュリティといった分野で一流と認められる専門
優れたエンジニアになる方法と、その知識を伝達する方法
世界で最も見られているWebページの1つ、Yahoo!のホームページを担当しているのが、同社のプリンシパル・フロントエンド・エンジニアのNicholas C. Zakas氏。Zakas氏のブログ「NCZOnline」、8月21日付けのエントリは「What makes a great software engineer?」でした。 Zakas氏が考える優れたエンジニアとはどういう人なのでしょう？ 彼のアドバイスはWebに関わるエンジニアに限らず、あらゆるエンジニアに共通するもののように思えます。 What makes a great software engineer? 長文のエントリの中から、ポイントとなりそうな部分を抜粋して紹介します。 Always do it the right way There's an "emergency" project, or something that
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
