プロフィールPROFILE

とあるSWエンジニアさんのプロフィール

住所
未設定
出身
未設定

自由文未設定

ブログタイトル
とあるソフトウェアエンジニアのつぶやき
ブログURL
https://toarusw.hatenablog.com/
ブログ紹介文
とあるソフトウェア開発会社の、とあるソフトウェアエンジニアです。 C言語、C++、Java、Pythonなど。最近はMATLABも。 開発者の目線で語っていきたいと思います。
更新頻度(1年)

15回 / 61日(平均1.7回/週)

ブログ村参加:2019/10/07

とあるSWエンジニアさんのプロフィール
読者になる

とあるSWエンジニアさんの人気ランキング

  • IN
  • OUT
  • PV
今日 12/07 12/06 12/05 12/04 12/03 12/02 全参加数
総合ランキング(IN) 37,661位 37,729位 37,792位 37,819位 37,931位 37,890位 34,064位 980,088サイト
INポイント 0 0 0 0 10 0 10 20/週
OUTポイント 0 0 0 0 10 0 10 20/週
PVポイント 0 0 0 0 50 10 30 90/週
サラリーマン日記ブログ 196位 197位 195位 203位 200位 199位 155位 11,543サイト
IT技術ブログ 144位 142位 144位 144位 145位 146位 120位 7,921サイト
ソフトウェア 14位 14位 15位 14位 13位 13位 13位 554サイト
プログラム・プログラマー 17位 18位 20位 20位 20位 23位 15位 789サイト
今日 12/07 12/06 12/05 12/04 12/03 12/02 全参加数
総合ランキング(OUT) 61,441位 56,702位 56,741位 56,672位 56,847位 56,978位 52,602位 980,088サイト
INポイント 0 0 0 0 10 0 10 20/週
OUTポイント 0 0 0 0 10 0 10 20/週
PVポイント 0 0 0 0 50 10 30 90/週
サラリーマン日記ブログ 288位 254位 252位 257位 257位 261位 229位 11,543サイト
IT技術ブログ 181位 157位 158位 150位 160位 162位 128位 7,921サイト
ソフトウェア 18位 17位 17位 14位 16位 16位 15位 554サイト
プログラム・プログラマー 23位 23位 22位 24位 20位 22位 18位 789サイト
今日 12/07 12/06 12/05 12/04 12/03 12/02 全参加数
総合ランキング(PV) 18,213位 17,681位 17,691位 17,710位 17,786位 17,790位 17,464位 980,088サイト
INポイント 0 0 0 0 10 0 10 20/週
OUTポイント 0 0 0 0 10 0 10 20/週
PVポイント 0 0 0 0 50 10 30 90/週
サラリーマン日記ブログ 143位 140位 139位 140位 141位 139位 138位 11,543サイト
IT技術ブログ 168位 168位 166位 165位 167位 164位 165位 7,921サイト
ソフトウェア 12位 12位 12位 12位 12位 12位 12位 554サイト
プログラム・プログラマー 17位 17位 17位 17位 17位 16位 16位 789サイト

新機能の「ブログリーダー」を活用して、とあるSWエンジニアさんの読者になりませんか?

ハンドル名
とあるSWエンジニアさん
ブログタイトル
とあるソフトウェアエンジニアのつぶやき
更新頻度
15回 / 61日(平均1.7回/週)
読者になる
とあるソフトウェアエンジニアのつぶやき

とあるSWエンジニアさんの新着記事

