ひろみ@人事労務&複業ワーカー @8600hiromi @matudakta ピボットとテーブル使っただけで これ言われました。 つぎ上司に呼び出されたらグループチャットルームにこの画像貼ってメンバーと「呼び出し」を楽しめるようにします。 pic.twitter.com/aEsYq3O9l5 2024-05-06 14:50:01
はじめに 📘 この記事は ラクス Advent Calendar 2023 の7日目の記事になります。 要件定義から基本設計、さらに実装や保守運用に至るまでの一貫した経験を何度か積んできましたが、毎回 「要件定義って具体的に何の項目が必要だっけ?」 「基本設計との違いって何だったっけ?」 「基本設計と詳細設計の区別って?」 といった疑問が頭をよぎってきました。 そんなわけで、これまでの経験を振り返りつつ、開発プロセスについて1からまとめていくことで頭の中の大掃除を行なっていきたいと思います🧹 この記事の対象者 🎯 開発プロセスについて学びたい方 要件定義の基本を学びたい人 要件定義と基本設計の違いがわからない人 一緒に開発プロセスについて復習したい方 前提 記事中の一部(特に要件定義や基本設計、詳細設計のサンプル)を自動生成で作成してます。一貫性の無い内容があるかも知れませんが、あく
タイトルのとおり、生産性向上のためにお金をかけてよかったものをご紹介します。 基本的には仕事道具と健康系が多いです。 腰痛 睡眠 集中力向上 このあたりにお悩みをお持ちの方の一助になれるかもしれません。 おしりセレブ 他のトイレットペーパーだと、おしりを拭いた後大体痛くなってしまいます。 そのまま長時間椅子に座って作業をするのが辛い…というのがあったのですが、おしりセレブを使うようになってからその悩みがなくなりました。 ステッパー メンタリストDaiGoさんがお薦めされていたのを見て購入しました。 もともと腰痛に悩まされており、「少し運動しようか」という日頃ランニングを日課としていました。 が、ランニングのために決まった時間をガッツリ取らないといけなかったり、雨の日はできなかったりという課題がありました。 ステッパーを買ってからは雨でも気にせず有酸素運動ができるし、Amazon Prime
チラシの裏僕たちはまだ本当のウォーターフォールを知らない作成日: 2022/03/01(火) 更新日: 2022/03/01(火) ソフトウェア工学の開発モデルで最も有名なものは、その内容の賛否を問わなければ間違いなくウォーターファールでしょう。現在はアジャイルという概念によって駆逐されている印象ですが、それでも大規模開発ではまだウォーターフォール、またはそれに似ているものが利用されています。 そんなウォーターフォール、初出とされている論文はRoyceによる「Managing the Development of Large Software Systems」[1](以下、原論文と記載)ですが、この論文Waterfallという単語は出てきません。更には一般的なウォーターフォールとは異なります。 本記事ではそんなウォーターフォール開発モデルに付いて詳しく振り返っていき、本当にいいたかったこと
回答 (12件中の1件目) まぁ思ってるかもしれませんが、気にしない事です。 だって彼は先輩なんですから、貴方と同じ位の時間で作っていたら、洒落にならないですし。 それに貴方と同じ位の頃に2〜3時間で作れていたわけではないと思いますよ。経験を数多く踏んで今の速さがあるんだと思います。 ただちょっとに気になることがあります。同期間働いてる他の方の速度はどうなのか?他の方は2〜3日で仕上げてるんだとすれば、貴方が倍時間掛かってる事になり、向いてないんじゃないかと言われかねません。 しかもその先輩プログラマー曰く、時間掛かってるのに「これはやばくない?」と言ってるわけですから、プログラ...
はじめに 「優れているがゆえにあっという間に研究され陳腐化してしまう。」 この現象を、アニメ『葬送のフリーレン』から「ゾルトラーク現象」と呼びます。 この記事では、そんなゾルトラーク現象に共通して、IT業界ではどのような現象が起きているのかを、エンジニア未経験の方にもわかりやすく解説します! “腐敗の賢老”の異名を持つ魔族「クヴァール」が編み出した、人類史上初の人を殺す魔法。 最も被害の大きかった地方では、冒険者の4割、そのうち魔法使いは7割がゾルトラークによって殺されたと言われている。 可能性は常に存在する IT業界では、日々のように新たな技術や情報が生まれています。 規模感の差はあれど、その中にはゾルトラーク現象やその火種が多く存在しています。 IT業界で生き抜くためには、それらの情報に目を光らせ、今後のIT業界の流れを常に予測する能力も必要です。 知識や技術の陳腐化 技術が進化するに
要求はふわっとしている。時間とともに変わりすらする。顧客もよく理解していない。 仕様はカチッとしている。曖昧さがあるべきではない。更新しないかぎり変わらない。ただし解釈は人により変わりうる。 実装は動かない。その挙動がバグか機能かはユーザーが決める。解釈系によって挙動が変わるかもしれないが、解釈系が決まれば挙動は決まる。 仕様そして実装は、ふわっとしていて、絶えず変化する要求に柔軟に対応しなければならない。要求のうち変化しうるものはなるべく実装の上で吸収されるべきであろう。 当初のユーザーが1名だったからといって、1名と決め打ちした仕様にしてしまうと、2名以上のユーザーが発生したときに大幅な仕様変更を伴うかもしれない。 決めるべきは、どこが変化するか。どのように変化するか。 自由変数が多く、自由度が高いほど、工数は増えるであろう。 ファミコンのゲームなどは、一旦発売したら変更は容易ではない
新しいプログラミング言語やライブラリ、フレームワークを学ぶには、実際にそれらを試して挙動などを見てみることが大事ですが、実行環境を用意するのは手間がかかります。 そこで役立つのが、いわゆる「プレイグラウンド」と呼ばれる、Webブラウザでプログラミング言語やライブラリ、フレームワークをすぐに試すことができるサービスです。 主要なプログラミング言語の公式サイトには、実際にその言語をすぐに試せるプレイグラウンドが用意されていることも多く、また公式サイト以外にもネット上にはさまざまなプレイグラウンドがあります。 プレイグラウンドを使えば、気軽にいろんなプログラミング言語やライブラリ、フレームワークを試せます。 この記事ではそうしたプレイグラウンドをまとめてみました。ここで紹介したプレイグラウンドの他にも、あなたのお気に入りのプレイグラウンドがあればX/Twitterやブックマークのコメント、メール
日付や時刻データの扱いについてまとめたスライド「日付時刻A to Z」を作ったので公開します。 これは何?「日付と時刻」を正しく扱うために、日付/時刻にまつわる諸概念やありがちな間違いを紹介したスライドです。このスライドは大きく3つのパートに分かれています: 第1部「日付編」§1 天体の周期§2 暦§3 紀元と通日第2部「時刻編」§4 時間と分§5 秒§6 相対性理論第3部「コンピューティング編」§7 文字列表現§8 数値表現§9 時刻同期第1部と第2部では、「日付」や「時刻」の概念を定めるのに必要な知識を整理します。第3部ではその日付時刻をコンピューターで扱うときに特有の事情を補足しています。 このスライドが作られた経緯ウォンテッドリー社内では毎週1回お昼の時間に任意で集まって技術の話をする "Tech Lunch" というイベントがあります。テーマは自由で、社内でやったことの紹介やアナ
minne事業部のnissyiです。私は最近、運用・開発業務の時間を確保するために、便利なツールを導入したり、ちょっとしたプログラムを書いて自動化したりしています。今回は、日頃の業務の自動化を進めたことで得られたものについて書きます。 自動化を進めたことで得られたもの 身近なところで自動化は可能 自動化の損益分岐点 メンテナンスと分かりやすさ 最後に 自動化を進めたことで得られたもの 早速本題ですが、自動化に取り組むことで以下のようなメリットや学びを得ました。 時間を生み出し、他の仕事に取り組む時間を確保できる 自動化の手段を知ることで、他の場面で応用できる 作業に対して「これは自動化できないか?」と考えるようになる 自動化を進めると、生み出した時間で新たな自動化に取り組めて、さらにそれで時間を生み出して…と複利のように効率化を進められます。 身近なところで自動化は可能 エンジニアの業務に
はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう!』 『今までモック使ってたけど意外とモック使わなくても書けるね!』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 前提の話: この記事の本旨は「テスト書きにくいプロダクトコードも依存関係を排除すれば楽にテスト書けるよ」なので、それ設計的にアウトでは?リファクタリング耐性低くない?みたいな話は度外視してます。
最近キーボードで文字を打つのが面倒になってきている技術本部 Eight Engineering Unitの斉藤です。 キーボードは既に100年以上使われ続けているみたいですね。そろそろ新しい入力の方法ができてもよさそうです。 例えば、頭で考えていることが文字に起こせたら、AIに任せるよりももっと便利だと思います。 前置きはさておき、Sansanではちょっと前にエンジニアの生産性と生産量の最大 化が話題になっていました。このブログをご覧の方ならご存知の方も多いのではないでしょうか。 私はこれまで何度か転職をしていますが、どの職場でも例外なくこの話題が挙がりました。 チームとして、あるいは事業としてどう最大化するかが基本前提となるのですが、私が今回話したいのは個人としての生産性の最大化についてです。 私は個人の生産性を上げることもチームの生産性を上げるのと同じくらい非常に大事なことだと考えてい
会社がリファクタリングに賛同してくれないたったひとつの理由一定の工数をかけてリファクタリングをやったほうがいいことは(少なくとも筆者の観測範囲では)エンジニアリングのバックグラウンドがない人でもだいたい理解しています。 上司の無理解をあげつらっても仕方ありません。 リファクタリングの実施を渋る真の原因が工期や予算の問題であることはあまりないとおもいます。タイミングの問題である可能性はありますが。 必要であればコストをかけることにも同意してくれます。 「技術的負債は過去のビジネス上の選択によって生じたまさに負債なので、計画的に返済しましょう」っていえば、多くの経営者は理解を示してしてくれるでしょう。 本当に無理解ゆえにリファクタリングをしないのであれば技術的には死んでいる組織なので、エンジニアとして幸せになりたい場合は逃げ出したほうが賢明です。 というわけで、本稿ではそういう組織においてもな
昨年NewsPicks さんに取り上げてもらって最近動画が公開されました。そこでもお話させてもらっていることなのですが、アメリカで働きはじめると日本人からすると「納期が無い」感覚が物凄く衝撃的だった。 最近、納期が無いことと生産性について頭の中で整理がついてきたのでシェアしておこうと思う。ちなみに、動画も含めて、私の発言は私の体験と意見であり、所属会社には全く関係が無いことを改めてお断りしておきます。 日米納期の感覚の違い アメリカで働いていると、日本人からすると納期がほとんどないという感じを受ける。もちろん納期があるものもあるが「本当に必要なもの」に限られる。例えば、大きなカンファレンスで何かの製品を発表するとかそんなのだと納期はもちろんある。そうでなれけばほとんど無いという感覚だ。私の所属会社だけではなく、北米の他の会社の人も同じような感覚らしいので文化によるものだと思う。 常に納期が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く