2018 2月

プロジェクトに不可欠なふたつの図とは？　体制図・WBSの作り方とその意義

プロジェクトの成功のために必要な2つのアイテムとは

プロジェクトを成功させるために必要なことはたくさんありますが、その中でもそれぞれの役割、関係者との連携、誰がどのタスクを担当するのかを明確にしておくことは非常に重要です。

近年「働き方改革」を推進する機運が高まっていますが、労働政策研究・研修機構の報告書には、「自らの業務目標の明確さや進め方の裁量度の高さが労働時間を短くする（引用：http://www.jil.go.jp/institute/reports/2011/0128.html）」と報告されています。

つまり、仕事の上での役割分野はプロジェクトを進めるにおいてはもちろんのこと、「ワーク・ライフ・バランス」を推進する上でも重要なポイントとなります。

プロジェクトで仕事を進めるにあたり、最初にキックオフミーティングを行ない、関係者で顔合わせを行ないます。この際、役割分担を正しく実行させるために必要なものが2つあります。

ひとつは体制図、もうひとつはWBS（Work Breakdown Structures）です。なぜこの2つが必要になるのか、実際に体制図とWBSを導入して運営したプロジェクトを例にとり、説明していきます。
※WBSとは何か、基礎について確認したい方はプロジェクト管理に役立つ！ WBSの使い方とツールの記事を参考にしてください。

事例紹介~IT系企業A社の例

IT系企業A社のインフラ系の事業部では、企業にPCやプリンタなどを中心としたハードウエアの導入支援プロジェクトを行なうことになりました。機器調達～導入から始まり、保守～機器の廃棄まで一貫して行なう事業です。

プロジェクトは約20人の規模で、内訳はサービスマネージャー、インフラ系エンジニア、データメンテナンス（資産管理）担当、ヘルプデスク担当、Webサイト担当（コーダーに近い）等です。外部の相手はクライアントオーナー、ハードウェア・システムベンダー、リース会社などで、ハードウエア導入後は運用部隊に引継ぐことになっています。

このプロジェクトチームに体制図とWBSを取り入れたところ、以下のようなことが起こったそうです。

1. 自ら報告、相談をする

メンバーが体制図を見て関係者を把握することにより、メンバーが関係者のメーリングリストを作成できます。プロジェクトメンバーに共有したところ、メンバーがメールのCCに入れるようにました。これにより、報告・相談がスムーズに行われるようになります。

2. 問題、トラブルの早期解決

体制図があることで、誰がどんな役割を担っているかが明確になります。そのため、問題・トラブルが発生した場合は、速やかに上司や関係者に伝わり、早期解決に向かうことができます。

3. 作業の事前準備ができる

WBSがあることで、自分が担当するタスク以外にもそれに関連するタスクやスケジュール感がわかります。これにより、作業着手にむけた事前準備ができるようになります。

4. 他のメンバーのフォローができる

WBSがあることで作業が遅れていることも把握できるため、他のメンバーがフォローに入りやすい状況になります。チーム内のコミュニケーションが活発になり、よい雰囲気のチームを作りあげることも可能になります。

経過あるいは原因：体制図・WBSのメリットとは?

体制図やWBSを作る最大のメリットは、上記にも挙げた通り、プロジェクトメンバーが自主的に動き出すという点です。実際、上記のプロジェクトでは、この2つの図によって自主的な行動が促されました。それができたのは、体制図・WBSで全体像が見えていることにより、いちいち上長に確認して動く必要がないという利点があったからです。自ら動いてメンバー（横のつながり）やリーダー・上長に共有・報告できる体制が整い、円滑なプロジェクト運営が可能になりました。

体制図を作る目的は、プロジェクトに参加するメンバーそれぞれの役割、そしてメンバー間の指揮命令系統を定義するためです。会社組織の中で定常業務を行う際は、自身の役割や上司や部下との指揮命令系統が決まっています。

しかし、プロジェクトは普段の定常的な業務とは別に、新たな体制を構築する必要があります。そこでプロジェクトの体制が明確化されていないと、必要な指示や報告が関係するメンバーに伝わらなかったり、意思決定に時間がかかったりと、作業ミスや効率低下の原因にもつながります。また、WBSの作成ができていないと、いつまでに、誰が、何をするのかが不明確で、作業もれやスケジュール遅延等が懸念されます。

どのような結果に至ったか、どのような方法を取ったか〜体制図・WBSの作る上でのポイント

それでは、体制図とWBSの作る上でのポイントをそれぞれ見ていきましょう。

プロジェクト体制図の作成

プロジェクトの体制図を作ることにより、メンバーは「誰の指示に従えばよいか」、「誰に報告すればよいか」という報告や相談ルートを定義することができます。
そのため、体制図を作る際には、プロジェクトメンバーの人数と役割を確認し、指示を与える人、受け取る人などの役割を明確にすることがポイントです。体制図があると、自分の担当以外がどのような役割をしているのかが把握できるため、メンバー間でコミュニケーションもとりやすいという副次的なメリットも生まれます。
参考：http://tech.nikkeibp.co.jp/it/article/COLUMN/20111220/377045/

WBSの作成

体制図でおおまかな役割は理解できても、具体的に自分がなにをすればいいのかという点についてはまだまだ分かりにくい点があります。そこで、WBSの出番です。WBSを作る際のポイントは、細かな作業のタスクを洗い出し、担当に割り振ることです。それら作業の工程を分解して示し、それをスケジュールにしたものがWBSです。ひとりひとりがやるべきことを大まかなフレームではなく、小さなタスクにブレイクダウンすることが大切です。これにより、メンバーがタスクに取り掛かりやすくなり、ひいてはプロジェクトに対するモチベーションを保つことができます。

また、WBSを使ってプロジェクトの進捗管理をすることもできます。作業開始日、終了日、進捗のステータスなどを記入できるようにし、定期的に各メンバーに更新させます。プロジェクトマネージャーやプロジェクトリーダーはWBSを確認すれば進捗状況を把握できるようになります。

さらに、WBSにできあがった成果物を記載しておくことで、成果物の完成までにどのようなタスクがあるのかを洗い出し、成果物・タスクの全体量を把握することも可能です。定期ミーティングなどで作業の進捗確認を行う際も、どこの作業が遅れているのか、どの作業がボトルネックになっているのか、課題が明確にわかります。

これからのWebの作られ方を展望するために、Webディレクターという仕事を振り返る

筆者は、1998年頃にWebディレクターという職業に就きました。当時は、何をするヒト？　と訝られました。幼稚園児だった長女が、「パパの仕事はパソコン！」と元気な声で紹介してくれたことをいまでもはっきりと覚えています。
インタビューを通して、複数のWeb制作会社さまのプロジェクト管理のあり方をお聞きしていて、Webディレクション術というものも取り上げておこうと考えましたので、今回はその端緒にWebディレクションの変遷（Webの作られ方）を追いかけてみます。

Windows 95が発売され、一製品であるにも関わらずこれが社会的なイベントのように喧伝されたことを覚えているひとはどれくらいいるのでしょうか？　この騒動を境に「パソコン」というものが当たり前に家庭に備わるようになったという点では、間違いなくそれは「革命的」でもありました。当時のぼくは、パソコンと同時にインターネットに強く惹かれ、これを生業にしようと独学でHTMLを覚えて実際にサイト制作を始めたのでした。一番最初に作ったのは、ある本屋さんのサイトでもあり、当時はブログなどという言葉もサービスもありませんでしたが、ごく個人的な「Book&Macintosh」というWebサイトです。（もちろん、それぞれいまは存在していません）
余談ですが、ちょうど青空文庫を作られる以前の富田倫生さんがこのサイトを発見してくれていて、メッセージをいただいたことも忘れられない出来事でよく覚えています。お亡くなりになったというニュースを見た際は、とても悲しかったです。改めて、ご冥福をお祈りします。

Webディレクターになる（おそらく町内唯一！）

やがて、98年頃に、とあるメディア企業のWeb推進チームという部署に所属することになり、WebデザイナーではなくWebディレクターと呼称するようになりました。以来、現在に至るまでほとんど自分ではデザイン（レイアウト）作業はしなくなりました（そもそもデザイナーではまったくないので）。
なお、この当時のWeb技術というのは、まだ非常にチープなもので、ロールオーバーアクションをデモでお見せするだけで「おお！」と感嘆の声があがり、さすが●●さんだね〜、と賞賛の言葉をいただいたのも一度や二度ではありません。Webディレクターという職業に就いているのはおそらく町内でぼく一人だけだったと言っても過言ではない時期でした。

現在、ぼくは主にWebマーケターを名乗っています。毎年幾つかのサイトディレクションも相変わらず続けてはいますが、仕事の主軸はWebマーケティングにシフトさせました。ディレクションの技術だけを比べてみても、20年もの期間の幅がありますので、その当時といまとではそもそも考える材料も比べ物にならないくらい増えていますし、学術的に定まっている要素も多々あります。
そんなテクニカルな比較も興味がありますが、今回は、以下、ANAのサイトを例にWebの作られ方を振り返りましょう。

ANA(ana.co.jp)のWebサイトをインターネット・アーカイブで遡る

残念ながら、インターネットアーカイブでは2004年以前は正しく表示されませんでした。

2004年のANAのサイト

この2004年のサイトを見ると、よくわかりませんが、ANAのWebサイトは随分初期の頃からネットからの予約を進めていて、当時から感心していました。
この当時は、まだメインイメージにFlash技術が使われていたことが特徴的でもあったのですが、ANAのサイトではそうしたクリエイティブ色は感じられません。
この当時の「クリエイティブディレクション」とは、どうかっこよくFlashムービーを作るかが重要なカギでした。2004年くらいの、個人的な印象を付記すると、Flashの演出はかなり早い段階で、言葉は悪いけれども「飽きて」、後にAjaxと呼ばれることになるjavaScriptで同じ（ような）動きを実現させることに腐心していました。一言で言えば、かなり面倒くさいので、デザイナーさんやエンジニアからちょっと嫌がられていた時期でした。

2011年のANAのサイト

2011年の画面では、ほぼ現在につながるテイストが確認できます。2カラムデザインです。
はっきりと「予約」が打ち出されていますね。

2016年のANAのサイト

2016年になると、フルスクリーンページに変更されており、フルスクリーンであるばかりでなくより画像を印象づけるデザインがなされています。

しかし、この３例だけでは、大きな視点が抜けています。
Webデザインの現場は、スマホの登場で大きく変わったことは言うまでもありません。

– パソコンからスマホへ
– テキストから画像へ
– さらに動画へ
クリエイティブの幅も大きく拡大をしてきています。

クリエイティブの「質」を担保するための考え

ディレクターが管理すべきクリエイティブの「質」も気になります。
常になんでもできるスーパーマンが求められるわけでもありません。
改めて思うのは、ユーザーの「感情を動かす」ものであるか、ということではないでしょうか？　ぼく自身はその点に常に心を砕いていたように感じています。
独りよがりなクリエイティブを目撃するときには、「もったいないなぁ」「残念だなぁ」と現在でも思うのです。

とはいえ、一般的にディレクター職にある人たちは忙しい毎日を送っているはず。
ぼく自身、30代はまるまるWebディレクター（プロデューサー）として過ごしました。朝早く出て終電で帰るという生活をぼくもしていました。
いまでは考えられないなぁと思いますが、仕事そのものは楽しかったしインターネットの世界もどんどん進化していきその動きと並走してきたという実感も強く持っています。

ここで、３つだけWebディレクターのための心得を挙げておきましょう。

それはなんのためのサイトか。そのサイトでなにが達成されるか

いちばん大事なのは、サイトの「目的」を明確に持っておくこと。クライアントの要望というものが原初の設定であっても、Webのプロとしての視点からそれをより最適な方向へ導くのはディレクターの役割です。

クライアントの要望がどこにあるか

そして、クライアントの要望をきちんと汲み取ること。特に、Web制作の初期の頃はなんのために作るかわからずに依頼をするクライアントばかりでした。やりたいことと手段が一致していないのは、他の業界でもよくあることです。プロとしての矜持がどこにあるのか、自らに問うことは大事なことではないでしょうか。

