伊東 輝

2008年からIT技術者を続けています。SIer勤務経験、上流工程の経験もあります。 …

伊東 輝

2008年からIT技術者を続けています。SIer勤務経験、上流工程の経験もあります。 IT現場で求められるソフトスキルの形式知化の必要性を強く感じたため、当Noteを作成しました。

最近の記事

IT現場で求められるソフトスキル集 目次

当noteは、技術者の方々に向けて、ITシステムの開発や保守の現場で求められるソフトスキルについて、形式知として伝えることを目的として作成したものである。 面談テクニックのようなSES独自のスキルについても紹介しているが、SES以外の形態で働く技術者にとっても参考になるスキルを多く取り上げる。 ソフトスキルの習得により、面談で好印象を与えたり、現場で信頼得たりすることができるようになる。 その結果、良質な仕事を任せられやすくなり、「上流工程SE」や「リーダー」のような、ハー

    • メンタルヘルスへの配慮

      IT業界は、メンタルヘルス不調が出やすい業界であるとされている。 メンタルヘルス不調者が出てしまうと事業に悪影響があり、何よりメンタルヘルス不調者自身のQOLを損なってしまうため、メンタルヘルスへの対策は必要である。 この記事では、IT業界の特殊な背景と、IT業界でのメンタルヘルス対策について、客観的に事柄に絞り説明する。 (1)IT業界特有の事情2020年に「過去1年間におけるメンタルヘルス不調による連続1か月以上の休業をした労働者及び退職者割合」という政府統計が取られ

      • 現場参画の面談のテクニック

        日本のシステムの開発や運用の現場では、客先常駐という労働形態は良く見られる形態である。 仮に、客先常駐を生業としている企業に勤めていなかったとしても、社内で余剰人員が出た場合、自社製品を取り扱う取引先へのサポートが必要な場合、業務提携先拡大の経営戦略が打ち出された場合等に社員が客先常駐に向かうことがあるため、この業界に携わる者であれば誰もが無関係ではなくなる可能性がある。 客先常駐で案件に参画する上で欠かすことができないものとして、候補者(技術者)と現場関係者(受け入れ担当

        • 会議による効率的な協働

          仕事を進める上で、関係者間で情報共有や意思決定を行う会議は欠かすことができないものである。 例えば、以下の目的で会議は必要になる。 管理表やチケットで管理されたタスクの棚卸 要件や作業状況等のヒアリング 問題に対する対応案の検討 成果物に対する方針確認やレビュー 会議を上手く運営することで仕事をスムーズに進めることができるが、会議には複数の人の時間を取らせてしまうという問題もあるため、効率的な運営が欠かせない。 この記事では、会議を効率的に進めるために心掛けるべ

        IT現場で求められるソフトスキル集 目次

          開発現場特有のドキュメントの書き方

          システムの開発・運用の現場では、業界特有のフォーマットのドキュメントが使われることがある。 業界内では一般化しているフォーマットであり、そのフォーマットに従うことで、技術者同士の意図の伝達をスムーズに行うことができるようになる。 この記事では、そのようなフォーマットの中で特に使用頻度が高いフローチャートとシーケンス図について取り上げていく。 (1)フローチャートの書き方フローチャートとは、処理の流れを図に起こして整理するために使うフォーマットである。 フローチャートを起こ

          開発現場特有のドキュメントの書き方

          ドキュメントの読み方

          システムの開発・運用の場では、情報伝達の手段としてドキュメントが用意されている。 このドキュメントは人間が作るものであるため、情報の抜け漏れ、時には誤りが埋め込まれていることもある。 そのため、ドキュメントを文字通り理解するような読み方では、正しく情報伝達がされない可能性がある。 ドキュメントを読む際には、自らも何かしらの推論を働かせ、何が正しいのかを確認しながら読み進める必要がある。 この記事では、ドキュメントを読み進める上で、助けになる視点を説明する。 (1)誤りの

          ドキュメントの読み方

          ドキュメント作成の基礎

          ドキュメントの良し悪しで、他者に意図が早く正確に伝わるかどうかが変わる。 良いドキュメントを作成するスキルは、スムーズに仕事をこなすには欠かせないスキルである。 この記事では、ドキュメント作成について、一般的な手法を紹介する。 ドキュメントには、設計書からユーザ向けのマニュアル、運用手順等、色々種類がありますが、今回の記事では、どのようなドキュメントにも共通する手法を紹介する。 (1)文章の構造化意図の伝達を目的とするドキュメントにおいては、小説のように文章をつらつらと書

          ドキュメント作成の基礎

          機能要件・非機能要件の充足

          しばしば、システム開発の場では、「ユーザーが求めている機能を実装できているか」という「機能要件」が重視されがちである。 しかし、安定的に機能を提供し続ける上では、「システムダウンの頻度を下げる」「応答を返す時間を遅くなるのを防ぐ」「ユーザーが求める機能追加を迅速に行えるようにする」といった、「非機能要件」も重要となる。 「機能要件」や「非機能要件」として、具体的にどのようなものが存在するのかは、国際規格ISO/IEC 9126(JIS X 0129)によって定義されている。

          機能要件・非機能要件の充足

          システム開発の見積もり

          見積もりとは、ある開発について、どの程度の工数(人数×期間)で終わるのかを予想する作業である。 「どのようなスキルを持った人員をいつ何人入れれば予定した期日に開発が終わるのか」「今の人員で開発を行った場合にいつ開発が終わるのか」といったことを考え、QCD(品質・コスト・価値提供)を満たすことができる計画を立てる上で、欠かせない事前作業である。 この記事では、見積もりの難しさや手法、見積もりを行う際の注意点について述べる。 (1)見積もりの難しさシステム開発には、要件の明

          システム開発の見積もり

          アジャイル開発の概要

          主要なプロセスモデルの一つとして、これまで述べてきた伝統的な「ウォーターフォール」の他に、後発の「アジャイル開発」というものが存在する。 「アジャイル(agile)」を日本語に翻訳すると「迅速」という意味になるが、「アジャイル開発」はその名の通り迅速に開発を行うことに特徴があるプロセスモデルであり、短い期間(数週間~1ヶ月程度)毎にユーザにとって重要な機能から順番にリリースを行う、というものである。 一つの開発期間は「スプリント」や「イテレーション」と呼ばれ、計画・設計・実

          アジャイル開発の概要

          保守フェーズにおける作業の概要

          システムはリリースして終わりではなく、リリースした後も、適切な保守作業を行うことで一般ユーザーが求める機能を提供し続ける必要がある。 システムを運用する中で、バグや機器の故障のような要因でシステム障害が発生したり、外部(公的機関や関連システム)から仕様変更を求められたりするため、機能を維持するためにはそれらに対応する必要がある。 また、一般ユーザーの満足を考えるのであれば、機能を維持するだけではなく、より少ないコストで同じ機能を提供したり、機能を強化したりすることも随時行う

          保守フェーズにおける作業の概要

          移行フェーズにおける作業の概要

          システム開発における「移行作業」とは、システムテストやクライアントの受け入れが完了し、リリースが了承されたシステムについて、実際にサービスを提供するための本番環境で稼働できるように設定変更を行う作業のことを指す。 「本番リリース」や「カットオーバー」等と呼ばれることもある。 移行作業前は、開発者やテスト担当者、受け入れ担当者のような一部の関係者しか新システムを操作することはできないが、移行作業後は一般ユーザーが新システムを操作して実運用を行うことができるようになる。 移行作

          移行フェーズにおける作業の概要

          試験工程の管理

          ウォーターフォールのプロジェクトを円滑に進めるには、工程管理が欠かせない。 工程管理を適切に行うことで、各工程で作られる成果物の品質を高めることができ、品質問題が発生したとしてもいち早くそれに気付き対処することができる。 この記事では、工程の中から、試験工程に該当する単体テスト・結合テスト・システムテストについて工程管理の概要を説明する。 なお、製造とほぼ同時に行うコードレビューについては、前回の記事で取り上げた開発工程のレビューと同じような方法で管理を行ったり、静的解析

          試験工程の管理

          要件定義・設計・製造工程の管理

          ウォーターフォールのプロジェクトを円滑に進めるには、工程管理が欠かせない。 工程管理を適切に行うことで、各工程で作られる成果物の品質を高めることができ、品質問題が発生したとしてもいち早くそれに気付き対処することができる。 この記事では、工程の中から、開発工程に該当する要件定義・設計・製造について工程管理の概要を説明する。 (1)各工程のトレーサビリティの確認開発工程は、クライアントと合意を取った要件を元に、徐々に設計や製造に落とし込んで行くという形で進められる。 品質を確

          要件定義・設計・製造工程の管理

          アローダイアグラムやWBSによる作業計画

          ウォーターフォールの作業計画や進捗管理では、WBSと呼ばれる管理表が用いられている。 また、WBSを作成するにあたっては、アローダイアグラムの概念を理解する必要がある。 この記事では、アローダイアグラムとWBSについて、簡単に説明する。 (1)アローダイアグラムの概念アローダイアグラム(PERT図とも呼ばれる)とは、プロジェクトの遂行に必要なタスクについて、タスクの流れを図形と数字で表現した図である。 平行作業を伴う複雑なタスクの順序を表現でき、各タスクの関連や前後関係を

          アローダイアグラムやWBSによる作業計画

          V字モデルと各工程の概要

          これまでの記事ではIT業界の仕事以外にも応用できる汎用的なソフトスキルを解説した。 しかし、IT業界でソフトスキルを活用するには、IT業界特有のプロセスを理解する必要がある。 IT業界で最も一般的に用いられているプロセスは、ウォーターフォールと呼ばれるプロセスモデルである。 今回の記事では、ウォーターフォールについて、そのプロセスの概要を端的に表したV字モデルを用いながら簡単に説明する。 (1)V字モデルを用いたウォーターフォールの概要の説明ウォーターフォールは、一つ一つ

          V字モデルと各工程の概要