2018 4月

タイムトラッキング（時間管理）で効率よく仕事をしよう【2018年度新版】

皆さんはタスクを処理する際、タイムトラッキング（時間管理）を行なっていますか？ 時間は全員に平等に与えられているもので、「Time is money」と言われるように時間が重要なものであることは明白です。時間管理を上手に行なえば、タスクを効率よく処理したり、自分の自由な時間も作り出すことも可能になります。
今回は時間をうまく利用することができるツールについていくつかご紹介します。

タイムトラッキング（時間管理）とは

タイムトラッキングを3日坊主にならないようにするには

タイムトラッキングを継続するための条件を簡単にまとめてみました。

シンプルでつけやすい

大前提としてシンプルで簡単ではないと、長続きせず飽きてしまいます。仮に操作が複雑であれば、開くのも面倒だと感じるようになるでしょう。そのため万人がつかいやすいようなモノがおススメです。

スマホも対応可能

パソコンを開いて毎度管理するのはとても手間がかかります。いまの時代スマホを持っていない人はいないといってもいいほどスマホは普及しています。そんなスマホであればいつでもどこでも時間管理が可能になるので、手軽に利用できます。

細かくつけすぎない

時間管理だからと言って、これは1時間、これは30分と、最初から細かく予定を立ててしまうと達成できず嫌になってしまいます。慣れるまでは大まかにつけて、自分の処理スピードを知ってから、細かく管理しましょう。

人気のタイムトラッキングツール

実際の企業で使われているツール、人気なツール、またその特徴についてご紹介します。

Teamhack（チームハック）

≪特徴≫

Teamhackは1つのツールでプロジェクト管理から情報共有まで全て可能です。もちろんタイムトラッキング機能もついているので、簡単に時間の管理ができます。またメンバーのタスク処理のスピードや納期についても確認が可能です。また無料でのお試し版を体験することができ、容量10GBのビジネスプランでは、1ユーザーあたり、月額1200円、年間契約割引で月額1000円です。1つのツールで全てを管理したい人にはおススメなツールです。

株式会社カタリストシステム　https://teamhack.io/

Timecrowd（タイムクラウド）

≪特徴≫

シンプルで使いやすい「Timecrowd」は個人での利用も可能ですが、チームでの利用が念頭にあるそうです。スマホとも連動をしているので、手軽にタイムトラッキングが可能になっています。個人利用は完全無料となっていて、チームでの利用は2週間お試し無料、540円 ✕ チームの所属人数が利用料金（月額・税込）となっています。チーム全員で一体となり、その上個人の時間もうまく利用したい人におススメです。

タイムクラウド株式会社　https://timecrowd.net/

Wrike（ライク）

≪特徴≫

「Wrike」は機能がとても豊富で使いやすいツールです。指標の管理にはボード・タイムライン・リストといったように様々な形式で表示が可能です。タイムトラッキングを利用するには有料版が必要です。50GBのBusinessプランでは一ユーザー当たり$24.80となっています。Teamhackと同様に一度で全てを管理したい人におススメです。

Wrike　https://www.wrike.com/ja/

Everhour

≪特徴≫

「Everhour」はチームでのトラッキングが可能で、リアルタイムで進捗が可能なため、だれが仕事をしていて、していないのかもすぐに確認可能です。加えて、AsanaやSlackなど多くのツールとの連携が可能なのがとても強みだといえます。無料版はありませんが14日間のトライアル期間を設けていて、ソロで使う場合には8ドル、チームでは最低5人で35ドルとなっています。

Weavora　https://everhour.com/

Clock It!(クロックイット！)

≪特徴≫

無料で利用が可能な「Clock It!」はシンプルなため人気があるといえます。作業時間を現在のタスクの進行から見積もりを自動的に出してくれるのもとても魅力的だといえます。無料のbasicプランでも十分だが、一月あたり980円のteamプランでは人件費の分析やカレンダー機能、最近では看板ボードが加わりました。

まとめ

いかがでしたか？自分にぴったりなツールは見つかったでしょうか。上手に時間を管理できるようになり、効率よく仕事をこなせるようになれば、会社の業績にもつながり、働き方改革の面からみると自分の時間をうまく利用できるようになる「ワークライフバランス」の充実にもつながってくるのではないでしょうか。メリハリよく物事を進めていき、自分の時間を支配しましょう。

烏合の衆をまとめ上げるリーダーシップ （２）　連載第７回

前回、フリーランスが一斉に集まってプロジェクトが始まった場合のリーダーシップについて取り上げました。これは1つの成功パターンとして理想のケースに該当するのですが、世の中あまたあるプロジェクトすべてがこうなるとは限りません。
例えば、炎上中のプロジェクトに外部からPM PLが招聘されてプロジェクトを立て直すといった事例もよく聞く話であります。こうしたケースにおいて、リーダーはどうやってプロジェクトの健全性を取り戻すのか、考察してみたいと思います。

炎上プロジェクトに火消し要員を招聘する、ということ

普段から付き合いのあるフリーランス同士が集まったプロジェクトで炎上した場合、関係者一同の総意として外部からリーダーを招聘するであろう、という前提として一旦本稿では考察の対象外とし、初見のメンバーだけで始まったプロジェクトにおいて、プロジェクトオーナーが現状を見かねて外部からリーダーを招聘したケースを想定することにします。

プロジェクトの途中で人をアサインする、ということは

人月の神話でフレデリック・ブルックスはこう書いています。

遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。

いわゆるブルックスの法則として有名ですね。ということは、メンバーであれリーダーであれ、誰かしらを追加要員としてアサインすると、必ずそのプロジェクトの進捗が遅延するのでしょうか。いいえ違います。単に既存のメンバーと同じスキルセットを持ったメンバーを追加でアサインしても、プロジェクトの状況説明や仕様のインプットなど、コミュニケーションの追加コストを支払う割に進捗しにくいことは事実ですが、こうした炎上プロジェクトにおいて単なる作業者を追加するのではなく、俯瞰して状況を観察し軌道修正を図れるリーダーを招聘することで、プロジェクトの立て直しを図るのです。

プロジェクトの途中でリーダーを招聘する際にプロジェクトオーナーがすべきこと

仮に、現在炎上しているプロジェクトにおいて
•既存のメンバーは自己のアウトプット、自己の責任を全うすることにしか興味がない
•メンバー間のコミュニケーションが皆無または少なく、それぞれがバラバラに品質や納期の調整をしたがる

こうした兆候が見受けられる場合、既存メンバーと同じタスクをこなすメンバーを追加アサインしたり、メンバーを総入れ替えしたりするよりも、まず全体を統括するリーダー招聘を検討しましょう。

プロジェクトオーナーは本来、プロジェクト全体を統括する立場ですが、ビジネス上の判断を技術者へ伝えたとしても、技術者が同じ温度感、同じ優先度でそれを理解できるとは限りません。ですので、ビジネス上の課題を正しく理解し、技術者が同じく理解できるようタスクの優先順位づけをしてプロジェクトのリカバリができるリーダーを招聘するべきです。

しかし、一方でビジネス上の課題と技術上の課題がイコールであるとは限らず、必ずしもビジネス上の課題がすべてに優先するとも限りません。ですので、プロジェクトオーナーはリーダーにイエスマン的な振る舞いは絶対に求めないでください。

炎上プロジェクトにリーダーを迎え入れたら最初にすること

炎上プロジェクトにリーダーを迎え入れることになったら、プロジェクトオーナーは最初に、次の4つを実行してください。
•リーダー招聘の理由説明とともに、オーナーがこれまで持っていた権限をリーダーに移譲した、という宣言をメンバー全員に(できれば同時に対面で)する
•招聘されたリーダーはメンバー全員に対して平等に接することを宣言する
•すべての作業はリーダーが承認してから行なうようルールづけする
•すべてのチケットは全員が平等に見えるようにする
以上の4つですが、目的は「今までのやり方ではうまくいかなかったという危機感を共有する」このたった1つです。

炎上プロジェクトにアサインされたリーダーのミッションとは

リーダーはまずメンバーの面倒ごとを巻き取ることから始める

炎上プロジェクトにアサインされたリーダーは、まず「コードを書く(実装する)以外のすべての面倒ごとをメンバーから巻き取る」つもりでメンバーと接することを強くおすすめします。

プロジェクトオーナーから招聘されたリーダーは、着任するまではオーナーの主観、ビジネス上の課題と現実の戦力にギャップがあるといったネガティブな情報しかもたらされていません。また、一方でメンバーからのインプットはゼロかそれに近い状態で着任するわけですから、客観的な事実を確認するためにも、まずメンバー全員から「面倒ごとを巻き取りたいので」という持ちかけかたでヒアリングを始めましょう。

