「知識ゼロから学ぶソフトウェアテスト」でテストの基本を学ぶ

ソフトウェア開発において切っても切り離すことのできないのが不具合（バグ）。そして、そのバグと表裏一体な存在がテスト。プロジェクトマネジメントをするうえで、テストを適切に工程へ組み込むことは非常に重要なことですが、PMがテストの中身を全く把握していないのは良くないと思い、「知識ゼロから学ぶソフトウェアテスト」を読んでみました。この本、本当に知識ゼロでも読むことができるのでお薦めです。 

知識ゼロから学ぶソフトウェアテスト 【改訂版】

ソフトウェアテストの実力診断

この本は「完全無欠なソフトウェアテストは可能か？」という問いかけから始まります。そして、いかに完全なソフトウェアテストが難しいものであるかを示すために下記の演習問題が出題されます。

このプログラムでは、ユ ーザーが三つの整数を入力します。この三つの値は 、それぞれ三角形の3辺の長さを表すものとします 。プログラムは、三角形が不等辺三角形 、二等辺三角形 、正三角形のうちのどれであるかを決めるメッセ ージを印字します 。このプログラムをテストするのに十分と思われる一連のテストケースを書いてください。

いかがでしょうか。テストケースのイメージ、湧きますか？僕もこの問題にチャレンジしてみたので、参考まで三角形の判定プログラムとそのテストコードを貼っておきます。※Node.jsのMochaとChaiで書きました。

どう思いますか？これで適切にテストパターンの洗い出しが出来ていると思いますか？...残念ながら答えは「いいえ」です。例えば、僕が書いたコードだと"0, 0, 0"とユーザーが入力した場合でも、正三角形と判定されてしまいます。これは正しい挙動とは言えません。

こうして実際に自分でやってみるとテスト設計の難しさがよくわかります。やはり専任の経験あるテスト担当者がいなければ、品質を担保して製品をリリースすることは難しいでしょう。

では、次に実際にどのようなテストが行われるべきなのかを見てみたいと思います。

ブラックボックステスト

ブラックボックステストは、プログラムを一種のブラックボックスと見立て、さまざまな入力を行うことによって、ソースコードを利用せず（見ずに）行う、というものです。本によれば、現在のソフトウェアテストの大半はこの手法が使用されているとのこと。さっそく詳細を見てみましょう。

同値分割法と境界値分析法

同値分割法

同値分割法は大きく次のような手順で進んでいきます。

1. 同値分割
2. 有効同値、無効同値に分類
3. テストケースを書く

同値分割とは、入力領域をいくつかのクラスに分けて、そのクラスの中の値は同値とみなす行為です。先ほどの三角形判定プログラムのUIが、ユーザーが任意の値を自由に入力できるフォームであると仮定すると、「数字」「文字」「記号」というようにクラス分けできると思います。

次に、有効同値と無効同値ですが、システム仕様から見て、有効な値か無効な値かという意味です。三角形判定プログラムでは、三つの整数が求められている値ですから、有効同値が「数字」、無効同値が「文字」「記号」ということになります。

最後にテストケースを書いていきます。三角形判定プログラムは、入力値が三つの整数だけで、無効同値も2種類しかありませんので、全ての有効同値と無効同値の組み合わせの強固なテストケースが書けると思います。しかし、実際のプログラムでは、無効同値の数や組み合わせ数が多く、テストケースを作ることが困難なこともあります。その場合は、テストケースを省略せざるを得ませんが、だからと言ってバグが起きても良いわけではありません。ちなみに、僕が書いた三角形判定プログラムでは「あ、あ、あ」と入力しても正三角形と出力されます。苦笑

境界値分析法

境界値分析法は、入力領域の境界に焦点を置いてテストを行う手法です。三角形判定プログラムでは、そもそも仕様が「三つの整数」としてあるのが問題でもあるので、整数の境界に焦点を置くのはあまり良いアイディアではありません。ここは三角形が成り立つ数値か？というところに視点を切り替えるべきでしょう。そうすると、入力領域は整数の中の「正の数（1以上の数値）」となります。

では、正の数の境界はどこか考えてみましょう。下の境界は簡単ですね。0以下は正の数ではなくなります。一方、上の境界はどうでしょうか。正の数に上限はありませんので、数値はどこまでも大きくなります。しかし、システム的に処理できる数値には上限があります（JavaScriptの場合は 2^53 - 1）。なので、仕様ではどこかに上限を設定しておくべきだと思います。

実際のテストでは、異なる処理が行われる一番近い2地点を用います。三角形判定プログラムの下の境界で言うと、「0」と「1」です。この境界値分析法と同値分割法を組み合わせることで、効果的かつ効率的にテストケースを作ることができます。

ディシジョンテーブル

ディシジョンデーブルは、すべての入力の組み合わせとそれに対する出力を表にまとめたものです。三角形判定プログラムでは、数値によって、「正三角形」「二等辺三角形」「不等辺三角形」と出力結果が変わります。組み合わせの複雑になるので、それらを表に可視化することで、漏れを防ぐことができます。基本のアイディアは同値分割法・境界値分析法と同じですが、多数の入出力をチェックするときに有効な手段となります。

自分の書いたコードでやってみました。本プログラムでは、各三角形ごとの組み合わせの入力値を書いてまとめた方がわかりやすいかなと思いました。本では、状態は「TRUE」「FALSE」だけの記載でしたが、実態に合わせて臨機応変にしても良いと思います。しかしまあ散々な結果ですね。ひどい。苦笑

状態遷移テスト

状態遷移テストは、状態によって出力結果が変わる場合に用いられるテストです。どういうイベントのときに、どのように状態が遷移するかを一覧にし、各遷移をチェックしていくというものですが、この三角形判定プログラムの例では説明できそうにありません。詳細は下の記事がよくまとまっているので参考にしてください。

