役職に応じた役割の違いと、それを意識した行動

通常の会社では、大まかに言って役職が「経営者」「管理者」「担当者」と分かれています。
先に挙げた方が、責任が重い上位の役割であるとみなされます。
そして、組織は通常ピラミッド式になっており、上位者は見る範囲が広く人数が少ない、下位者は見る範囲が狭く人数が多くなります。

それぞれ役割が違うため、その役割の違いを意識して行動することで、仕事がスムーズに進むようになります。
自分の役割をこなすことも重要ですが、組織として高いパフォーマンスを出すためには、役割が違う者と上手く協働することもまた重要です。


「経営者」「管理者」「担当者」の役割の違いは、簡単に言うと以下の通りです。

■経営者

  • お客様を開拓し、お客様にサービスの提案を行う
  • サービスを提供することで利益を得られるようにし、経営を継続可能にする
  • 会社全体の状況を見て、全体最適を考える

■管理者

  • サービス提供の実作業、及びサービスの担当者の管理を行う
  • 複数のサービスについて管理を行う

■担当者

  • サービス提供の実作業を行う
  • 自分が担当するサービスについて専門的に取り扱う

  

ここで重要なのは、下位者が持っている全ての情報を上位者は持っていないということです。
一つ一つのサービスの専門的な知識、ITシステム提供であればプログラムや業務ロジックといったものは、通常は担当者が一番詳しく、管理者や経営者は概要しか知らないことが多いです。


役割の違いにより、持っている情報には差が生まれます。
この差を必要に応じて埋めるためには、上位者への的確な「報連相」が重要になります。
今更書くまでもないかもしれませんが、「報連相」とは以下のようなものです。

■報告

上位者から指示された作業の進捗状況や結果を知らせる。

■連絡

上位者に事実を知らせる。

■相談

判断に迷うことがあった時に、上位者に指示を仰ぐ。

  

何か良くない事象が起きた時に、上位者が作成した方針やマニュアルに沿って対応できる場合には問題ありません。
その場合は、報告や連絡で問題がないことを伝えれば良いです。

しかし、上位者が作成した方針やマニュアルに沿って対応できない場合は問題です。
その場合は、どのように対応するか相談する必要があります。
(IT業界では「エスカレーション」とも呼ばれます)

相談を行う際、自分が担当しているサービスについて上位者は自分ほど詳しくないので、判断に必要な情報を的確に連絡することが重要です。
また、上位者は見る範囲が広く忙しいので、多くの労力をかけずに判断できるような形で相談すると尚良いです。
つまり、「~という事象が起きています。~と私は判断したので~をしたいのですが、それでよろしいですか?」という形で相談を行うことが理想です。

しかし、このような相談を行うためには、上位者の意図を汲む必要があります。
スキルや経験を積まない内は難しいので、その場合は「自分で判断できない何かが起きている」ということを伝えられれば及第点です。自分で抱え込むのが一番良くないです。


上位者の意図を汲んで仕事ができるようになると、自分自身が上位者へステップアップするチャンスを得られます。
この際、自分が担当していた仕事を後任に任せられるかどうかが一つの課題になります。
今の仕事をしながら上位者の仕事もこなすことは仕事量的にできないので、自分が担当していた仕事は後任に任せる必要があります。
(それができない場合は、ステップアップが止まってしまいかねません)

しかし、実際に後任に仕事を任せてみると、教える時間がかかりますし、普段自分がやらないようなミスもします(そのリカバリーでも時間を取られます)。お客様に迷惑をかけてしまうこともあります。
自分よりも知識・経験が浅い人に仕事を任せる場合は特にこの傾向が顕著です。そうではない場合も、仕事に慣れる期間は必要なため、この傾向が見られることがあります。
とはいえ、このようなデメリットは一時的なものであり、長期的に見れば組織にとって以下のようなメリットがあります。