もし、メンバーから集まった面倒ごとが、本当にビジネス上の課題として置き去りにされていたのであれば、まずそこから着手すべきという判断になるでしょうし、逆に、不要な面倒ごとに対して高い優先度が割り当てられていたのであれば、プロジェクトオーナーに「チームの総意として」これを諫言し、本来やるべきタスクの優先度を上げることができるよう調整するべきなのです。

リーダーはメンバーとの接し方に細心の注意を

さて、リーダーはプロジェクトの要請で参画したのですが、正しくは「プロジェクトオーナーの要請」であって、メンバーを含めた総意で迎え入れられたとは限りません。ですので、
•最初からメンバー全員の協力が得られるとは限らない
•メンバーからは、自分たちの利益ではなくオーナーの利益のために招聘されたと思われている可能性がある

この2点を充分念頭に置いて振る舞いましょう。また、もう1つ大事な着眼点があり、それは「既存メンバーは着任したばかりのリーダーが知らない情報を山のように持っている」ということです。こうした観点を踏まえ、リーダーはメンバーとの接し方に細心の注意をはらうべきなのです。

炎上したプロジェクトにおいては、往々にしてビジネス上の要求と技術的課題の狭間で、あるいは、メンバー間などで様々な対立がおこりがちです。こうした対立はとかく主観と主観のぶつかり合いに終始する傾向にあるので、常に客観的事実で判断し、最適な着地点を探し当てることが求められます。

プロジェクト再生における取捨選択

本稿でこれまで述べた、プロジェクトオーナーや新規着任したリーダーがやるべきことは、あくまで「取捨選択」の範囲で行う優先順位付けの整理です。炎上プロジェクトを救う銀の弾丸などない、と言うのは簡単ですが、限られた納期や予算の中でプロジェクト再生を行うには、ALL or NOTHINGの発想ではなく、まず取捨選択という発想をしましょう。

もちろん、時には今まで書いたコードのほとんどを捨てる選択をしなければならないこともあるでしょう。しかし、決してコードを書いた人を責めてはいけません。何故なら、最初から書きたくて捨てられてしまうクォリティのコードを書いたわけではないからです。

人間は感情の動物です。そして、社会性をもった動物でもあります。言い換えれば、正しい動機づけさえ行われて正当な社会的評価、承認欲求が満たされればプラスの結果へ向かいます。ですので、取捨選択の理由を人の資質に求めず、先ほども述べたように「今までのやり方ではうまくいかなかったという危機感を共有する」ことを繰り返し理解してもらうしかありません。

一方で、プロジェクトオーナーは「これだけ予算と期間をかけたのに」という執着を少なからず持っています。また、プロジェクトオーナーが上司や株主や顧客に対して説明責任を持っていることも多く、こうした焦燥感や不安感から、現実解とはかけ離れた要求を(リーダーを通じて)メンバーへ行うこともあるでしょう。

つまり、先ほど述べた「人間は感情の動物」「社会性をもった動物」というのは、プロジェクトオーナーにも当てはまるのです。しかし、こうした要求が果たして正当なのかどうかを判断し、プロジェクトオーナーを諌める必要すらあるのです。また、こうした局面において、感情に感情で処理しようとすると往々にして収集がつかなくなります。まったく感情を無視してドライに処理するわけにもいきませんが、必要以上に感情論に振り回されず、プロジェクトオーナーあるいはメンバー側のどちらにも偏らず、公平で客観的な判断が常に求められることを常に意識しましょう。

アルバイト求人情報サービスの定番アプリ「an」の開発の裏側を公開！

アルバイト求人情報サービス「an」の開発元であるパーソルキャリア株式会社（旧株式会社インテリジェンス）。「an」と言えば、アルバイト情報の定番ブランドでもあります。現在では、Webサイトとアプリ両方を運営されているわけですが、こちらは開発体制が大きく異なっているということで、今回はアプリ開発を担うanサイトBITAグループの地家（じけ）さんに、スクラム開発についてのお話を伺ってきました。

「an」のアプリ誕生を振り返る

今年は「an」アプリの大幅リニューアルを行なわれたとのことですが、「an」と言えばアルバイト求人情報サービスのブランドとしては定着しているようにも思います。そんなブランドであるが故の開発の苦労なども想像できますが、まずは全体の開発体制を教えていただけますか？

全体のブランドという点からご説明しますと、「an」はWebサイトとアプリで共通の基盤を持っていますが、Webサイト側はウォーターフォール型。アプリはスクラム開発でという体制になっています。

もともと、開発において外注している範囲が広かったため、コストやスピードに大きな課題がありました。「○○を変更したい」と思っても、予算の確認をしたりと手間がかかることもあり、肝心のPDCAをスピーディーに回しにくく運用にとって致命的と感じられるようになってきました。

しかも、「an」アプリは５年前に公開された古い基盤の使い回しが続いていたので、経年劣化による品質低下やそれによるストアランキング低迷など多くの課題を抱えていました。

５年前というと、2012年から2013年のことになりますか

その後、2016年の11月くらいに、開発経験のあるエンジニア数人でアプリのスクラム開発を始めたというのが、弊社のスクラム開発の始まりですね。

せっかくアプリが広く活用されているのに、ユーザーデータの分析基盤を構築できていなかったりして、ユーザーの動きに対する分析と対策が打てていない状態を改善していこうという気運が自社開発での勢いをつけたのだと思いますね。

ん？　その言い方は、当時はまだスクラムマスターではなかったということですか？

入社４年目、いきなり「スクラムマスター」になる

スクラムマスターになったのは、今年の１月からです。それまではメンバーとしてスクラムチームに参加していたのですが、スクラムマスターの役割を果たしていたものが退職することになって、私が手を上げたという事情です。

それでは、改めてスクラム開発についてのお話を伺っていきたいと思います。

もともとは、プロジェクト開始から2週間おきに開発スプリントを回していました。2週間ごとにUIやバグの改善を繰り返し、随時アップデートも行なっていくという体制が基本です。

管理体制としては、Redmineにスクラムプラグインを導入したものがベースです。

アプリの場合、公開アップデートのスケジュールも重要に思いますが

大きなアップデートは、２、３ヶ月ごとにというスケジュール感でしたね。小さな修正・改善は2週間のスプリントごとで行っていましたが、これからはもう少し短いサイクルで更新していけると思います。

というのは

私がスクラムマスターになって、２週間スプリントだったものを１週間スプリントに変更しました。ひとつには、今回の大型アップデートでそれまで懸念していたことは大きく改善できているという考えがあることと、スプリントの期間を短くすることでスプリント計画の精度を高めたいという狙いがあります。

もう少し詳しくお聞かせいただけますか

先ほど、自ら手を上げたとお伝えしましたが、もともとスクラムマスターはやってみたかったことです。が、予定よりも早くにスクラムマスターになってしまった、という自らの印象もあって、自分の中でスクラムマスターになるための知識や経験の絶対量が不足しているという意識もあります。

だから、スクラムマスター研修に参加したり、よりよいスクラム実践のために知識を身につける活動を意識しています。

これまでのスクラムのやり方を変える必要があると感じるのは、例えばどんな課題感があるのでしょう

過去には、本来ならレビューで解決できることが長期のテスト期間を費やすことになってほとんどウォーターフォール型のようになってしまう、ということもありました。それはそれで、そうなってしまった原因も明確ではあるのですが、スピードと高品質の開発という点で、体制的にももっと改善すべきところがたくさんあると感じたことです。

今年３月、地味に大きなアップデートを実施したばかり

３月には、速度改善のためのフロント側の実装方法を改善されたとか。こういった地味なアップデートは多くのユーザーが存在するサービスには欠かせないものですが、実はとても大変なのですよね

アプリのフレームワークはionicを使っていたのですが、速度改善を目的としてionicのバージョンを1から3に上げました。フロントのソースは全面的に書き直しとなる大きな改修でしたが、プロダクトの安定化に伴って開発に余裕ができてきたからこそ、いま取り組むべき、という声が挙がりました。

Ionicは、HTML5ハイブリッドモバイルアプリの制作に便利なフレームワークです。Cordova/PhoneGapでモバイルアプリを作る際もIonicの利用をおすすめします。
Ionicはモバイルアプリによく使われるコンポーネントを、再利用・改造できる形で用意しています。また、非常に使いやすいCLI（コマンドラインツール）が用意されているため、新規作成、コンパイル、実行、エクスポートが快適にできます。新しい機能も継続的に追加されて、単なるフロントエンドフレームワークの域を超えています。ネイティブアプリやレスポンシブWebアプリを制作する前の、プロトタイプ制作にもぴったりです。
https://www.webprofessional.jp/5-ionic-app-development-tips-tricks/

