ムダ・ムラ・ムリを取り除け！トヨタ生産方式に学ぶプロジェクトマネジメント
前回のエントリーで、プロジェクトの遂行能力を上げるには、組織の体制や行動習慣を向上させる必要があるということを書きました。組織の行動習慣と言えば、やはりトヨタ。車の製造は、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行目を編集 / 削除しない
- 各項目の間に列を挿入しない
以上です。ソースコードはGithubに公開しているので興味がある人はどうぞ。また、追加して欲しい機能やバグなどあればこちらのフォームからご連絡ください。まあ正直なところ、今回のアドオンは用途が限定的なので、どれだけの人に役立つか不明なのですが。個人的には仕様に落とし込む過程で理論を深く理解することができたので、開発して良かったなと思います。もし「ちょうどこんなアドオンが欲しかったんだぜ！」という人がいれば、ぜひいつものあれをお願いします。
=> Amazon欲しいものリスト / PayPal
プロジェクトの遂行能力を高める方法
プロジェクトの遂行能力を高めたいというのは、プロジェクトマネージャーの共通の願いであると思います。しかし、どのように遂行能力を高めるか？の答えを持っている人は少数ではないでしょうか。このエントリーでは、日揮でプロジェクトマネージャーを務めていた佐藤知一氏の著書「世界を動かすプロジェクトマネジメントの教科書」を引用しながら、その方法論を考えてみたいと思います。ところで、佐藤氏のブログ「タイム・コンサルタントの日誌から」は玉石混淆なインターネットの中にある素晴らしい情報源です。プロジェクトマネジメントに関わる人は必読です。
世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方
- 作者: 佐藤知一
- 出版社/メーカー: 技術評論社
- 発売日: 2015/09/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
プロジェクトの遂行能力とは？
佐藤氏は著書の中で、プロジェクトはチームで取り組むもの。プロジェクトの遂行能力は、リーダー個人の能力ではなく、組織の能力である。優秀なプロマネをスカウトしてリーダーに据えれば上手くいくというのは誤りで、個人を支える組織の体制や行動習慣が重要である、と提唱しています。また、それをコンテンツ・アプリケーション・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の作り方
- 作者: 佐藤知一
- 出版社/メーカー: 技術評論社
- 発売日: 2015/09/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
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)
- 作者: Takuya Tokiwa
- 発売日: 2017/02/24
- メディア: Kindle版
- この商品を含むブログを見る
何度か紹介しているので詳細は省きますが、英語話者向けの日本語の文法書です。前職のコンテンツマーケティングの一部を集約して本にしました。ただ、肝心の売れ行きはと言うと、残念ながら芳しくありません。 月に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年の目標
この4つを2018年の目標にしたいと思います。 「プロジェクトマネジメントのスキルアップ」は言わずもがな自分の実務なのでもっと成長していかなければいけません。現在は業務に合わせての書籍やオンラインコースなどのインプットが中心ですが、今後は蓄積した知識がどのように業務に活かせるかをまとめて、どんどんアウトプットしていくつもりです。毎年のようにブログ書く書く詐欺をしていますが、毎月2~4冊ほどの読書と、それをブログに書きまとめるのが理想だと思っています。
「PythonとSQLを覚える」は、やはりプログラミングを続けるのであれば、業務に直結するものを勉強したいと思っています。会社の言語がPythonなので最終ゴールはプロダクトのコードが理解できるようになることなのですが、まずはPythonを使って自分の好きなものが作れるようになりたいです。また、SQLは非エンジニアがトッププライオリティで使えるようになるべきだと思っていて、これも業務で使えるレベルにまでするつもりです。
次に「中学数学、数学IAをやり直す」ですが、これはもうそのままで、数学を勉強し直したいと思っています。数学の教材開発していて、数学がわからないというのは本当シャレにならないので、かなり危機感があります。幸いなことに（？）自社でQubenaというアダプティブラーニングの教材があるので、低学力の代表として、とりあえず2017年は数IAまで一気に勉強します。ちなみに今は中学3年生の因数分解をやっています。
最後に「筋力トレーニングを始める」。年が明けて2月になれば31歳になります。そろそろ意図的に身体を鍛えないと、体力が原因になって仕事やプライベートが楽しめなくなってくる年齢になりました。これまではもやしっ子代表でしたが、意識改革して鍛えます。当面のメニューは腕立て30回・スクワット50回・プランク60秒。慣れてくれば1日2セットやろうと思います。目指せ逆三角形のボディ。
終わりに
さて、2017年も本当に多くの人にお世話になりました。そして、2018年も引き続きよろしくお願いします。年末はどのようにお過ごしでしょうか。僕は3年ぶりに日本で年越しを迎えます。家でゆっくりと紅白歌合戦とゆく年くる年、こういうのも悪くないですね。それでは皆さまも良いお年をお迎えください。
震災から6年半、福島県浪江町の様子（2017年9月）
福島に行くのは、僕が高校生のとき以来なので、かれこれ約15年振りでした。震災があってから、ずっと行きたいと思っていて、ようやく週末の3連休を利用して行くことができました。非常に印象深い旅行になったので、備忘録としてブログにも残しておきたいと思います。
まず基本的な情報に触れたいと思います。浪江町から福島第一原子力発電所への距離は、最も近いところで約4km、浪江町役場までは約8kmです。東日本大震災当時の人口は約21,500人。原発の事故によって、町全域に避難指示が出されました。それから6年、2017年3月31日に一部地域を除き避難指示が解除されています。しかし、5月31日時点の居住人口はわずか234人。避難指示解除前に実施した住民の帰還意向調査では、「まだ判断がつかない」が全体の28.2％、「戻らないと決めている」が52.6％という結果が出ているそうです。
さて、そろそろ町の様子に移ります。私は、東京から新幹線で福島市へ向かい、そこから高速バスに乗って南相馬市原ノ町駅、そして、JRで10時ごろに浪江町へ入りました。JRも避難指示解除に伴って運行が開始されています。
ちなみに、南相馬市原ノ町駅から浪江町に向かう乗客は僕一人でした。ダイヤは1日5本です。
浪江駅からの風景。いたって普通の町です。人気がないことを除いて。
電車で来たので当日は徒歩移動でした。町内に一般のバスやタクシーはまだありません（※浪江町民はデマンドタクシーというサービスが利用できる）。町役場を目指して歩きます。
建物は震災当時のままのよう。
町が少し緑に飲み込まれています。
写真を撮りながら20分ほど歩いて町役場に到着。実は、本当の目的は、町役場ではなく、その隣にある「まち・なみ・まるしぇ」。これは復興に向けたシンボルとして、2016年10月にオープンした仮想商店街です。飲食点、ホームセンター、コンビニなどがお店を構えています。
BGMにJazzがかかっていてとてもいい感じでした。残念ながら日曜日ということで、殆んどが閉まっていましたが...。「日曜日に浪江で営業しているのはうちだけ」と笑顔で迎えてくれた喫茶店「COSMOS」でランチをとって、沿岸部を目指します。
のどかな道。その中に、急に現れる非日常。光の関係で見えづらいですが、数値は0.083です。
海。ここから津波が来たんだなあ。
↑この写真は、請戸橋で撮影したものです。請戸は、震災前は人口1800人の漁師町だったそうです。しかし、現在そこにあるのは大きな原っぱでした。
一軒だけ残っていた住宅。
高台から見た様子。遠くに見えるのが小学校跡でしょうか。津波の恐ろしさを実感します。
まだまだ続く、復旧作業。
以上です。私はこのあと17時30分まで滞在し、JRの代行バスで浪江町を離れました。実は、浪江から南は今も電車が運休中で、バスを使わざるをえないのです。また、バス内では常に放射線量を計測しており、帰還困難区域を一部走行するため、窓を開けないように注意を受けました。
原発や税金の議論はさておき、事故から6年半経ち、現実として今もこのような状態の町があることは、もっと認識すべきことのように思います。実際、僕もようやく自分の目で見ることができて、色々と考えるところがありました。折を見て、再訪したいと思います。
100年ライフと生涯学習
私たちは今、情報革命の最中にいると言われています。情報革命は、あの農業革命や産業革命と並び、強烈なインパクトを社会構造に与えるだろうと考えられています。しかし、実はそのインパクトに負けないぐらいのある変化が起きていることをご存知でしょうか？…それは人間の長寿化です。なんと2015年時点で日本人男性の平均寿命は80.79歳、女性に至っては87.05歳です（厚生労働省の統計調査より）。そして、ワーク・シフトを書いたLynda Gratton氏とAndrew Scott氏の新著であるライフ・シフトによれば、2007年生まれの日本の子供たちは、50%の確率で107歳まで生きるという研究結果もあるそうです。
3フェーズの70年ライフから多フェーズ化する100年ライフ
ライフ・シフトは非常に良書であると思いました。自身のキャリアを考えあぐねている人には一読をお薦めします。私は1987年生まれの現在30歳です。ライフ・シフトによれば、10年ごとに平均寿命が2～3年伸びていることを考慮すると、僕は98～100歳ぐらいまで生きる可能性が高いそうです。従来の3フェーズの人生設計（すなわち、22歳までの教育フェーズ、60歳までの仕事フェーズ、そして60歳以後の引退フェーズ）が果たして上手く機能するのでしょうか。この人生設計は、集中的なインプットは教育フェーズで終わらせ、仕事フェーズで蓄えを作り、その蓄えと公的年金で引退フェーズを過ごす…というものでした。ライフ・シフトは、100年ライフにおいて仕事フェーズで長期化した引退フェーズを生き抜くだけの蓄えを作るのは困難であると主張しています。
上記のグラフでは、100年ライフを65歳まで働く設定としました。それでも老後は35年あります。仮に年間300万円で生活するとしても、必要な金額は合計で1億を超えます。公的年金に大きな期待が出来ない今、一体どれだけの人が1億円もの生活費を用意することが出来るのでしょうか。
新しいフェーズが人生設計に登場
ライフ・シフトでは「探検者」「独立生産者」「ポートフォリオ・ワーカー」の新しいフェーズが提言されています。詳しくは本を読んでもらいたいのですが、シンプルに考えれば、新たな学びによって自己の再創造をせよと言えると思います。
もし仮に、3フェーズのまま人生設計を考えれば、仕事フェーズを引き延ばすしかありません。実際、日本は定年が65歳まで引き上げられました。しかし、まとまったインプットは若い頃だけで、その時の知識とスキルで定年まで逃げ切るというスタイルはもはや現実的ではありません。知識やスキルはどんどん陳腐化します。これからのAIやロボット技術の進化を考えると、従来の仕事のやり方が通用しなくなることは自明です。大学院で最先端の知識を学び直す、旅をして異なる価値観に触れる、独立し事業を営むことによって実践的なスキルや経験を積む…手段は様々だと思いますが、仕事フェーズの途中で自分自身を磨き直し、新しい第二の仕事フェーズを迎える必要があります。
上記のように、仮に45歳から自分を再創造する時間をとり、最先端の知識やスキルを身につけたとします。体力を使う仕事はロボットが代わりにやってくれるでしょうから、頭だけを使う仕事だと、きっとこれまでより長く働けることでしょう。もし83歳まで働けば、引退フェーズは17年です。ずいぶんと現実的な計算ができるようになりました。
この人生設計を「そんなに長く働きたくないし、大人になってまで勉強したくない」と考えるのか、「色んなことに挑戦できる充実した人生だ」と考えるのかは人によると思います。
自分自身のことを考えると…
30歳になって転職をしました。久しぶりの日本のサラリーマンです。住環境も労働環境も大きく変わりました。仕事に必要な本質的な要素は変わらないと思いますが、それでも新しい知識を身につける必要があります。生活リズムも規則正しくしないといけません。幸いにも、今はこうした変化を楽しいと感じられています。
再創造とまではいきませんが、転職した業界についての情報収集や専門知識をつけなければと、インプット・アウトプットの時間を増やしました。ライフ・シフトを読んだこと、こうしてブログを書いていることもその一貫です。
- 毎日Economistの記事を2つ読む
- 毎日教育系の記事を2つ読む
- 毎週洋書・和書を一冊ずつ読む
- 毎週ブログを書く
まだまだ全てを守れていませんが、こんなルーティンを自分に課しています。100年ライフで大事なのは「新たな学びによる自己の再創造」と書きましたが、おそらく、これまで机に向かう習慣のなかった人が、急に40歳ぐらいになって学び直そうと決心しても難しい気がします。年を重ねれば否応なしに柔軟性が失われます。地位があがっていけば、それまでのやり方にプライドを持つでしょうし、積み上げてきたものを0に戻すことは勇気が要ります。若い頃から日々を謙虚に過ごし学ぶ姿勢を保つこと、そして新しい考えや異なる価値観に対して飛び込んでいける、いわゆるOpen-Mindednessが重要なんだと思います。
僕は人付き合いの幅が狭いところがあるし、基本的に引きこもり体質なので、その辺りはもっと柔軟性を持っていきたいと思いました。歳を重ねるとともに自分自身を変化させていきたいものですね。