ランダムテスト（モンキーテスト）

これはランダムにソフトウェアを操作し、バグを洗い出すテストです。著者はこの手法に関しては、批判的な意見を持っているようで、推奨していませんでした。テスト設計の必要もないし、一定数のバグは見つかるだろうが、バグはランダムテストでは見つからないところにまだまだ潜んでいると。

以上がブラックボックステストの手法として紹介されているものでした。ソフトウェアの複雑さにもよりますが、「同値分割と境界値分析 → ディシジョンテーブル → 状態遷移テスト」は、どのソフトウェアにおいても最低限実施すべきものだと思います。ランダムテストについては、個人的にはそこにテスターの労力を割くのであれば、別のテストを実施した方が良いと思いますね。

まとめ

本では、ブラックボックステスト以外にも「探索テスト」「非機能テスト」「セキュリティテスト」などの重要なものが説明されています（詳細はぜひ本をお読みください）。月並みな感想ですが、テストの奥深さと難しさに驚きました。プログラムを書くこと以上にテストを作ることの方が難しいのではと思ったぐらいです。品質要求を満たしたプロダクト、不具合のないプロダクトを出すために必要な労力を改めて認識し、今後のプロジェクトマネジメントに活かしていきたいと思います。

知識ゼロから学ぶソフトウェアテスト 【改訂版】

マイヒーロー、イチロー

イチローの試合を観戦するために、シアトルのセイフコ・フィールドに行ってきました。が、残念ながらイチローのプレーを観ることはできませんでした。ご存知の通り、5月4日にイチローは球団の特別アドバイザーに就任し、今シーズンはもう試合に出場しないという報道が出ています。僕がチケットを取ったのは4月16日だったので、タッチの差で間に合いませんでした。僕のことをよく知る人は「あれ？そんなに野球が好きだったっけ？」と思うかもしれません。実際、野球がそこまで好きというわけではありません。ただイチローが好きでした。セイフコ・フィールドに行ってきて、高まった気持ちを胸に盛大にポエらせて頂ければと思います。

あいにくの曇り。それでも美しいセイフコ・フィールド

イチローとの出会い

そもそも野球を見ない僕は、日本でのイチローをあまり知りません。パワプロで「サクセスじゃないのにオールAに近い選手がいる」と思っていた程度です。むしろイチローは扱いづらいキャラでした。ミートが広くてパワーが中途半端にあると打ち損じが出やすいというの僕の自論です。ヒット狙いの選手はミートC、パワーCぐらいがちょうど良い。...話を戻します。

僕がイチローの試合を初めて見たのは、メジャー移籍後のオールスターゲームでした。当時の僕は中学校3年生。試合は学校の時間でしたが、野球部の同級生が「先生、お願い！イチローの打席だけ見せて！」と懇願しました。「第一打席だけだぞ」と返す先生。いま思うとこの先生も見たくて堪らなかったに違いありません（ちなみに野球部の顧問の先生でした）。そして、僕たちはイチローがランディー・ジョンソンから内野安打を打つところを目撃したのです。

イチローに興味を持つ

それから3年後、イチローはメジャーリーグの年間最多安打記録を塗り替えようとしていました。当時の僕は高校3年生。学校へ行く前にテレビを見ていたのですが、イチローのニュースは毎日取り上げられていました。しかし、はっきり言って、僕は無理だと思っていました。たしか夏休みの終わった9月中頃に、イチローは一度無安打をやってしまいます。その時、ニュースのレポーターも「これで残り◯試合で◯本、1日◯本のペースでヒットを打たないといけません。厳しくなってきました。（※はっきりと数字を覚えていないが15試合で20本ぐらいの厳しい数字だったはず）」と話していたのを覚えています。ところがどっこい、その後イチローは5打数5安打, 6打数4安打とヒットを量産して逆境をひっくり返してしまうのでした。

そしてその瞬間へ。もうね、映画ですよね、これ。鳴り止まない歓声と拍手、駆け寄るチームメイト、前記録保持者のジョージ・シスラーの娘との握手、まるでひとつのショーを見ているようです。

イチローのファンへ

僕は2004年の記録達成をきっかけにイチローのファンになったわけではありません。 ファンになるのはそれから3年ほど経ってからのこと。当時の僕は成人して、社会人になっていました。仕事は個人宅への外回りの営業職、簡単な仕事ではありませんでした。「いま天ぷら揚げているから結構です！」何度こう断られたことでしょう。「マジでこの断り文句が使われるのか」などと思いながら、毎日16時〜21時の間は外回りをしていました。

夏は暑いし冬は寒い。業務の過酷さに加えて、なかなかのブラック企業だったので、酷いときは2ヶ月間休みがないときもありました。仕事の調子の良いときは、稼げせてそれなりに楽しい仕事でしたが、調子の悪いときはかなり辛いものでした。1日誰にも話すら聞いてもらえず、インターホンで断られ続け、会社に戻ると上司に激詰めされる。「売れるまで帰って来るな！」と、電話で突き放される日もありました。そんな職場だったので、モチベーションをいかに管理するかは多くの社員の共有の悩みでした。

「トッキー、良い本があるよ。」

そう声をかけてくれて、とある人に手渡されたのが、イチロー 262のメッセージという本です。

イチロー 262のメッセージ

この本にはイチローがメジャーデビューから4年の間にした発言が抜粋して載せられています。特になにか解説があるわけでもなく、ただ淡々とイチローの発言が紹介されているだけなのですが、これが妙に心に刺さりました。一部を引用して紹介します。

