タグ

関連タグで絞り込む (45)

タグの絞り込みを解除

SEに関するyhira0202のブックマーク (35)

  • 若手プログラマー保存版！フローチャート徹底解説と作成カンニングペーパー


    フローチャートを書く能力はプログラマーにとって必須スキルであり、優秀なプログラマーになるための第一歩です。なぜなら、フローチャートの有無、もしくはフローチャートの内容次第で出来上がるプログラムの品質に大きな差が出るためです。だからこそ、若手プログラマーやSE教育の場で必ず登場するのです。 しかし、フローチャートというテーマは、それだけで書籍1冊になるほどの分野であり、多忙なIT業界においていかに効率的に学習するか悩んでいる方も多いと思います。 プログラマーとしてスキルを高めたいが… 実はそもそもフローチャートのことをよく理解していない 最低限の知識で良質なフローチャートを作りたい フローチャートを書くことに自信がないが、今さら人には聞きづらい このようなことをお思いではないですか？このような悩みから解放頂けるよう、最短ルートで良質なフローチャートを書くための方法を1ページにまとめました。
    若手プログラマー保存版！フローチャート徹底解説と作成カンニングペーパー

  • 若手エンジニア必読！超絶分かるユースケース図－全知識と書き方５ステップ


    要求定義フェーズでよく使われるユースケース図。先輩に書けと言われたけど、﹁そもそもユースケース図って何？﹂﹁必要性は？﹂﹁どう書けば良いの？﹂と困っている方も多いのではないでしょうか。 若手SEなど難しいイメージを持っている方も多いですが、実はけして難しいものではありません。この記事で解説している基礎知識を抑えてしまえば、たった5つのステップで作成できてしまいます。 この記事では、ユースケース図の基礎知識から5つの作成ステップまで、エンジニアが抑えておくべきユースケース図の全知識を徹底的に分かりやすく解説します。 この記事を読み終えたとき、若手エンジニアもユースケース図を書けるようになっているでしょう。この記事を参考に、ユースケース図を書いてみましょう。1．ユースケース図とは ユースケース図とは、﹁ユーザーの視点でシステムの利用例を表現する図解術﹂です。 海外では﹁Use Case Di
    若手エンジニア必読！超絶分かるユースケース図－全知識と書き方５ステップ

  • 糞システムにしないため、私ができること『はじめよう！ 要件定義』


    ﹁なぜ糞システムができあがるか？﹂の答えは、﹁一つ前の仕事をしている﹂に尽きる。 詳しくはリンク先を見てもらうとして、まとめるなら、自分の仕事のインプットが出来てないので、仕方なく前工程の仕事を代行しているうちに、リソースと気力がどんどん失われているからになる。これはプログラマに限らず、SEからPM、テスタや運用を入れても、当てはまる。﹁何をするのか﹂が決められない経営層が糞だから、あとはGIGOの法則︵Garbage In, Garbage Out︶に従う。 では、どうすればよいか？ ﹁“何をするのか”を決めてもらう﹂という回答だと、連中と同じ肥溜めに落ちている。なぜなら奴らの“目標”とは、﹁売上を○％ストレッチする﹂とか﹁新規市場を開拓する﹂といった、現状を裏返した願望にすぎないから。売上アップ／新規開拓のために、どこに注力して、何にリソースを使い、そのために必要な道具︵システム︶を“
    糞システムにしないため、私ができること『はじめよう！ 要件定義』

  • 雇用契約と労働契約ってどう違うの？ - SEが契約を勉強してみたブログ


    今日は、ふと気になった 雇用契約と労働契約の違いを調べてみようと思います。 というのも、最近は民法が改正されそうだし、労働基準法が改正されそうだしと、﹁雇用﹂とか﹁労働﹂の環境が大きく変わろうとしています。 で、違いが気になったというわけです。 民法と労働基準法 法律的に調べてみると、 ︵雇用︶ 第六百二十三条 　雇用は、当事者の一方が相手方に対して労働に従事することを約し、相手方がこれに対してその報酬を与えることを約することによって、その効力を生ずる。 民法623条 と ︵労働契約の成立︶ 第六条 　労働契約は、労働者が使用者に使用されて労働し、使用者がこれに対して賃金を支払うことについて、労働者及び使用者が合意することによって成立する。 労働契約法6条 あたりが関係しそうですが、具体的な言葉の定義がいまいちよくわからず、雇用契約と労働契約の違いはわかりません。 労働契約論争 さらに調査
    雇用契約と労働契約ってどう違うの？ - SEが契約を勉強してみたブログ

  • インフラ系SEだけど質問ある？ : キニ速

  • はてなブログ | 無料ブログを作成しよう


    ネイルで使う材料で、DIY時の木割れやネジ跡を派手にしたらかわいい OSB合板でちょっとしたボックスをつくりました。 ビス止め下手すぎて木を割ったり穴あけすぎたりした場所に、好きな派手色の樹脂を詰めてパテ代わりにしてみました。 ちょっと某HAYっぽみ出て可愛かったので、自分用にメモです。 手順 塗装 派手色グミジェルで失敗部分…
    はてなブログ | 無料ブログを作成しよう

  • はてなブログ | 無料ブログを作成しよう


    週報 2024/04/28 川はただ流れている 4/20︵土︶ 初期値依存性 さいきん土曜日は寝てばかり。平日で何か消耗しているらしい。やったことと言えば庭いじりと読書くらい。 ベランダの大改造をした。 サンドイッチ 一年前に引っ越してからこんな配置だったのだけど、さいきん鉢を増やしたら洗濯担当大臣の妻氏…
    はてなブログ | 無料ブログを作成しよう

  • わたしが知らないスゴ本は、きっとあなたが読んでいる: いきなりコンサルタントに抜擢されたSEが読むべき4冊目


    このエントリは、﹁いきなりコンサルタントに抜擢されたSEが読むべき3冊﹂[参照]の続きになる。 ﹁コンサルタント﹂と一緒に仕事をしたことがあるだろうか?肩書だけのなんちゃって自称コンサルではなく、McKinsey & Company や accenture といった、それでメシ喰っている連中のことだ。 彼らの阿呆ほどの猛仕事ぶりは、﹁マッキンゼーITの本質﹂[参照] に書いたが、仕事の順序というか、ダンドリの要領よさについては常々不思議に思っていた。﹁俺たちに明日はない﹂という言葉がピッタリの猪突猛進なのだが、仕事のやり方は整然粛々としている。見た目のロジカルさだけでなく、コンサルティングの仕事そのものが、あたかも何かのマニュアルに従っているかのような感じがしてならなかった。 その予感はあたってた。マニュアルを見つけたんだ。それは、﹁情報システム計画の立て方・活かし方﹂。いや、その辺に転
    わたしが知らないスゴ本は、きっとあなたが読んでいる: いきなりコンサルタントに抜擢されたSEが読むべき4冊目

  • わたしが知らないスゴ本は、きっとあなたが読んでいる いきなりコンサルタントに抜擢されたSEが読むべき3冊


    この記事のまとめ。また長文エントリごめん。“IT”コンサルじゃない、﹁ファーム﹂のコンサルタントと一緒に仕事をするハメになったら読む本。 ﹁問題解決プロフェッショナル﹂を読めば、コンサルタントの土俵で話ができるSEとしての分をわきまえるなら﹁RFP＆提案書作成マニュアル﹂で準備しておくSEには、コンサルタントに無い視座がある。その強みを生かす﹁業務システムのための上流工程入門﹂ コンサルタントは、知識経験ないけれどキャラとハートがおおまかカバーすることはぶっちゃけありえない。そうなったらどうしようと思い悩む前にメモをどうぞ。 このblogは﹁それを知らなかった私にとって有益なもの﹂になるように心がけてる。つまり、その記事の知識・情報を知らなかったとして、﹁あ、こんな記事を見つけてラッキー﹂と思えるようなネタ。 で、この記事は一年前の私が見つけたなら﹁お、タイムリー﹂と思えるような内容　
    わたしが知らないスゴ本は、きっとあなたが読んでいる いきなりコンサルタントに抜擢されたSEが読むべき3冊

  • わたしが知らないスゴ本は、きっとあなたが読んでいる: いきなりコンサルタントに抜擢されたSEが読むべき5冊


    上長から﹁来週からコンサルタントとして○○社に入ってくれ﹂なんて言われたときに、あわてないための5冊。以下の条件全部にあてはまる人のための選書なので、関係ない方はスルーしてくだされ。シリーズ化しつつあるエントリ︵ [その1]、[その2] ︶だが、ここらでまとめ。 システム開発チームのメンバーまたはリーダー 顧客の御用聞きを﹁コンサルティング﹂だと思っている　←これ誤り McKinsey や accenture といった﹁ファーム﹂と一緒に、顧客の中に入って仕事しなければならなくなった これまで、即効性と実用性で4冊レビューしてきたが、このたび5冊目として扱いたいガイドを見つけた︵4冊目︶のでまとめてご紹介。 ■最初に結論 コンサル会社がやっている﹁コンサルティング﹂は、決まりきった手順や方法を粛々と実行しているに過ぎない。目標に対して泥臭いぐらい愚直に反応する。そうしたメソッドと沢山持って
    わたしが知らないスゴ本は、きっとあなたが読んでいる: いきなりコンサルタントに抜擢されたSEが読むべき5冊

  • パブリックコメント−経済産業省


    当省では、情報システムを主に外注により調達しています。この場合、システム開発企業に当方の要求を的確に伝えるための媒体である外注仕様書が非常に重要なものとなります。この調達を適正かつ効率的に行うため、平成14年度に行った﹁システム開発仕様書の作成における調査分析﹂︵外注先‥株式会社三菱総合研究所︶を基に﹁システム開発に係る外注仕様書作成マニュアル︵案︶﹂を作成しました。 本マニュアルは当省の情報システム室が関与するシステム調達に使用することを主な目的としておりますが、今般、本マニュアルを取りまとめるに当たり、広く国民の皆様からの御意見をいただきたく、以下の要領で御意見︵パブリックコメント︶の募集をいたしますので、忌憚のない御意見をお寄せいただきますようお願い申し上げます。
    yhira0202
    yhira0202 2009/04/07
    リンク

  • System Requirements Specifications

    システム要求仕様書の書き方 IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specificationより Table of Contents (目次) 1. Introduction (はじめに) SRSの「はじめに」では、SRS全体の概要を書く。 1.1. Purpose (目的) この小節では SRSの目的を描写する SRSが意図する聴衆を指定する 1.2. Scope (範囲) この小節では これから作るソフトウェア成果物に名前を付ける このソフトウェア成果物が何であるか(必要ならば、何でないか)を説明する 指定されたソフトウェアの適用について、対応する利点、目的、目標を含めて記述する もし上位レベルの仕様書(例えばSyRS)があれば、同様の記述と矛盾がないようにする 1.3. Def

    yhira0202
    yhira0202 2009/04/07
    リンク

  • はてなブログ


    はてなブログ お邪魔します。 お早う御座います、よゐこ有野です！ こちらのLINEブログから引っ越して来ました。 僕のブログ歴はココに居てはる人らの中では長い方やと思います。 あらすじはこんな感じ 飛ぶのが面倒な方はそのまま読み進めてもなんとなく分かります。 2005年に書いたブログやから、…
    はてなブログ

  • ITmedia エンタープライズ：SEの道は仕様書に始まり仕様書に終わる (1/3)


    最近のシステム構築では仕様書をきちんと記述しないで、いきなりツールを使ってプログラムを作成することも多いようだ。否定する気はないが、駆け出しのころはしっかり自分の手で仕様書を書いた方がいい。 前回は、SEを目指している皆さんに向けて、仕事に取り組む姿勢の観点からアドバイスを書いた。今回は、SEに求められるより具体的な知識やスキルの向上に役立つ話を書いてみたい。SEとして必要な知識やスキルは非常に広範にわたる。経験を積み、上級SEになってくればより経営的な知識が求められるが、最初のころは、システム構築に必要な知識やスキルが特に重要になる。今回は、システム構築における基礎的なスキルの開発方法を紹介しよう。 仕様書を書くこと 最近のシステム構築では、仕様書をきちんと記述しないで、いきなりツールを使ってプログラムを作成したり、システムを構築したりする手法が取られることも多いようだ。こういった手法
    ITmedia エンタープライズ：SEの道は仕様書に始まり仕様書に終わる (1/3)

  • 営業担当者がSEに抱く不満とは：ITpro


    ﹁もっと顧客から課題を聞き出す力があればなあ﹂﹁専門知識を生かして積極的に提案してもらえると助かるのだが﹂---。 営業担当者がITに関する商談で客先を訪問した際に、同行したSEに対してこんな不満や要望を抱いている。顧客に対して﹁何をすればいいのでしょうか﹂と“御用聞き”に徹して提案しようとしないSEや、顧客と積極的にコミュニケーションを図ろうとしないSEに対して、営業担当者はもどかしい思いをしているのだ。 日経ソリューションビジネスは，5月15日号の特集﹁SEの提案力強化で差をつけろ！トップ営業も認めるソリューションの達人育成法﹂に関連して企画・実施した調査で、ソリューションプロバイダの営業担当者208人から、“普段はなかなか話せないSEに対する本音”を聞いた。 その結果、﹁SEに足りないと思うスキル﹂の上位3項目は、﹁顧客の課題などを聞きだす力﹂、﹁その場に応じた会話ができる力﹂、そし
    営業担当者がSEに抱く不満とは：ITpro

  • 「2009年はトレンドを追うな」――小飼弾氏が講演

    「トレンドを追うな」「キーワードは晴耕雨読」「確立された“知恵”はなくならない」――2月7日、パソナテックが開催したセミナー『Webデベロッパの祭典』において、プログラマの小飼弾氏が『どうするデベロッパ!? 2009年プログラミング大展望』と題した講演を行った。会場となった東京・秋葉原のUDXギャラリーには、多くのWeb系エンジニアが集まった。 2009年は「晴耕：雨読＝20％：80％」 小飼氏は最初に「大展望という講演タイトルですが、トレンドというと株式市場のトレンドを思い出して暗くなるので、やめましょう」と発言。「今年は給料が上がると思うか、下がると思うか」「皆さんのお客さんの売り上げは上がるか下がるか」などの質問を客席に投げ掛けた。 続いて小飼氏はグーグルの「20％ルール」（自分の業務時間の20％を、自分が重要だと思うプロジェクトに費やすことができるというグーグルの社内ルール）を取り

    「2009年はトレンドを追うな」――小飼弾氏が講演

  • 書評 - Dr.きたみりゅうじのSE業界ありがち勘違いクリニック リターンズ : 404 Blog Not Found


    2008年06月21日16:30 カテゴリ書評/画評/品評iTech 書評 - Dr.きたみりゅうじのSE業界ありがち勘違いクリニック リターンズ 講談社Bizより献本御礼。 Dr.きたみりゅうじのSE業界ありがち勘違いクリニック リターンズ きたみりゅうじ リクナビ総研のあの名物企画、 Dr.きたみりゅうじの“IT業界の勘違い”クリニック／Ｔｅｃｈ総研 [書籍] Dr.きたみりゅうじのSE業界ありがち勘違いクリニック リターンズ (キタ印工房)おお、本当にフルカラーだ…としばし感激。 となって登場。 本書、﹁Dr.きたみりゅうじのSE業界ありがち勘違いクリニック リターンズ﹂は、SEという職業の神話とそれによる弊害を、元プログラマーのイラスト作家、Dr.きたみりゅうじが治療してきたカルテを、情報を落とさないようフルカラーで一冊にまとめたもの。 目次 - 講談社BIZ-netより Cas
    書評 - Dr.きたみりゅうじのSE業界ありがち勘違いクリニック リターンズ : 404 Blog Not Found

  • 一般人よりプログラマが優れている10の理由 - あと味


    私は常日頃、﹁プログラマって絶対優秀だよなぁ﹂と感じています。そう思っている理由を10個にまとめてみました。 ちなみに、私はプログラマではありません。一般人です。現場を知らないので、理想論に近い話になっていると思いますがご了承ください。どうやらおもいっきり理想論っぽいです。 抽象化・具体化ができる オブジェクト指向限定かもしれません。一般人よりもものごとの本質を見極める目を持っています。また、その訓練をしています。多くの偉人たちは、このスキルを持って、人々を導いてきました。 適材適所ができる どの言語を使うべきか、どのライブラリを使うべきかということの最適解を常に模索しています。一般人よりも適材適所に対する感度が高いと思います。 MECEなグルーピングができる 関数やクラスなど、漏れ・重複が極力ない設計を心がけています。一般人は、グルーピングしても漏れも重複も発生してしまうことが多いです。
    一般人よりプログラマが優れている10の理由 - あと味

  • 5分で絶対に分かるビジネス・インテリジェンス ― ＠IT情報マネジメント


    ビジネス・インテリジェンスとは何か？ビジネス・インテリジェンスとは何か？ IT︵情報技術︶関係の記事を読んだり、説明を聞いたりしていると、ビジネス・インテリジェンス︵business intelligence︶、略してBIという言葉が出てくることがよくあります。しかし、BIベンダといわれる企業の製品や主張を見ても、各社バラバラで何となく釈然とせず、あいまいな印象を持たれている人も多いのではないでしょうか？ この言葉はもともと、1989年にガートナーグループのアナリストだったハワード・ドレスナー氏によって使われたのが最初だといわれています。彼の主張するBIとは、﹁企業内外の事実に基づくデータを組織的かつ系統的に蓄積・分類・検索・分析・加工して、ビジネス上の各種の意思決定に有用な知識や洞察を生み出すこと﹂ぐらいの意味です。 要するに経営者や社員は、売上分析、利益分析、顧客動向分析などを、専門家
    5分で絶対に分かるビジネス・インテリジェンス ― ＠IT情報マネジメント

  • 上手なキャパシティ管理


    アクセス量やシステムの処理量に対してシステムリソースが不足すれば、システムの安定稼動は見込めない。最適なコストでキャパシティを改善するには、どうすうればよいのだろう？︵攻めのシステム運用管理︶ 顧客やユーザーに提供しているITサービスで、サービスへのアクセス量やシステムの処理量に対してCPU／メモリ／ディスク／ネットワークといったシステムリソースが不足した場合、システムの安定稼動は見込めない。 あるシステムで、サーバの使用率が継続的に上昇しており、顧客やユーザーに提供しているITサービスにおいて、パフォーマンス低下の兆候を検知したとしよう。このパフォーマンス低下がビジネスに対して負のインパクトを与える可能性がある場合、対応策を検討することになる。既存システムのチューニングで問題を解決できれば、これを計画、実行することになるが、そうでない場合はシステムリソースの追加や、ネットワークの帯域の増
    上手なキャパシティ管理
  • 1 2 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.