代替案がない反対はなにも解決しない

「なんか違うんだよな」もよくあるかもしれませんが、きちんと代替案がないならば解決はできません。そのために存分に知恵を使うこと、勉強すること。
技術が足りないならそれを補うべく習得すること。知識が浅いならしっかり学ぶこと。

getting things done という言葉を知っていますか？

本メディアでは、タスク管理の手法についてあるいはユーザーケースについていくつか紹介してきました。元祖とも言える、「GTD（getting things done）」について説明不足でしたので、今回はたっぷりGTDについて説明をしていきたいと思います。
実は、編集部内でもこの言葉を知らない若者がいました。若い世代にはもはやなじみのない言葉になっているのだと実感した瞬間でもあります。タスク管理を語るなら、知っていなくてはならないGTDとは、いかなるものでしょうか？
GTD（Getting Things Done）とは、デビッド・アレン（David Allen）が同名の書籍『仕事を成し遂げる技術 ―ストレスなく生産性を発揮する方法』（原題: Getting Things Done、2002年）の中で提唱した個人で使うタスク管理術です。2000年代前半には、LifeHack（ライフハック）という言葉とともに広く使われました。
1. アタマの中身を分野（プロジェクト）ごとに全部リストに出しきります（全脳思考という言葉に通じます。これも後半で説明します）
2. やる順番にリストをつくる
3. リストは定期的にレビューして常に信頼できる状態にしておく
4. 常に信頼できるリストがあるので、実際に作業する時はリストに書いてある事を信じて集中して仕事が出来るので効率が良くなる
という考え方がその中心。

GTDをまず実践してみる

とにかく、まずどうやるか！　を振り返ってみましょう。

GTDの具体的手順を、言葉を言い換えながらもう一度整理しましょう。

上記では、「４つ」の項目だったのに、言い換えを含んだので「５つ」になりました。このあたりは、実際にやりきれるように個人が判断をすればよい、というのが筆者の見解でもあります。GTDにせよ「タスク管理」手法の選択のもっとも大事なポイントは続けられるかどうかです。

では、順番に説明していきます。

１．把握する（すべてをリスト化する）

まずはアタマの中にあるものすべてを出し切るところまで精一杯リスト化を実行します。GTDの方法のキモの一つが「出し切る！」ということです。これを、「まぁこんなものかな」で一覧化＝タスク化していると、GTDはうまく行きません。
なぜなら、次の行動が意味を成さないからです。

２．見極める（行動が必要かどうか、誰かに依頼するのかどうか）

書き出してみたものをそれぞれについて実際に行動に移すべきものなのか、必要ないものなのか、誰かに依賴すべきなのかを見極めて処理をします。

GTDの手法では、この見極めは「整理」ではない、という点は注目です。
2分以内にできるかどうか、が判断基準です。
「すぐにできる」というものは、この時に次から次へと処理をしていきます。
これも、「次から次へと」がキモです。スッキリ！「片付いたなぁ」と実感できることができたなら、このGTDはうまくいきます。

３．整理する（仕分けたものを適切な場所に保管）

スッキリ！ができたあと、いよいよ整理をします。

この「整理する」には、２つの目的があります。
タスク管理としての整理と、それぞれのタスクに資料などが伴っていれば実際の資料としての整理も忘れてはいけない重要項目になります。

ところで、GTD手法としては以下の項目が推奨されています。

インボックス
次にとるべき行動（おそらく複数のリスト。これについては後で説明します）
連絡待ち
プロジェクト
いつかやる／多分やる

冒頭にお話した通り、このような手法は「続けられるかどうか」です。この項目も人それぞれで、自分自身が分類＝整理しやすいように考えていけば良いと思っています。
それが仮に、GTD風となっても続けられることのほうが重要です。

それが自分で判断できるようになるには、まずはやってみるが先決なのだとも自らの経験を通しても思います。

４．更新する（定期的に見直す）

整理したタスクを定期的に更新しなくてはいけません。
これも、人それぞれで、1週間で見直すか毎日見直すか。
GTDではありませんが、「アイビー・リー　メソッド」をご存知ですか？　

– 前日の夜かその日の朝にTodoリストを作る
– 優先順位をつける
– 優先順位の高い順に６つだけ書き出す
やるべき作業はこれだけ。
これは、１９１８年にアイビー・リーがチャールズ・シュワッブに伝えたということで有名な方法です。大事な点が、いま行なってるものが終わるまでは絶対に他のことには手を付けないことと、優先度の高い順から始めるということ。
この方法を実践して、チャールズ・シュワッブは経営していた事業を持ち直し、アイビー・リーは２５０００ドルを得たという逸話としても非常に有名です。

少し脱線しました。

５．選択する（状況・優先順位に合わせて実行）

分類したタスクを処理していきます。あとは、やっていくだけ！

駆け足で整理しましたが、これがGTDの方法です。

≫グーグルから使いやすいタスク管理アプリがリリース！詳細はこちらの記事から

GTDが続けられない原因を整理する

こうしたタスク管理術を既に試してきた方は、疑問に思うかもしれません。また、若い世代に浸透していないことを考えてもGTDでは何かが足りないのではないか？　その通りです。

GTDの方法論は基本的に個人に特化しています。チームを組んでものごとを進めるためのメソッドではありません。また、誰かのGTDの方法を別の誰かに移植できるというものでもありません。
過去にそういう間違いを犯した企業やチームはきっとたくさんあったかもしれません。

もうひとつ、GTDには「プロジェクト」というリスト項目が推奨されてて、このプロジェクトの定義を確認すると
「GTDにおけるプロジェクトの定義はとても広く、ひとつ以上の行動を伴う目標はプロジェクトと定義されます。」
とあります。

が、個人にこれをうまく使っていたという事例を探すのには一苦労しますし、プランニングをするにはGTDは不向きな方法でもありました。また、GTD一式をあるプロジェクト管理で活用するとなると、目の前のタスクは処理されていくことが確認できても、ある期限に間に合うかどうかが判断できません。

というのも、GTDは「時間管理」をパージしている方法論でもあります。

「従来のタイムマネジメント（時間管理手法）では、優先順位や仕事の計画を立てることが強調されてきたが、実際の仕事の場は年々複雑化し、せっかく立てた計画や優先順位は次々に割り込んでくる仕事のために破綻しがちである。計画の破綻や、計画を立てることすらできない多忙な状態の中、頭の中にすべき仕事を山ほど抱え込んでストレスは増大し、仕事はますます苦痛になり進まなくなる。

アレンは他のタイムマネジメントのプロたちと違い、仕事の優先順位をつけることを強調しない。そのかわり、状況に応じたタスクリストを作るよう勧めている（例としてかけるべき電話のリスト、市内へ出て回る先のリスト）。また新しい仕事が飛び込んできた場合、2分以内でできるようなものならばすぐ済ませるべきだとも説いている。仕事すべてがリストに書き出され把握できているのでない状態で考えた優先順位はむしろ不正確であまり役に立たない。

GTDは、やらなければならない仕事に関する情報を蓄え、追跡し、思い出すことを、簡単にするにはどうすればよいかという心理学的基礎に基づいている。」wikiより引用

ん？　こういう考え方、プロジェクト管理でもありましたね。スクラム開発におけるストーリーポイントとは、まさに同様の考え方です。
はっきりわかるのは、我々はもう１００年くらい、自分たちのすべきことにどう向き合うかを考え続けてきているということ。生産性（向上）というものは、数年前に始まった議論でもなんでもなくて、これまでずっと働いてきた人たちが常に向き合ってきた問題だということなのです。

GTDのベストプラクティスとGTDの成功事例

では、GTDの成功事例というものも振り返ってみましょう。

http://gtd-japan.jp/activity_example

https://blogs.technet.microsoft.com/mpn_japan/2018/02/07/work-smarter-not-harder-getting-things-done/
などが、公開されていますが、調べてみるとつくづく最近はGTDが使われなくなってきたのだな、と実感します。

１０年ほど遡らないと、個人での活発な取り組みが見つかりません。

このGTDの国内の紹介者でもある田口さん（現在は、ドットインストールの代表と紹介したほうがよいですね）のIT Media の記事一連のものは、GTDが元気だった様子を忍ばせます。

GTDとマインドマップ

最新の成功事例を簡単に確認したあとで、冒頭の
「まずはアタマの中にあるものすべてを出し切るところまで精一杯リスト化を実行します。」
をもう一度振り返ってみましょう。

この言い方もどこかで聞いていますね、全脳思考やマインドマップなどは同じ概念で語られます。マインドマップは、イギリスの著述家トニー・ブザン(Tony Buzan)が提唱した、自らの思考や発想を視覚的に捉えて脳内の情報を整理・解放し、新たな発想を得るための手法のことです。時に、教育術（教育手法）とも紹介され、実際にこれを採用している日本の学校も複数あります。

マインドマップそのものは、かなり厳格なルールが存在しているのですが、「放射思考」法としては、すでに多くの企業でプランニングや会議に使われたりしているのではないでしょうか。
マインドマップは、明らかに「放射思考」と呼ばれる脳の仕組みをアウトプットするための方法から生まれています。放射思考とは、ひとつの情報が別の情報と関連付けられ、またその情報が別の情報へと展開していくという流れを指し、中心の情報から放射状に思考が広がるというもの。
さて、ここではGTDを、マインドマップを活用して進める方法を紹介します。
その目的は、GTDそのものの手法ではなく、「共有」です。GTDはチームで活用する方法ではなかったと先に述べていますが、それを補いうるのではないかと注目できます。

また繰り返しますが、このような方法は自ら取り組んでみてはじめて結果が語れるものです。興味が生まれたなら、ぜひ実践してみてください。そこからカスタマイズをして、自分の方法が生まれるものだと思います。

今回紹介する方法では、ものごと＝タスクを完了するための５つの基本項目があります。

1.現在のプロジェクト

いわゆるGTD手法で語られている「プロジェクト」に当たります。
完了するまでに多くのアクションを必要とするものは、「現在のプロジェクト」に入れます。この「プロジェクト」については、自分たちの目指すより大きなゴールに合わせることで実際に働く目標を立てることができます。

2.タスク

「タスク」には、１で導かれた「現在のプロジェクト」に対して、これをを完了するために必要なすべてのタスクが置かれます。
プロジェクトごとにマインドマップがあれば、プロジェクト下のタスクを簡単に一覧表示できます。

3.次のアクション

「次のアクション」というのは、プロジェクトを完了するために必要なタスクか否かに関わらず、次に行なう必要があるタスクを置きます。
急に発生した「やらなければならないこと」は誰もに思い当たることがあるのではありませんか？
したがって、いま集中しなければならないのは、「次のアクション」だけということになります。それが完了したら、リストから削除して次のマークを追加するか、マインドマップのTo Doリストのように色分けシステムを使用します。
また、★や特定のシンボルを使用して、次に実行するタスクを強調表示することで、タスクが処理されることを牽引します。

4.コンテキスト

「コンテキスト」というのは、仕分けのために加えられます。
自分たちの仕事をある文脈（コンテクスト）に分けておくことで、適切な時に適切な仕事に集中することが可能になります。たとえば、ビジネスタスクを自宅のタスクから分離することができます。これにより、適切なタイミングで適切なタスクに常に集中できるようになります。

5.カレンダー

「カレンダー」というものは、もともとのGTD手法にはありませんでしたね。
ここでは、スケジュールを把握するために、全体的な概要、日次の進捗、あるいは期限を確認できるように工夫が必要です。
締め切りを重視する特定の日付までに完了しなければならないタスクはなにか、簡単に把握できなければなりません。

6.ソフトウェア

「ソフトウェア」は、
どのようなソフトウェアを使って自分の仕事の何を管理し、ここにあるものごとを終わらせるか、を確認します。

詳しくは、以下に示すページなどで確認してください。
（この項は、http://www.usingmindmaps.com/getting-things-done-mind-map.html　を参考し紹介しています）

GTDはこれからどうなるか

