プロジェクトマネジメントの現場力を鍛える PM Portal《事例の背景・事象》 ビッグデータ分析基盤構築プロジェクトにプロジェクト・マネジメント・オフィス（以下、PMO）として参画した。 本プロジェクトは、ホールディングスを母体とした各事業会社からのデータを筆者が参画している機
考えすぎてコミュニケーション能力が低い人へ - teruyastarはかく語りき
コミュニケーション能力の鍛え方を教えて欲しい http://anond.hatelabo.jp/20140807005003 でも、少し話をしてる中で、少なくとも「嫌なやつ」ではないことがわかった。 真面目だし、素直だし、やる気はある。 でも、会話が成立しない、ただただ成立しない。 「AとBのどっちが好き？」と聞くと 「〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 〜〜〜〜〜という理由で、Cのこと嫌いじゃないです」 と返してくる。 辛抱強く最後まで聞いてから、 「で、AとBのどっちが好きなの？」と聞くと 「あ！Aです、すいません」と答える。 ずっとこの調子。本人に悪意はない、 単純にコミュニケーション能力が低いだけ、異様に、低いだけ。 (犬の糞は増田の訳だと思われるので引用しない) もし、会話の本質を探るために 質問の前提をさかのぼり、抽象化して 会話するまでもない常識には触れず、 いかに
米Appleの元副社長が説く、人生とキャリアを充実させる8カ条 | ライフハッカー・ジャパン
Inc.:ハイディ・ロイゼン氏は、シリコンバレーの有名人です。14年間、自分の会社を経営したあと、アップルの副社長としてデベロッパーとの関係構築に尽力してきました。現在は、DFJ Ventureの投資家の1人であり、また、スタンフォード大学で「Spirit of Entrepreneurship（起業家の精神）」という授業を教えています。ロイゼン氏は、広大なネットワークを持っており（おかげでハーバードビジネススクールのケーススタディにもなっているほど）、その影響力を優雅に行使しています。 今年の卒業式の前、彼女は母校のスタンフォード大学でスピーチを行い、30以上のテック業界の経験から学んことをシェアしました。その内容は、まるで未来の起業家に向けた学位授与式のスピーチのようであり、彼女の確かな経験に基づいた宝石のような格言に満ちていました。 ここで紹介する8つの信条は、ロイゼン氏がテック業界
凝集度と結合度
凝集度と結合度について 凝集度と結合度という概念は、コンスタンチンとヨードンが、その共著である「構造化設計」において提案した関数の尺度です。言い換えれば、これらは構造化設計の中心的テーマで、構造図を書くのも、設計時にこの尺度で判断して品質を織り込むためなのです。以下に、これらの尺度について簡単に説明します。 またこれらの尺度は、オブジェクト指向の時代に入って、残念ながらあまり省みられなくなりましたが、メソッド内で関数が階層構造になる場合の関数の尺度には、そのまま有効ですし、表現はちがっても、クラスやオブジェクトの関係や、適切な大きさを判断する際にも有効です。 保守作業に伴って品質の低下を招く危険は、構造化の言語であろうと、オブジェクト指向の言語であろうと同じです。 凝集度（コヒージョン） これは、プログラムのひとつのコンポーネント（以下、関数と呼ぶ）の中に含ま
CWE -2009 CWE/SANS Top 25 Most Dangerous Programming Errors
Welcome to the 2023 Common Weakness Enumeration (CWE™) Top 25 Most Dangerous Software Weaknesses list (CWE™ Top 25). This list demonstrates the currently most common and impactful software weaknesses. Often easy to find and exploit, these can lead to exploitable vulnerabilities that allow adversaries to completely take over a system, steal data, or prevent applications from working. CWEs are becom
Part5 基本設計におけるレビューの勘どころ
Part5では，基本設計フェーズにおける成果物の品質を向上させる施策について解説する。カギは，欠陥を除去するとともに欠陥を防止する仕組みを確立すること。重要な成果物については有識者を交えて「インスペクション」を実施することも大切だ。 「考慮していない外部システムとの連携が詳細設計で見つかった」，「仕様間の不整合が実装フェーズで発見された」――。どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。 そこでPart5では，基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「欠陥防止」を徹底する 改めて言うまでもないが，基本設計の成果物の品質を向上させるプロセスは，（1）設計作業を実施する，（2）成果物をレビューして欠陥を洗い出す，（3）
Part4 方式設計で利用できる「パターン」を知る
高品質で変化に強いシステムは，アーキテクチャの良し悪しに依存する。だがアーキテクチャの設計は，外部システムとの連携や性能・信頼性の確保など考慮すべき点が多く，困難を極める。そこで利用したいのが，先人たちが生み出した方式設計のひな型である「パターン」だ。 ここ数年で，「パターン」という言葉がよく使われるようになった。読者も耳にしたことがあるだろう。 そもそも「パターン（Pattern）」とは，ある問題の解決策をテンプレート（ひな型）として記述したものである。問題を解決する手順や方法が記されているため，パターンを利用することで，迅速かつ確実に問題を解決できる。採用したパターン名をお互いに伝え合えば，メンバー間のコミュニケーション・ギャップも少なくなる。ただし，何でもパターンになるわけではない。再利用の価値があるものだけがパターンとなる。 パターンそのものの起源は古く，1970年代に米カリフォル
Part3 オブジェクト指向の基本設計を理解する
Part3では，オブジェクト指向に基づく基本設計の方法論を，UP（Unified Process）をベースに解説する。下流工程で試行錯誤を繰り返さないためには，「実行可能なアーキテクチャ」を構築することと，アーキテクチャの利用方法を解説した「アーキテクチャ説明書」が極めて重要になる。 Part2では，主にウォーターフォール型開発プロセスとDOA（データ中心型アプローチ）に基づいた基本設計の手順を示した。だが，最近はWebシステム開発を中心に，反復型開発プロセスやオブジェクト指向設計を採用するケースが増えている。 そこでPart3では，オブジェクト指向設計に基づく代表的な反復型開発プロセスであるUP（Unified Process）を例にとって，オブジェクト指向設計における基本設計の勘どころを解説しよう。 動くアーキテクチャを作る UPでは「方向付け」，「推敲」，「作成」，「移行」という4つ
Part1 今こそ「基本設計」のスキルを見直す
システムの構造や実装方針を決定し，アプリケーションの機能，データ，画面などを定義する「基本設計」。ITエンジニアの「コア中のコア」と言えるスキルだが，「最近弱体化している」と指摘する声が増えている。今こそすべてのITエンジニアが，ユーザーの高品質，短納期の要求に応えるために，「基本設計」のスキルを改めて見直すべきだ。 「ベテランのエンジニアは基本設計の一般的な手順は理解しているが，高度化・専門化した実装技術を駆使したアーキテクチャの設計でとまどう。一方，若手エンジニアは実装技術には詳しいものの，肝心の基本設計の基礎的な方法論を理解していないことが多い」――。 こうした悩みは，多くの開発現場に共通する。これは，基本設計そのものが難しくなっているからにほかならない（図1）。 メインフレーム時代は，ウォーターフォール型の開発プロセスと自社の製品の知識さえあれば基本設計をこなせた。しかし，システム
Part2 設計手順の基本を身に付ける
Part2では，多くのシステム開発で実績を持つ日本IBMの「IBM-DOA」に基づく外部設計フェーズの手順を説明する。ここで紹介するDOAに基づく複合／構造化設計手法は，どんなプロジェクトにも応用できる基本的なアプローチだ。基本をしっかりと身に付けてほしい。 DOA（Data Oriented Approach：データ中心型アプローチ）は対象システムの「データの流れ」の把握に重点を置きながら，要件定義や設計を進めていくアプローチである。 DOAには様々なタイプがあるが，日本IBM独自の「IBM-DOA」では，主に業務全体をデータの流れに着目して図で表現するDFD（Data Flow Diagram）を使って業務を分析・設計していく。Part2では，この「IBM-DOA」に基づく外部設計フェーズの進め方を説明しよう。「今さらDOAか」と思わないでほしい。最も基本的で一般的なアプローチなので，
How to add a new shape to Dia
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. You may obtain a copy of the GNU Free Documentation License from the Free Software Foundation by visiting their Web site or b
エンジニア必須の概念 – 契約による設計と信頼境界線
(Last Updated On: 2019年5月29日)少し設計よりの話を書くとそれに関連する話を書きたくなったので出力の話は後日書きます。 契約による設計（契約プログラミング）（Design by Contract – DbC）は優れた設計・プログラミング手法です。契約による設計と信頼境界線について解説します。 契約プログラミングとは 契約プログラミングは比較的新しい設計思想で、サポートしている言語にはEffile、D、Clojure、Valaなどがあります。最近作られた言語の多くが契約プログラミングをサポートする機能を持っています。C++、C#やJavaなどでも契約プログラミングをサポートするライブラリが利用できます。契約プログラミングをサポートする言語やライブラリを利用しない場合でも、契約プログラミングの概念を適用すると安全かつ効率が良い開発の手助けになります。 Wikipdiaの
ヘルスソフトウェアに関する開発ガイドライン(手引き)を策定しました（METI/経済産業省）
個人の健康管理・維持等の目的で使用されるヘルスソフトウェアの開発にあたり、利用者に対する使用上の安全性を維持・向上させるための基本的な考え方を、開発ガイドライン(手引き)として策定しました。 今後、本ガイドラインをもとに、産業界による詳細な自主基準が策定・運用されることで、ヘルスソフトウェアに関する産業振興が期待されます。 1．策定の背景 平成25年11月に公布された「薬事法等の一部を改正する法律」(平成25年法律第84号、本年11月施行予定)により、診断等の目的で用いる単体プログラム(医療用ソフトウェア)については、薬事法(上記施行後は「医薬品、医療機器等の品質、 有効性及び安全性の確保等に関する法律(医薬品医療機器等法)」に名称を改正) における医療機器として規制の対象となります。 このため、経済産業省では、平成24年度から「医療用ソフトウェアに関する研究会」を開催し、利用者に対する使
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://sw-eng.larc.nasa.gov/files/2013/05/Simulation-Project-Software-Configuration-Management-SCM-Plan.doc