こんなに苦しいのは自分だけか、と思うこともあります。それを見せるか見せないかだけの話です。みなさん、ぼくのことは、疲れていないと思っていませんか？

ぼくも、グラウンドに行きたくない日はたくさんあるのです。そのときには職業意識が出てきます。「仕事だからしょうがない」と、自分に言い聞かせるときもあるのです

グラウンドの上では、自分の築きあげてきた技術に対する自信、今までやってきたことに対する自信、「やりたい」と思う強い気持ちが、支えになります

僕はこの本を読むまで、イチローがこんなに苦しみながら野球をしているとは考えたこともありませんでした。メンタルをコントロールし、高いプロフェッショナル意識をもって野球と向き合うイチロー。一気にイチローのファンになりました。

それから毎日イチローのニュースを追いかけました。勝手にイチローをライバル視して、イチローがヒット2本なら、僕も2契約を取るまで頑張ろうと、仕事の目標にしたりもしました。他にも、mixiのイチローコミュニティで実況しながら試合を見たり、「Road to 4256」というトピックでイチローのヒットを皆でカウントしたりとか。ちなみに、4256とはピート・ローズが残した通算安打数のMLB記録です。当時カウントしているときは遥か先の夢のような数字でしたが、本当に達成してしまうイチローは本当に凄いです。

仕事の営業の数字に追われていた日々の中で、イチローの安打数という他に意識を置く数字ができたことは本当に救いでした。また、イチローの野球への姿勢を少しでも見習おうと心がけて仕事をすることで、自分の中にも徐々にプロフェッショナル意識が生まれてきたように思います。職業人の理想像であり続けてくれたイチローには感謝しかありません。

最後に

特別アドバイザーに就任して試合にはもう出場しないということから、事実上の引退という声も出ています。マリナーズとの契約としては、来季試合に出場する可能性は残した内容になっているそうですが、僕も来年になって第一線へ復帰するのは難しいと言わざるをえないと思います。しかし、イチローは常々50歳までプレーしたいと公言していますし、チームに帯同しての練習は続けていくそうです。現在44歳のイチロー、今後どうなっていくのか、何をしていくのか、まだまだ目が離せません。最後の最後までイチローを応援していきたいと思います。ありがとう、イチロー！

All the feels.

💚 💙 #ThankYouIchiro pic.twitter.com/U5fQAx1uWW

— MLB (@MLB) 2018年5月3日

おまけ

オバマ前大統領がイチローの話をしているこのシーンがとても好き。

I talked to Ichiro and I said, now, how exactly do you throw that ball from in the outfield to home plate like a laser? He said, "Soft muscle." He said, "You don't need to be big." it was a very zen-like answer. He's an impressive guy.

レーザービームのような送球をどうやって投げるのか？というオバマの問いに対して、「ソフトマッスルです。大きな筋肉は必要ありません。」と答えたイチロー。オバマはそれを”まるで禅のような答え”とコメントしています。オバマにさえ認められるイチロー、素敵すぎる。

後、イチロー 262のメッセージ、イチローが好きな人には本当お薦めです。 未読の方はぜひどうぞ。

イチロー 262のメッセージ

未来をかえる イチロー 262のNextメッセージ

自己を変革する イチロー262のメッセージ

ムダ・ムラ・ムリを取り除け！トヨタ生産方式に学ぶプロジェクトマネジメント

前回のエントリーで、プロジェクトの遂行能力を上げるには、組織の体制や行動習慣を向上させる必要があるということを書きました。組織の行動習慣と言えば、やはりトヨタ。車の製造は、ITの世界と勝手が違っていても、モノづくりの現場から学ぶことは多くあるはずです。特に、何かを大量に作らなければいけないプロジェクトでは、特定の技術力だけではなく、大量生産に耐えられるノウハウが重要です。ということで、「トヨタ 仕事の基本大全」という本を読んでみました。

トヨタ 仕事の基本大全

大量生産型モノづくりの指針「ムダ・ムラ・ムリを取り除く」

IT業界は大量生産とは無縁なのではと思うかもしれませんが、実はそうでもありません。自分の過去の業務を振り返っても、SEO対策をしていたときはブログの記事を、教材開発をしていたときは問題や例文を大量に制作していました。

一つのモノの品質を追求するには職人の技が必要ですが、何万個のモノを同じ品質で提供するにはシステマチックなマネジメントが必要です。トヨタは年間で一千万台以上の車を製造していますが、いずれも高い品質を保っており、高度な技術力と生産方式を兼ね合わせた素晴らしい企業だと思います。

そのトヨタで推奨されているのが「 ムダ・ムラ・ムリを取り除く」ということ。プロジェクトマネジメントの本質は時間・コスト・品質をマネジメントすることですが、このムダ・ムラ・ムリはそれらに密接に関わっています。

 ムダ

「トヨタ 仕事の基本大全」によると、ムダは次のように定義されています。

トヨタでは、ムダを「付加価値を高めない現象や結果」と定義し、「７つのムダ」（❶つくりすぎのムダ、❷手待ちのムダ、❸運搬のムダ、❹加工そのもののムダ、❺在庫のムダ、❻動作のムダ、❼不良をつくるムダ）をなくすことを徹底しています 

このようなムダをなくす為に、あの有名な「5S」や「自工程完結」という考え方があるというわけです。この２つは既にご存知の方も多いと思いますが一応説明をします。

「5S」は整理・整頓・清掃・清潔・しつけの頭文字をとったもので、これを徹底することで "必要なもの" を "必要なとき" に "必要なだけ" 取り出せることができるようになります。

