Webエンジニアスキルの勘所
Webのエンジニアにはどういうスキルが一番必要か？という話を考えてみた。 例えば、C言語やUnixの経験が長く、オブジェクト指向も理解していたとしたら、PHPから始まり、Rubyなどの理解は決して難しくないだろう。 では、それだけの経験で一線級のWebエンジニアとしての信頼が置けるかというと、ちょっと違うような気がする。 考え方のベースは、 「Webは、要するにテキスト処理であることが多い。だから難しい」 ほとんどの事がHTTPプロトコルを通じてテキストデータとして情報が、なんのネットワークの制約もなく流通する。つまり、HTTPヘッダを含むテキストの操作でセキュリティホールを作り、それが世界のどこから攻撃されるかわからない。 また、 同様に世界中からアクセスが集まることがありうるので、回りくどいテーブル設計をしてしまうと、あっというまに破綻してしまうこともある。 そして、 基本的にマルチア
“設計思想書”で開発の効率と質を高めよう
システム開発を効率化するために、過去に開発した資産の“流用”がよく行われている。エクスプレス開発の場合、最初から“再利用”を前提に開発を行い、その“開発思想”を記録として残すことで、より積極的に既存資産を活用する。 前回『“すべてを任せてもらえる「専門家」になろう 』では、顧客企業との打ち合わせの早い段階で、SEが「専門家」と認められれば、スケジュールを含めたあらゆる提案が受け入れられやすくなる──すなわち短納期化に貢献する、といったことを解説しました。 ただ、これは短納期化に不可欠な要素ではありますが、直接的に寄与するわけではありません。短納期化には、もっと具体的な考え方や方法論、そして、日ごろからの準備や工夫が必要なのです。今回は、そうした短納期化の方法論の1つとして、「システムの再利用」について解説したいと思います。 “流用”と“再利用”は違う SEやベンダのスタッフは「過去の開発資
外部設計（がいぶせっけい）
ソフトウェアの開発工程の1つで設計フェイズのうち、開発しようとするシステムが外部（ユーザーや外部システム）に対してどのような機能、インターフェイスを提供するかを設計すること。 簡単にいえば、要求仕様に基づいて“開発するシステムの機能”を決定する工程で、例えば、「Aをキーボード入力するとBを画面に出力する」というようにソフトウェアの実装を意識せずに、ユーザー視点で記述する。これによりおよそのシステム規模が明らかになり、開発スケジュールと予算が試算できるようになる。ユーザー（システム発注者）とSE（設計者）の間で行われる工程である。 具体的には、システム分割（アーキテクチャの決定）、入出力概要設計（画面／帳票設計）、コード設計（データ形式／構造）、論理データ設計（データベースの論理設計）などの作業がある。 一般に、基本設計／概要設計と同一視されるが、方法論やスコープによっては別の工程とされるこ
内部設計（ないぶせっけい）
ソフトウェアの開発工程の1つで設計フェイズのうち、外部設計で作成された仕様に基づいて、ソフトウェア内部のアーキテクチャ、データ処理や管理の方法、アルゴリズムなどを設計すること。詳細設計ともいう。 外部設計では実装を意識しないで機能を定めていくが、内部設計ではソフトウェア内部における具体的な処理手順を設計していく。SE（設計者）がビルダ（プログラマ）に対する指示を決定する工程である。 作業内容としては、機能分割、物理データ設計、入出力詳細設計に分類される。
「開発言語」を知らない設計者：地方からの戯言：エンジニアライフ
いま勤めている会社の中で問題になっているのですが、最近の潮流としてターゲットとなる開発言語を知らない設計者が増えてきているという話題があります。酷い場合には、言語のみならずプラットフォームであるOSやネットワークの基礎すら知らない人というのも目にすることがあります。このあたりは「人材の空洞化・ドーナツ化」などとよく言われていることだと思います。 要件定義から概要設計の中において、言語を知らなくとも構わない部分が存在しますので、個人的にはOKだと思っています。ですが、今回のような点が話題にあがる環境ですと、言語に大きく依存する部分まで設計してしまおうという状態ではないでしょうか。要件定義をほとんど行わない状態で概要設計を行う、概要設計と詳細設計の区別がついていない、GUIのデザインだけでAPを実装させる（時間的な都合はわかるのですがね……。人のことは言えないですが）など、落ち着いて考えれば酷
「やることリスト」に基づく見積もり手法
業務としてソフトウェアを開発するならば、工数の見積もりは避けては通れない。見積もりは、ソフトウェア開発プロセスのはじめの一歩に過ぎないが、その成否はプロジェクト全体の命運を握ることになる。プロジェクトに焦燥と混乱をもたらすことなく、堅実に開発を進めていくためには、正確で具体的な見積もり手法が求められる。 良く知られた見積もり手法の１つに、ファンクションポイント法がある。外部との入出力に着目して、ソフトウェアの機能から工数を見積もるファンクションポイント法は、有効な見積もり手法である。 だが、実際のソフトウェア開発の現場では、ファンクションポイント法で見積もりを行っているケースは多くはない。その原因の１つには、ファンクションポイント法を使うためには、入出力を定めたモデルの作成や、ポイントの計算方法など、専門的な知識と技能が必要なことが挙げられる。 小規模なソフトウェア開発では、見積もりのしや
肉厚と抜き勾配をおさえるべし！（1/3） － ＠IT MONOist
機械設計に携わるようになってから30年超、3D CADとの付き合いも20年以上になる筆者が、毎回さまざまな切り口で「3D設計の未来」に関する話題をコラム形式で発信する。第13回は、中小製造業における「スマートファクトリー」の実現にフォーカスして、筆者の考えを述べる。
ITエンジニアの「やってはいけない」---目次：ITpro
設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ClearDoc(クリアドック) | ソフトウェア第三者検証サービスのPROVEQ＜プロベック＞