少し話を戻しますが、１週間スプリントは具体的に曜日ごとのスケジュールが決まっていますか？

スクラムセレモニーは水曜日に集中して時間を取っています。

スプリントレビュー：計画した価値が生まれているかを確認する。 より良くするためにはどうしていくかを学ぶ
プロダクトバックログ・リファインメント：「いま」ではなく「次」さらに「その次」のスプリントの準備をする。継続実施することで、スプリントプランニングにおける計画精度を向上させることになる。
スプリント計画：プロダクトバックログの優先順位の高い項目について、目的や状況を話し合い、理解を共有 すること。

セレモニーを水曜にまとめることで、他の日は開発に集中できる状態にすることが理想です。

レトロスペクティブは、KPT手法を取り入れていますが、最近はPROBLEMやTRYが出てこなくなっています。プロダクトやチームが安定してきたということだと思いますが、もっと潜在的な課題を抽出できる方法を模索中です。

ベロシティはどのようにしていますか

スクラム体制として、という前提で語ると、生産性の強度はそこまで高くはないです。Redmineで管理をしています、とお伝えしていますが、タスクを共有する際にストーリーポイントを記入するようにしています。この場合、メンバー一人ひとりのユーザーストーリをそれぞれ一覧化して確認するということをしています。

見積もりを「作業」で図るか、「時間」で図るかということも、課題として見えています。現在は、スプリント内で終わらなかったタスクを次へ先送りしてしまったり、スプリント期間の途中ですべて消化してしまった場合には小さなユーザーストーリーを追加で実施して調整をしています。

スプリント計画の段階では、絶対的な「時間」での見積もりを取り入れることで予実のブレをなくしていきたいと思っています。

ところで、利用ツールについて、改めて確認です。Redmineは伺いました。コミュニケーションの面では、なにを使っていますか

ロケットチャットですね。実は、Slackではないんですよ。これは、会社としてのセキュリティ指針から判断されています。

「究極のオープンソースWebチャットプラットフォーム」を謳ったチャットツール
https://rocket.chat/

「an」アプリの今後は

チームのみなさん、元からスクラム開発のメンバーだったのですか？

いえ、ほぼ全員スクラム未経験で加わってアプリ開発を始めています

多くの企業でも同様なのですが、そうしたスクラム未経験のエンジニアに対してなにか研修などの試みはどのようにされているのでしょうか

そのあたりはスクラムマスターからの説明で補っているところですね。スクラムとしては、最初の体制がうまく回ったことで、機能はしているという実感が全員にあるのだと思っています。

実際に、今回のアップデートによる定量的な効果が出始めています。目標に掲げていたのはユーザーの応募数増加だったのですが、 結果的にリニューアル前の1.5倍ほど増加しました。

さらに、ストアへよいレビューも増えており、ストアでのアプリ検索でも上位表示されるようになりました。おかげさまで、DL数も順調に増えています。

「an」と言えば、アルバイト求人情報サービスの老舗ブランドです。一方で、まさに「an」がそうなのですが、紙メディアからwebになり、さらにどんどんアプリ化が進んでいくサービスへの展望っていかがですか

まだまだこれから新しい価値を提供していく段階ではないかと思っています。
これからの、新しいアルバイトの探し方、マッチングのあり方を模索していき、社会への提案を進めていきたいですね。

取材を終えて

「an」と言えば、学生援護会という名前が思い浮かぶ世代です。「職業選択の自由〜♪」というCMも非常に印象的でもあり懐かしい話題です。

株式会社インテリジェンスとの合併もよく覚えているニュースでしたが、社名が変わってから「中の人」にお話を伺うのは今回が初めて。

お邪魔したビルには、多くの社員が働いておられ、かつご訪問される方々もひっきりなしで、冒頭の写真撮影も少し待って撮影をさせていただきました。紙からWebへ、そしてアプリへ。とは、多くのサービスが抱える課題でもあります。どのような未来があるのか、その答えを私たちも一緒に見つけていかなくてはならない、と改めて感じました。

TeamHackersでは、これから数回にわたってスクラム開発事例を個社インタビューを通してご紹介していきます。引き続き、ご購読をよろしくお願いいたします。

タスク管理について、新人が体験してみた学びを共有する～Trello編～

新年度を迎えるにあたり、新人の方は慣れない仕事に追われ、既存の方は新しい仕事が既存の仕事に加わり、忙しい時期を過ごしているのではないかと思います。どれから手をつければいいのか分からず、期限内に仕事を終わらせることができないという人はタスク管理をしてみませんか？　今回は実際にタスク管理ツールの「Trello」を初めて使って一か月たった雑感について書いていきます。タスク管理ツールを利用したことがない人やこれから利用してみたいと思っている人はこの記事を参考にしてみてください。

タスク管理のメリット

まずはタスク管理のメリットについていくつか確認していきましょう。

頭の中の整理になる

まずはタスクを管理するために、そのとき思い浮かぶタスクをすべて書き出してみましょう。簡単なタスクでも構いません。その後、思い浮かんだタスクをカテゴリーごとに分けることで、ごちゃごちゃしたものを頭の中から離して整理することができます。

優先度の順位付け

次にカテゴリーごとに分けられたタスクを、すぐに終わるものなのか、延期するものなのかを判断することで、手をつける順番を考えることができます。期限内に仕事が終わらないことが少なくなり、結果的に効率化につながります。

チームでの進捗度確認

またツールを使ってタスク管理を行なえば、誰がどれぐらい進んでいるのかなどの進捗度の共有が可能です。もし遅れているタスクなどがあれば、管理者がタスクやプロジェクトの修正などフォローすることも可能になります。

このようにタスク管理を行なうことで、自分の頭の中の整理、加えて仕事の効率化にもつながるので、タスク管理は行なった方が良いと断言できます。
またタスクの絞り方にはこちらのGTDを参考にするとさらにいいものになるでしょう。
GTD記事：https://teamhackers.io/getting-things-done

「Trello」とは

かんばん方式でタスクを視覚的に管理することができるツールです。タスクをカードに入力して、ドラック＆ドロップして、作業中や完了などのリストに自由に動かすことが可能です。また一人で使うだけではなく、登録をしていれば共有してタスクを管理することも可能です。加えて、iPhoneやAndroidのアプリとして提供されているので、どこにいても使える便利なツールとなっています。

Trello：https://trello.com/

なぜ「Trello」にしたのか

数あるツールの中からなぜ「Trello」を選んだのか。なぜなら、だれが使っても使いやすいツールだったからです。自分も1か月前はタスク管理ツールどころか、そもそもタスク管理って何？　という状態でした。なので早く慣れたいという思いから、Redmine やslack 、 Backlogといった管理ツールを試してみた結果、タスク管理ツールは「Trello」が初心者に向いていて使いやすいことがわかりました。

また、プロジェクト管理やタイムトラッキングについては併用して「TeamHack」というツールを使っています。「TeamHack」についての情報はこちらを参考にしてください。
TeamHack：https://teamhack.io/

使ってみての雑感

ここからは「Trello」を実際に使ってみた感想についてまとめてみました。良かった点、反省点、改善の方法の組み立てで書いていきます。

良かった点

良かった点としては、1つ目はタスク管理でのメリットでもある仕事の効率化が非常に図れました。毎朝起きてからやらなくてはいけないことをタスク化する時間を設けて、朝ごはんや通勤中に順番付けを行うことで、職場についてからすぐに仕事に取り掛かることが可能になりました。もちろん職場についてからも、ほかのタスクを加えてどれを優先すべきかは確認をしました。

2つ目は自分のための時間を作ることができるようになりました。家に帰ってからダラダラしてしまうところを何をやればいいのか明確化されているので、タスクを処理した後に、趣味の読書やランニングなど自分の時間が増えたことが大きかったです。

反省点

反省点としては、1つ目は習慣化するまでに時間がかかったことです。始めてから1週間までは継続して管理していましたが、1週間～2週間目はタスクを打ち出し忘れたり、そもそもツールを使わないこともありました。なので家事をタスクに追加するなどして毎日使う癖をつけました。

2つ目はタスクを打ち出すこと自体は始めから苦ではありませんでしたが、タスクのスケールが大きすぎるために処理しきれないことが多々ありました。なのでタスクを細分化しなくてはいけませんでした。

タスク管理する際のススメ

前述の反省点を生かして、タスク管理する際には