「自工程完結」は作業のやり直しが発生しないように自分の工程で作り込むことを意味します。例えば、教材の問題作りで、ラフ作成の手を抜いてしまい、最後の校正で問題の作り直しになったとします。そうなれば、ラフ作成の後にした作業、例えばデザインあて等の時間がムダになってしまいます。一つひとつの工程でしっかりと作り込んでいれば、やり直しのムダはありませんし、通常工程の校正の工数も軽くなります。 

ムダが出れば出るほど、工数に影響があるため、ムダをなくすことはコストを抑えることと同義であると言えます。上で引用した7つのムダをなくす為に、様々な改善活動を続けるのがトヨタの仕事の進め方だそうです。

ムラ

モノづくりでは、納品の後に不良品がないかを調べる「検品」や、発注した内容通りに作られているかをチェックする「検収」というものがあります。もし不良品率が高ければ、不良を作るムダが発生していますし、そもそもクライアントの信頼を損ねて今後のビジネスがなくなってしまうかもしれません。品質にムラを出さないというのは非常に重要なことです。では、トヨタではムラをなくす為にどのような取り組みをしているのでしょうか。

トヨタには「標準」という考え方があります。 標準とは、各作業のやり方や条件であり、作業者はこれにもとづきながら、仕事をこなしていきます。簡単にいえば、標準とは、「このようにつくりましょう」という取り決めです。具体的には、作業要領書や作業指導書、品質チェック要領書、刃具取り替え作業要領書など「標準書」は多岐にわたります。これらは、少しずつ各職場でつくられてきたもので、まさに現場の知恵が凝縮された手引書です。たとえば、ある部品のボルトを締める作業があるとき、「しっかり締めろよ」と教えても、人によって「しっかり」の解釈に誤差があるため、ボルトが緩い状態になってしまう可能性があります。しかし、「カチッという音がするまで締める」という標準が決められていれば、誰でも同じ強さで締められます。標準とは「誰がやっても同じものができるしくみ」なのです

 大量生産型のモノづくりでは、特定の人や機械に依存することはできません。あの機械を使えば良いものができるがこの機械を使えば不良品が出る...そんな状況では不良品率は跳ね上がってしまうでしょう。きちんと品質を担保する為、誰がどこで作業しても同じ品質が出るようにムラをなくすことは非常に重要です。

ムリ

さて、ここまで ”プロジェクトマネジメントの本質は、時間・コスト・品質をマネジメントすること”とし、ムダはコスト、ムラは品質に関わっていることを書きました。では、ムダはどういう位置づけなのでしょうか？実は、「トヨタ 仕事の基本大全」ではムダについてはあまり触れられていませんでした。そこで、自分なりに考えてみたのですが、ムリはムダやムリを生む根本原因になるという結論に至りました。

例えば、要件定義が十分でないのに仮説で仕様を決めて実装をするというムリをすると、後になって実装のやり直しが発生する可能性が高まります。つまり、ムダが生まれやすくなります。例えば、長時間労働を前提にプロジェクトを進めるというムリをすると、日常業務の集中力が落ちて不良品が出る可能性が高まります。つまり、ムラが生まれやすくなります。

このように、あれほど良くないと述べたムダやムラを容易に生み出してしまうのがムリです。プロジェクトではムリをせざるを得ない状況が出てくるのは避けられないと思いますが、計画段階ではムリを最大限排除するのが賢明でしょう。一見、不必要にゆとりがあるように見える計画が、実はムダとムラを取り除ける効率の良いプロジェクトの進め方なのだと思います。

最後に

失敗したプロジェクトの事例を見てみると、精神論が先行したマネジメントが散見されます。精神論の多くはムリを誘発するもので、その最たる例が大日本帝国だと僕は思っています（計画性のないムリな侵略で100万人を超える餓死者を出した）。 プロジェクトは不確実性との戦いであるからこそ、まずムリのない計画を立てること。そして、その上で、ムダとムラをなくせる仕組みづくりをすることが重要なのだと思います。

トヨタ生産方式、業界を問わず、モノづくりに関わる人にはお薦めです。

トヨタ 仕事の基本大全

Googleスプレッドシートでプレシデンス・ダイアグラム法（PDM）を自動生成するアドオンを作ってみた

プロジェクトマネジメントの手法の一つにプレシデンス・ダイアグラム法（Precedence Diagram Method）というものがあります。これを使えば、各アクティビティごとの作業順序や依存関係が明らかになり、どのアクティビティが、絶対に遅れてはならないクリティカルパスなのか、逆に遅れてもよいフロート*を持つものなのか、を知ることができます。しかし、有効な手法である反面、一つひとつのアクティビティを依存関係に沿って繋ぎ、期間を計算をするのは骨が折れます。そこで、Googleスプレッドシートで自動生成をしてくれるアドオンを作成してみました。

*フロートとバッファはよく混同されますが別のものです。フロートとはスケジュールに影響なくアクティビティを遅らせられる期間を意味します。ちなみに、フロートが0のアクティビティを繋いだものがクリティカルパスです。

Precedence Diagram Maker

アクティビティをリストアップし、必要な情報を入力するだけで、自動でネットワーク図を生成してくれるアドオンです。WBS作成後など、やることが決まって「さあこれからスケジュールに落とし込むぞ」というときに活用するのが効果的です。

インストール

Precedence Diagram Maker - Google Sheets add-on

上記にPCからアクセスして、Googleアカウントにログインし、「インストール」をクリック。

Precedence Diagram Makerで出来ること

• PDMのネットワーク図を自動生成
• プロジェクト全体の必要総期間を自動計算
• クリティカルパスを赤色で表示

仕様

アドオンメニュー

目次	動作結果
プレシデンス・ダイアグラムの作成	listシートを作成
サイドバーの表示	サイドバーを表示

サイドバー