■後任に仕事を任せることによるメリット

  • 自分の技術が他の人にも伝わり、組織全体としてレベルアップする
  • 複数人で作業できるようになるので、残業が減り、アウトプットの量も増える
  • 自分にしかできない作業に集中できるようになり、作業の品質が良くなる(品質チェックと報告、仕事の方向性の検討…等)
  • 休暇や異動等で自分が居なくなった時にも仕事が回るようになる
  • 自分の仕事に他の人の目が入ることで、仕事の改善点に気付くことができる

  

そのため、自分の仕事を後任に任せることは、自らのステップアップのためだけでなく、組織のためにもなります。


いかがでしたでしょうか?

スキルや知識に優れている若手でも、組織での動き方がわからずに躓くことがあります。
それはとても勿体ないことなので、組織の中ではどのように役割が分担されているのか、その中で自分はどのように動くべきなのか、ということを意識していただければ、と思っています。

本番障害発生時に元請けSIerで発生する作業とその影響

社会インフラを支えるシステム、例えば金融システムや公共システムについては、高い信頼性が求められます。
このようなシステムの本番運用で障害が発生した場合、その結果は重大なものになります。
一般的なイメージとして、その「重大なもの」として、以下のようなものをイメージすると思います。

  • 信頼が失墜する(最悪の場合は報道される)
  • 経営者がお客様に怒られて、責任者が経営者に怒られて、技術者が責任者に怒られる
  • 技術者や責任者が缶詰になる

この記事では、本番運用で障害が発生した場合に、元請けSIerで一体何が発生するのか、元請けSIerのプロパーであった私の経験を交えて、より具体的に書いていこうと思います。
そして、具体的に何が起こるのかを知ることで、品質向上の意識を高めていただければと思います。


【障害の検知】

障害を検知する契機として、「お客様に指摘される」という契機で見つかるのは最悪です。
事前にSIer側で障害を発見できなかったためにお客様の心象が悪くなることで、その後の要求(障害対応、再発防止、補償)が厳しいものになるためです。
また、お客様に指摘されているということは、既にデータが作成されて、「画面」「帳票」といった形でお客様の目に触れているので、そのデータを補正しなければならないということで障害対応の作業内容の難易度も上がります。

そのため、お客様に見つかる前に障害を検知する努力を惜しまず行うべきです。
異常なデータが発生した時点でその箇所の処理を停止させれば、運用作業でその箇所だけ補正して対応することができます。
エラーハンドルが重要であるとされるのはこのような理由からです。
また、この運用作業は人手で行うこととなりミスが発生しやすいので、システムを構築する場合は、運用作業を予め計画して手順化することでミスの発生を抑える努力も重要になります。
システム改修直後は障害が発生する可能性が高いので、すぐに障害対応できるように、改修直後の監視体制を敷くことも重要です。

なお、システム改修の結果、思いもよらぬ箇所に影響が発生し、重点的に監視していない箇所で障害が発生しお客様に指摘されるというのも良くあることです。
影響調査を抜け漏れなく行うことも重要になります。

【障害の対応方針の検討】

障害が発生した場合、どのような障害が発生したのか、その事象内容と原因をお客様に報告する必要があります。
そして、システムの都合の観点と、お客様の業務の継続の観点から、対応方針をすり合わせることになります。
検討している間にも障害は発生し続けているので、検討は迅速に行う必要があります。

システムの都合の観点で言うと、障害対応でプログラム作成が必要なのであればその期間を見る必要がありますし、プログラムを実行・リリースするタイミングも計る必要があります(サービス停止日にしか実行・リリースできないことも多いです)。
それまでの間の暫定対応(運用作業)の計画も立てる必要があります。
そして、暫定対応はお客様の業務を継続する上で必要なレベルを満たす必要がありますし、恒久対応では元々求められていたレベルに戻す必要があります。暫定対応中に制約や機能制限が発生するのであれば、そのことについてもお客様の了承を得る必要があります。