• 癖をつけるために毎日使う
• タスクを細分化する

この2点を守ることをおススメします。ぜひタスク管理する際にはこの2点を意識してみてください。

映画『イミテーション・ゲーム』に見るチームビルディング成功へのヒント

私たちが当たり前のように使っているパソコンや人口知能内蔵のタブレット、それらの進化が、生活にダイレクトに影響を及ぼす世の中になって久しいですが、そもそも、コンピュータという概念（チューリング・マシン）を生み出した人物をご存知でしょうか？　この記事では、そのコンピュータの父であるイギリス人数学者＝アラン・チューリングの人生を描いた映画『イミテーション・ゲーム/エニグマと天才数学者の秘密』にみる、大きな目標達成へ導くチームビルディングへのヒントをご紹介していきます。

最近、こんなニュースを耳にしました。Amazonのスマートスピーカー「Amazon Echo」シリーズなどに搭載された Alexa（アレクサ）が突然笑い出すという報告が、海外で問題にあがっているというのです。（日本での報告はまだありません）
参考URL： https://headlines.yahoo.co.jp/hl?a=20180308-00000048-it_nlab-sci

Alexa は、話しかけるほどにボキャブラリーが増え、便利に使えるクラウドベースの音声アシスタント。インターネットに接続してあるテレビをつけたり、音楽をかけたりと便利に使うことができます。筆者宅には、Alexaはいませんが、かわりにアップルのiPhoneやiPadにSiriがいます。いつも子供たちはSiriに話しかけ、天気を聞いたり、算数の宿題の答えを聞いたり（!）、AIとのコミュニケーション頻度は確実に増えています。子供たちには素直に良い答えを返してくれるSiriですが、同じように筆者が話しかけても、「それは面白い質問ですね」と煙にまかれたり、うまく答えを引き出せないときもあり、完全にこちらを警戒しているような様子すら感じてしまいます。人工知能への警戒感や抵抗感（？）は、大人の方が強いのでしょうか。

それはともかく、映画『イミテーション・ゲーム』の主人公、ベネディクト・カンバーバッチ演じる数学者アラン・チューリングは、既に１９５０年に人工知能の問題を提起するという先見性と数学的な天才的な才能を持つ人物でした。この映画でのチューリングは、暗号解読のためのチームリーダーとしての姿が描かれています。第二次世界大戦が始まった１９３９年、チューリングたちのチームがナチス・ドイツの暗号機エニグマの解読を成功させ、同時にイギリス連合軍が勝利するための作戦も計算し、終戦を早めたという実話を元にしています。

絶対的な確信を本物にするための行動力

エニグマの暗号を解読するために、人海戦術的に、人の手動により暗号を解こうとするのには限界があると考えたチューリング。現在で言うコンピュータを作って解読をしようと考えます。そして彼は、その考えに絶対的な確信を持っていました。絶対的な確信を持つ彼は、同僚にどう思われるかも考えず、自分の考えを決してまげずストレートな物言いをするため、悪気がなくとも同僚からは見下した態度をとっていると思われてしまいます。

チューリングは、協調性がまったくないまま、暗号解読装置の設計を進めるのですが、同僚の評判もすこぶる悪く、上司が好むような行動も取れないことから、直属の上司から装置開発のための出資を拒否されてしまいます。しかしチューリングはめげずに、彼を飛び越え、時の首相ウィンストン・チャーチルに直訴の手紙を送り、結果、予算を手にすることに成功。しかも自分をチームの責任者にすえることも成し遂げます。

このときのチューリングは、チーム力もなく、コミュニケーションもうまくいっていません。にもかかわらず、最初にクリアすべき問題である予算の入手と、リーダーになるという働きを見せます。それは、彼自身の考え方の勝利というほかありません。もし直属の上司にNOと言われたら、その彼に直訴するというのは一般的な企業では難しく、また勇気も必要な行動ですが、チューリングには、まったく迷いがありませんでした。迷いのなさの理由は、彼が自分の考えに絶対的な確信があったことに他ならず、確信を絶対に感じられるほどに、勉強し、知識と経験があったからこそ、その確信を持てることにもなったのでしょう。

柔軟性を持つ

リーダーになったとたん、チューリングはこれまでいた２名を即クビにし、新しい人材を探します。その探し方とは、新聞に難解なクロスワードパズルを載せて、解けた人にテストをさせるという斬新なものでした。結果、沢山の人材のなかから、効率よく２名の才能ある人材を採用することとなります。うち一人の女性は、キーラ・ナイトレイ演じるジョーンでした。その頃、男性と同じ職場で働くことは一般的でない時代で、女性の知性もあまり尊重されない時代でもありました。そんななか、チューリングは、ジョーンの勤務に反対する家族を納得させ、彼女を解読任務に仲間入りさせることに成功します。

ここでは、チューリングの柔軟性を見てとることができます。当時のイギリスは21歳以上のすべての女性に選挙権が与えられるようになってから11年経っていましたが、まだまだ男性と女性の仕事は完全に分かれており、女性が解読のプロジェクトに入ることも極めて異例なことでした。しかしチューリングは、女性だからと差別することもせず、ジョーンの能力や才能を評価し、彼女を仲間に入れるのです。その姿は、現在の時代の女性からみても、彼女の存在を誇らしく思える場面です。

未だに、日本の国技のスポーツは、土俵に女性を入れることに非常に抵抗があるようです。女性だからNG、男性だからOKといった考え方が未だにある風潮のなか、第二次世界大戦中という時代に、女性の仕事への理解と、女性を採用する柔軟性を持った人物がいたことに非常に感銘をうけます。ここに、チューニングのリーダーとしての人の能力を見る目と、能力を生かすためにぶれない姿勢を感じることができます。

チームメンバーを味方にする方法

チューリングが手がける解読のためのコンピュータや、解読に興味を持ったジョーン。チューリングと同僚の関係が悪いことをすかさず見抜きます。彼女は、プロジェクトを成功させるために、チューリングとチームの仲間との関係を良くしようとし、チューリングにアドバイスや行動をとらせます。結果、彼らのチームはエニグマ解読のため結束を強めることに成功します。そして、チームで協力しあい、ついに解読のためのコンピュータが完成しますが、多大なコストにもかかわらず結果を出していないようにみえるチームにいらだつ上司はチューリングをクビにしようとします。しかし、いつしかチームの結束を深めていた同僚は、総辞職をちらつかせ、クビを阻止してくれるのです。

ジョーンがチームに入るまで、関係の悪かったチームの仲間たち。ジョーンは数少ない女性のため、嫌われないための処世術を熟知していました。コミュニケーション能力の長けた彼女を味方にできたことでチューニングのチームは一変します。チューニング自身はコミュニケーションをうまくできなくとも、かわりにジェーンの機転で「チームとうまくやっていきたい」という気持ちをチームの仲間に伝えることができたことから、チームの仲間と心が通じあい、協力体制を作ることも可能にしたのです。このシーンでは、うまくコミュニケーションができなくとも、心が伝わればチームをまとめることができるという奇跡を見ることができます。

期限を決めることの重要さ

上司から、最後のチャンスとして結果を出すまで1ヶ月という期限を出されたチューリングたちは、チームメンバーと食事や酒を飲みながら話をしているうち、たまたま耳にした女性職員の会話から、エニグマ解読のための鍵に気づきます。これまで結果を出せなかった解読コンピュータ装置が、ついに暗号の解読に成功することになります。

期限が一ヶ月と追い込まれるチューリングたち。たまたま聞いた話からヒントを得て、全世界的に不可能とされてきたエニグマの解読に成功します。期限が決まってしまったとき、私たちは、期限までに目標を達成できないのではないかという絶望的に不安な気持ちに頭を抱えてしまいがちですが、何でも時間がいくらでもあるときよりも、期限があるほうが瞬発力や集中力があがり、成し遂げられることが増える傾向にあります。これは期限だけに言えることではなく、少しのルールや制約があるほうが、大きな結果を得られると言われるビジネスモデルとも一致します。自由過ぎると、かえってすべきことが見えなくなることがありえます。限られた時間のなかで、集中し、仕事の成果を手にする醍醐味を味わえるシーンです。

なお、この暗号解読に成功したものの、チームはその後大きな「犠牲」を払う決断を強いられるのですが、その悲しい決断に至る経緯はぜひ映画を確認ください。
（つまり、暗号解読までを追いかける映画ではなかったんですね）

烏合の衆をまとめ上げるリーダーシップ （１）　連載第６回

前回、技術者のいない発注主企業(プロジェクトオーナー)から複数の下請企業が並列に1つのプロジェクトを受注した場合のハンドリングについて考察してみましたが、今回は同じような商流で、いわゆる「フリーランスの集合体」の場合について考察してみたいと思います。