最後に、少し筆者の「タスク管理」術遍歴を語ってこの記事を終わりたいと思います。そういう考え方や取り組みに初めて触れたのは、３０代のWebディレクターをしていた頃です。いまでもお世話になっている野口悠紀雄氏の『超整理術』という爆発的ベストセラーがきっかけです。
朝７時に出勤して終電まで働くという生活がちょうど始まった頃で、自分の抱える仕事をどううまく処理していくか考えるにちょうどよいタイミングでもありました。この著書で紹介されているファイリング方法をまさに自分のタスク管理として実践しました。ちなみに筆者はそもそも整理上手というか、基本的にビジネスマン人生で「机が汚い」と言われたことは一度もありません。

そのファイリング術をアップデートしたのは、まさに本稿で取り上げたGTDが登場した頃です。すぐにWebサービスも誕生し、これはちょうどWeb2.0という言葉が頻繁に語られ始めた時期です。いまでも使われているチェックパッド（http://www.checkpad.jp/）とかRemember The Milk: Online to-do list and task management(https://www.rememberthemilk.com/)がその代表選手です。チェックパッドは、確か田口さんが開発・運営されていたはずです。
どちらも試しましたし、GTDが語られるたびに紹介される『はじめてのGTD ストレスフリーの整理術』（この本の監修者は田口さん）も早々に購入して大勢に紹介をしました。自慢をするわけではないのですが、上記で紹介したようなタスク処理方法は一緒に働くメンバーなどにも紹介して、まさにチームで実践をする体制を作っていました。「仕事が早い」という評価も受けていましたので、そういう背景があったわけです。

ただし、実際に筆者が使っていたツールは、Wikiです。
GTD Tiddlywikiというもので、現在は、既にありません。
こちらに集約されてしまっています。https://tiddlywiki.com/
これを、個人サーバにあげて、「スマートフォン」（という言葉）が登場以前のめちゃ愛用していたNokiaのスマホで見られる（かつ更新できる）ようにしていました。ついでに語ると、そのNokiaを使う（４台くらい使ったかな、うちE61は個人輸入したもの）前はPDAのPalmやSony のCLIEの愛用者でした。特に、CLIEはクライアント様にも大絶賛をして３名が実際にCLIEユーザーになりました。
このあたりは語ると長いので割愛しましょう。
GTD Tiddlywikiは、GTDに特化したWikiです。ローカルマシンでも動くのがこれを選択した決め手です。実際にかなり長い間、この方法を使っていました。

が、これが他のツールに移行する時点で、GTD時代は終焉を迎えました。

では、いま何使ってるのか？　と当然お考えになるでしょうが、答えは複数併用しています。
– マルチタスク
– ノマド的（個人的にはノマドという言葉は嫌いです）
– フリーランス
その３つがうまくコントロールできる方法を考え続けています。これだ、と言うものに落ち着いていません。アナログ的でもあり最新だ、というものが常に正解になっている気がします。

上記の各項目でも語りましたが、そもそもこういう手法や考え方は１００年前からずっとただひとつの答えを見つけ出せずに続いているものです。その答えは、まずは一人ひとりの中にある、が真実なのだと思っています。その答えは風の中さ♪〜 the answer my friend is blowin’ in the wind 、じゃないですけどね（by Bob Dylan）。

不動産業界特化型ディレクターとして全国区に活躍するサービシンク名村さんにプロジェクト管理道を訊く

不動産業界に特化したWeb開発会社であるサービシンクの名村さんをお訪ねしました。
「サービシンク」という社名は「サービスを考えぬく＝Service＋Think」だそうです。
不動産業界は、そもそも広告費用が大きく、広告なくしては成立しない業界である一方、不動産業法や業界慣習・文化、専門用語をきちんと理解できていなければ成果を生むWebサイトは作れないのだ、と戦略的に業界特化型となった背景を説明されています。その一方で「不動産業界の不透明さをどうにかしたい」と語られるのです。この言葉に象徴されるように熱い言葉があふれるインタビューになりました。

２０００年からは、俳優修業の傍らで不動産検索サイトHOME’Sを運営している株式会社ライフル（旧ネクスト）に合流。
同時期にプロの声優としても活動していたが「３０歳までに声優として喰えなかったら諦める」という父親との約束があり、自分の才能に見切りをつけ廃業。
０５年からは他の制作会社に合流し取締役などを歴任し、不動産業界のサイト制作のディレクションからフロント実装を担当する。
１０年１月１２日、ネイムヴィレッジを法人化した株式会社サービシンクを立ち上げ、代表取締役に就任。不動産業界に特化したサイト制作のプロデュース、ディレクションに取り組み、現在に至る。
著書：
『Webブランディングの入門教科書』『変革期のウェブ』（ともに毎日コミュニケーションズ刊）

サービシンクのプロジェクト開発体制は

今回のインタビューは、実は以前インタビューさせていただいた谷口さんからのご縁で実現しました。つくづく、仕事というのは人のつながりだなと感じる次第です。早速ですが、御社のやられているプロジェクトのご紹介をいただけますか？　不動産のWebサイト、Webシステムと言っても実に多様なものが存在すると思います。

おかげさまで会社設立以来ずっと順調に事業成長していまして、創業直後からお付き合いさせていただいているデベロッパー様などはもう８年のおつきあいになります。プロジェクトとしても、インフラからアプリケーションの開発、さらに都度都度いただく保守メンテのような案件も含めて、現在では２チームに分けて動かしているというものがあります。年間で数千万もの規模になるプロジェクトになっていますよ。チームを分けたというのは、異なるWebサイトが２つというご理解で大丈夫です。そのチームは、ちょうど５人ずつに分かれていますね。
ちなみに、現在の社内体制としては、ディレクターが６人、デザイナーが２人、マークアップエンジニアが２人、エンジニアが６人、その他６、７人ですね。このメンバーで、担当プロジェクトをそれぞれアサインして動いています。

開発手法ということで考えると、このデベロッパー様のプロジェクトはウォータフォール型になることもあるし、なんとなくアジャイルになることもあるという曖昧な感じでもあります。この案件もそうですが、プロジェクトそのものは言わば延々と続いていくものでもあります。数時間で終わるような1タスクが終わってもさらに新しいタスクが待っていて、常に複数のタスクが存在してる。ただ、全体としては、ウォータフォール型のプロジェクトになっているのが現実かなとは、業界的にも感じていますね。
そこは、特に最近悩みながら進んでいるところでもあり、今回のお話は私にとっても勉強になるかなと思いました。

その悩まれるというか考えられているポイントは、どういうものなんでしょうか

一番大事にしているのは、制作側の都合でお客さまのビジネス速度を止めないことです。お客さまと我々との密な連携のもとで進めないと危ないものについてはきちんと仕様書も作成して進めます。ですが、お客さま側の一担当者だけしか使わないものなどは、ミスがあっては困るものの速度優先でどんどんやっていくと、クライアントにも社内でも共有されています。
機能改修のようなものの頻度も多いのですよ。

その業務の流れってどのようなものなんですか？　概ね想像もできそうですが

要件そのものの打ち合わせができたら、ワイヤーフレームを作成して、要件定義（仕様書）を確定させて、モックが必要な場合はモックも作って、その後HTML化するというごくごく一般的な流れですね。

そのクライアントさんとの窓口はディレクターの方がされるわけですよね？　その際にチケットを切っていくようなツール、あるいはクライアントさんとの情報共有ツールはどんなツールを使っていますか？

そこは完全に使い分けをしています。社内では、Redmineの一択。実は、過去にはRedmineだけではなくTrackを使っていたこともありましたが、いまは使っていません。一方、クライアントさんとの共有は、Backlogにしています。エンジニア仕様のRedmineだとクライアントさんにとっては使いにくいものでしかないので、どうしてもBacklogを選択することになります。したがって、ディレクターは、同じタスクをその２ツールに登録をしたり、ステイタスを変えたりしなきゃいけない状態になっているのは悩ましい。わかってるんですけど、これはもうずっとそのままになっています。

新しいプロジェクト管理ツールが登場してくると、もちろん興味もあるのですが、例えばRedmineからの移行ツールなどがないと切り替えはできないのですね。先にお話したデベロッパー様の案件などは８年分の経緯がそこに蓄積されていて社内資産にもなっていますから、ここは大事なポイントなんです。
ただし、私自身ずっとディレクターをやっているので、不便なことを不便のまま慣れていくということは認めたくないことでもあります。以前Trackを使っていた時、クライアント用にBacklogに同様のものを記述しなきゃいけない。ただ、両者のwiki記法が異なっている、その書き換えが面倒でTrackのチケットの内容をBacklog用に変換できるブックマークレットを自作していました。そういう仕組みづくりはそもそも好きなんですよ。

ブックマークレットとは、少し懐かしい響きですが、、、やはりアイデアマンなんですね。

プロジェクト管理と呼ばれるものについて思うこと

他のツールや、他にこんな取り組みをしたなどという事例はありますか

弊社は今年新しいサービスを始める計画なのですが、そのプロジェクトではTrelloを使い始めました。あるベンダーさんとの提携プロジェクトでもあるので、そのベンダーさんからのご提案で使うことになった次第です。社内のディレクターからも「一度使ってみたかった」という声もあがり、ちょうどよかったかな、なんて思っています。
また、あるマネージャーには「かんばん」手法を試してもらいました。ホワイトボードも設置して試しましたが、彼のキャラクターに合ってなかったので頓挫しました。これでわかったのは、手法そのものじゃなくて、プロジェクトは人と人なんだという実感でした。うまくいってほしかったんですけどね。結果、これも宿題です。

Redmineについても、社内的には特殊なプラグインを加えていたり、運用に特別な工夫をしたりということはあえて避けることにしています。と言うのも、お伝えした通り、

– 長期プロジェクトが多い
– タスク（チケット）にイレギュラーが多い
– などが当たり前となっているので、変則的な進行が常体化していて特殊仕様がすぐに陳腐化して使えなくなります。ここは、まさに業界的な課題というか事情なのかもしれません。

ということは逆に、プロジェクト管理ツールを活用して、プロジェクトをうまく回すためのコツというのは、この業界的にも重要なスキルになってくるかもしれませんよね。

そのために、何か考えておられることもあるのでしょうか

社内リソースをプロジェクト管理のカスタマイズのために割くということは、いまの段階では考えられなくて、ただ今後社内の規模の拡大に備えておくためにはそろそろ本格的に動き始めなきゃな、とはずっと思っています。
理想としては、コミュニケーションツールとしてのSlack、管理機能本体のRedmine、ソース管理・デプロイ管理のGitあるいはGitLabを一つのツールで集約できること。いまはデプロイが済んだ段階で、Slack上で「完了」報告し、Redmineのステイタスを「完了」に変更し、という手順で、デプロイに至るまでのフローも追いかけるのが面倒になっています。これが、一つのツールで完結できるようになればまさに理想的です。

いまは、一つのチケットを完了するのはディレクターしかできませんが、デプロイの連絡はクライアントさんと共有するBacklogからしか行なわれないというようなフローであったりします。かつ、Backlogのタスク終了はクライアントさん権限だったり。
ここがキレイにまとまったら言うことないですね。
ビジネス的にも、Backlogのタスク完了していること＝納品でもありますから、おいそれとは手を付けられないという事情です。

その理想像が見えてくるまでのプロセスって

スケジュール管理とタスク管理だけで考えたほうがわかりやすかったな、という実感はありますよね。コミュニケーションツールやマイルストーンを考えるところから悩みが始まったみたいな

そういえば、Web制作会社さんだとExcelでスケジュールを一元管理してます、みたいなお話も多いのですが、御社もそういう時期がありましたか

Excelでガントチャートをひくマクロは自分で書いて使ってたことがありましたが、それで一元管理をするということはしてこなかったですね。創業当時だと、OmniPlanを使ってたことはありました。でも、その当時からBackLogは出てきていましたから使い始めていましたよ。それ考えると、やはり長い、、、
10人規模になると、Excelでの管理は無理があります。２、３人で数ヶ月のプロジェクトなら、そっちのほうが楽かとは思いますけど。それでも、クライアントはいまでもExcelが好きですよね。実際に、よく言われますよ。

