タグ

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

  • 関連タグはありません

タグの絞り込みを解除

@itとworkstyleに関するaonosanのブックマーク (3)

  • ITエンジニアとしての道を究めるには(1)

    さまざまな困難をどう乗り切ればいいのか ITエンジニアとしての道を究めるには 第1回 スランプを脱出する方法 萩順三(豆蔵取締役) 2003/10/29 読者の皆さんは、スランプに陥ったことがないだろうか。中には慢性のスランプに陥り、「もうこの業界は嫌だ」と考えている人も多いだろう。私もこの業界に長年いる中で、非常に優秀な技術者なのにこの業界についていけなくなり転職してしまったり、病んでしまったりするケースに出くわした。 実は、私も幾度となく激しいスランプに陥ったことがある。いやスランプというのは、日常茶飯事であるが、もうこの業界では駄目ではないかと思ったことが何度かあるものだ。 私のスランプの原因は下記のようなものであった。

  • @IT - スキル創造研究室 - 全記事一覧

    デジタル化やDXといえば、仕事の「見える化」や「効率化」など、目に見えて分かりやすい効果を期待することが多い。だが、変革の質は「想定していなかったこと」にあるのかもしれない。(2024年9月6日)

  • 開発現場で学べること(4)

    エンジニアは日々現場で学ぶ 開発現場で学べること 第4回 最良のシステム設計書とは? クロノス 山野寛 2004/1/28 エンジニアにとって最も大切なことの1つが、開発現場での経験だ。それがエンジニアに多くの知識と勘をもたらす。そんな開発現場で若きエンジニアが失敗し、そこで何を学んでいくか。それを毎回紹介したい。 ■要求定義から開発フェイズへ移行 前回(「第3回 システム開発の真の目的を見失わない 」)までわれわれの開発チームは、ある某サービス業を営む企業Aの要求定義をまとめる作業を行ってきた。その作業も3カ月間でようやく無事に終了し、いよいよ格的な開発フェイズへと移行した。 開発フェイズではまず初めに、設計手段の統一化を図るため、メンバー全員で設計書の標準化を行うミーティングを実施した。われわれはこのミーティングで、クラス間の静的な関連の記述にはクラス図を、また動的な関連の記述にはシ

  • 1