フリーランスや複数社のメンバーをまとめるリーダーに求められる資質は何か？

複数企業の座組の仕方があまり上手でないプロジェクトは、各社の担当営業の仕切りが悪かったり、あるいは社間の力関係があったりするなど、エンジニアの手を離れたいわゆる「政治」のレイヤーで始まることが多い印象ですが、技術者のいない発注主が複数のフリーランスを集めて始めるプロジェクトは、単に「そこまで考えていない」ケースが多いように見受けられます。
例えばクラウドソーシングなどで発注主がプログラマーとデザイナーを1名ずつ集めて始めたプロジェクトのように、単に機能単位で役割分担しているだけであれば、いわゆる全体を統括するリーダーは、メンバー間のコミュニケーションが普通にできている限り、それほど必要とされないかも知れません。

しかし、もう少し人数が膨れ上がったりした場合には、やはりリーダーシップを発揮できるメンバーが1人はいないと、プロジェクトの捗りかたが違ってきます。このような座組のしかたで始まったプロジェクトで求められるリーダーシップは、前回のような「最初に強引にイニシアティブを握ってしまう」タイプではなく、「温厚な調整型」「飲み会の幹事型」のような振る舞いができる人に資質があるでしょう(もちろん強力なリーダーが請われるケースもありますが、本稿では例外とします)。

フリーランスの集合体で求められるリーダーシップとは

先ほど申し上げましたように、フリーランスの集合体でのリーダーシップは、なぜ「温厚な調整型」「飲み会の幹事型」がよいのかについて、少し説明しますと、様々な理由で集まったフリーランスは、そもそも各メンバー間に雇用関係や上下関係がないフラットな関係が前提です。また、こうした関係性での働き方を求めていない傾向にありますので、強引にリーダーシップを振りかざそうとすると、うまくいくプロジェクトも人間関係で困難化してしまいかねません。

ですので、烏合の衆であるフリーランスたちが集まったプロジェクトにおいて、いわゆるリーダーシップというよりは「コードを書く以外の面倒ごとを積極的に巻き取る役割」といったロールが求められるでしょう。つまり、各メンバー間の潤滑油的な存在で「温厚な調整型」「飲み会の幹事型」のリーダーが1人いれば、各メンバーの意思が同じ方向を向くようになり、スムーズにプロジェクトが進行するでしょう。

どうやってフリーランスの集合体でリーダーを決めるのか

いわゆる「温厚な調整型」「飲み会の幹事型」なリーダーがいて、その存在を誰もが認知していればよいのですが、「せーの」で集まった烏合の衆では、なかなかそうもいかないでしょう。
我こそは是非立候補したい、という方がいらっしゃれば是非やってみてください、という結論で本節はおしまいになってしまうのですが、なかなかリーダーが決まらない場合は、それとなくプロジェクトオーナーにリーダーを決めて欲しいという要望を出すとよいでしょう。

しかし、プロジェクトオーナーもあまりメンバーの素性をよく理解していない場合、いきなり「我々の中からリーダーを指名してくれ」と言われたところで困るでしょうから、「プロジェクトの意思決定において、メンバーの意見を集約して技術的な観点からまとめる役割を誰かにお願いしたほうがいいですよ」「チャットやBTSツールなどで司会的な役割を担う人を早めに決めておくとプロジェクトの進行がスムーズですよ」といった、柔らかい表現で促すことをおすすめします。

リーダーはメンバーたちとプロジェクトオーナーをどう取り持つか

烏合の衆であるメンバーたちがある程度まとまったところで、プロジェクトオーナーとの調整はどうするのか、という課題はまだ解決していません。プロジェクトオーナーと各メンバー間のコミュニケーション方法、コミュニケーションの仕組みについては前回同様フラットであるべきなのですが、プロジェクト内でのコミュニケーションについてはもう少し踏み込んでルールを作ったほうがよいでしょう。いくつか例を挙げますと、
• 機能別または非機能要件などの担当をゆるく決めておく
• 誰にお願いすればよいかわからないことは、バイネームではなくプロジェクト全体に呼びかけ、全員で考える
•　　タスクの分配についてはオープンな場で議論し、その過程はなるべく可視化されるようにする
•　　ただし、追加工数の金額についてなど、センシティブな話題は個別連絡の例外を認める

このようなルールを最初に作っておくと、各メンバー間がフラットであり、プロジェクトオーナーとの折衝もやりやすくなります。こうしたルールでオープンなコミュニケーションをとる場においては、強力なリーダーシップというよりはモデレーター、ファシリテーター的な振る舞いをしたほうがよく、大きなストレスがかからずにメンバーたちとプロジェクトオーナーの間を取り持つことも可能になるでしょう。次に、ファシリテーターに求められるスキルについて知識化してみたいと思います。

ファシリテーションスキルとは

各メンバーやプロジェクトオーナー間を取り持つリーダーに求められるのは、いわゆる強力なリーダーシップというよりも、モデレーター、ファシリテーター的なスキルであるのですが、こうしたスキルを「ファシリテーションスキル」と呼びます。

ファシリテーションスキルと聞くと、単に「司会者的な役割をすればよいのでは」と思う方もいらっしゃるかも知れません。しかし、確かに司会者的な役割「も」担いますが、最初にこう思った方はもしかしたら「主観的な意見をもたない傍観者的な存在」とみなしているのかも知れません。
そうではなく、ファシリテーションとは何か、を日本ファシリテーション協会のサイトから引用しますと、

ファシリテーション（facilitation）とは、人々の活動が容易にできるよう支援し、うまくことが運ぶよう舵取りすること。集団による問題解決、アイデア創造、教育、学習等、あらゆる知識創造活動を支援し促進していく働きを意味します。その役割を担う人がファシリテーター（facilitatior）であり、会議で言えば進行役にあたります。

とあります。
そして、ファシリテーションの4つのスキルというものも定義されており、
•　場のデザインのスキル ～ 場をつくり、つなげる ～
•　対人関係のスキル ～ 受け止め、引き出す ～
•　構造化のスキル ～ かみあわせ、整理する ～
•　合意形成のスキル ～ まとめて、分かち合う ～
としています。

こうして目次だけ見ても、非常に前向きで合理的な考えのもとに編み出されたスキルセットであるとイメージできるかと思いますが、同サイトにはこれらのスキルセットやマインドについて詳しく書かれていますので、是非訪問して熟読されることをおすすめします。

ファシリテーションスキルをフリーランスのプロジェクトにどう発展させられるか (社会性と広がり)

ファシリテーションスキルをフリーランスのプロジェクトへどう持ち込み発展させるか、について、私はこう考えます。
•　その場(プロジェクト)にいる全員が向かう「あるべき方向性」を示すか、または場の流れを前向きにする
•　特定の意見や発言者に偏らず、プロジェクトメンバーが意見を出しやすくする
•　議論の発散だけでなく、収束も促す
•　メンバーの多様性は重視しつつもプロジェクトのゴール(目的)はブレない
このたった4つを守るだけでも、メンバーは前向きにプロジェクトへ参画することができ、即席の烏合の衆がいつの間にか力強いチームとして機能することすら夢ではなくなるでしょう。

新人を失望させないコミュニケーション術とは?

４月の新年度が始まっています。学校では新入学生の初々しい姿が見られるこの季節、ビジネスの現場においても、新入社員や、人事異動、転職などで新しい人がチームや職場に入ってくる季節です。加わる側は、新しい環境に希望や不安で胸を一杯にしながら、会社に通ってくることでしょう。そして、受け入れる側も、不安と緊張が入り交じり、いつもとは違う神妙な気持ちを感じる人もいるのではないでしょうか。
この記事では、新人を受け入れる側が頭に入れておきたいコミュニケーションにおけるポイントについて紹介していきます。

新人の無防備さにつけいらない

いつの時代でも、どんな場所でも、ジェネレーションギャップへの戸惑いや悩みは存在してきました。普段筆者は、小学生や幼稚園の子供のママ友達と接する機会が多いですが、共通の話題がある子供の話をしていたときには感じないジェネレーションギャップも、ふと子供のこと以外に話題が広がったとたん、育った時代や価値観の違いに驚きや新鮮さ、戸惑いを感じることがあります。もちろん、職場においても、そのような状況はつきものであることでしょう。特に、職場における古い世代と新しい世代との軋轢の壁を崩すのは難しいものがあります。人は皆等しく歳をとっていく存在である限り、それは仕方がないことなのかもしれません。