結局は「働き方」や「社内カルチャー」について悩むことなんじゃないか

リモートメンバーがいないのですよね？

個人情報の扱いも含んでいますので、基本的にリモートでの作業は考えられないです。社内メンバーからもリモート勤務の要望はないです。また、私個人の考えとしても、まだリモートワークの環境準備できていないと感じています。
評価がとても難しいですよね。みなさん、どうしてるんだろうと思っています。

弊社にも北海道で働くリモート社員がいます。彼の場合は、毎日の定期的なリモートMtgや四半期ごとに東京に来てもらってコミュニケーションをするように心掛けています。具体的に彼の専任プロジェクトというものも存在しますが、プロジェクトの成果物だけで評価するということにはしていません。

「納期、間に合いませんでした」ということが一番心配なんですよ。恥ずかしい話ですが、弊社で過去に実際にあったので。コミュニケーションを取っていても結果としてそういうことでは評価できないな、と。「頑張ってます」ということでは評価できないと言いますか。
なので「その責任を誰が負うのか？」ということを徹底して社員にインプットしています。

つまり、そこはツールに任せるのではなく上司たるものがきちんと見るべきだということですか？　なにか、アラートを発信させる工夫などはあります？

属人化してると言っていいでしょうね。いまのところは、それが弊社のカルチャーでもあるかもしれません。

少し戻りますが、工数管理はRedmineでされているということですか

その通りです。これも、そもそも工数＝作業時間でこれが積み上がっていくことで見積金額、請求金額も変わってしまいますから、きっちり時間計算もしています。
仮に、３日＝２４時間で見積もりしていたものが、「残業含めてなんとか３日で終わりました」という報告が上がって来た場合、結果的には、２４時間ではなく３０時間だったという結果を受けて、その作業の振り返りはきっちり詰めておくようにしています。なぜ、２４時間で終わらなかったのか、と。３０時間は３日じゃないよ、と。原因がクライアント側の指示なのか、エンジニア自身の見積もりなのかの原因がはっきりしておかないと、次の改善ができないので、そこは大事にしています。

それで、さっきの責任ということなのですが、会社のカルチャーとしては「上意下達」で徹底していると思っています。これは「責任」と「指揮命令系統」の話で、責任所在をはっきりさせたい、ということです。たとえば何かのプログラムが意図通りにできていなかった。この場合、指示が明確じゃなかったのか、プログラムの作りが間違えていたのか。指示が不明確だった場合、当然部下には一切責任を押し付けないこと。「部下の当初の設計に対して上司がアドバイスの元、部下が修正をしていた結果、実は間違えていた」といった場合、「まぁ・・・どっちにも責任があるよね」みたいになりますが、これをするのが一番良くないことと考えているからです。この場合１００％上司の責任ですから。

ディレクターの指示が明確じゃなかったらディレクターの責任、あるいは進捗管理がうまくできなかったPMである私の責任。部下には一切責任を押し付けないこと。
もう一言加えておくと、モチベーションは会社が与えるものでなくて自分自身が作るものだ、という伝え方をしています。これも会社のカルチャーとして重要なところだと思っています。

少し「働き方」とか勤怠制度のところにも突っ込んでしまいますが、というのも「プロジェクト管理」というのは直線的にどうしてもそういうところにつながっていくものでもあります。

はい、先ほども「上意下達」なんて言葉を使いましたが、始業時間も朝は９時半から絶対で、遅刻は厳禁です。ルーズさとは無縁なカルチャーになっていますね。出勤と退勤時のあいさつをはっきり言う、というのも社内ルールとしては厳しく決めてます。あいさつについては、中途入社してきたエンジニアが「この会社はみんながきちんとあいさつを返してくれるのでうれしい」なんて入社１ヶ月後の感想を伝えてきたときには、驚きましたね。そんなものかなって、、、彼はもともと転職の理由が「前職では、会社の人があいさつをしても一切返してくれない」というものだったので。

御社は今後社員を増やされる計画なのですよね

２０２０年までには社員５０名体制にすることを決めています。今年も１０名の新卒採用を計画しているので、いまは人事がピリピリしていますよ。
こちらはまさに、人事の問題で教育をどうしようかという話ですね。私自身も多くの機会でセミナー講師をさせていただいており、いろいろなことをお話させていただいておりますので、外部で話したセミナーを社内でもおこなう機会を設けています。

単純に、働きがいのある会社にしたいと強く思っていまして、社内制度としては充分誇れる体制ができていると自負しています。毎月の残業は平均で２２時間くらい／人になっていますが、自社の責任における納品遅延などは一切ありません。
さきほどもモチベーションづくりは会社ではなくて個人による、と言っていますが、会社とは装置なので個人は会社を利用すればいい。その時、一個人、人それぞれの価値がなんなのかを追求して欲しい。それが会社の底上げにもなりますからね。時代が厳しい方にどんどん進むので、若い社員にはそういう意識を持って成長していって欲しいのです。私からはそのための種まきはしていると思ってます。
ただ、今後さらに社員が増えていく過程で、いまの弊社のカルチャーも変わるべきところもあるだろうと思いますし、それはそれで楽しみなんですよね。

弊社は、約１０名の会社ですが、やはり規模の拡大は考えていますので、追いかけていきたいです。
今日はどうもありがとうございました。

取材を終えて

実は、今回のサービシンクさんは同じビルに同居する者同士。
とはいえ、いままで交流はありませんでした。取り持っていただいたのは、本企画にご協力いただいた谷口さん。

不動産業界特化の制作会社、とお聞きして最初に想像したのは、おそらく多くの人にも一番想像できそうな不動産仲介の営業さんたちの印象。ビシっとスーツを決めて、みたいな。かつ、それなりに年季も入っている方だから貫禄も、、、という想像のもとにお会いすることになりましたが、写真の通りの出で立ちでした。

でも、その言葉は熱かったです。改めて確信することができたのは、「プロジェクト管理ツール」の機能の一つひとつが会社のカルチャーや各種制度と地続きにあるということでした。
名村さん、ありがとうございました。ご紹介いただいた、谷口さんにも改めて感謝申し上げます。

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

働くママのための、育児の家庭内チームビルディング

働きながら子育てをするママ達の苦労は、大変なものがあります。
子供がいなかったときは、仕事量が多くともスケジュール管理や他の人に仕事を分散させるなどとして、さまざまな工夫ややりくりを重ね、結果を残していくことができていた女性も、妊娠・出産を経て職場に復帰してみれば、仕事とプライベートに育児が加わり、想像よりも大変さを痛感する日々を送っているという方々は多いでしょう。育児は長期事業。子供の成長を通じて、親も学びを得ることができる特別な期間です。育児＝子育ては、当然ひとりではできず、地域や社会を通じた多角的な視野をもった体制が理想的です。よく、社会で育てると表現されるのはまさにそういう意味です。が、核家族化が浸透し個人情報の個守を重んじる現代社会では、高度成長期に存在していたような世話焼きのおせっかいおばさんおじさんも、子育て経験のあるおばあさんや親戚とも滅多にお目にかかることができません。
近年「ワンオペ育児」が問題になっているように、世の働くママたちは孤立しがちです。そのため、ママたちが、安心して育児をしながら仕事もできるようにするために、育児者周辺でのチームビルディングをすることが望まれます。この記事では働くママのための育児のチームビルディングについて考えていきます。

『わたしおかあさんだから』炎上にみる自己犠牲感の危険性

仕事も育児も多忙をきわめ、熱心になるあまり周りが見えなくなり、必要のない我慢を重ねてしまっているワーキングマザーはいませんか？

最近問題になった、絵本作家のぶみ氏が作詞し、NHKのうたのおにいさんだった横山だいすけさんが歌った『わたしおかあさんだから』という歌。歌詞の内容は、「おかあさん」であるわたしは、子供ができてからというもの、自分のことは後回しにして子供に尽くしている。自分のしたいことができなくとも、子供を産み、子供に会えたことが幸せだ、という内容でした。だいすけおにいさんの歌を聞けば、ここまで反感が出なかったかもしれませんが、有料放送での放映だったため、歌詞のみが拡散してしまい、その歌詞を読んだ世の女性たちの怒りをかってしまうこととなりました。女性たちは、望まない自己犠牲を、「おかあさん」である女性ばかりがいまだに求められており、子育て中であれば我慢や自分をおさえることを強要されていると感じてしまったことが原因だと考えられます。

子育て中に我慢し続け、つらかった気持ちを、仕事することで自己実現や自信を回復して解消できた女性や、子供が成長し自立したために育児経験を客観的に見られる女性は、この曲の歌詞に反感を持たなかった方も多いようです。しかし、子供が小さく手がかかり、自分のことを後回しにせざるを得ない状況の真っ最中である「おかあさん」が、この曲の歌詞を読めば、自己犠牲を強要させられている気分になるであろうことは想像がつきます。

そもそも、育児はママだけがするものではなく、パパとで協力してすすめるべき大事な事業です。ママ一人だけでできる簡単なことではありません。それにもかかわらず、ママの「ワンオペ育児」が問題になったり、ママが我慢を強要させられているよう感じてしまうのはなぜなのでしょうか。ママは子供が産まれてからは、体に変化がみられ体調も変わったり、環境が変わったりと、パパよりも状況が大きく変わります。そのため、さまざまなストレスにさらされるのです。ママのストレスを軽減し、育児中にも仕事を進めやすい環境をつくるためにも、チームビルディングを行なうことを考えましょう。一見、一般家庭に関係のなさそうなチームビルディングですが、家庭こそ、もっとも小さなチームでもあることを思い出しましょう。
現代社会は、仕事での生産性をあげるために、一人ひとりのスキルを掛け合わせて業務進行スピードや達成力を最大化させようと、チームビルディングをすすめています。仕事上のチームビルディングを考えるそのまえに、子育てと仕事で疲弊した毎日を、もっと快適なものにするためにも、家庭でのチームビルディングについてもっと考えるべきではありませんか。

働くママこそ、チームビルディングを進めよう！

子育て中には、病気、怪我、さまざまな子供の問題など、予想もしていなかった問題が起きるときがあります。そんなとき、わたしたちはどう対処していくべきなのでしょうか。
予期しないトラブル対応、それは子供がいないビジネスパーソンにも起こりえます。トラブルに対応できるスキルがあれば、子育てで起こるさまざまな問題にも対応できるようになります。そのスキルとは一体なんなのでしょうか。

それはなんといっても時間管理能力です。時間管理を制するものは仕事も制するといっても過言ではありません。限りある時間を有効に使い、タスク管理を行なって、仕事と仕事以外に使う時間について、十分な把握とコントロールを心がけましょう。時間管理がうまくできたならば、タスクをさまざまな人に分散させて、チームで育児と仕事を充分にまわせるようになるのです。育児に関することを周りに頼むと申し訳ないし、頼める人もいない、とひとりで抱え込んでしまっていたママは、考え方を変えてみましょう。仕事と同じように、子育ては、チームで進めるほうが、さまざまな人と関わりができて楽しいですし、他の人とのコミュニケーションから貴重な学びを得られることもあります。子供にもよい影響を与えることができると思いませんか？ パパ、親戚以外にも、周辺の保育ママや、学童保育、習い事の先生、頼れるママ友達など、子供に関わるのある人たちを自分たちのチームメンバーと考えて、満足のいく子育てができるように、最善を尽くしましょう。

チームビルディングの要の時間管理に必要なものとは

働くママのあなた。いつも頭のなかで、すべきことをぐるぐると考えてはいませんか？ 働くママである筆者も、朝、学校に行こうとする子供に、「買ってきて！」と頼まれた文房具は何だったろうか？ と思い出しながら仕事をしているときがあります。何か違うことを考えながら仕事をすると、集中できませんし、効率もさがります。そんなときは、朝、家族が起きてくる前に、その日一日ですべきこと、したいと考えていることをすべて頭の中から出し、Todoリストを作りましょう。できれば、そのなかに、すべきこと以外にしたいことも書き出してみましょう。

