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

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


【理論】

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

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

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

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

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


【実践】

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

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

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

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

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


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

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

ソースコード修正の競合と統合

複数の案件が同時に動いており、1つのソースコードを複数の案件で修正する場合、ソースコード修正の競合(コンフリクト)の統合(マージ、差分取り込み)が必要になります。
統合には、全体のロジックの整合性や案件のリリース時期の違いを考慮する必要があり、機械的に判断できない場合もあるので、最終的には人の手で判断し統合する必要があります。


例えば、商品の販売価格を計算する以下のソースコードがあるとします。
(今回はjavaのソースコードであると仮定します)

・修正前ソース

このソースコードについて、下記3案件で修正するものとします。
案件1.消費税増税対応(3ヶ月後リリース)
案件2.店舗毎セール対応(3ヶ月後リリース)
案件3.タイムセール対応(6ヶ月後リリース)

3案件の修正後ソースはそれぞれ以下の通りとします。

・案件1

・案件2

・案件3

リリースすることを考えると、以下の2段階に分けてソースコードの修正を統合する必要があります。

・3ヶ月後を想定

 案件1と案件2を統合

・6ヶ月後を想定

 3ヶ月後のソースと案件3を統合


案件1と案件2の統合は容易です。
以下のように機械的に統合することができます。

・3ヶ月後のソース

対して、3ヶ月後のソースと案件3を統合は機械的に行うことができません。
修正ポイント2-5と修正ポイント3-4は同じ個所を修正しているので、両方の修正が反映されるようにソースを書き変えなければなりません。
そもそも、修正ポイント2-3でコンストラクタが追加になっているため、新たに追加したコンストラクタに対しても案件3の内容を反映しなければなりません。
よって、6ヶ月後のソースは以下のようになります。

・6ヶ月後のソース


なお、バージョン管理システムのGitのブランチやマージの機能を使えば、これらの統合の作業が楽になります。
機械的に統合できる箇所は自動で統合できますし、機械的に統合できないブランチについても以下のような方法を用いて比較的容易に統合することができます。
(具体的な操作方法は省略します。操作方法はWebで調べられるので、必要に応じて調べると良いでしょう。)

  • Gitが出力した差分を見てエディタで編集
  • 競合の原因となったコミットを取り消しコミットし直し
  • マスター管理しているブランチを元に新たにブランチを作り直し、作り直したブランチに対して同じ修正を行う

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

「ソースコード修正の競合と統合」と言うと、Gitのテクニックが求められるように思われるかもしれません。
しかし、Gitの操作が多少不得手でも、何をしなければならないのかが理解できていれば、多少手間取ったり非効率になったりすることはあっても、最終的には問題無く修正作業を行うことができます。
まずは、何をしなければならないのかを理解することに努めましょう。
(それを理解する上で、今回の記事が参考になれば幸いです)

障害の発生原因の切り分けのポイント

テストや本番運用で障害が発生した場合、既知の障害等で原因が明らかな場合を除き、対応のために原因を調査する必要があります。
原因を調査する上ではどこに原因があるのかの切り分けが必要になります。
以下では、切り分け作業を行う上でのポイントを順を追って説明します。

1.障害が発生した状況を保全する

障害が発生したデータやその状況を記録したログは後の調査で使いますので、誤って更新したり削除したりしないように保全する必要があります。
テスト中であればそのデータを用いたテストは中断する必要がありますし、場合によってはコピーして別の場所に補完する必要があります。

2.期待される値との比較を行う

データやログを見て、設計上期待される値と異なる点を探していきます。
コーディングの単純な誤りであれば、大抵の場合は、データが期待値と異なるようになった箇所やログの出力内容から原因を特定できます。
場合によっては、その期待値自体が合っているのかどうか、設計や要件の確認・再検討が必要になる場合もあります。

3.障害発生手順を確立させる

ログの出力内容が不足している場合や原因が込み入っている場合は、データやログを見ただけでは原因がわからない場合があります。
その場合は、障害が発生した時と同じ手順で障害の再現を確認します。
障害が再現すれば、障害を発生させる手順が確立されたということになります。
厄介なのは障害が再現しなかった場合で、一意キー(顧客番号や受付番号の類)が障害発生時と異なることに注目して一意キーと結びつくデータを洗い出す、ランダムに処理が変わる箇所がないか(乱数を使っている箇所や振り分け先がランダムなロードバランサー等に注目する)、という観点で再現しなかった理由を調査し、障害発生手順を確立させます。
どうしても確立できない場合は、ハード障害である可能性を視野に、障害発生時の状況をまとめてハードウェアを提供するベンダーに確認する、というアクションを起こす必要がある場合もあります。
(私の経験上、「太陽フレアでビットが入れ替わってしまった」という冗談のような原因を告げられたこともあります)

4.再現手順を元に開発環境で原因調査を行う

再現手順が確立したら、開発環境で再現手順を試し、徐々に原因を絞り込んでいきます。
もし環境を変えたことで障害が再現しなくなった場合、環境問題である可能性が出てきます。
(例えば、マスタデータの不備、機器の構成の違いに起因する問題、等)
障害が再現する場合、開発環境ではデバッグを入れて変数の内容を表示することができますので、それをログの代わりにして原因調査を進めることができます。
また、開発環境ではデータも自由に書き変えられますので、データを少しずつ書き変えて挙動を確かめることでも、原因調査を進められます。


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