私は2000年前後、就職活動を超氷河期に行いましたが、なんとか新卒で商社に拾ってもらい、新入社員となりました。その企業で新人歓迎会があったのですが、その時に、部長に言われた、「おい、水割り持ってこい！」というセリフを未だに覚えています。今であれば、女性新入社員に水割りを作るよう命じればセクハラと言われたり、自分の仕事ではないと断わる人もいるでしょうが、2000年頃の大手企業は、女性社員は、結婚までの腰掛けとみなされ、男性の補佐的なポジションを担うことが一般的でした。私に水割りを作るよう命じた人物も、これまで、女性新入社員に水割りを作らせたり、酒をつがせることが常識だったのでしょうから、彼はその発言について何の疑問も持っていなかったことでしょう。

当時の私は無知なひよっこで、会社はそんなものなのかな？と作ったこともない水割りを頑張って作った記憶があります。そのとき感じた違和感を今であれば理由をつけて説明できるのですが。どんな新入社員であっても、職場においては知識がなく、まっさらな状態です。そこにかこつけて、自分だけの常識や価値を押しつけたり、ひけらかすことはやめましょう。新人は、経験不足な代わりに、フレッシュな視点を持っています。それを、職場の通例と違うと切り捨てることなく、職場の活性化のために役立てられるような関係性を構築していきましょう。

相手を尊重する

株式会社リクルートキャリアの、就職・採用の在り方を追究する研究機関である就職みらい研究所は、調査モニターの大学生を対象に「就職プロセス調査」を実施した「就職内定状況」について、12月1日時点での大学生の就職内定率が94.8％であったとまとめています。

参考URL https://www.recruitcareer.co.jp/news/pressrelease/2017/171222-01/

この数字からも見てとれるように、2018年入社の新入社員たちは、売り手市場のなか入社してきたとも言えます。そのため、彼らは、入社を決めるとき働きやすさや、やりがいを感じられるか、などといったメリットが多い会社を好んで選んでいる傾向があると考えられます。売り手市場であったという側面から、新入社員が会社にどのような姿を求め、考えているのかを理解しようと努めることも必要です。そんな彼らとコミュニケーションをとっていくためには、どのような心がけが必要なのでしょうか。

これからも加速していく少子高齢化のなか、生産性向上への取り組みがますます重要になっていきます。生産性向上のために、新しい考え方を受け売れる柔軟性があることが大いに役に立つスキルとなります。新人は、その職場での経験はまだ少ないですが、これまでの職場にはなかった考え方や取り組みをもたらしてくれる可能性もあります。新人よりも先に働いていた経験者で先輩だからといって新人を下に見たりむりやし従わせたりするのではなく、お互いに一人の人間として尊重しましょう。

不要な先入観を受け付けない

おせっかいにも、上司のうわさ話や会社内のゴシップなど、業務にプラスして話してしまうときはありませんか？例えば「あの営業マンは、月末には売上が心配になって、カリカリしているから近寄るな」とか、「あの人はパソコンの知識が薄いから」とか、自分の感じたことやまた聞きしたうわさ話などを、そのまま伝えてしまうことの危険性を考えてみましょう。どんなうわさ話も、新人にとっては、会社のことを知る大事な知識としてしっかりインプットされることになるでしょう。

しかし、それによって間違った先入観が植え付けられてしまったら、これから産まれるはずだった様々な可能性を消してしまう恐れすらあることも理解してください。「あの人にこの仕事のことを教えてもらおうかと思ったけど、先輩がこう言っていたからやめておこう」というような思考を作ってしまうかも知れません。たまたま、あなたが感じたことを、新人が同じように感じるとは限らないのです。新人の将来性や、可能性を減らさないミュニケーションを取れるように、努めてみてください。

変化を恐れない

新しい職場に入った時に新人が感じた素朴な疑問や問題点に、変化へのヒントを見いだせることがあります。例えば、「狭いオフィスの入り口に、なぜ沢山の段ボールが積まれているのだろう？」「なぜこのパソコンはこんなに立ち上がりが遅いんだ？」など、これまでその職場での常識として、なあなあにされていたり、気づかないフリをされてきた問題点に、業務の改善化への鍵を見つけられるかもしれません。新人の素朴な疑問をきちんと声に出せるような雰囲気やシチュエーションを作る機会を持ちましょう。そのとき、新人の周囲の人たちが忘れてはならないことは、「変化を恐れない」ということです。これまで培った経験から、変化を拒む気持ちがあると、前に進んでいくことはできないのです。

これからの企業は、世の中に大きな変化が巻き起こっていくなか、それに順応していく能力を持つことが多いに重要になってきています。時代に取り残されず、成功に近づいていくための練習としても、まずは新人の話をきちんと聞きましょう。そして、新人が起こす変化のお手伝いをしてみましょう。そのことが、新人の成功体験構築にもつながりますし、結果が会社や業務の生産性向上にプラスにもなれば、あなたが行ったサポートである柔軟性への評価も高くなることでしょう。

働きやすさだけを売りにせず、やりがいを見せる

働きやすい職場というのは大変魅力的です。ブラック企業が問題化するなか、企業も、働き手から選ばれ、将来生き残る企業を目指して様々な努力を重ねています。そんななか、入社してきた新人たちが皆、会社の働きやすさだけに魅力を感じていると捉え、そこだけにフォーカスしたコミュニケーションを周囲がとってしまうとしたら少々問題です。人は働きやすさだけで会社を選ぶわけではありません。働くためのモチベーションや意義を見いだし、やりがいを手に入れたいと、働く人たちは皆願っているのです。

職場でも、新人と一緒に働きやすさだけを追求していくのではなく、やりがいを見つけられるようなコミュニケーションが出来たらハッピーです。そのためには、まずあなたが、仕事のやりがいや楽しさ、醍醐味を見せて、共有していくことが必要です。昔ながらの体育会系的先輩後輩のような、従属的な関係性ではない、新しいスタイルのコミュニケーションを探して、すばらしいチーム力を育てていきましょう。そして、新人を一人前の人材にいち早く育てることができれば、即戦力を早くに育てたことにもなり、会社全体の生産性にもポジティブな影響を与えることができます。

企業文化や風土を見直すことで、よりよいチームを築きプロジェクトを成功に導く

事例紹介　ある大企業でのハードウェアリプレースプロジェクト

全国に支店のある大企業で、現在利用中のOS(Windows7)のサポート終了時期が迫っていることにともない、次期OS（Windows10）への一斉切り替えが決定されました。
そして、OSを切り替えるために最新のハードウェアにリプレースされることが確定しました。およそ2000台規模の機器リプレースプロジェクトが立ち上がったのです。

経過、あるいは原因　ヒエラルキー型の組織で、突然リーダー不在の状況になったら

日本企業の一般的な組織構成はヒエラルキー型と呼ばれる縦型の構成です。この形の組織は機能ごとに組織が作られ、縦割りで作られています。ヒエラルキー型組織のメリットは、機能・責任・指揮命令系統がわかりやすいという点です。そのため、日本の企業では大企業を中心に多くの企業がこのシステムを採用しています。プロジェクトに関してもヒエラルキー型の組織構成が多く、リーダーが筆頭となってプロジェクトをまとめ、メンバーがその手足となって振り分けられた業務を遂行するのが一般的です。

今回取り上げるリプレースプロジェクトも、ヒエラルキー型の組織体制で円滑に進んでいました。ところが、プロジェクトリーダーが事故を起こして入院することになりました。
つまり、退院までの数週間、リーダー不在の状態になってしまったのです。すべての作業をリーダーが統括し指揮命令をおこなっていたため、メンバーは動揺し、現場は混乱しました。

知識化する　ミドル・リーダーを活躍させる

ミドル・リーダーの奮闘

プロジェクトリーダー不在の状態に陥り、メンバーはこのプロジェクトをどう進めればよいのかわからず、上司（管理職）に相談しました。すると、上司はこの状況を解決するために後任（代理）のリーダーを立てず、あえてプロジェクトメンバーに任せることにしたのです。今まではリーダーが率いていたプロジェクトを、現場のミドル・リーダー（それぞれの機能をまとめあげるリーダー）に任せました。

ミドル・リーダーたちは普段、決められた役割の中で動いているため、当初は戸惑いました。しかし、プロジェクトを進めるために、今までプロジェクトリーダーに相談していたことをミドル・リーダー同士で相談し合うようになりました。それをきっかけとして、徐々に横の連携を図るようになっていったのです。