すべきことだけ行った日よりも、したいことができた日のほうが、満足度を上げることができます。30分ランニングをする、いつもより丁寧に体をストレッチする、読みたかった本をゆっくり読む等等、どんなことでもよいので、ひとつはTodoリストにしたいことを加えてみましょう。

Todoリストをつくる目的とは?

GTDを知っていますか？ GTDとは,生産性向上についてのコンサルタントであるデビット・アレンの著書、『仕事を成し遂げる技術 ―ストレスなく生産性を発揮する方法』（原題: Getting Things Done、2002年）の中で提唱されている、ワークフロー手法のことを指します。

知識労働者の仕事術とも呼ばれているこのGTDは、「次に何を、いつやるのか」という予定をたててスケジュールを管理したり、決めたスケジュールを進行していく上でのモチベーションを保つための体制作りなどを含む仕事術でもあります。仕事のみならずプライベートでも、すべきことが沢山あるのに、時間が限られておりあせってしまう、というような心理的な負担を減らしながら、個人の生産性をいかに上げていくのかを目的としています。日々のなすべきことをこなしながら、人生においての目標も達成できるようにするための行動を現実に落としこむスキルでもあります。

GTDは、忙しさを極める子育て世代のワーキングマザーにぴったりな手法だといえます。この手法の基本は、なすべき仕事のリスト、Todoリストを記録しておくこと。リストをつくる目的は、頭の中からしなければならない仕事のことを追い出して、これで頭の中のなかをすっきりとさせることが最大の目的です。そうすれば、しなければならないことを無限に考え続けてしまうループに陥ることもなく、よけいなストレスをなくすことができます。リストに従って実際の仕事を進めていけば、いますべき仕事に集中できるので、能率も生産性もあがることになるのです。

パソコンも、さまざまなデータを入れたまま、多様なアプリケーションを使うとフリーズしてしまったり、動作が遅くなってしまうことがあります。人も考えながらタスクをこなしていると生産性が下がってしまうのです。女性は特に、古代から子供を育てる役割を果たしてきたことから、男性よりもタスクの同時進行が得意だと言われます。しかし、そのタスクも膨大であったり、疲労を持ちながらタスクをこなすのでは無理が生まれます。Todoリストを作って、すべきことを整理し、いますべきことに集中できる環境を整えましょう。

筆者は在宅で仕事をしていますが、タスクを処理しながらも家のほこりを掃除したくなったり、今晩のおかずにはなにを作ろうか考えてしまっていたりします。そんなときは、とにかく浮かんだことをTodoリストに追加して記入していきます。そうすると、浮かんできてしまった内容から離れて、タスクにまた集中できるようになります。特に、忙しくてTodoリストを作れずに外出してしまった日などは、しなければいけないことを忘れて、漏れがでてしまうので、忙しいときこそ注意が必要です。

チームメンバーに仕事をふろう

Todoリストを作ったら、自分がしなくても、他の人に頼めることはしっかり頼みましょう。頼み方も、仕事のときのように、その人物にあわせた頼み方を考えておきましょう。パパには、力仕事やママが手の届かないところについてのことを頼んだり、子供にも頼めることは家族の一員としての自覚を持たせるためにも、危険なこと以外、いろいろ積極的に頼みましょう。

仕事のチームで他のメンバーに仕事を割り振ることができていれば、家庭のチームメンバーにも同様にすることができるはず。しかしお願いするばかりではなく、感謝の気持ちも忘れないようにしましょう。筆者は２階建ての家に住んでいますが、朝、小学低学年の長男を起こしたら、幼稚園児の次男を、長男に起こしてきてもらうことにしました。以前は、私や夫が起こしていたのですが、リビングが1階のため、子供を起こすために2回も階段を登らなくてはならず、お弁当作りで忙しい朝には非常にストレスでした。そのため長男にお願いしたところ、やってくれるようになり、助かっています。次男を起こしてくれたときは、必ず褒めるようにします。このタスクが長男に定着することを望みます。

筆者の家庭では、家族は一人ひとり協力しあうことが必要だと常日頃から話をしています。そうすれば、希望的観測ですが、頼んだことを、すぐにきちんとしてくれるようになるのではないかと思っています。

エンジニアがデザイナーと協業する際に覚えておきたいコミュニケーションのポイント

WEBサービスを成功させるためには、UIやUXが的確に意識された良いフロントエンドのデザインが必要不可欠です。しかしながら、現在優秀なフロントエンド・デザイナーは開発案件の数に対し圧倒的に不足しているのが現状。理想的な人材に依頼することができない状態で開発を進めなくてはならないことも少なくありません。開発の現場からは「デザイナーに頼んだものの、意図したものとズレたものが上がってきた」「デザイナーに頼む際にどう伝えたらいいか分からない」と言った声が聞こえてきます。この記事では、デザイナーがどのようなプロセスを経てデザインを生み出しているかを知り、正しく案件を伝えられるようになるためのコミュニケーションのポイントについてご紹介します。

そもそもデザインとは？

デザイナーの仕事は「カッコ良いビジュアルを生み出すこと」という風に理解されている方が多いかもしれません。しかしデザインの語源を調べると、このように記述されています。

デザインは日本語では「設計」にもあたり、「形態」や「意匠」と訳されてきたが、それだけに限らず、人間の行為（その多くは目的を持つ）をより良いかたちで適えるための「計画」も意味する。人間が作り出すものは特定の目的を持ち、それに適うようデザイナー（設計者）の手によって計画されるのである。
Wikipedia > デザイン > 語源

どこにも、ビジュアルに関する記述がないのにお気づきでしょうか。実を言うと、デザイナーは決してビジュアルを良くすることだけがメインの仕事ではありません。デザイナーは、依頼されたデザインを行うために「依頼の本質（目的）を掴む」「構成に必要な要素を揃える」「配置や動線を考える」など、いわゆる「目的を達成するための設計」に多くの時間を使います。その結果、出力されたものが美しく機能的なデザインとなってビジュアルに現れるのです。

「ビジュアルを出力する前段階として、エンジニアの方が言うところの『要件定義』に近いプロセスを、デザイナーも行なっている」と言うと、伝わりやすいかもしれません。

デザイナーは「お任せ」では良いものを作れない

前項で、デザイナーにも要件定義のようなプロセスを行なっているとお伝えしました。つまり、良いデザインを出力するためには、ある程度の要件が決められていることが必要不可欠なのです。エンジニアの方がクライアントからよく言われて困る言葉に「いい感じで、なる早で」というものがあると思います。これは、デザイナーも同様で「なんとなくでは進められない」のがデザイナーの本音。腕のいいデザイナーは、その辺のディレクションを自分でかけられるため、作る前に依頼主に質問をして、必要な要件決めをしていきますが、デザイナーのディレクションスキルがそこまで達していない場合は、デザイナーがクライアントの求めるものを正確に把握できないまま制作が進むため「デザイナーに頼んだものの、意図したものと少しズレたものが上がってきた」という結果になってしまうのです。

デザイナーに開発の意図を正しく伝えるために必ず決めておくべき5つのポイント

逆に考えれば、デザインに関する要件定義をしっかり擦り合せることさえできれば、意図通りのデザインが仕上がってくる可能性が高くなります。この章では、デザイナーに依頼する際に必ず決めて伝えなければいけないポイントをまとめました。

①依頼するデザインの目的は何か？

デザイナーは「そのデザインが何の目的のために作られるのか？」という部分から逆算してデザインの構成を決めていきます。逆に言えば、目的の存在しないものはデザインできません。まず最初に「今回デザインして欲しいものは、こういった目的のために作って欲しい」という部分を伝えなくてはいけません。

②そのデザインは誰のためのものなのか？

そのデザインを最終的に見て使う、エンドユーザーの「性別や年齢」「どんな考え方、趣味嗜好を持っているのか？」などは、デザインの方向性を決める重要なポイントになります。原宿系の10代〜20代が対象なら「ポップな感じでいこう！」「文字サイズも少し小さめでもある程度は問題ないな」となりますし、60代のシニア世代向けなら「落ち着いた色調を選んだ方がいいな」「文字サイズやボタンなども少し大きめにしよう」となったりします。そのくらい誰のためのデザインなのかという部分は、デザインを定義していく重要な指針になるのです。

③ユーザーにどんな印象を与えたいのか？

デザインは正しく出力された時、非言語の部分でユーザーの印象を操作することすら可能にします。デザイナーは、色調・フォント・余白などの組み合わせから、この組み合わせはこういった印象を与えやすいということを感覚で理解しており、案件によってその組み合わせをうまく調整して、人に与える印象を変えることができます。ただしそれにも、依頼側の「このような印象を与えたい」という意図が必要です。できるだけ具体的に与えたい印象を言語化できるようにしておきましょう。

④優先して伝えたいこと、重要なポイントは何なのか？

複数の内容をデザインの中に組み込む場合には、それぞれの優先順位を明確に決めておくことでより伝わりやすいデザインをデザイナーが作りやすくなります。よく、すべてを主張させたいがために「これも、あれも目立たせて」という指示を受けることがあるのですが、これはデザイン上ではタブーとされています。デザインには、印象の弱い部分と差があるから強い部分が目立つという法則があるからです。すべてを強めてしまうと、すべての強さが同じになり目立たなくなります。強めたいポイントの優先順位はハッキリさせるようにしましょう。

⑤デザインサンプルがあるとより伝わりやすい

作りたいデザインの参考になるようなウェブサイトやサービス、画像などがあれば、似た印象を持つ事例を３つほど用意しておきましょう。言葉で伝えるよりも視覚的に伝えられるので、デザイナーに伝わりやすくなります。参考デザインを伝えたからといってマトモなデザイナーならパクリになることはありません。そのデザインが構成している要素をうまく感じとって今回の案件にマッチするように変換してくれます。

デザイナーにお任せしてしまった方がいいこと

逆に、デザイナーにお任せしてしまった方が良い部分もあります。定義してしまうことでデザイナーの自由度を奪いすぎてしまい、デザイナーのやる気を削いだり、本来もっと良くなった可能性を潰すことになりかねない部分です。知らないうちにデザイン的に不可能な無理難題を言ってデザイナーを困らせてしまうというようなことがないように、ある程度幅をもたせたほうがいいポイントについてご紹介します。

色の組み合わせ

すでにコンセプトカラーの組み合わせが決定している場合を除き、どの色の組み合わせを使うかはデザイナーに一任、または擦り合わせをしながら決めて行ったほうが良いでしょう。色の組み合わせは、ユーザーに与える印象に大きく影響するからです。例えば、落ち着いた印象を与えたいと定義したにもかかわらず、蛍光ピンクを前面に押し出して使って欲しい！なんて言われると、それはデザイン的にちょっと難しいのです。ここはプロに任せて、与えたい印象に即した配色を決めてもらいましょう。前章の「ユーザーにどんな印象を与えたいのか」さえ伝えていれば、ある程度デザイナー側でそれに必要な色の組み合わせを数パターン提示してくれます。コンセプトカラーが既に決まってしまっている案件においては、その色によっては出しにくい印象もあるということを理解した上で、デザイナーと擦り合わせをしていきましょう。

配置・余白

文字の読みやすさ、伝わりやすさ、すっきりと美しく見える感じなどは、どこに何をどのくらいの大きさで配置するか？ など絶妙なバランスで成り立っています。よく余白があると、そこにもっとアレコレもこれもと詰め込みたくなったり、目立たせようと必要以上に要素や文字を大きくしたくなったりしますが、それが本来の与えたい印象とズレることがあります。前章で定義したことと照らし合わせつつ、デザイナーと相談しながら進めるのが良いでしょう。

デザイナーに仕事を依頼する上で気をつけたい注意点

曖昧なまま、依頼を進めない

「デザイナーに開発の意図を正しく伝えるために必ず決めておくべきポイント」で紹介した内容は少なくとも決めておく必要があります。曖昧なまま進めてしまうと、必ずと言っていいほど「意図とは違う」結果となり、作り直しが発生してしまい、工数も費用も多くかかってしまいます。開発がスタートしている時点であれば、ある程度決まっていることと思いますが、もし開発にかかる前段階からデザイナーと協力して進める場合は、まずしっかりとこの部分を決めるところから始めていきましょう。