1件〜30件

  • ツール販売方法の調査

    ツール販売を目論み今さらこういった記事を熟読してみる。パッケージ・ビジネスはなぜ儲からないのか https://t.co/sYuaM1aOPO— とあるSWエンジニアのつぶやき (@SW11131900) 2019年12月3日とあるSWエンジニアのつぶやき on Twitter: "ツール販売を目論み今さらこういった記事を熟読してみる。 パッケージ・ビジネスはなぜ儲からないのか https://t.co/sYuaM1aOPO"

  • チェックリストの弊害

    AUTOSARの事よりもこの記事内の「チェックリストは想像力を妨げるという弊害がある」ということに今更ハッとさせられた。AUTOSAR導入初期段階における試作評価の適切な進め方 https://t.co/yWUgdTTXUg— とあるSWエンジニアのつぶやき (@SW11131900) 2019年11月25日とあるSWエンジニアのつぶやき on Twitter: "AUTOSARの事よりもこの記事内の「チェックリストは想像力を妨げるという弊害がある」ということに今更ハッとさせられた。 AUTOSAR導入初期段階における試作評価の適切な進め方 https://t.co/yWUgdTTXUg"

  • ドラえもん感動回に泣くしかない

    子供ができた私には刺さり過ぎる😭あの感動をもう一度!大人気アニメ、ドラえもんの感動名シーン特集!|エントピ[Entertainment Topics] https://t.co/sUidKRTras— とあるSWエンジニアのつぶやき (@SW11131900) 2019年11月18日とあるSWエンジニアのつぶやき on Twitter: "子供ができた私には刺さり過ぎる😭 あの感動をもう一度!大人気アニメ、ドラえもんの感動名シーン特集!|エントピ[Entertainment Topics] https://t.co/sUidKRTras"

  • アジャイル開発の成功事例が出始めている

    嬉しいニュース。こういった取組を素早く吸収できる企業でありたい。アジャイルの成功例がそろそろ出てきている - orangeitems’s diary https://t.co/tnU9lJD1A2— とあるSWエンジニアのつぶやき (@SW11131900) 2019年11月13日とあるSWエンジニアのつぶやき on Twitter: "嬉しいニュース。こういった取組を素早く吸収できる企業でありたい。 アジャイルの成功例がそろそろ出てきている - orangeitems’s diary https://t.co/tnU9lJD1A2"

  • 会社をうまく活用しよう

    会社は利用されるものでは無い。利用するもの。会社でしかできない経験でスキルを上げ、そして自分の為に会社以外のやりたい事でそのスキルを使う。自分の為に生きよう。— とあるSWエンジニアのつぶやき (@SW11131900) 2019年11月7日とあるSWエンジニアのつぶやき on Twitter: "会社は利用されるものでは無い。利用するもの。会社でしかできない経験でスキルを上げ、そして自分の為に会社以外のやりたい事でそのスキルを使う。自分の為に生きよう。"

  • エンジニアあるある#3

    人が作ったものをレビューで指摘するのは大好きでも自分が作ったものを指摘されるとイラッとくる(・д・)#エンジニアあるある— とあるSWエンジニアのつぶやき (@SW11131900) 2019年10月29日とあるSWエンジニアのつぶやき on Twitter: "人が作ったものをレビューで指摘するのは大好き でも 自分が作ったものを指摘されるとイラッとくる(・д・) #エンジニアあるある"

  • エンジニアあるある#2

    人が苦手機会が大好き文句も言わず高速に従順に働いてくれる機械が大好きです#エンジニアあるある— とあるSWエンジニアのつぶやき (@SW11131900) 2019年10月29日とあるSWエンジニアのつぶやき on Twitter: "人が苦手 機会が大好き 文句も言わず高速に従順に働いてくれる機械が大好きです #エンジニアあるある" ↓にほんブログ村ランキングに参加しています

  • 人に頼む秘訣!期待値は下げろ

    開発の現場では自分がやらなければ終わらない、人には頼めない、という状況が多々あります。 説明が下手な人は客先の前には出せないので自分が窓口をしないと怖いとか、 専門知識のいるツールでの開発だから知らない人に頼むと遅いので自分がやるしかないとか。 プレイングマネージャーのような立場になると、客先への説明も必要だし、納期に遅れないようにスピーディーな開発が求められ、何でも自分でやりたくなってしまいます。 実際に、自分が詳しいことは自分がやるのが速いです。 しかし仕事の量は減ることはありませんので、自分がやることを増やすと、確実に負荷が上がることになります。 そうするとどれだけ残業しても立ち行かなく…

  • エンジニアあるある

    いつもやること、標準と感じるものについてはデフォルトと言う。由来はC言語のdefault宣言かな。例「課長はデフォルトで忙しい」「晩飯はデフォルト吉牛」#エンジニアあるある— とあるSWエンジニアのつぶやき (@SW11131900) 2019年10月26日とあるSWエンジニアのつぶやき on Twitter: "いつもやること、標準と感じるものについてはデフォルトと言う。 由来はC言語のdefault宣言かな。 例 「課長はデフォルトで忙しい」 「晩飯はデフォルト吉牛」 #エンジニアあるある"

  • USJ大盛況!10/21は皆休暇だった?

    10/21月曜日、一応平日なのでUSJ行くならこの日が狙い目!と思って家族で行ってみると 大盛況やないかい! 人人人!完全に休日の混雑ぶり。 まずもって、近隣の安い駐車場が根こそぎ満車! 正式な駐車場は高いので、一駅離れた安治川口駅周辺のコインパーキングを利用するのが経済的なのだが午前10時には満車の嵐。 あまりに無いから結局JR野田駅前まで戻ったよ! その後電車で向かってユニバーサルシティ駅に着いたらもう人だらけ。 レストランなんて並ぶ気も起きないし、ちょっとしたポップコーンみたいなものでも長蛇の列。 仕方なくこっそり持参した芋けんぴで我慢! で、ハロウィンパーティーのパレードを見るべく1時…

  • 外注のジレンマ

    ソフトウェア開発では、自社のメンバだけではリソースが足らず、外注発注することが良くあります。 通常、仕事の依頼は、会社に対してするもので、特定の個人に依頼するものではありません。 よって、相手会社のメンバーを指定することはできません。 期待する成果が期限までに納品されれば良いのです。 が、これは正論であって実態は違うことがあります。 実際には例え会社間の場所が離れていても、どのようなスキルの人が開発をしているかが見えてきてしまいます。 それは発注してから納品日までに会社間で様々なコミュニケーションが頻繁に発生するからです。 発注してから納品日まで、進捗把握するための打ち合わせを頻繁にしますし、…

  • 自分が作った所ぐらいきちんと説明して!

    エンジニアとはプログラミングする事が仕事ではありません。 プログラミングは作業の一つであり、実際に必要なのは、顧客の要求に対して、どう考え、どう設計し、どのように検証したかを、説明、保証することです。 プロジェクトのメンバーにはプログラミングだけできればオッケーというスキルの人が稀におられます。 自分が作ったところが、正しく作れていることをうまく説明できない人がいます。 具体的には、 デザインレビューやコードレビューで指摘された箇所に対して、指摘者が納得できる回答ができないような人です。 「仕様書Aの関数Bの処理内容が間違ってます」 と指摘しているのに 「関数Bとついでに関数C,Dも直しました…

  • 会議の在り方、人の時間を食い潰すな!

    会議の目的は様々です。 関係者に ・情報を展開したい ・情報を収集したい ・合意を得たい ・意見交換したい ・テーマに沿って議論したい などなど。 しかし中にはこの目的が不明な会議もあります。 何をしたいのか、誰が何を喋るのか、何の資料を見るのか不明瞭。 誰かがおもむろに喋りだし、誰かが好きなように口出しし、謎の沈黙があったり、イライラして貧乏ゆすりしたり、寝る人が現れたり、もう知っちゃかめっちゃかなやつ。 たまに有るんですよね。 どうして目的を共有しないのでしょうか。 例えば会議に10人が参加し7人は理解してるけど3人は何してるのこれ?って事もあります。 会議の主催者は 参加者の貴重な時間を…

  • 若い頃の未熟な自分を殴りたい

    エンジニアとは技術の側面だけ見られがちですが結局は一人の社会人、企業人であり、組織としてどう振る舞うか、人間性が様々な局面で問われます。 若かりし頃、自分の技術に自身過剰になりプロジェクト全体の調和を考えず、担当範囲外は知りませんの一点張りだった時代。 当時のリーダーがどれほど扱いに困ったか、今の年齢、立場になって身にしみて申し訳なさで一杯になります。 当時の自分を殴りたい、そんな気持ちにもなります。 中堅になってその事に気づけただけまだましかもしれません。 高齢になってもその考えで、私はこれ以上知りませんやりませんという人の多いこと。。 歳とってその意固地なスタンスの人を変えるのは容易ではな…

  • エンジニアなら提案型であれ!

    客先の前に出しにくい社内メンバっていませんか? 技術的にはそこそこなんだけど、客先と面だって会話するには心もとない。。 社内で守られて当たり前、そんな人もいると思います。 ソフトウェア開発に限らずですが、与えられたインプットと与えられた要求だけでやりきれる開発などそうそうありゃしません。 いや実際やりきれない事はないですが、それで良いとは言い難い。 ちゃんと客先に途中成果についてレビューしてもらってフィードバックをもらわないと。 で、こんなの作ってみたらどうでしょう?とかこんなやり方もありますよ?とか提案していかないと! そこで客先から得た意見が次の仕事に繋がったりもします。 でもそういうお客…

  • 不毛な戦い 開発の現場

    ソフトウェア開発、それは殆どの場合、納期に追われた厳しい戦いになります。 それは何故か、なぜいつもそうなってしまうのか、それは 見積もり(計画)と実際の作業量とのギャップがあるからです。 リーダーが何らかの指標を元に見積もりした開発コストをお客さんと交渉し、開発コストをいただくわけですが、殆どの場合見積もり工数はハズレます。 開発メンバのスキル 勉強する時間 機材の調達にかかる工数 管理にかかる工数 色々考えて見積もったはずなのに、それでも足りない、、、 で、当初想定していなかった作業ってなんだろ、って分析すると お客さんの要求は変化する、というところですね 開発していくと、だんだんとプログラ…

  • MBSE (Model-Based Systems Engineering)って何ですの?

    ソフトウェア開発者ならモデルベース開発 (MBD)などは耳にしたことがあると思います。 私も数年、技術的なことを学び、概ね理解したかな、という感じです。 最近の流行り(最近ていうかもっと前からあるけど)では、 MBSE (Model-Based SyStems Engineeiring) という言葉が開発の現場にも浸透してきています。 いったい何者?少しだけ学んだことを整理しておこうと思います。 要するに「モデルを使ったシステム設計」 です。 システム設計ですから、製品開発におけるいわゆる上流フェーズでの工程ですね。 そこでは、作りたいもの・機能・運用方法など、所謂仕様を固めた後、 どうやって…

  • Redmineで工程管理!

    仕事する男性 エクセルでの工程管理は限界だ! そんな思いからプロジェクト管理ツールのRedmineを最近使い始めましたがこれが最初はややこしいのですか慣れると意外と使えます 特に良いのがLychee(ライチ)というガントチャートのプラグイン このプラグインをいれると工程管理、進捗管理がだいぶやり易くなりました フィールドの作り方次第ですが、以下の情報を持つチケットをタスクとして作れば開発メンバーの進捗の見える化は図れるでしょう ・計画工数 ・計画成果物量 ・計画開始日、終了日 ・担当者名 ・達成度 ・ステータス ・実績工数 ・実績成果物量 ・実開始日、終了日 これらの項目をすぐにフィルタ表示で…

  • とあるソフトウェアエンジニアのつぶきやき

    とにかくソフトウェアエンジニアとしてのスキルをアウトプットし、磨きたい!そんな思いでスキマ時間に色々と吐き出すためにブログを解説しました。筆者はとあるソフトウェア開発会社に務めるとあるソフトウェアエンジニアです仕事の内容はもちろん非公開ですが、勤続15年目、下っ端プログラミングからプロマネまでそれなりの経験は積んできました言語で言えばC言語を中心に、C++、Java、Pythonなど様々です最近はMATLABなんかもやりました主な業態は組み込みですが、研究向けのアルゴリズム開発や、アプリケーションを作ることもありますまた民製品から業務用までこれまた様々、最近はもっぱら車載関係が多いです今回はこ…

カテゴリー一覧
商用