その結果、ミドル・リーダー同士のコミュニケーションが活発になりました。今まではプロジェクトリーダーを経由することによって横の連携をとっていましたが、定期的にミドル・リーダー同志が集まり、積極的に周りに情報を発信し、連携を図るようになったのです。
さらに、トラブルや問題をチーム内で解決しようとせず所属部署の上司や同僚に相談するようになったことも、横との連携を強めることができた要因の一つとなりました。

ヒエラルキー型組織からからマトリックス型組織へ

さらに、ミドル・リーダーたちは今の体制のままではプロジェクトが円滑に進まないことに気づき、組織体制を見直しました。新組織のポイントは、統率力のあるリーダーがいないかわりに、横のつながりを強化した点です。

プロジェクトチームの枠を超え、所属部署の上司たちをも巻き込み、それまでのヒエラルキー型組織とは対象的な「マトリックス型組織」へと変わりました。マトリックス型組織のメリットは、状況に応じてプロジェクトメンバーを柔軟にアサインし、稼働させることができる点です。今回のように、急きょリーダーが不在になり、トラブルや問題が発生するプロジェクトには向いている場合もあります。トライしてみる価値はありそうです。

社会性と広がり　「先を読む力」でチームを変える

チームの文化や風土の改革、先を読む力

プロジェクトをまとめていたリーダーが不在になるという状況になった場合、通常であればリーダーの代理を立てるでしょう。しかし、プロジェクトマネージャーである上司は、あえてプロジェクトリーダーの代理を立てず、ミドル・リーダーたちに任せました。つまり、「この課題をプロジェクト内で解決せよ」とメンバーに問いかけたのです。

プロジェクトに限った話ではありませんが、業務を進めるにあたって、今までと同じ体制・同じ手順で物事を進めようとすることはよくある話です。それは過去に成功体験があり、道筋があることでコストや時間が削減できるほか、メンバーの精神的なハードルが下がった状態で業務に取り掛かることができます。しかし、毎回適用できるとは限りません。今までの文化や風土を見直さなければいけない場面に遭遇することもあります。
リーダーだけではなく、プロジェクトに携わるメンバーには以下のような柔軟な考え方が求められます。

・想定外のことが起きた際、広い視点で進む方向を見極める力
・環境の変化に流されず、変化を取り込んで動ける力
・担っている役割の成果を最大限にするため、組織に変化を生み出せる力
・職責を果たすプロセスのなかで自分の能力・価値観を見直し、柔軟に変化し続ける力

チームの現状について考える

今回はリーダーが急きょ不在になるというトラブルがきっかけだったので、不安材料が明確でした。そのため、プロジェクトメンバーに「企業風土（文化）を変えよう」というモチベーションが高い状況にありました。

しかし、「なぜかよくわからないけど、プロジェクトがうまく回らない」ということもあります。この場合「うまく回っていないけど、メンバーが残業すればなんとかなる」と考えていてはいけません。うまく回っていない組織や仕組みは、基本的な部分がぶれていることが多いのです。何のためにこのプロジェクトが立ち上がったのか、クライアントから何を求められているのか、プロジェクトのゴールはどこにあるのか等のビジョンを明確にしましょう。

リーダー不在のプロジェクトをコントロールするために　連載第５回

「リーダー不在のプロジェクトが動き出してしまった…」
今回は、筆者が実際に経験した事例(とは言えNDAがあるのでフィクション仕立てにしています)から、リーダー不在のプロジェクトでどう舵取りをすればよいのかについて述べてみたいと思います。
最初に結論を書いてしまいますと、「結局のところ誰かがリーダーシップを発揮しないといけない」という現実解に行き着くのですが、プロジェクトの予算や座組のしかたによっては、リーダー不在のままプロジェクトがスタートしてしまう、といったケースも残念ながら存在します。
必ずしも下記図1のような座組がいけない、というわけではありませんが、このような座組でトラブルが長期化する(した)ケースというのは、おそらく経験がある方もいらっしゃるのではないでしょうか。

（図1 プロジェクトオーナーが技術者ではなく、プロジェクトオーナーとエンジニアの間にリーダーが不在なケース）

リーダー不在でおきたトラブル – 責任分界点上の障害発生 –

前章/図1のように、プロジェクトオーナーとエンジニアとの間にリーダーがいないプロジェクトの場合、下請各社の責任分界点に近い箇所で障害がおきたりすると、誰が初動の調査を行ない、障害被疑部位の切り分けを行ない対応するのか・・・が曖昧なために初動が遅れたり、「まずはネットワーク・サーバーエンジニアが初動対応をするのだろう」と暗黙のうちに決めてかかられたりしてA社の業務負荷のみが増えるといったことが起きたりします。

A社もB社も契約はプロジェクトオーナーと結んでいるため、本来ですとプロジェクトオーナー側に受入試験を行なうスキルのあるエンジニアがいて、PLおよびPM業務を行なうべきなのですが、プロジェクトオーナー側にこうしたエンジニアがいないと、障害発生時の対応負荷に偏りが発生し、「弊社で調査しましたが、弊社担当箇所に問題はなく、他社構築担当箇所が障害被疑部位と思われます」といったたらい回しが発生するリスクが高まります。

こうした体制ですと、A社とB社との間で協力して問題解決を行なうよりも「うちのせいじゃない」という責任回避に終始することにもなりかねず、技術的な、本質的な解決からは遠のくばかりで、これではプロジェクトオーナーも含め全員が不幸なままです。仮に、こうした体制において個人のエンジニアがどう頑張っても、自己犠牲の上に成り立つ解決しかできないので、いわゆる「スーパーエンジニアによる解決」が行われたとしても、彼がプロジェクトを離脱してしまうと同じ品質での解決は困難です。こうした属人的な解決が仮にできたとしても、それは組織としては不健全なままなので、プロジェクトオーナー側に技術のわかるPMやPLを立てるしかありません。

また、PMやPLを立てたから即ち解決、というわけにはいかず、運用設計や責任分界点も含めた契約の見直しすら必要になることもあります。

リーダー不在のプロジェクトをどう着地させるのか？ – 短期プロジェクトでメンバーができること –

1つのサービスやシステムを複数社で長年運用するようなケースですと、根本的にプロジェクトの体制や契約から見直すしかない、という結論でしたが、短期間のプロジェクトの場合はそうもいきません。少々乱暴な言い方になってしまいますが、「四の五の言わずさっさと手を動かしてプロジェクトを終わらせる」しか解決方法はなく、誰かが率先して社間のハンドリングも含めて実行するしかありません。

次に私が経験したケースですが、こちらも発注元企業の下に下請が複数社あり、下請各社はそれぞれ発注元企業との直接契約でしたので、下請各社間において商流の上下はありません。こうした体制であることをプロジェクト発足後に自社の営業から聞かされて作業に着手したのですが、どうやって案件の進行をハンドリングしてプロジェクトを完遂させたのかを振り返ってみたいと思います。

まずはキックオフミーティングを実施する

新たにプロダクトを作るなど、前向きに始まったプロジェクトではキックオフミーティングで士気を上げるといった話はよく聞きます。しかし、下請各社のうち、プロジェクトに積極的に関与する会社と運用フェーズであまり手を動かしたくない会社があるだろう、つまり社間でプロジェクト関与度や関心に温度差があるだろうという予想をしていたので、社間のコミュニケーションで如何にロスを減らすか、という目的をもってキックオフミーティング開催を各社にはたらきかけました。

もちろんこうした目的もあるのですが、リーダー不在のプロジェクトなど成功するわけがないという予想をしていたので、キックオフミーティングの場でイニシアティブを握り、プロジェクト推進をやりやすくしたいという狙いが本音でした。

仮にプロジェクトが進みだし(暗雲が立ち込めて)からこうした動きをしようにも、各社の足並みが揃う可能性は低く、プロジェクトのイニシアティブを握るチャンスはキックオフミーティングが最初で最後、かつ最大であると考えます。

各社にキックオフミーティングを持ちかける際に、1つだけ気をつけていただきたいのですが、こちらがあまり張り切った雰囲気で「キックオフミーティングしましょう！」という誘い方をしてしまうと、あまり熱意のない会社から敬遠されてしまいます。ファーストコンタクトの時点では相手の温度感はなかなかわからないと思いますので、硬軟使い分けて「まずは顔合わせしたいと思います」といったニュアンスでキックオフミーティングに参加してもらうのがよいでしょう。

キックオフミーティングは観察の場にしよう

キックオフミーティングでは、だいたい各社ともキーパーソンが集まるのが通例ですが、いわゆる「職位が上なのでキーパーソンとされている人」と「手を動かしたり上司のサポートをしたりしているために技術または業務に精通している“事実上の”キーパーソン」のうち、どちらのタイプが出席しているのかを見極めます。