目次	動作結果
Project Nameフォーム（任意）	プロジェクト名を入力すればネットワーク図に反映される
実行	diagramシートを作成し、listシートの情報を元にネットワーク図を自動生成

listシート

目次	内容
アクティビティ一覧	アクティビティ名を入力（IDが自動付与される）
期間	数字を入力
先行ID	先行するアクティビティIDを入力。最初のアクティビティの場合は0に 先行アクティビティが複数ある場合はコンマ区切りで入力すること（例: 1,2）
関係性	アクティビティの依存関係を入力。FS (Finish to Start), SS (Start to Start), SF (Start to Finish), FF (Finish to Finish) のいずれかを選ぶこと 先行アクティビティが複数ある場合はコンマ区切りで入力すること（例: FS,SS）
リード / ラグ	数字を入力。リードタイムのときは負の数を、ラグタイムをのときは正の数に 先行アクティビティが複数ある場合はコンマ区切りで入力すること（例: -10,0）

diagramシート 

目次	内容
欄外	（ID）関係性_リード/ラグ）の順で先行アクティビティの情報を表示
一列目	赤色...クリティカルパス、灰色...一般のアクティビティ アクティビティIDと必要期間を表示
二列目	最も早い開始日と終了日を表示
三列目	アクティビティ名を表示
四列目	最も遅い開始日と終了日を表示

お薦めの活用法

大雑把にですが、スケジューリングは次の順に進んでいきます。5番目のところで、このアドオンを用いて、全体の工期（クリティカルパスの期間の合計）を出すのがお薦めの活用法です。

1. プロジェクト達成に必要なアクティビティを洗い出す
2. 各アクティビティを担当するメンバー構成を考える
3. 作業量と担当するメンバーから対応に必要な期間を出す
4. 着手に必要なインプットと、完了時のアウトプットを整理し、アクティビティの依存関係を明らかにする
5. 依存関係に基づいてアクティビティをつなぎ、全体の工期を計算する

制約

• シート名を変更しない
• 1行目より上に行の挿入をしない
• 非表示の2行目を編集 / 削除しない
• 各項目の間に列を挿入しない

以上です。ソースコードはGithubに公開しているので興味がある人はどうぞ。また、追加して欲しい機能やバグなどあればこちらのフォームからご連絡ください。まあ正直なところ、今回のアドオンは用途が限定的なので、どれだけの人に役立つか不明なのですが。個人的には仕様に落とし込む過程で理論を深く理解することができたので、開発して良かったなと思います。もし「ちょうどこんなアドオンが欲しかったんだぜ！」という人がいれば、ぜひいつものあれをお願いします。

=> Amazon欲しいものリスト / PayPal

プロジェクトの遂行能力を高める方法

プロジェクトの遂行能力を高めたいというのは、プロジェクトマネージャーの共通の願いであると思います。しかし、どのように遂行能力を高めるか？の答えを持っている人は少数ではないでしょうか。このエントリーでは、日揮でプロジェクトマネージャーを務めていた佐藤知一氏の著書「世界を動かすプロジェクトマネジメントの教科書」を引用しながら、その方法論を考えてみたいと思います。ところで、佐藤氏のブログ「タイム・コンサルタントの日誌から」は玉石混淆なインターネットの中にある素晴らしい情報源です。プロジェクトマネジメントに関わる人は必読です。

世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方

プロジェクトの遂行能力とは？

佐藤氏は著書の中で、プロジェクトはチームで取り組むもの。プロジェクトの遂行能力は、リーダー個人の能力ではなく、組織の能力である。優秀なプロマネをスカウトしてリーダーに据えれば上手くいくというのは誤りで、個人を支える組織の体制や行動習慣が重要である、と提唱しています。また、それをコンテンツ・アプリケーション・OSに例えて、下記のように図解しています。

コンピュータにコンテンツだけあっても有用とは言えません。コンテンツを活用する為のアプリケーションがあって然るべきですし、そのアプリケーションもOS（Operation System）がなければ動きません。同様に、個人の持つプロジェクトマネジメントの知識だけではあまり意味がなく、社内にあるデータや制度、そして何より、その会社に属する人の行動習慣が重要になる、ということです。つまり、プロジェクトの遂行能力を高めるには、組織のOSをアップデートする必要があると言えます。

現実的には「鶏が先か、卵が先か」で、優秀なマネージャーがいなければ、優れた組織体制や行動習慣は生成されないかもしれません。ここで大事なことは、コンテンツ・アプリケーション・OSの3つの要素を強化する必要があると、まず認識することだと思います。その前提に立てば、経験豊富なプロマネを採用して終わりとはならず、本質的にプロジェクトの遂行能力を高めるところまで進めるはずです。

さて、次にプロジェクトマネジメントのコンテンツ・アプリケーション・OSが何なのか自分なりに考えてみたいと思います。

コンテンツ（プロマネ個人スキル）

プロマネの個人スキルは、知識・経験・人間力の3つ要素で構成されていると思います。

知識は、EVMS (Earned Value Management System) ・ WBS (Work Breakdown Structure) ・ PDM (Precedence Diagram Method) などのプロジェクトマネジメント理論や、アジャイル型開発・ウォーターフォール型開発などのフレームワークを指します。

経験は、上記の知識を業務で使用したことがあるかどうかです。やはり、"知っている”と”やったことがある”には大きな差があります。状況に合わせて適切な判断を下すには、それぞれの理論やフレームワークのメリット・デメリットを身体で理解している必要があります。

最後に人間力。プロジェクトメンバーが人間で構成される以上、感情の要素を除くことはできません。様々なステークホルダーと信頼関係を築き、プロジェクトを円滑に回すことは重要なスキルの一つです。

アプリケーション（データ・業務プロセス）