なお、この時点で明らかに対応するべきことがあれば、責任者の許可を取った上で、技術者は検討中にも対応し続ける必要があります。
手順書に書かれた作業や、その他常識的に行うべき作業(例えばディスク容量オーバーでシステムが落ちたのであれば不要データの削除とシステム再起動)がそれに該当します。

【暫定対応の実施】

検討された方針に従って、暫定対応を行います。
この作業は基本的に手作業での運用になることが多いため、運用担当者を立てて体制を整える必要がありますし、運用作業でのミスが無いように手順書や簡易ツールを作成する必要もあります。
また、暫定対応中に制約や機能制限が発生するのであれば、そのことを説明する文書の作成と周知という事務作業も発生します。

【恒久対応の実施】

プログラムの作成が必要なのであれば、それを作成する担当者を用意して工数を割り振る必要があります。
そして、プログラムの本番環境での実行・リリースに向けた準備(手順書作成、社内手続き等)も必要になり、また実行・リリースに向けた出社体制を整える必要も出てきます。
お客様の立ち合いが必要なのであれば、お客様にも立ち合いを依頼する必要があります。

【再発防止策策定】

恒久対応が完了した後、お客様へ恒久対応完了の報告を行います。
しかしそこで終わりではなく、今後同じようなことが起こらないように、障害が発生した要因の報告と、再発防止策の策定を求められることが多いです。
社内での再発防止策の検討、そして再発防止策の説明にまた工数を取られることになります。
また、再発防止策は、チェック体制の強化に繋がることも多いので、それが積み重なると開発スピードの低下にも繋がりかねません。
(多くの開発者にとってストレスになるであろう、重厚長大なチェックリスト、煩雑な承認体制、頻繁なダブルチェック・トリプルチェックは、再発防止策が積み重なって出来上がるものです)

【障害に対する金銭的な補償】

障害が発生した場合、SIer側が金銭的な補償をしなければならない場合もあります。
システムのSLA(サービス内容に関する合意文書)に補償に関する項目があるなら、それに従って補償をしなければなりません。
重大な障害である場合は、裁判で損害賠償請求されることもあります。

仮に、直接的な補償がなかったとしても、障害を発生させたことでその後の交渉でSIer側が不利になり、システム継続利用時に値下げ要求をのまざるを得なくなることも少なくありません。
ニュースで報道された場合は、直接被害が発生していないお客様との交渉でも不利になりやすくなります。
当然、競合システムに離反されることもあり、この場合も収益の低下に繋がります。


以上のように、本番障害を発生させることで、SIer側には以下のような損害が発生します。

  • 障害対応や再発防止策のための工数の発生
  • 再発防止策による開発スピードの低下
  • 障害に伴う金銭的な補償

本番障害が頻発する現場では、不定期に発生する障害対応・再発防止策の工数と開発スピードの低下が原因で、次のシステム開発にも支障が発生し、QCD(品質・コスト・納期)のバランスを取ることが困難になります。
障害に伴う補償をしただけでなく次のシステム開発も予定通りに進めることができなくなるため、収益力が低下することになります。
頑張って長時間働いても、それに見合う収益を得ることができなくなってしまいます。

このように、本番障害を発生させることによる損害は誰にとっても大きいため、本番障害を発生させないように一人一人が意識する必要があります。
障害を発生させた経験から学ぶという姿勢ではなく、社内外の過去の障害事例から学ぶ姿勢が重要になります。


いかがでしたでしょうか。

2次請け以降の立場で案件に参画していると、本番障害発生時に何をしているのか伺い知れない所が出てきます。
この記事により、その情報を上手く共有できれば幸いです。

来年も、この調子でブログを更新していこうと思います。
では、良いお年を!

ドキュメント作成時の基本的な心構え

ドキュメント作成のコツについて一般的なことを書きます。
ドキュメントの良し悪しで意図が早く正確に伝わるかどうかが変わってくるので、スムーズに仕事をこなすには欠かせないスキルです。