障害調査は経験則で語られることが多いので、私自身の経験を基に文章にしてみました。
もし参考になれば幸いです。

テレワークにおけるコミュニケーションのコツ

コロナ渦の影響で、テレワークが流行っています。
テレワークではコミュニケーションの取り方が変わるため、チャットでのやりとりに慣れていない技術者がコミュニケーションの取り方に悩むという姿を目にします。

先日、相談に乗る機会があったので、それを元にうまくコミュニケーションを取るコツを書いていきたいと思います。

1.姿が見えない環境であることを意識する

テレワークでは相手の姿を見ずにコミュニケーションを取ることが多いです。
そのため、表情やしぐさを読み取り円滑にやりとりするということができません。
友好的な態度、意欲的な態度、切迫した状況、等はチャット上で示す必要があります。

友好的な態度は、顔文字や絵文字を使い表情を豊かにすることで示すことができます。
例えば、Slackでは顔文字や絵文字が登録されています。
登録されている顔文字や絵文字であれば、使って問題無いと思います。

意欲的な態度は、文字で示すしかありません。
対面のコミュニケーションとは異なり、文字に起こさないと察してくれません。
仕事が欲しい場合は、手が空いたから仕事が欲しい、と明確に書く必要があります。
そこで作業が無いと言われた場合は、自分で作業を提案する必要があります。
(ドキュメントの改善、自分が携わるシステムの勉強、等)

切迫した状況を伝えるには、現在の状況や作業の期限を明確に書く必要があります。
音声でチャットしたい、と書くだけでも暗に急ぎであることを示すことができます。
音声チャットは、相手の時間を取らせる代わりに、早く要件を終わらせられます。

2.どれが自分の書き込みなのかを認識しやすいようにする

リアルのコミュニケーションでは顔や声で個人を認識できます。
しかし、文字だらけのチャットでは、すぐに個人を認識できない場合があります。
これはコミュニケーションを難しくさせ、時に認識齟齬の原因にもなり得ます。

そのため、チャットツールのアイコンやアバターを設定すると良いです。
アイコンやアバターにより、視覚的に個人を認識することができるようになります。

3.スルーされても気にしない

リアルのコミュニケーションでは、声をかければ何かしら反応が来ます。
しかし、テレワークでは、チャットに書き込んでも長時間反応がないことがあります。
これは不安に思うかもしれませんが、多くの場合は問題ありません。
システム開発は、作業の性質上、作業に没頭する時間が必要です。
作業に没頭している時はチャットに気付きにくくなります。
そのため、長時間反応がなければ、作業に没頭しているだけだと思いましょう。

本当に急ぎの時は、チャットとは別ルートで通話を申し込むと良いです。
逆に言うと、作業に没頭する時も、別ルートの申し込みはチェックするべきです。


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

チャットでは、リアルのコミュニケーションとは異なるコツが必要になります。
コロナ禍が収まった後もテレワークが実施され続ける可能性もあるので、これを機に慣れておくと良いと思います。
SNSや、プライベートの趣味のチャットと似通った部分もあるので、これらのことをついでに始めても良いかもしれません。

Word:改行時に勝手に番号が割り振られないようにする

Wordを使っていて思い通りに文書が書けないことは良くあります。
良くある悩みの一つは、「勝手に番号が振られてしまう」というものです。

例えば、「1.ほげ」と入力して、Enterを押下すると、以下のように勝手に番号が振られます。

「1.」と入力すると、段落が入力されたものだとWordの内部で判断されるため、このような挙動となります。

お勧めの解決法は、Shift+Enterで改行することです。
Shift+Enterで改行することで、「箇条書きは続いているけど次の箇条書きには移っていない」とWordの内部で判断され、内部的にも見た目的にも上手い具合になります。 次の箇条書きに移りたい時は、Enterで改行すれば良いです。

なお、よく見る解決法として、箇条書きの自動設定をオフにするという方法があります。
しかし、この方法には、既定の設定を変更するのは面倒という欠点があります。
また、自動で箇条書きになるというのを理解していれば箇条書きしたい時にEnter一つで箇条書きにできるので、箇条書きの設定は必ずしも不便な設定というわけではないです。

他の解決法としては、自動的に番号が振られた後にCtrl+zで自動操作を戻し箇条書きを解除するという方法が挙げられることもあります。
この解決法を用いると見た目を整えることはできますが、改行した箇所以降は箇条書きではないとWordの内部で判断されてしまいます。
箇条書きの機能自体は理解していれば便利(例えば目次を自動で作ることができる)なので、Wordの良さを活かすという意味で言うとこの解決法もあまり良くありません。
(見た目だけ整えれば良いのであれば、それこそExcel方眼紙の方が良いという話になってしまいます)


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

SIerの業界では「Excel方眼紙は慣れているけどWordには慣れていない」という人が少なくないと感じたので、このような記事を書いてみました。

ちなみに、Word以外にも、Enterだと段落が変わりShift+Enterだと通常の改行が行われる、という挙動のソフトウェアが存在します(例えばコミュニケーションツールのConfluence)。
Shift+Enterは半ば一般常識化している面もあるので、通常の改行はShift+Enterで行うという癖を身に付けておいても良いかもしれません。