上記のピラミッドでは、アプリケーションは過去データや情報システムなどの要素で構成されていますが、ここは大きくデータと業務プロセスに分類してしまって良いと思います。

データは、過去に同種のプロジェクトに要した時間やメンバー構成、WBS、発生した欠陥などの情報を指します。プロジェクトマネジメントは、端的に言うと、時間・スコープ・お金の3点のマネジメントです。それらの過去データが蓄積されていれば、正しい判断を下せる可能性が高まります。

業務プロセスは、作業要領書や仕様書のようなドキュメント、gitやredmineのようなツール、その他ヒューマンエラー防いだり、作業速度を上げる為のシステムなどを意味します。ドキュメントやツールを用いて、品質を高められた状態で作業の標準化ができれば、個人への依存度が下がり、効率的に作業を進められるようになります。

OS（組織体制・行動習慣）

さて、ピラミッドで一番の比重を占める OS、つまり組織体制と行動習慣ですが、個人的には組織体制よりも行動習慣の方が重要度が高いと考えています。

組織体制は定義の広い言葉ですが、代表的なところで言えば、意思決定のスピード・権限委譲・人事制度・財務制度などでしょうか。こうした組織体制が整っていないと、たとえ個人がどれだけ頑張っても、またはどんなに便利なツールがあったとしても、あまり意味がありません。

次に行動習慣ですが、これは会社の文化と言い換えられるかもしれません。僕はトヨタグループの商社で働いた経験があるのですが、そこでは隅々までトヨタの文化が浸透しているのがよくわかりました。

例えば、有名な三現主義。"三現"とは、現場・現物・現実を指し、 現場に足を運び、現物を手に取り、現実を自分の目で見て確認するというものです。これは驚くほどの徹底ぶりでした。役職者の現場を見ずにの意思決定は見たことがありません。効率が悪いのでは？と思う人もいるかもしれませんが、こうした初期フェーズにパワーをかけることによって、不良品の流通を防ぎ、長期的な効率化が図られていると思います。

トヨタの良い文化を説明し始めると長くなるのですが、僕が感銘を受けたものをもう一つ挙げると、バッドニュース・ファーストというものがあります。これは「悪いニュースほど真っ先に報連相せよ」ということなのですが、言うは易く行うは難しで、組織として実現する難易度は高いです。というのも、上長は悪いニュースを受けても部下を感情的に怒らないというのがセットでないと成立しないからです。僕がいた組織では、どんなに悪いニュースを報告しても「報告してくれてありがとう」と、上長が部下を褒めるところを何度も見ました（ちなみに、バッドニュースの報告が遅いと怒られますw）。これも組織に根付く行動習慣の一つだと思います。トヨタグループでは、問題が起きるとすぐに上長へ情報が届き、適切な初期対応を取ることが可能になっています。

まとめ

プロジェクトの遂行能力のピラミッドを考えると、個人に出来ることは限られています。しかし、大前提として日々の勉強を怠ってはいけません。プロジェクトマネジメントは科学的なアプローチの研究が進んでいるので、積極的にその理論は取り入れるべきです。

ただ、組織体制や行動習慣に大きな比重がある以上はここを改善していく施策も行っていく必要があります。しかし、僕ではその効果的な具体策が今ひとつ見えないのが現状です。第一歩は周囲の人にその重要性を認識してもらい、味方を増やしていくことでしょうか。組織体制や行動習慣を個人の発信で変えるのは簡単ではありません。が、佐藤氏も著書の中で言っていましたが「ローマは一日にして成らず」。理想像をしっかり持ち、一歩ずつ前に進んでいくことが地道ですが確実な方法だと思います。

世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方

Googleスプレッドシートでガントチャートを自動生成するアドオンを作ってみた

会社にG Suite（Googleのグループウェアツール）が導入されたこともあって、Googleドキュメントを使用することが増えてきました。そこで、ガントチャートを生成するツールを自作してみました。有り難いことに、GoogleスプレッドシートはJavaScriptで制御が可能です。

※2018/2/20更新: "親タスクの自動反映"機能を実装しました。

※2018/3/26更新: "ガントチャートの表示期間変更"機能を実装しました。

※2021/02/20更新: プレミアム会員用の機能を追加開発しました。

Gantt Chart Generator （ガントチャートジェネレーター）

WBS (*Work Breakdown Structure) をベースにガントチャートを自動生成してくれます。小規模から中規模のプロジェクトの進行管理や、大規模プロジェクトの叩き台のスケジュールを引くときなどに活用できると思います。以下、仕様や活用法を記述します。

インストール

Gantt Chart Generator - Google Sheets add-on

上記にPCからアクセスして、Googleアカウントにログインし、「インストール」をクリック。

※ アドオンをアップデートした際に、システム的な理由でURLが変わってしまいました。ご不便をおかけして申し訳ありません。

プレミアム機能

 プレミアム会員専用に新たに機能開発をしております。興味のある方はこちらよりお申し込みください。 → Gantt Chart Generator Premium

Gantt Chart Generatorで出来ること

• タスクを5階層までブレイクダウン
• 入力した日付に合わせてガントチャートの自動色塗り
• 親タスクに紐づく工数の合計を自動計算
• 入力した進捗に合わせてガントチャートにバーを自動反映
• 親タスクの進捗を工数のウエイトに合わせて自動計算
• プログラムによる自動計算と自身が入力する関数の共存
• 祝日の自由設定

仕様

アドオンメニュー

目次	動作結果
ガントチャートの作成	scheduleシート、holidayシートを作成
サイドバーの表示	サイドバーを表示

scheudleシート