ドキュメントには設計書からユーザ向けのマニュアル、運用手順等、色々種類がありますが、今回はどのようなドキュメントについても通じることを書きます。

【根→葉の流れで構造的に書く】

小説のように文章をつらつらと書くのではなく、適度に見出しを付けることが重要です。
また、その見出しは、根→葉の流れで構造的に書くことが重要で、見出しだけを見れば何がどこに書いてあるのかがわかるようにすることが理想です。
プログラム改修の設計書で言うと、以下のように書くのが良いでしょう。
 
 1.背景
  ……
 2.リリース日
  ……
 3.修正箇所
  3.1.プログラムA
   3.1.1.hoge対応
    ……
   3.1.2.fuga対応
    ……
  3.2.プログラムB
   ……
  3.3.プログラムC
   ……

【箇条書きや表や図で完結に書く】

・箇条書きの使用

並列である複数の事柄を書く時は、箇条書きを用いると文章が見やすくなります。
例えば、
「条件Aの時か、条件Bの時か、条件Cの場合に、hoge処理をする」
という文章は、以下のように書くとわかりやすくなります。

以下の何れかの条件に当てはまる時に、hoge処理をする。
 ・条件A
 ・条件B
 ・条件C

・表の使用

2×2かそれ以上の項目・条件が絡み合う事象を書く場合は、表を用いると状況をわかりやすく整理できます。

例えば、下記はリスクの対応策を表にまとめたものです。

これを表を使わずに表現すると、
「脅威に対しては回避と転嫁と軽減の戦略があり、回避とは…」
といういかにも冗長な文章になってしまいます。

・図の使用

複雑な事象を言葉で説明するのは難しいですが、図解するとわかりやすく説明できることが多いです。

例えば、理解が難しい概念である「モジュール強度」と「モジュール結合度」を図解した記事がこちらです。
「モジュール強度とモジュール結合度」の図解

日本語を読んでも何が言いたいのかわかりにくいと思いますが、図解することで意図を理解しやすくなると思います。

【誤解のない表現を使う】

・客観的な数値を示す

「性能が大幅に良くなった」「キャパシティに与える影響は軽微である」
といった主観的な表現だと、それぞれの受け手毎に異なる解釈をされる可能性があります。

ここは、異なる解釈をされないように、
「性能が10倍になった」「ディスク容量が100GBであるがデータ増加量は10MBである」
といった形で、客観的な数字で表すことが重要です。

・複数の意味で取られる日本語を避ける

例えば、「私は何度もコンソールがエラーを出力する所を見ました」という文章の場合、「何度も」の係り受けが曖昧であるため、以下の2つの意味で取られる可能性があります。
 ・私は「コンソールがエラーを出力する所」を何度も見た
 ・私は「何度もコンソールがエラーを出力する所」を見た

このようなことが設計書や手順書を書く中でも起こり得ます。

出来上がった文章を読み返して、複数の意味に取られないか考える癖を身に付けることが重要です。複数の意味に取られかねない時は、上手く書き換える必要があります。
特に、文章を短く区切る書き換えは、文章が分かりやすくなる可能性が高くお勧めです。
例えば、上記の例の場合、「コンソールは何度もエラーを出力しました。私はそれを見ました。」と書き変えると、意味が明確になります。

・要件、仕様等を明確にする

要件定義書なら誰がいつどのようにシステムを使うのか定義する必要がありますし、画面設計書なら画面項目のフォーマットや桁数等を定義する必要があります。

ドキュメントによって絶対に定義しなければならないポイントがあるので、そのポイントを落とさないようにすることが重要です。
もし定義が不十分だと、情報の受け手に自分の意図とは異なる解釈をされてしまう恐れがあります。

【情報の受け手に合わせて粒度を変える】