本番デザインの前にラフ（カンプ）を出してもらう

デザイナーに要件を伝えたら、いきなり本番のデザインを作ってもらうのではなく、ラフ（カンプ）段階で方向性が間違っていないかの擦り合わせをしましょう。極力労力をかけずに作れるラフ（カンプ）の状態での修正であれば、デザイナー側にも負担が少ないため、お互いにとって良い関係で作業を進めていけます。

一度確定させたことを、途中で変更しない。

例えば、ページのトップにこの文言をメインキャッチとして入れてくださいとお願いしたとして、デザインが完成した後にやっぱり変更しようとなったとします。文字を変えるくらいだからすぐできる修正だろうと思われるかもしれませんが、文字数が大幅に変わったり、文字から醸し出されている印象が変わると、その１つの修正のバランスをとるために他の要素も時として修正しなくてはいけなくなるのがデザインです。まだ文字くらいならなんとかなることも多いですが、これがメインカラーやデザインにおいて重要な要素になってくると、１から作り直しになるレベルのことも少なくありません。

非常にわかりやすい説明をしているイラストがあったのでご紹介いたします。

このように、デザインとはすべての必要な要素を絶妙なバランス感覚で、美しくまとまるように積み木を積み上げていくような作業です。ちょっとした変更がデザイナーにとってはとても大変なこともあるということを理解した上で、デザイナーに頼む際には極力変更がない状態で依頼しましょう。それでもどうしても、変更せざるをえないということもあると思います。その際は、変更してもらって当たり前というスタンスではなく「途中で変更になって、申し訳ないんですが」というスタンスでコミュニケーションをとると、良好な関係を続けやすいと思います。

それでもイメージ通りにならない時は

以上のことに気をつけてさえいれば、ある程度のレベルのデザイナーならマッチするデザインを提案してくれますが、デザイナーが個性派だったり、力量不足だったりすると上手くいかないことがあるかもしれません。そんな時は、気になる点に関してこんな質問をしてみてください。

「ここの部分に関しては、どのような意図でデザインされたのですか？」

冒頭で述べた通り、デザインは設計する仕事。必ず、そのデザインになった意図があります。もし、そのデザイナーがちゃんとデザインをしている人なのであれば、自分が出力したデザインに対して、何故このようなデザインにしたのかを理解できるように説明してくれます。それを聞いてあなたが納得するものであれば、そのデザイナーは優秀であるということです。もし、定義したデザインの目的と大幅にズレていたり、意図がない「なんとなく」でデザインされているものだったとすればデザイナーの力量不足です。他のデザイナーにお願いすることも視野に入れたほうが良いかもしれません。

男女で違う？ チームワークとジェンダーの関係性

ビジネスを効果的に進めていくうえでのチームワークの重要性が叫ばれるようになっています。まとめ上手、アイディアマン、ムードメーカー……など、チームには様々な属性を持つメンバーが参加することになりますが、ここでは人間の最も根本的な属性の一つである性別という観点から、チームワークについて考えてみたいと思います。

アフガニスタンでの米軍女性部隊

米国の心理学者であるスーザン・ピンカーは米国海兵隊の「女性エンゲージメントチーム（Female Engagement Team、FET）」の隊員とインタビューしたときの経験を記しています。

インタビューは偶然にも2011年にアルカイダの指導者、オサマ・ビン・ラディンがネイビー・シールズによって殺害されたことが発表された直後に行なわれました。ピンカー氏は、機密的で暴力的な作戦を実行していた（全員が男性である）ネイビー・シールズの部隊と、全員が女性で構成されているFETの働き方の違いを印象的に感じたそうです。FETもまたアフガニスタンの危険な地域に派遣されていましたが、彼女たちがそこで行なっていたのは、アフガン人の市民たちとの絆を築くという任務だったのです。

記事には、男女では集団で働く際に何をモチベーションの源と感じるのかという点で異なっているとあります。

イリノイ州ノースウェスタン大学の社会心理学の准教授であるウェンディ・ガードナーと、レナード・N・スターン・スクールの助教授であるエリザベス・シーリー・ハワードらの研究によると、女性は集団の中にいるときに一対一の関係性を築くことに積極的になるという。それとは対照的に、男性は集団の環境下で相棒を持つが、彼らは集団から、そして、集団の一員であるという自己認識からより多くの満足感を得る。

一対一の関係性を築くことに長けているという女性の特性は、アフガニスタンのような敵意に満ちた環境下でも力を発揮しました。FETと行動を共にしていた衛生兵はこのように発言しています。

あるFETのメンバーは「とても強い関係性を築いたので、私たちが通りを歩いていると、女性や男性、みんなが家から出てきて彼女の名前を呼びました。彼女がそこにいないときでさえ、私たちの姿を見るや否や、彼女に会うためにアメリカに行ってみたいと言っていた」

一方、男性が非社会的で協調性がないというわけではなく、関係性を築くうえで何を重視するのかということが異なっているそうです。ガードナー教授は言います。

「男性と女性は同様に自分の集団に対して惹きつけられ、忠誠心を持ちます。しかし、そのコミットメントの基盤が異なるのです。女性が集団に惹きつけられるには、関係性の繋がりが必要になるのです」

このような観察をもとに、ピンカー氏はチームワークについて、良いチームプレイヤーになるには複数のあり方があるのだと結論付けています。

社会的ジレンマの下では男性がより協調的になる

実際、特定の状況下では、男性のほうが女性よりも協調的になるという研究結果があります。それは、「社会的ジレンマ」と呼ばれる状況下に置かれた場合です。社会的ジレンマとは、集団の中で各個人が合理的な行動を行なうと、集団として最適な結果が得られないという状況を意味します。

具体的な例として銀行の取り付け騒ぎが挙げられます。ある銀行が倒産の危機にあり、預金が引き出せなくなるかもしれないという噂が流れた場合、それが正確な情報なのか否かにかかわらず、それぞれの預金者がとるべき合理的な行動は自分の預金を引き出して自宅の金庫に保管する、あるいは他の銀行に預けるということです。ところが、実際にすべての預金者がこうした行動をとると、実は噂が間違っており、その銀行には潤沢な蓄えがあった場合であっても、銀行は倒産してしまいます（その場合、預金を取り返すことが出来なくなるかもしれません）。

同研究では、このような、個人が自分の利益のための選択を行なうことで、集団として不利益をこうむってしまうという状況下でどれだけ協調的になるのかという点では統計的な男女差は見つかりませんでした。ところが、男性のみの集団にいる男性は、女性だけの集団にいる女性よりも協調的にふるまうという結果が明らかになりました。この理由として、研究者たちは進化の過程に要因があるのではないかと推測しています。

「人類の進化の歴史の中で、男性同士の連携は食べ物や財産などの資源を得るにあたって効果的な戦略であり続けてきた」と、アムステルダム自由大学の研究者、ダニエル・バリエットは言う。「狩猟も戦争も個人と集団の利益が相反する社会的ジレンマである。もし全員が自分の目下の利益に基づいて行動をすると、食料を得ることはできず、戦争には負けてしまう。これらの社会的ジレンマを乗り越えるためには、お互いに強調するという戦略が必要になる」

一方で、古代の女性は同性同士で協力し合う機会が少なかったとされているため、現代でもその影響があるというのです。もちろん、男女の考え方の違いのすべてを進化に帰結させることはできません。社会的に構築されたステレオタイプもまた男女の考え方に対しての影響力を持っているからです。

それが進化によって形成されたのか、あるいは社会的に構成されたのかという議論はあるにせよ、男性と女性はチームワークを行なう際に、それぞれの特徴があるということが分かりました。それでは、どのようにすれば男女で最適なチームワークを行なうことができるのでしょうか。

≫「最高のチームを作るための５つのポイント」はこちら

フンボルト大学で行われた実験

どのようにすれば最適なチームワークを行なうことができるのか、それを明らかにするためにフンボルト大学で実験が行なわれました。この実験では、さまざまな男女の構成からなるチームが、異なる2つのインセンティブ構造の下でゲームを行なった際のパフォーマンスを分析しています。

ゲームは2つのチームで「神経衰弱」のような暗記ゲームのスコアを競います。各チームは2人組で、構成は「男男」、「女女」、「男女」の3種類。勝敗のほかに、チームにはインセンティブ（賞金）が与えられることになっています。インセンティブを与える際の仕組みは2種類あります。

「賞金共有」と呼ばれるシステムでは、各チームのメンバーが獲得したポイントの合計を等分し、2人のメンバーに報酬を支払います。「チーム対抗」と呼ばれるシステムでは、各チームが獲得したポイントを相手チームのポイントと比較し、より多くポイントを獲得しているチームが相手チームから4ポイントを奪い、その合計を等分して2人のメンバーに支払います。相手チームとポイントを競い合うチーム対抗システムのほうが競争的なインセンティブ構造と言えるでしょう。

それぞれのチーム構成、インセンティブ構造で複数回の試合を行なった結果、統計的に有意な結果が出たのは以下の2つの観察です。

観察1：賞金共有システムの下では、同性チーム内での男性と女性のパフォーマンスに有意な差は見られない。しかしながら、混合のチームの中では男性が女性よりも有意に良い結果を出す。

観察2：男性チームと男性チームの対戦および女性チームと女性チームの対戦では、男性が女性より有意に良い結果を出す。この差は男性チームが女性チームと対戦するときにはわずかに有意に異なるにすぎないが、混合チーム同士の対戦では、男性と女性のパフォーマンスに有意な差は見られない。

まとめると、賞金共有システムでは混合チームにいる男性が女性よりも良い結果を出し、チーム対抗システムでは男性チーム同士が対戦した際に男性がより良い結果を出すということが分かりました。つまり、性別とインセンティブ構造の組み合わせによって、男女のパフォーマンスに差が出る場合があるということです。

この研究結果は組織に対して難しい選択を迫ることになります。多くの組織は全体としてのパフォーマンスを向上させるという目標のほかに、男女の平等を実現するという目標を持っています。ところが、全体としてのパフォーマンスが良い「混合チーム＋賞金共有システム」という組み合わせでは、男性のパフォーマンスが女性よりも有意に高くなってしまうのです。

統計的に分析してみても、組織のパフォーマンスを最大化させ、男女のパフォーマンスのギャップを最小化するという理想的なチーム構成とインセンティブ構造の組み合わせが存在しないことが分かりました。それでも、次善のものとしては、「混合チーム＋チーム対抗システム」の組み合わせが挙げられるそうです。この組み合わせではチームのパフォーマンスが最大になる一方で、男女間のパフォーマンスの差は、それがもっとも小さくなる組み合わせ（同性チーム＋賞金共有システム）よりも少し高いだけに抑えられるそうです。

経営者感覚なくしてプロジェクトの目標達成はできない、は本当か？

プロジェクトの目標達成のために必要なものとは何か？

プロジェクト全体を見通し、実行させるために何が必要なのかを想像する力や先を読む計算力は、簡単に身につけることは難しいかもしれません。まずは、自身の苦手分野を把握し、克服できるようにこころがけてみましょう。

想像力を働かせよう

上司から指示を出されさえすれば、たとえ量が多くても、どんな内容のものでも仕事でもきちんと業務ができるのに、自分で物事を決めたり考えることが苦手な人はいませんか？

もし自分が考えることが苦手だと意識できれば、克服できる鍵を手に入れられることでしょう。これからの時代、誰でもできる仕事はAI（人工知能）に取って代わる可能性もあります。指示待ち人間から進化して、自律型の人材を目指しましょう。

いまの自分や仕事の状態を観察して認識し、必要なことや、こうしたら良いと思うことを探して積極的に提案できるようにしましょう。

当事者意識をもって数字を見よう

プロジェクト達成のために必要なことを考えられることができたら、それに必要な数字やさまざまなことを意識できるようにしましょう。

数字といっても、細かな数字が必要な事柄と、ざっくりとした概算を出したいときと計算方法も違ってくることでしょう。出したい数字に必要な情報を調べ、吟味しましょう。プロジェクト達成のために必要な費用について、計算力がない、計算が苦手と感じる人は当事者意識を持つべきです。

