Help us understand the problem. What is going on with this article?

【要約】日経SYSTEMS 2018/12号

1. はじめに

以下雑誌の要約。

  • 題名:日経SYSTEMS 2018/12号

2. リーダーを困らせる厄介な部下

~要約~

2-1. この章について

チームのリーダーにとって、扱いの難しい部下に振り回されチームのモチベーションが低下するのは避けたい。
しかし、人間の性格や特性はそう簡単に変えられるものではない。変えられるべきなのは、メンバーの仕事の進め方やメンバーへのアプローチの仕方である。
部下の特性を理解し、チームのパフォーマンスを高めるポイントを以下にまとめる。

2-2. 報連相ができない部下

  • 報連相をきちんとするタイプと、いくら言ってもできないタイプ(あるいはしないタイプ)の2者が存在する。
  • 報連相ができる部下は、リーダーが何を求めているのかを理解しており、伝え方、タイミング、報告の粒度が的を得ている。
  • 報連相ができない部下は、報告の目的が曖昧、または全く理解できていないことが多い。そのため聞かれたことしか話さない、聞かれないと報告しない、表面的なことしか報告しないということになる。
  • こうした行動を変えるには、まず報告の目的を部下ときちんと共有することが重要となる。それによって部下は自分の仕事に関わるどんな情報を報告すべきなのかを理解できる。
    • ユーザヒヤリングの抜け漏れがないか洗い出すため
    • 進捗状況に応じて要因の調整が必要なため など
  • 大切なことは、リーダーからも報連相を行い、自分がもっている情報を部下と共有する姿勢を見せることも重要。互いに情報共有し合う機会を増やすことで、部下は自分から進んで報連相するようになる。

2-3. 仕事にムラがある部下

  • 自分が理解しているところは徹底して作りこむが、よく分からないところは適当に済ませてしまう人もいる。(仕事にムラがある)
  • これは本人の性格や特性を取り上げてもなかなか解決には至らない。真っ先に変えるべきものは仕事の手順や仕組みである。
  • レビューとは何かを質問すると、「確認すること」という回答が返ってくることが多い。これは間違いではないが「分からないところはレビューのときに質問すればいい」と考えていることの表れでもある。これは極端な話、「いい加減に作る」ことを容認しているようなものになる。
  • ここで問題となるのは成果物が出来上がるまで何も確認しないことである。大きな問題がレビュー時に判明したら、多大な手戻りとなってしまう。
  • こうした状況を避けるためにも、中間レビューを取り入れるとよい。中間レビューは、成果物が完成する前の段階で、作業の方向性や作業量などについて確認するレビューである。
  • 必要に応じて、30%完了時にレビュー、50%完了時にレビュー、100%完了時にレビューなどするとよい。
  • 最終レビューはレビュアーに成果物の正しさを証明することと意識すべき。

~感想~

仕事の手戻りは、リーダーにとっても部下にとっても大きなマイナスとなる。
リーダーは報連相しやすい環境を作り、部下はリーダーが何を求めているかを意識すべき。
つまりはお互いを尊重し合う姿勢が大切だと思った。仕事はチームでやるもの。チームで成功に導く。
「レビュー時に確認しよう」は今でもやってしまうことがあり反省。。。

3. [テスト計画] 最初に実施する重要作業 テスト対象や種類の決定

~要約~

3-1. この章について

テスト計画ではテスト対象の決定、テスト種類を含むテストのやり方の決定が非常に重要となる。
これらを決めないと根拠が曖昧なスケジュールしか作れないし、次プロセスのテスト設計に必要な情報が不足してしまう。テスト計画のポイントを以下にまとめる。

3-2. テスト対象の決定

3-2-1. テスト対象の候補を洗い出す
  • テスト対象の候補を洗い出すにあたり、インプットとなるのは要件定義や設計書といったシステム開発で作成するドキュメントとなる。
  • 新規システムの場合は開発対象とテスト対象がほぼイコールになるが、機能追加や改修では、改修していない箇所もテスト対象として検討しなければならない。1か所を修正すると、その他の修正していない箇所にも影響を及ぼす可能性がある。そのため、改修していないプログラムのテストも実施しないと、想定外の不具合を引き起こすリスクがある
  • 具体的には、改修した機能と関連する機能を洗い出す。
    • 改修した機能と同じデータを参照している機能
    • 改修した機能と同じ業務フローに含まれる機能 など
3-2-2. テスト対象の優先順位を決める
  • テスト対象の手を広げすぎると、テスト期間内にテストが終わらないといった問題に直面する。そのため、テスト対象の優先順位を決めることが重要となる。優先順位を決めるにあたり、代表的なのは以下のような考え方がある。
    • 開発規模に着目する・・・開発規模が大きい機能は、それだけ開発時にバグが混在するリスクが高い。
    • 業務重要度に着目する・・・該当の機能がどの程度重要なのかを評価する。競合者に対抗する機能、経営者が強く望んでいる機能など。
    • 障害発生時のインパクトに着目する・・・不具合が発生するとビジネスが止まるような機能など。
    • 過去の障害に着目する・・・過去の開発時にバグあが多く検出された機能は、今回も障害発生リスクが高いと判断できる。