システムの利用者にとっては、システムをどのように操作すれば良いのかがわかれば良いので、詳しい仕様は冗長な情報になります。
逆に、システムの開発者にとっては詳しい仕様こそが重要になります。

このように、情報の受け手によって、どのような粒度で情報を求めているかが異なります。
受け手にとって粒度が細かすぎる場合は知りたい情報を誤解なく手早く知ることが困難になりますし、粗すぎる場合は知りたい情報を十分に知ることができなくなります。
ドキュメントを作成する際は、情報の受け手が誰であるかを想像して、適切な粒度で情報を提供することが重要になります。


いかがでしたでしょうか。

今回は、私がドキュメントを書く時に意識していることを列挙してみました。
ドキュメントはチームで仕事を進めていく上では欠かせないものですし、未来の自分が内容を思い出すためにドキュメントを読むこともあるので、今までドキュメントを重視してこなかった方は是非意識して書いてみてください。

なお、Slackのようなチャットツールでの会話でも、この記事で挙げたドキュメント作成のスキルを活かすことができます。
特に昨今はテレワークが普及しており、チャットツールでの会話も増えているかと思いますので、チャットでの意思疎通がスムーズにできるだけでも仕事ができる人だとみなされやすくなると思います。


アジャイル開発の概要

プロセスモデルの一つとして、「アジャイル開発」というものがあります。
ウォーターフォールモデルと比較すると新しいモデルです。

アジャイル開発はその名の通り迅速に開発を行うもので、短い期間(数週間~1ヶ月程度)毎にユーザにとって重要な機能から順番にリリースを行います。
一つの期間はイテレーションと呼ばれ、計画・設計・実装・テストがこの期間の間に行われます。
このように開発を行うことで、ユーザは少ない期間・コストで重要な機能を使用することができるようになります。ユーザの要求の変更にもいち早く対応することができます。
また、システムを実際に使うと新たな要望が浮かぶものなのですが、システムを早い段階で手に取ることができるので新たな要望を早く出すことができます。仮に、せっかくリリースした機能がユーザに響くものでなかったとしても、その問題に少ない期間・コストで気付き、軌道修正することができます。
これらの利点により、重厚長大なウォーターフォールモデルを採用した場合に比べて、ビジネス上で優位に立つことができるようになります。
(特にスタートアップ企業にとってはこれらの利点が重要)

しかし、アジャイル開発はユーザの要望が頻繁に変わる小規模システムの開発には向くものの、要望が固定されているミッションクリティカルな大規模システムの開発には向かないとされています。
アジャイル開発ではシステムを小出しで開発するので、システム全体の整合性や最終製品の品質を上手く管理しないと、システムの品質が低下する問題やシステムのスケーラビリティが損なわれる問題が発生してしまいます。
そのため、教科書的には、要望が固定されているミッションクリティカルな大規模システムの開発はウォーターフォールモデルの方が向いているとされています。

ユーザーの要件を満たすプロダクトを迅速に開発するためには、それを実現するための手法や考え方が必要です。
アジャイル開発を実現するための手法、またアジャイル開発と親和性の高い考え方としては、以下のようなものがあります。

・アジャイルソフトウェア開発宣言

アジャイル開発の価値観を端的に言い表した宣言である。
原文はこちら。

・エクストリームプログラミング(XP)

迅速にプログラミングを行うための手法。
リファクタリング(保守性を高めるためのコード見直し)、ペアプログラミング(一人がコーディング、もう一人がリアルタイムにコーディングを見ることで、即座にレビュー・知識共有を行う)、テスト駆動開発(テストケース・テストコードを先に設定してからプログラミングを行う手法で、テスト自動化が伴う場合が多い)、等により実現する。

・プロトタイピング

ユーザからのフィードバックを早期に得るために試作品を作成して提供する。
試作品はコーディングして作成するとは限らず、紙芝居のような形でコンセプトを伝えるペーパープロトタイピングと呼ばれる手法もある。