会社のお金を使って事業をするのと、自分のお金を使って事業をするのとでは、計算すべき数字にもかなり違いが出てきます。経営者の方はもちろんですが、社員もプロジェクトのために、自分のお金を使うつもりになって計算力を高めましょう。業務に必要で納得のいく数字を出すことにもつながることでしょう。当事者意識を持つことは経営感覚を養うことでもあります。

そもそも経営感覚とはなんでしょうか？

経営感覚の重要性を耳にすることがあります。経営者に必要なのはともかく、企業に雇用されているビジネスパーソンにも必要なものなのでしょうか？

例えば、同じラーメン屋であるのに、流行っている店と、流行っていない店と分かれてしまうのはなぜなのか、そういった好奇心が、経営感覚を身につけるために大事なきっかけのひとつになります。その他、経営感覚に必要なものとはいったい何でしょうか。経営者ではなくても、誰もが簡単に取り入れて身につけられる経営感覚を習得するためには、以下のことに気を配ってみましょう。

顧客を大切にする

当然ですが、顧客がいなければ事業はまわりません。顧客あっての仕事、顧客があってこそのプロジェクトなのです。つねに顧客を引きつけるためには何をすればよいのかということを考えて行動しましょう。

コスト感覚を持つ

経営にコスト感覚が必須なことも言うまでもありません。コスト感覚の有無が会社に危機的状況をもたらしてしまうこともあります。自社製品の原価、単価、付加価値をつけるための経費など、コスト感覚を敏感に持てるようにしましょう。自社製品が売れただけでも満足していてはいけません。自分の給料分ほどの売上の達成率だと、会社は赤字になってしまうのです。売上がどれだけたてば会社に貢献できるのか、それを考えましょう。それも当事者意識を持つことがポイントになってきます。

先を読み、チャレンジ精神を持つ

経営感覚を身につけるためには、チャレンジ精神が求められます。既存のビジネスで常に上向きに営業利益を出し続けることは難しいことは明らかです。常に時代の少し先を見極め、会社や自分自身、事業の成長のために必要なチャレンジすべきこと見つけ実行を続けましょう。

自分が会社の代表！ 会社を代弁できる人材をめざす

これまでご紹介したような当事者意識を持ち、自分自身が、担当している業務や、会社の代表であり、代弁者なのだという意識を持ってみましょう。その意識を持っていれば、さまざまな業務やプロジェクト達成にも大きく貢献できることでしょう。

意識改革でプロジェクト達成をめざそう

上記で紹介したような意識を持ってプロジェクト実行にあたってみましょう。まず、達成目標を決定できたら、現状をくわしく把握し、達成目標を遂行するために必要な具体的な目標設定を行ないましょう。

目標を設定できたら、次はそれを達成するために目標達成前と達成できたときとのギャップを考えて、事前に行動の段取りを行ない、実行していくのです。先のことを考えて段取りを組むことが非常に重要となっていきます。

会社の代弁者という自負を持って、業務を積極的にすすめていきましょう。

経営感覚の有無にプロジェクト達成は左右されるのか

プロジェクトを達成させるためには、創造力や計算力を発揮し、業務を遂行することが求められます。プロジェクトを一人で達成させると力まないで、チーム内でのコミュニケーションをしっかり取りながら、チームの一人ひとりが当事者意識を持って仕事ができたならば、そのチームではプロジェクトを成功させられる可能性が高まります。

最後に、具体的な事例を振り返ってみましょう。

大手医薬品会社R社の事例

大手の医薬品会社R社は商品展開にともない、商品の販売先が比率において国内と国外がほぼ同等になりました。商品が先行する形でグローバル化が加速したため、グローバルな流れに対応できるリーダー育成が急務となりました。そのため、社内にて、グローバルリーダー育成のために、2つのコースを設けることになりました。若手管理職向けのコースと、35歳以下で、管理職ではないが課長代理・主任といったリーダークラスの人材を対象としたコースです。

年に数回、または数週、実務に即したビジネスのフレームワークのセッションや、ビジネス上の経営課題を精査し、トップに提案を行なったり、経営理念・リーダーシップの理解、360度評価の実施、個人リーダーシップの開発、などをコースで行なっています。

このコースに参加することで、参加者は通常業務上では接点のない社員とつながり、能力を知り、業務発展に役立てたりと、実際の業務に役立つセッションを行なうことができます。幹部候補生同士の実力を知り、知識や経験を深めるよい機会にもなります。

このような研修体験を通じて、実際の経営感覚を身につけることができ、プロジェクト拡大に活きているようです。
（参考URL https://jinjibu.jp/article/detl/manage/1184/2/）

国産CMSとして強固なファンたちを築き上げたa-blog cmsのこだわりは

CMSという言葉を始めて使うようになったのは、2000年を過ぎてからのことかと記憶しています。
CMSとは、Contents Management Systemの略で、日本語では「コンテンツ管理システム」。 いわゆる、管理画面からテキストや画像を入力できHTMLを編集することなくWebサイト（ホームページ）が更新できるシステムを言います。
山本さんは、a-blog cmsを提供する有限会社アップルップルの代表取締役で、このCMSの生みの親でいらっしゃいます。
「私より長い間CMSをやっている人はいないでしょうね」とさらっと言葉にされましたが、強固なファンを持つ国産CMSの開発について、またその経緯を含めお話を伺いました。

a-blog cms〜 Web上でサイトを更新する仕組みを作り続けてはや20数年

国産CMSとして多くのユーザーを抱えられていること。また、サービスを持続している強さということを御社のサービスからいつも感じていまして、今日はそのあたりの秘密も伺えたらと思ってきました。

はい、何かお役に立てることがお話できればよいのですが

まずは、a-blogというサービスのこれまでの経緯をお聞かせください

実はよく勘違いされていることがありまして、a-blogというサービスとa-blog cmsというサービスはまったく別のものなんですね。2004年から2009年まで、CMSのシェアNo.1が WordPressではなく、 Movable Typeのころにa-blogという製品を開発し、私がプログラムを書いていました。a-blog cmsというのは、名前は継承していますが、a-blogのコードは1行も使われていません。「Web上で簡単にサイトを更新できる」という機能を特化して、開発当時からオリジナルなことにこだわって開発をアップデートしてきています。

その、サイトを更新するための開発ということはなにがきっかけだったのですか？

もともと私はCOBOLのプログラマーでした。あるSIerに新卒入社しエンジニアになりました。その当時はインターネットはありません。その後、プロバイダーがたくさん誕生し、あるプロバイダーに転職し、5年程度勤めました。まさにそのころから、Webサイトの更新を簡単にするためのプログラムを書き始めたのです。

a-blogという名称の前には、a-nikkiやa-Newsというプログラムがありました。そもそも「ブログ」というものがなかった時代から作っていますからね、当時のネットサービスはネットに「日記」を書くという伝え方から私の考えるサービスを認識していただくという感じだったと思います。
ちなみに、それらのプログラムはPerlのCGIです。
※ a-nikkiの初公開は、2000年の10月28日

それが、a-blog cmsになっていくのは？

ちょうどいまのWordPressがまさに同様の使われ方をしていると思うのですが、ブログのためのソフトウェアだけど、ブログ以外のこともやれるようにしたいという要求が強くなったからですね。制作者が作りやすいもの、そして、利用者が使いやすいシステムするべく、何度も作り直して現在のシステムになりました。

ところで、2018年はこのWordPressもMovable TypeもUIが大きく変わると予想されています。ご存知ですか？

それは知りませんでした。なにが起こっているのでしょう？

「書く」ことに特化したサービスがいくつか人気を呼んでいます。国内ではnote、海外のものだとmediumというサービスがあります。これらに特徴的なのが、いわゆるWYSIWYGではなく、真っ白な画面に自分の好きなように書いていけるUIデザイン。WordPressは、Gutenberg（グーテンベルグ）という新エディターが用意されているそうです。

「ブロックタイプCMS」と呼ばれますが、要素という単位でブロックを画面に置いて、そのブロックごとに文字を入力、あるいは画像を貼り付けるなどというスタイルに変わるんですよ。実は、この方法はa-blogの前のa-Newsの頃から早々に実現していたので、その点では時代が追いついてきたかなんて思っています。

a-blog cms 開発のスタイルとは

では、開発のスタイルについてのお話をお願いします

だいそれた開発体制があるわけじゃないので、恐れ多いのですが、現在はエンジニアが２人で開発しています。そのマネージを私が行なっているという体制ですね。a-blog cmsもすでに８年経ってまして、当初はエンジニア一人で開発していました。最初のエンジニアは既にいなくなってて、現体制は３代目エンジニアです。

彼が一通りやりつつ、フロントエンドをメインにやるエンジニアがいる。また、弊社はCMSを作るだけじゃなくて、受託の制作もやっているので、それをすることもあります。
テーマの開発なども自社内でやっていますから、デザイナーも携わっているので、社員全員がこのプロジェクトメンバーですね。

プロジェクト管理という視点で語ると、どのようになりますか？

CMSのことについてはCTOに任せて、自由にやってもらっています。

ツールはなにをお使いですか？

JIRAを使っています。バージョン管理ではBitbucketを使っています。かつてはBacklogを使っていた時期もあったのですが、現在では、受託もすべてJIRAを使っています。

JIRAを使い始めたきっかけはどのようなものですか？

そうですね、GitHubからBitbucketに移行したタイミングで、BitbucketをやっているAtlassianがJIRAというツールもやっているというところからでした。

なるほど。あくまでBitbucketとの連携をさせるということが前提だったと

そうですね。そのあたり一連のことをきちんとやろうとすると、非常に整っている環境だと思いました。

少しお話がずれるのかもしれませんが、ツールということでいま一番困っているのは、時間管理です。どれだけの時間でそのタスクをしているのかという計測をするサービスがあるじゃないですか。そういったものを積極的に使っていきたいと思っているのですが、当社は開発をしながら受託もやっているので、急に電話がかかってきて、そのサポートをしなければならなくなることも多々あります。

結局、時間管理をしていても、すぐに別の作業に移ってしまい、設定を切り替えて時間を記録することが非常に難しい。そこを何とかしたいと思っています。

なるほど。タイムトラッキングのツールには何をお使いになりましたか？

TimeCrowd、Togglの2つを使おうとしていました。

続かない、ということがタイムトラッキングの一番の問題ですからね。マルチタスク作業ということも、他社でも悩まれていると伺いますよ

オープンソースに取り組み始めたのが、最近の大きな転換

プロジェクト管理で工夫されていること、御社独自のやり方は何かありますか？

a-blog cmsはオープンソースではなく、クローズド・ソフトウェアです。世の中の流れからみても、少しずつオープンソースを考えていかなければならないので、最近ではJavaScript系のライブラリなどをオープンソースで作るように転換をしました。

CMSで使うものを、まずはオープンソースのライブラリとして世の中に公開するわけです。初めはCMSで使ったものをオープンソースで公開しようというつもりでした。が、だんだん逆転してきて、いまでは「こういうものが欲しいよね」と意見が出たら、まずオープンソースで外部でも使えるライブラリを作っています。それをCMSに取り込んでいく。世の中に出して、世の中にもんでもらっていい感じになってから、うちの中に戻すというような開発フロー体制ですね。

それと、基本的にPHPでクローズなのですが、JavaScriptについてはオープンソースにしています。GitHubのランキングをベンチマークしています。

いま現在、JavaScriptではGitHubのスター数が昨年末に、名古屋で1位、日本で27位になりました。a-table.jsというプログラムはテーブルのHTMLを書くためのライブラリですが、Movable Type 7 Developer Previewにも採用されました。

すばらしいですね！

誰もが使うものではありませんから、星の数は少ないのですが。

a-blog cmsという製品がオープンソースになることはないと思うのですが、できるだけ、出せるものは出していく、と。現在は暗号化されて見えない部分も多いのですが、いま現在は既に半分くらいのソースコードは公開している状態になっています。徐々に公開を進める方向に動いていますね。

ユーザーコミュニティを大事にしたい