目次	入力	動作結果
階層別 タスク一覧	文字列	IDが付与
予定開始 予定終了	日付	ガントチャートに青色で反映
予定終了	日付	ガントチャートにオレンジ色で反映
実際開始 実際終了	日付	ガントチャートに緑色で反映（*デフォルト非表示）
工数（予）	数字	親タスクへ自動集計（子タスクの工数を合計する）
進捗	数字	ガントチャートにバーが反映 工数（予）に数字があれば親タスク進捗が自動計算

holidayシート

目次	入力	動作結果
A列	日付	ガントチャートに縦ラインがピンクで反映

サイドバー

目次	動作結果
ガントチャートの操作	ガントチャートの始まる日付を変更 ガントチャートの表示期間を週単位で変更 ガントチャートの表示単位を「日」「週」で変更 ※プレミアム会員のみ
ガントチャートの手動更新	全ての親タスクの値を再計算 全てのタスクのガントチャートを更新
進捗別の色表記	完了を青色、進行中を黄色、遅れを赤色で表す
親タスクの自動反映	子タスクの総期間を自動で表示
アサインの空き状況の確認	ガントチャートを担当者ごとにソート ※プレミアム会員のみ
ガントチャートの初期化	scheduleシートとholidayシートを初期化

お薦めの活用法

• プロジェクト名を一番上の階層に置き、全てのタスクを紐付ける（プロジェクト全体の進捗が自動計算できる）
• タスクは親タスク・子タスク・孫タスクと細かくブレイクダウンする
• 日次もしくは週次で進捗を追いかけるタスクに予定開始 / 終了を入れる
• 総合的に進捗を見たいときに「親タスクの自動反映」を使う。*普段はオフ
• 日付入力はworkday関数を使う（holidayシートA列と工数（予）を参照する）
• 工数は人日で入れる
• 進捗は「実際開始 / 終了」もしくは「進捗」を使って追いかける
• 「進捗」を使う場合、「進捗別の色表記」をオンにする
• 数式を使って「進捗」の数字を更新すると、ガントチャートへは自動反映されないので、そのときは「ガントチャートの手動更新」を行う（自動反映はセルを編集したとき、もしくは日次の自動更新に行われる）

制約

• シート名を変更しない
• 1行目より上に行の挿入をしない
• 開始日と終了日の行の間に行を挿入しない
• 非表示の2行目を編集 / 削除しない
• 「進捗」より右に列を挿入しない
• ガントチャートの日付を編集しない

よくある質問

• 色塗り機能が急に動かなくなりました

このアドオンは通知なしでアップデートされることがあります。 多くの場合、ガントチャートの開始日を変更することによって新しいバージョンをアクティベートできますのでお試しください。それでも色塗り機能が動かない場合、新しいスプレッドシートを作成し、アドオンを1から動かしてみてください。恐れ入りますが、データは旧シートからコピー＆ペーストで復旧をお願いします。

• サイドバーを使おうとしたらsystem errorとなるのですが...

権限に関する問題が発生している可能性があります。同様の事例がいくつかあったのですが、①ブラウザのキャッシュを削除する、②複数のグーグルアカウントが同時にブラウザで使われている場合は一つを除いてログアウトする、③シークレットブラウザ（キャッシュのない状況下）で開き直してみる、などで回復したと聞いています。一度お試しください。

• 祝日が ”2017/12/31 07:00 元旦“ のように表示されるのですが...

既知のバグです。アドオンメニューから何度か「ガントチャートの作成」をして頂くと直ります。もしそれでも直らない場合は、手動で日付を編集をして頂けますか？その際、”2018/1/1 00:00 元旦“ のように時間を0時に設定してください。ご迷惑をおかけしますがよろしくお願いします。

• ガントチャートの日付がずれてしまいます...

PCのタイムゾーンとスプレッドシートのタイムゾーンが一致していない可能性があります。同じタイムゾーンに揃っていることを確認して頂けますか。※スプレッドシートのタイムゾーンの確認の仕方

• ガントチャートで表示される期間を延ばしたいのですが...

サイドバーから表示期間が週単位で任意設定できるようになっています。ただし、列数が多いとスプレッドシートの処理速度が遅くなるため、期間を極端に長くするのはお薦めしません。

• ガントチャートの色を変更したいのですが...

現状、色を自由に変える機能はありません。既存機能で色に関わるものでは、サイドバーの「進捗別の色表記」にチェックを入れることによって、下記のように色を自動で切り替えることができます。

・達成度100% or タスク開始日前 ... 青色
・タスク開始日後かつ進捗オンスケ ... 黄色
・タスク開始日後かつ進捗遅延 ... 赤色

• 親タスクの進捗が0のままになります

親タスクの進捗は子タスクの工数の加重平均を基に算出します。つまり、工数を入力しない限り、親タスク進捗は常に0を表示します。また、工数には「予」と「実」の2列があります。「実」に関しては、プログラムと関わっておらず、プロジェクト終了後に振り返りをするために、実工数を記録しておくスペースです。「予」が親タスク進捗の加重平均を出すための役割をしています。 

以上です。ソースコードはGithubに公開しているので興味がある人はどうぞ。ただし、プレミアム会員用に追加開発した部分は公開していないため、ソースコードは最新の状態ではないことにご注意ください。どうガントチャート・ジェネレーターを引き続きよろしくお願いします。

2017年を振り返って

気がつけばもう大晦日、あっという間に年越しです。2017年は、日本に帰国して新しい仕事を始めたりと、大きく環境が変わって、刺激的で良い一年になったと思います。上手くいくことばかりではなかったですが、日々の充実感がありました。2018年もこの調子で頑張っていきたいと思います。

*さっそく観光に行った東京タワー

2017年の振り返り