・スクラム

チーム一体となってプロジェクトを遂行して行くことに重点を置くプロセスモデル。
デイリースクラム(始業時に今日の予定と問題点を共有する)、プロダクトバックログ(システムの要求一覧)、スプリントバックログ(イテレーション内で対応する要求一覧)、イテレーション、スプリントレビュー(イテレーション内で開発した機能のユーザとのレビュー)、ふりかえり(イテレーション終了時の改善点の共有)等により実現する。

・バーンダウンチャート

縦軸に「残作業量」、横軸に「時間」を割り当て、残作業量を折れ線グラフにより記述したチャート。
ガントチャート等と比べて、プロジェクトの進捗状況をいち早く把握することができる。
誰もが見える場所に張り出すと効果が高い。

・リーン生産方式

トヨタ生産方式を元に編み出された方式。
開発工程におけるムダを排除することを目的として、製品および開発工程の全体にわたって、トータルコストを系統的に減らそうとするのが狙い。「ムダをなくせ(顧客に価値を与えない作業を無くす)」「学習を強化せよ(反復型開発)」「決断を遅らせよ(状況の変化に合わせた決断)」「できる限り早く出荷せよ(機会損失防止)」「チームに権限を(チームの手で最良のプロセスを採用)」「摺り合わせて作り込め(ユーザとのトライ&エラーの繰り返し)」「全体を見よ(全体最適化)」という7つの原則によって成り立っている。

・チケット駆動開発

スプリントバックログを約2~3時間のタスクである「チケット」に分割し、チケットを管理することで、メンバーの作業把握と成果物の更新理由の把握を容易にする。
チケットによる管理を行う場合は、チケットの完了(Done)の定義を明確にし、完了基準を満たすまでは完了とみなさないようにすることも重要である。

・ストーリーポイント

案件の規模や複雑性を「ストーリーポイント」と呼ばれる直感的・相対的な基準で測ることにより、俯瞰的な視点で直感的に迅速に見積もりを行う。


いかがでしたでしょうか。

日本ではアジャイル開発はあまり普及しておらず、アジャイル開発を採用しているプロジェクトには巡り合えないかもしれませんが、それでも顧客の要望に沿ったシステム開発を行う必要があることには変わりありません。
そのため、ウォーターフォールの開発だとしても、アジャイル開発の手法や考え方は部分的にでも取り入れることは有効ですし、実際に部分的に取り入れているプロジェクトも少なくありません。
開発者としても、アジャイル開発の手法について知っておくことに越したことは無いでしょう。

リーダーシップ状況論の理論と実践

今回の記事では、リーダーシップの理論と、IT業界における実践について述べていきます。
情報処理技術者試験対策としては理論を知っていれば良いですが、実際に現場で活かす上で役に立つ情報(経験則)も書いていきます。


【理論】

組織とリーダシップの関係は下記図のようになるとされています。
組織が成熟するにつれて、有効なリーダーシップの取り方がa→b→c→dに移行するとされています。

aは組織の発足時の段階です。
構成員のスキルも自主性も不足しているため、仕事関係本位でリーダー自ら先頭に立ってチームを引っ張る必要があります。
スポーツに例えると「選手をきちんと管理することが勝つための条件だ。」という状態です。

bはaから成熟度が進み、構成員がスキルを身に付け始めた頃です。
構成員を引っ張るだけでなく、リーダーが1から10まで指示しなくてもチームがパフォーマンスを発揮できるようにするために、構成員の自主性を育て大切にすることも考える必要が出てきます。言い換えると、仕事関係本位のリーダーシップだけでなく人間関係本位のリーダーシップも強めていくことが有効になります。
スポーツに例えると、「うるさく言うのも半分くらいで勝てるようになってきた。」という状態です。