また、こうしたプロジェクトでは、エンドユーザーの担当者が複数の下請企業の担当者に何度も同じ話をするのを嫌う傾向があります。なので、キックオフミーティングの場では、誰がエンドユーザーの担当者と一番長いつきあいをしているか、または一番信頼されている下請企業の担当者なのか、という見極めをし、その人を通じて顧客との調整をしてもらうという役割分担をお願いするのも1つの作戦です。

キックオフミーティングでこうした見極めができれば、
•無駄のないレポートラインの確立
•社間の利害調整の優先順位づけ
の道筋が見えてきます。

そして、キックオフミーティングの場では必ずプロジェクト進行中のコミュニケーション方法について調整しておきましょう。

プロジェクト進行中のコミュニケーションについて

複数社で進行するプロジェクトにおけるコミュニケーションでもっとも忌避すべきなのは、社間の情報連携漏れです。過去にはメーリングリストや手オペによる同報メールが主流でしたが、今はだいたい以下のコミュニケーションツールを使い分けています。

•Slack や ChatWork などのチャットツール
•Backlog や Redmine などのプロジェクト管理ソフト
•Google Drive や OneDrive for Business などでファイル共有

これらツールの基本的な使い方については割愛しますが、以下の運用ルールでコミュニケーションを図っていました。

•コミュニケーションツールは基本的にクラウドですぐに利用可能なものを選定し、構築コストをかけない。
•ツールの管理権限は選定した企業がもち、他社のアクセス権は基本的に平等な扱いとし、個別チャットは原則禁止する。ただし、一部センシティブなファイルのやり取りのみ例外とすることもある。
•ファイル共有にメールは使用せず、チャットツールにファイルのリンクを貼り付ける。

これらのルールは同報性と情報の公平性を保つ目的で考えて導入しました。これは、別の言い方をすると「コミュニケーションロスやコミュニケーションミスとそれをリカバリする工数を削減する」という目的でもあります。電子メールによるコミュニケーションを極力なくすことで、

•都度宛先やCC、BCCを設定したメール送信がなくなるため、誤送信リスクを無くすことができる
•電子メールの往復で何重にもついた引用文よりもチャットツールやBTSのほうが対応履歴などのテキスト検索がしやすい上に可読性も高い
•情報アクセスの権限はコミュニケーションツールへの招待時に決定し設定するので、都度のやりとりにおけるセキュリティリスクを減らすことができる

という効果がもたらされ、プロジェクトの進行が大きく前進しました。

こうしたツールの特性を理解し、キックオフミーティングで「こういうコミュニケーション方法でプロジェクトを進行しましょう」と提案することで、プロジェクト推進のイニシアティブを握ることすら可能になります。ただし、ツールの使用を強制することが目的になると、本末転倒です。

リーダー不在のプロジェクトでイニシアティブを握るメリットと学び

「他のメンバーより多く給料を貰っていないのに」「他社の面倒なんて見たくない」というネガティブな理由で、複数社間に跨るプロジェクトのリーダーシップを取りたくない、という方がいらっしゃるのは100も承知です。しかし、リーダー不在のプロジェクトで消耗するくらいなら、「早く終わらせる」というモチベーションでも構いませんので、リーダー不在のプロジェクトにアサインされたら、リーダーシップを買って出てみましょう。すると、以下のようなメリットがあります。

•洞察力が鍛えられる
•リーダーシップが鍛えられる
•人脈が外に広がる

プロジェクトそのものの成否にかかわらず、プロジェクトでのリーダーシップを買って出ることで、単なる「作業者」ではなく、ビジネスの要求をどうやって実装へ落とし込むか、プロジェクトの進行のために次に必要なタスクは何なのか、社間でどう協力していけばよいのか、という普段なかなか得ることのできない学びが得られるほか、自らの考えとハンドリング技術でプロジェクトが成功裏に終わると、これは自分の成果として誇ってよいと考えます。

プロジェクトマネジメントのアプリケーションを再評価する【2018年度新版】

みなさんはプロジェクトの管理をどのようにしていますか？　プロジェクトをうまく進めるためにもプロジェクト管理は欠かせないものになっています。しかしプロジェクト管理するツールを使って管理しようと思っても、ツールの数がたくさんあってなかなか選ぶことができない経験をしたことはありませんか？　今回は新年度を迎えるにあたって、プロジェクト管理ツールについて再評価を行なっていきました。

どんなツールが使いやすいと思いますか？

プロジェクト管理ツールを紹介していく前に、万人に使いやすいツールとは何かを簡単にまとめてみました。

進捗度が簡単に確認できる

やはりプロジェクト管理ということで、進捗度が簡単に分からなければ、管理する人も困ってしまう。ガントチャートのように見える化を図ることができるものがあるといいですね。

多機能であるか

複数のツールを使って、管理をするのは非常に手間がかかります。1つのツールにタイムトラッキング機能やチャット機能などが1つまとまっていれば、一括で管理できて効率的です。

プロジェクト管理に便利なツール

実際に多くの企業で使われ高評価を得ている使いやすいツール、またその特徴を紹介します。

Team hack（チームハック）

Teamhackではタスクやドキュメントごとにチャット機能がついており、メンバー一人ひとりやチームでの進捗度をグラフで簡単に見ることができます。プロジェクトを管理しながらコミュニケーションの活性化にぴったりなツールです。また無料でのお試し版を体験することができ、容量10GBのビジネスプランでは、1ユーザーあたり、月額1200円、年間契約割引で月額1000円です。

≪特徴≫

≪注目ポイント≫
コミュニケーションの活性化も図れる上、どれくらいタスクやプロジェクトが進んでるのかお互いに見れることでモチベーションにもつながり、メンバーの仕事の実績を詳細に分析できる機能もついているのでチームで使うツールにぴったりです。

株式会社カタリストシステムhttps://teamhack.io/

Wrike（ライク）

「Wrike」は機能がとても豊富で使いやすいツールです。指標の管理にはボード・タイムライン・リストといったようにさまざまな形式で表示が可能です。加えて、Excelやiosとの連結も可能な優れものです。また容量50GBのBusinessプランでは一ユーザー当たり$24.80となっています。
≪特徴≫

≪注目ポイント≫
多機能であるのにかかわらず、だれでも使いこなせます。特に不足している点はありませんが、ほかのツールと比べると値段が少し高いかなという印象を受けました。
Wrike　https://www.wrike.com/ja/

JIRA（ジラ）

アジャイルチームに選ばれたナンバー1 のソフトウェア開発ツールと謳っているように、「JIRA」はチーム内で情報共有を図り、円滑に進めたい人に向いています。10ユーザーまでだったら一月$10です。11ユーザー以降は一人当たり$7となっていて、101ユーザー以降は割引が付きます。
≪特徴≫

≪注目ポイント≫
プロジェクトの全体像を即座に判断でき、少人数での管理にはお金もそこまでぴったりと言えます。しかし大人数になるとコストがかかってしまいます。
Atlassian　https://ja.atlassian.com/software/jira

Asana

かんばんとカレンダーを入れ替えながら使うことができるのが特徴な「Asana」は、デザイン自体もシンプルで見やすいため、多様な人に好まれて使われています。Premiumプランでは一人当たり$9.99となっています。またチームで利用すると割引が付きます。
≪特徴≫

≪注目ポイント≫
デザインもシンプルでタスクなども簡単に追加が可能です。1つ不満な点を上げるとするならば、日本語には対応していないため英語が苦手な人にはおススメできません。
Asana　https://asana.com/?noredirect

Teamgantt

ガントチャート機能に特化し、進捗度が一目瞭然な「Teamgantt」。小さいタスクではなく、全体を一気に把握したい人にはおススメ！標準チームコースでは5名まで利用が可能で一月あたり$39.50で、人数が多くなるごとに割引になります。
≪特徴≫

≪注目ポイント≫
ドラッグ＆ドロップでガントチャートを作成したり、直したりできるのはとても画期的です。AmazonやNikeといった大手の企業も利用しています。
teamgantt　https://www.teamgantt.com/

これからのツールに期待すること

TeamHackersでは、さまざまなシステム開発企業やWeb制作会社を訪ね、主にアジャイルやスクラム開発などチーム体制の開発スタイルについてのインタビューを行なっていますが、どの会社も複数のツールを組み合わせて自分たちにとっての最適化を図っていることがわかります。したがって、タスク管理やプロジェクト管理など1つのツールでまとまったものが理想形であるとも言えます。万人が使いやすいようにシンプルなのが求められます。
インタビュー記事：　https://teamhackers.io/interview-summary01