• 2月 … 電子書籍の出版
• 3月 … 日本のEdTechスタートアップへ参加
• 5月 … 事業部責任者へ昇格
• 8月 … STEM教育コースの立ち上げ
• 10月 … プロジェクトマネージャーへ社内転職

昨年末のエントリーでは「電子書籍の出版」「Webアプリケーションの開発」「新しく打ち込める仕事に就く」の３つを2017年の目標として掲げていました。これらに関しては、おおむね達成することが出来たと思います。プライベートでも、昔の友人や仕事仲間と東京で再会することができて、とても満足のいく一年でした。一つずつ振り返ってみたいと思います。

目標 1. 電子書籍の出版

Wasabi's Japanese Grammar Reference (with Audio Files) (English Edition)

何度か紹介しているので詳細は省きますが、英語話者向けの日本語の文法書です。前職のコンテンツマーケティングの一部を集約して本にしました。ただ、肝心の売れ行きはと言うと、残念ながら芳しくありません。 月に2~3冊売れる程度です。$9.99という価格設定と、Web上に全コンテンツが無料公開されていることを考えれば、そんなものかという気もしますが。

しかし、電子書籍の出版に関しては、売上は度外視できるほどの達成感がありました。約650ページほどの本なのですが、全て英語で執筆し、校正者達と体裁を整えていくのは非常に骨が折れました。一番最後にPreface（序文）を書いたのですが、お決まりの “Let us take this opportunity to express our deepest gratitude to...” と書いているときは、ついにこのプロジェクトも終わるのかと感傷に浸っていました。あまりそういうタイプではないですが、こういう時は自然に感謝の気持ちが出てくるものですね。

目標 2. Webアプリケーションの開発

2017年はJavaScriptの勉強を続けていました。簡単なものならサクッと実装できるようになってきて、最近はおもに自分が関わる業務改善のツールを作っています。例えば、HTMLの<ruby>タグを自動生成するアプリケーション、SlackのBot、エクセルを解析して重要な係数を自動計算するアプリケーション、Google Apps Scriptでガントチャートを自動生成するスクリプト、などを開発しました。 業務用で用途が限られているので特に公開はしていませんが、ガントチャートを自動生成するスクリプトは近日中にGoogleスプレッドシートのアドオンとして一般の人にも使えるようにしようと思っています。こういう感じで、小〜中規模のプロジェクトの工数とスケジュールが管理できるようなアドオンになる予定です。

目標 3. 新しく打ち込める仕事に就く

これは目標と言えるのかわかりませんが、無事に新たな仕事が見つかり、日々忙しく過ごしています。 Compassという会社で人工知能型教材Qubena（キュビナ）を開発しています。僕は当初はCompassの直営塾の運営の仕事をしていたのですが、会社に大型の受託開発の話があって、急遽プロジェクトマネージャーの仕事をするようになりました。また、今後もしばらくは大型のプロジェクトが続きそうで、エンジニア・デザイナーと開発メンバーを絶賛募集中です。興味ある人はご連絡ください。

プロジェクトマネージャーの仕事は、損な役回りだと感じることもしばしばありますが、性格が細かい自分としては、性にあっていると思います。それに、勉強すればするほどに、”プロジェクトマネジメント”という専門性を実感し、やりがいも感じます。変化の多い組織なので、先のことはどうなるかわかりませんが、しばらくはプロジェクトマネージャーとして頑張ってみたいと思っています。経験者の方は色々教えてもらえると嬉しいです。

2018年の目標 

• プロジェクトマネジメントのスキルアップ
• PythonとSQLを覚える
• 中学数学、数学IAをやり直す
• 筋力トレーニングを始める

この4つを2018年の目標にしたいと思います。 「プロジェクトマネジメントのスキルアップ」は言わずもがな自分の実務なのでもっと成長していかなければいけません。現在は業務に合わせての書籍やオンラインコースなどのインプットが中心ですが、今後は蓄積した知識がどのように業務に活かせるかをまとめて、どんどんアウトプットしていくつもりです。毎年のようにブログ書く書く詐欺をしていますが、毎月2~4冊ほどの読書と、それをブログに書きまとめるのが理想だと思っています。

「PythonとSQLを覚える」は、やはりプログラミングを続けるのであれば、業務に直結するものを勉強したいと思っています。会社の言語がPythonなので最終ゴールはプロダクトのコードが理解できるようになることなのですが、まずはPythonを使って自分の好きなものが作れるようになりたいです。また、SQLは非エンジニアがトッププライオリティで使えるようになるべきだと思っていて、これも業務で使えるレベルにまでするつもりです。

次に「中学数学、数学IAをやり直す」ですが、これはもうそのままで、数学を勉強し直したいと思っています。数学の教材開発していて、数学がわからないというのは本当シャレにならないので、かなり危機感があります。幸いなことに（？）自社でQubenaというアダプティブラーニングの教材があるので、低学力の代表として、とりあえず2017年は数IAまで一気に勉強します。ちなみに今は中学3年生の因数分解をやっています。

最後に「筋力トレーニングを始める」。年が明けて2月になれば31歳になります。そろそろ意図的に身体を鍛えないと、体力が原因になって仕事やプライベートが楽しめなくなってくる年齢になりました。これまではもやしっ子代表でしたが、意識改革して鍛えます。当面のメニューは腕立て30回・スクワット50回・プランク60秒。慣れてくれば1日2セットやろうと思います。目指せ逆三角形のボディ。

終わりに

さて、2017年も本当に多くの人にお世話になりました。そして、2018年も引き続きよろしくお願いします。年末はどのようにお過ごしでしょうか。僕は3年ぶりに日本で年越しを迎えます。家でゆっくりと紅白歌合戦とゆく年くる年、こういうのも悪くないですね。それでは皆さまも良いお年をお迎えください。