cは更に成熟度が進み、構成員が自主性を身に付けはじめ、自分の仕事を自ら見つけ、必要なスキルを自ら身に付けるようになり始める段階です。
この段階になると、仕事本位のリーダーシップを取る必要性が薄くなり、構成員の自主性を維持するための人間関係本位のリーダーシップを前面に押し出すことが有効になります。
スポーツに例えると、「勝つためには選手と十分に話し合って戦略を作ることだ。」という状態です。

dは成熟度が最も進んだ段階です。
各々の構成員が自らリーダーシップを取るようになるので、リーダーは人間関係本位のリーダーシップも弱め、構成員に任せて見守るというリーダーシップの取り方が有効になります。
スポーツに例えると、「勝つためには選手に戦術の立案と実行を任せることだ。」という状態です。


【実践】

IT業界の開発の現場では、具体的に以下のことが言えます。

最も成熟度が低いaの状態というのは、構成員のスキルも自主性も不足している状態のことです。もう少し具体的に言うと、成果を出すために何をすれば良いのかわからない状態や、そもそも成果を出すための意欲が低い状態のことを指します。
現場としては、全くの新規プロジェクトの現場や、前任者が離脱して残された構成員が右往左往している現場、組織再編や短納期化等でこれまで頼っていた社内プロセスを見直さざるを得なくなった現場等が、これに該当するでしょう。
この状態の組織では、十分な能力や経験を持つ者がリーダーとなり、リーダー主導で作業計画や品質強化を行う必要がありますし、リーダー自ら設計や開発に関わる必要もあります。炎上プロジェクトの火消し役、というのもここに含まれます。
リーダーのワンマンプレイのようになるので人間関係に軋轢が生じることもありますが、この段階では副作用としてある程度受け入れざるを得ません

成熟度が少し高くなり、bの状態になると、構成員にスキルが身に付き始めます。この状態になると、末端の細かい判断や作業は構成員自らできるようになります。
現場で言うと、混沌とした時期を乗り越え、プロセスが正常に回り始めた現場と言うことができると思います。
この状態になると、構成員がプロセスに沿って自ら仕事ができるようになります。リーダーは、構成員がプロセスに沿って仕事ができるようにサポートするのが主な仕事になります。
まだまだリーダー自ら動かなければならない場面も多いですが、このあたりからは構成員に任せる仕事の範囲を徐々に広げ、構成員と良い人間関係を築くことも考える必要が出てきます。あまり長い間リーダーが前面に出ていると、構成員の自主性が育つのを阻害し、次の成熟度へ進むのが難しくなります。

成熟度が更に高くなり、cの状態になると、構成員に自主性が育ち、自ら考えられるようになります。
この段階になると、重厚長大なプロセスに頼らずとも、各々の構成員が適切な判断をするようになります。不測の事態が発生した時にも対応が楽になりますし、そもそも不測の事態が発生しないように各々の構成員が手を打つようになります。
この状態になると、これまでリーダーが行っていたような判断を構成員自ら行うようになりますし、その上で足りないスキルがあれば構成員自ら努力して身に付けるようになります。
この段階になれば、リーダー自ら動く必要はなくなります。構成員が気持ちよく仕事ができるように(このリーダーの下で働きたいと思ってもらえるように)、人間関係のメンテナンスに注力するのが有効になります。

成熟度が最高に高まり、dの状態になると、構成員自らリーダーシップを取るようになります。
各々の構成員が適切な判断をするようになるだけでなく、リーダーのように組織作りといったことも考えるようになります。
この段階に到達すると、リーダーは人間関係のメンテナンスをする必要もなくなります。
リーダーの仕事は、構成員に任せて見守るというものになります。この状態であれば、リーダーが更に上の立場に昇進したとしても、現場に問題は発生しないでしょう。


いかがでしたでしょうか。

今回は、リーダーシップ状況論について、情報処理技術者試験で問われることだけでなく、より実践的なことを経験則から補記しました。
実践的なことも知っていると、記憶が定着しやすくなりますし、知識も活かしやすくなると思います。