3-3. テストのやり方の決定

3-3-1. テストレベルを決める
  • テストレベルとはテスト対象を区切る粒度のこと。テスト対象やテストの目的、インプットする情報をもとに、どのレベルのテスト(単体テスト、結合テスト、システムテスト、受け入れテスト)を行うかを決定する。
3-3-2. テストタイプを決める
  • テストタイプとはテスト観点を目的別に分類したものとなる。一般的には以下のようなものがある。
    • 機能テスト・・・ソフトウェアの機能が、設計書で規定した通りに動作するかを確認するテスト。
    • 性能テスト・・・プロジェクトで規定したシステム性能が出ているかを検証するテスト。
    • 回帰テスト・・・システム改修を行っていない部分が、規定通りの結果を返すかを検証するテスト。
    • ユーザビリティテスト・・・ユーザの使用性に着目したテスト。
    • 疎通テスト・・・システム間でデータが通るがどうかを検証するテスト。
    • セキュリティテスト・・・システムのセキュリティに着目したテスト。(Webサイトの脆弱性確認など)
3-3-3. テストのやり方を決める
  • テストレベルとテストタイプの組み合わせごとに、どのようなテストの実施方法を採用するのかを検討する。
  • この検討が不十分だと、テスト実施段階で「環境制約で実施できない」「ツールを使わないとテストできない」といったことが判明したりする。

~感想~

テストをするにあたり、今までの経験のみに頼ってしまうと、テスト粒度や観点が担当者によって異なったりしてしまうことが起こる。
プロジェクトによってベストなテスト方法は違ってくるので、テスト計画にてテストレベルやテストタイプをしっかり決めるべき。
テスト計画、テスト設計を行わずいきなりテストケース作成に入ってしまうことも少なくなかったので、プロセスをしっかり意識していきたい。

4. 会議に不可欠なセットアップ 相手を尊重すればうまくいく

~要約~

4-1. この章について

会議において、参加者がお互いに自分本位になってしまえば目指すゴールにたどり着けない。
誰もが「自分を尊重してほしい」と思っていることを前提に会議の場を整えることが重要となる。
会議を整えるためのポイントを以下にまとめる。

4-2. プロセスを整える

  • 話し合いのプロセスは、セットアップ、発散、収束の3つに分けて考えておくと会議に臨みやすい。
    • セットアップ・・・参加者の意識のベクトルを合わせていく
    • 発散・・・本題について議論を深め広げていく
    • 収束・・・発散の段階で得た情報から、話し合いのゴールに向けて導いていく
  • この中で最も大切なのがセットアップのプロセスである。具体的には話し合いの目的の確認、時間や進め方、話し合いのゴールの確認などを共通事項として認識していくプロセスである。
  • ゴールが曖昧なまま会議が始まると、参加者が自分の考えるゴールを持ったまま話し合いを進めることになる。原因を究明すればよいのか、アイデアを出せばよいのか、対策をたてるとこまでいくのか、参加者にとって目指すゴールが違うと話が色々な方向に広がってしまう。
  • 「この会議では、終わったときに~な状況(状態)になっていたいので、ご協力お願いします。」といった言葉をセットアップ時の決まり文句にしてしまうとよい。
  • 主催者ではなく、参加者として話し合いに参加する場合もセットアップを行うことは可能。「会議終了後にアイデアがいくつか出ていればよいという認識でよろしいですか」などと確認の質問をすることで、ゴールがはっきりすると同時に、意識のベクトル合わせが可能になる。

4-3. 自分自身を整える

  • 人は誰でも自分のことを尊重してほしい生き物である。つまりは誰でも自分は正しいと思っているし、自分の考えや立場を尊重してほしいと思っている。
  • 人の話を素直に聞くことは、利害関係がある中では特に難しい。なぜなら人は相手の話を推測や判断を入れながら聞くため。
  • 会議に限らず、日々のコミュニケーションの際に「厳しい」「無理です」といった否定的な表現を使ったりすると、険悪な雰囲気になってしまう。否定的な表現を使ってしまうのは、真面目で責任感が強い人に多い。
  • 否定的な表現にならないような工夫を日ごろから心掛けるべき。
    • お客さん:「この機能の追加を今月中にお願いしたいのですが」
    • (×)リーダー:「いやー、ちょっと厳しいですね・・・」
    • (○)リーダー:「今月中だと、追加工数を出して頂くか、別作業をいったんストップすると可能なのですが、いかがでしょうか?」

~感想~

会議中に様々なベクトルの話が飛び交い、時間が逼迫してしまい、ゴールが達成できない(もしくは無理やり決まる)ことがちょいちょいあった。
セットアップにおいて、まずは全員でベクトルを合わせることが重要だと思った。また、会議の方向がずれてきていると感じたら「その話は別の会議にて決めましょう」といった調整をしていくべきと思った。振り返ってみると、調整のうまい人はそれができているなーと感じた。

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away