a-blog cmsには多くのファンがいますよね。ユーザーとのコミュニケーションと開発の仕組みで、何か工夫されていることはありますか？ 例えば、ユーザーからの声を吸い上げて、開発に活かすといったような

毎年5月と11月に日本中からユーザーを集めたイベントを行なっています。そのイベントに合わせて、完成していなくても何か見せられるものを用意して、そこでいろいろな人からの声を聞くことで、それを実装しています。うちは制作会社でもあるので、うちの社内でほしいものはみんなも欲しいのではないかと考えています。うちはシステムだけを作っている会社ではないので、実際に我々が使っている武器を皆さまにもお渡ししているという感じです。

ついでに、一言。昨年の11月のイベントで、年末から年始までには次期バージョンをリリースすると伝えたのですが、結局まだできていないのが目下の悩みです。2月中にはリリースすると決めましたので、ここできちんと発表しておきます。

オンライン上のコミュニティの運用は、現状は行なっていないということでしょうか？

有償でサポートしているパートナーさんたちだけのFacebookグループがありますが、そこに参加している人はほとんどイベントにもいらしている人になります。イベントは平日に行なっているので、仕事で本当に使っていただいている人たちに来ていただいていると思います。

全国あちこちで使われていると思うのですが、特にここのエリアで強い、といった地域はありますか？

日本全国、いろいろなところで勉強会をやっていて、その後、勉強会を行なった地域で利用者が増えてくる状況ではあります。東京・大阪・名古屋で多く使われていますが、他には北九州や、香川、福井なども多く使われています。

展望

次期バージョンのリリースが2月とのことですが、a-blog cmsがこれからどうなっていくのか、さらにこれからの開発上の取組みについてお聞きできればと思います

次のバージョンは外部APIとの連携の機能をしっかりと作っていきたいです。システムの中だけで全部やろうとしても難しい部分が出てくますからね。

お問い合わせフォームから、Google スプレッドシートへの書き出しがオリジナルのデザインを加えた状態でできるようにしたりとか。さらにCRMとの連携、メルマガのシステムとの連携などを考えています。

内部的には、より使いやすいテンプレートエンジンを加えていきます。新しいものができたとしても、古い書き方をサポートして、より効率的にできるようにするということを考えています。あとは、MTのように静的書き出しを実装します。

毎回新しいバージョンを出すたびに、これだけあればもう何もいらないだろうと思いながらも、やっぱりリリースされると次にやらないといけないことが出てきますね。

プロジェクト管理というものを、ソース管理、タスク管理、コミュニケーション（メッセージング）と分解すると、メッセージングには何を使っていますか？ Slack一択ですか？

社内ではそうですね。ですが、クライアントとのやり取りでSlackを使うことはまだまだ難しいです。場合によっては外部と一緒に仕事をするときには、社内的にもChatWorkを使ったりすることもありますね。

メールを使うこともありますか？

社外とのやり取りは、まだまだメールが多いですが、社内のコミュニケーションにメールを使うことはなくなりました。先ほどお話しした外部連携機能についても、新しいお問い合わせなどのメッセージを、メールではなくてChatWorkとSlackに送信する機能を実装する予定です。

そのメッセージングは重要ですね。社内的なソース管理はBitbucket一択ですか？

クローズドの部分はBitbucketで、オープンソースはGitHubにしています。

お話を伺ってると、とにかく継続することの強さを感じます

個人的には、私より長くCMSに取り組んでいる人はいないだろうという自信もあります。が、ただやめられない、というのも真実です。

エンジニアの人たちに向けて、何か一言

今年は新しい試みとして、ブースを出すようなイベントを行なうことを考えています。コンテンツとコンテンツマネジメントシステムというくくりで、名古屋で1日開催することを企画しています。

それもまた新しいチャレンジなんですね。本日はありがとうございました

取材を終えて

CMSというのも、もともとは「日記」から始まった、という少し前のインターネットの動きのお話はとても興味深いものでした。私はもともと2000年にこのIT分野に参入した人間なので、一部知らない世界の物語となっていたかもしれません。
それにしても、20年近いサービス提供期間という事実には感嘆せざるをえません。無料ユーザーではなく、有料サービスでいらっしゃるのですから。素晴らしいサービスを作られているな、と大いに勉強になりました。

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

労働時間を短くすることで日本の生産性の問題は解決するのか｜働き方改革

日本の戦後、1960年代〜80年代の高度成長期がもたらした大きな成功は、長時間労働を積極的に勧める滅私奉公的に支える働き方と、年功序列の厳格な階層構造によってなし得たものでした。武士のような存在からも考えられるように、日本人は一度お上と決めた人物に対して、盲目的なほどの忠誠心を持ちながら仁義を切って時代を生きてきた民族です。

成功を収めて世界的にも有名となった経営者たちの自伝を読んでみても、寝る間も惜しんで死ぬ気で働き、仕事以外のことは妻に丸投げしながら成功を手にしていることを読んで取れます。日本文化の深いところで、お上に仕え、長時間労働を奨励してしまう感情が存在しているのです。

しかし、そのような働き方は、いつの間にか時代遅れとなってしまいました。現在では長時間労働を強要する会社はブラック企業と呼ばれ、企業の口コミサイトにマイナス評価を書き付けられてしまう時代になりました。少子高齢化で働き手が減っていくなかで、企業は働きやすさをもっと追求しアピールし続けないと、よい働き手をキープできなくなってくるのです。

ネガティブなニュースが多い日本

日本人は、長時間労働の弊害にもっと早く気づくべきでした。うら若くかわいらしい女性が働く環境に絶望し、自死を選んでしまう、そんなニュースが流れる世の中にいったい誰がしたのでしょうか。ネットでさまざまな記事を読んでみても、育児について見てみれば、夫や周囲のママ友の愚痴がたくさん。周りの理解が少ない中、もがきながらも頑張るママの姿が見て取れます。仕事について見てみれば、上司にセクハラやパワハラをされた、会社でとんでもないことが誰も指摘されず横行してきた、といった記事が沢山でてくるのです。

本来であれば、戦争や民族間の紛争もなく、経済的にも豊かであり、識字率も高く、お財布や携帯を落としても戻ってくる平和な日本は、世界でも幸せ度が高い有数の国であるはずなのです。にもかかわらず、ネットやテレビではネガティブな話題ばかり、いったいどうしてなのでしょうか。

このままでは日本人の自尊心があぶない

私が考えるには、私たち日本人が潜在的に持っている、会社に忠誠心を持つ仕事第一主義が、日本人の生活や自尊心を締めつけ続けていることに一因があるのではないかと感じます。高度成長期の長時間労働をよしとする風潮が、家族に家庭をないがしろにされたという被害意識を抱かせ、子供に親は子供よりも仕事のほうが大事であると思わせ、そして仕事をする働き手自身にとっても、仕事以外のことに重点を置くことへの罪悪感を覚えさせてしまう。

そのような構造のまま、この時代をむかえてしまったように考えます。

終身雇用という体制の問題

日本では長らく終身雇用が採用されてきました。この雇用方法は、働き手を会社に取り込むものであり、欧米諸国のように、仕事によって会社に雇用されるのとは異なる雇用システムです。終身雇用の場合、会社に雇用されている限り働き続けることができる反面、畑違いの部署移動を命じられれば、それを受けて、仕事を遂行することになります。

部署や社内の配置転換などで、ひんぱんに異動が発生すれば、その都度新しい業務をこなす必要が出てきます。部署替えや配置転換、昇進などで仕事内容が変わってしまうと、新しい仕事を覚えてこなしていく力が必要となってしまいます。結果として仕事をするスピードを高めるための経験を十分に積めないため、長時間労働につながっています。

長年仕事内容を変えずに同じことをしていれば、仕事のスピードアップは可能であり、生産性向上についても追求が容易くなるはずです。しかし、働き手が会社に雇用されているというシステムでは、本人がキャリア内容について確固たる線引きができる人材でない限り、会社の事業内容に人を合わせていかざるを得ない状況になってしまいます。

生産性の低い日本

日本における生産性についての統計を見てみると、

OECD(経済協力開発機構)加盟国(EU加盟国22か国、そのほか13カ国の計35カ国)のなかでも、日本の時間当たりの労働生産性は46.0ドルで、OECD加盟35ヵ国中20位。主要先進7カ国でみると、データが取得可能な1970年以降、最下位の状況が続いている。

（http://www.jpc-net.jp/intl_comparison/より）
とあります。高齢化と人口の減少に伴って、日本の経済成長への唯一の希望は、生産性の向上が鍵をにぎっています。

第２次安倍政権も、2016年8月から働き方改革というスローガンをかかげ、ようやく時間外労働の削減、ワークライフバランスの改善、女性と高齢労働者のスキルの向上などをうたい、諸処の問題を改善させていこうとしているようですが、なかなか結果が出ていません。月末の金曜に仕事を早く終え、帰宅時間を早めるプレミアム・フライデーの試みは、ロゴを作って有名企業に採用させたりとさまざまな施策がはかられていますが、なかなか浸透していません。

人ごとではない働き方改革をすすめよう

今後、日本社会には、効果的なワークスタイルの改革が必要であると考えられます。そのためには、日本の働き方の根本から見直しと、多様性についての認識を広めることが重要です。企業は、生産性を向上させるための技術にもっと投資を行なうべきでしょう。また、雇用に関する法的基盤を時代にあったものへと変更し、仕事のスタイルを大きく変えていけるように政府は、より具体的に労働規制を検討していくべきだと感じます。

多くの働き手は、働き方改革について、非常に懐疑的で人ごとのように感じていることでしょう。メディアや他の企業からそのニュースや取り組みについて聞いたことはあっても、自社では何も進んでいないという人が多いようです。
働き方を本当に変えていくためには、日本企業は長時間労働のわりに生産性が低いという事実をもっと直視すべきです。なぜ長時間労働が横行してきてしまったのか、必要以上に美しすぎる書類作成、執拗なまでの厳しい管理体制などなど……。部外者から見ればあきらかに問題であることを指摘し、改善できるコミュニケーション、体制づくりが必要でしょう。

少しづつ増えてきた時短正社員の流れ

多種多様な働き方を推奨し、生産性をあげて勤務時間を減らしてプライベートへの時間をとれるようにできるための取り組みとして、企業も少しずつ取り組みを進めているようです。たとえば大手商社の丸紅では、会社・社員双方が、キャリアの段階や、ライフステージに応じて働く環境を整えて、中長期的にみたときの社員ひとりひとりの「会社への貢献」を最大化することを目指し、ワーク・ライフバランスを推進しています。

すなわち、妊娠出産、子育て、介護などといった、個人生活におけるライフステージの変化によって退職をする社員を減らし、そのかわり長いスパンで会社に貢献することをすすめるということです。具体的な施策としては下記のとおりです。

・短時間勤務を選ぶ場合、育児・介護を事由に取得することが可能であり、育児の場合は子が小学校4年生6月末まで、介護の場合は介護事由が存在する限り取得可能。
・1日2時間までの遅刻、早退、勤務中断（中抜け）を認める。家族との役割分担や仕事の状況に応じ、利用日や利用時間をフレキシブルに変更できる。
・2010年に育児・介護関連制度の改訂を行い、短時間勤務に加え、時差勤務の仕組みを導入。1日1時間まで、15分単位で始業時刻を繰り上げ/下げできる制度。1日1時間までであれば短時間勤務を併用することも可能。
・短時間勤務を育児目的で長期間取得する場合、子どもの成長に応じて勤務時間を見直すことを促している。復職時に短時間勤務を利用し、時差勤務に切り替え、通常勤務に戻るといったパターンをとる社員も増えている。

厚生労働省 短時間正社員制度導入ナビより抜粋

ほかにも、同様の短時間正社員制度導入をすすめる企業も増えてきています。
このような情報をもっと政府は取り上げていくべきではないでしょうか。その結果、追随する企業や取り組みも増えていくことができると考えます。

他にも、時短であるが正社員なみの時給に特化した求人サイトサービスも増えてきています。確実に、長時間労働だけにとらわれない正社員、働き方の多様性を理解し推進していく時代へと流れができつつあるのです。