プロジェクトマネジメントとプロダクトマネジメントの棲み分けとその組み合わせ

突然ですが「PM」という言葉は何の略称だと思いますか?

Project Manager、それともProduct Manager でしょうか?日本だとProject Manager、海外だとProduct Managerという意味が一般的という話も聞いたりします。また、最近はPjM,、PdMというように明確に呼び分けることも増えてきているそうです。さて、このPjMとPdM、残念ながら呼称どころかその役割さえもよく混同されています。このエントリーでは、両者の役割を明確にし、現場でのベスト・プラクティスを考えてみたいと思います。

 

Inspired: 顧客の心を捉える製品の創り方

Inspired: 顧客の心を捉える製品の創り方

 

 

プロジェクトマネジメントとプロダクトマネジメントの役割とその融合のベスト・プラクティス

プロジェクトとプロダクトの違い

PjMとPdMの役割を整理する為に、まずはプロジェクトとプロダクトの違いを整理してみましょう。特徴を言語化すると次のようになります。

  • プロジェクト
    • 「始まり」と「終わり」がある
    • プロジェクトの「終わり」の条件を満たすことが重要
  • プロダクト
    • 「始まり」はあるが「終わり」はない
    • プロダクトが市場に受け入れられ続けることが重要

プロジェクトを日本語で言い換えると「目標を達成するための計画や業務」となります。プロジェクトには必ず「始まり」と「終わり」があります。例えば、工場を建てるというプロジェクトであれば、スポンサーの発注によってプロジェクトが始まり、どのような工場を建てるのかを決めて、その通りの工場が建てられたことが確認されてプロジェクトが終わります。どのような工場を建てるのか、といのうがプロジェクトの終了条件となります。

プロダクトを日本語で言い換えると「製品・商品・サービス」となります。プロダクトには「始まり」はあっても「終わり」はありません。例えば、iPhoneというプロダクトは2007年に始まりましたが、それからバージョンアップを重ね、2019年になってもなお多くの人が使用しています。厳密には、プロダクトには製造中止などで終わりが来てしまうものもありますが、それは望ましいことではなく、市場に受け入れられている状態を継続することが重要です。

 

プロジェクトとプロダクトのマネジメントの違い

プロジェクトとプロダクトの違いについては整理できました。次はそれらのマネジメントについて整理したいと思います。内容が異なるもののマネジメントですので、目標や手段は大きく異なります。

  • プロジェクトマネジメント
    • プロジェクトの終了条件を満たすことにコミット
    • 進行管理、リソース管理、スコープ管理、コスト管理などが主な業務
  • プロダクトマネジメント
    • プロダクトが生み出す価値にコミット
    • 市場分析、戦略・方針の決定、要件・仕様に関わる決定、ユーザー分析、データ分析などが主な業務

プロジェクトマネジメントでは、プロジェクトを終わらせることが最大のゴールです。多くの場合、終了条件は品質、費用、納期によって定義されます。その条件を満たすために、プロジェクトの各フェーズ(立ち上げ期、計画期、実行期、コントロール期など)で、重要なエリア(進行、リソース、スコープ、コストなど)を管理していきます。プロジェクトの進捗を把握し、スポンサーと終了条件を調整していくことも大きな役割の一つです。このような管理や調整がメインの業務になります。

プロダクトマネジメントでは、プロダクトが市場に受け入れられる状態を作るため、プロダクトの価値を高めることが最大のゴールです。しかし、価値の最大化というのは決まった答えがあるわけではありません。その不確実性と向き合い、市場を分析し、戦略を練り、どういう機能を開発するかを意思決定していきます。また、ユーザーインタビューやアクティビティログの分析などを通じて、継続的な改善の方針を決めていくのも重要な役割の一つです。一言で表すならば、何を作るのかを意思決定するのがメインの業務になります。

 

プロダクトを作るプロジェクトのベスト・プラクティス

さて、ここで難しいのが、世の中には「プロダクト」を生み出す「プロジェクト」が存在することです。 市場に受け入れられるプロダクトを、スポンサーから提示される品質・費用・納期の制限のなかで生み出さないといけません。達成するには「プロダクト」と「プロジェクト」の両方を適切にマネジメントする必要があります。そして、その為には、Product ManagerProject ManagerUX DesignerEngineering Managerの存在が鍵になると考えます。実際の体制をプロジェクトのフェーズに照らし合わせて見てみましょう。

プロジェクトの立ち上げ期の組織体制

立ち上げ期の主導はProduct ManagerとUX Desginerです。プロジェクトマネジメントの鉄則は、なるべく早い段階で要件・仕様を固めることですが、プロダクトの開発となれば、本当に市場に受け入れられるものは何なのか?を見定める必要があります。そこで立ち上げ期では、Product ManagerとUX Desginerがプロトタイピングを通じて何を作るかを決めていきます。Checkではユーザーテストなどを行い、最大限に市場優位性のあるものを目指します。

一方で、Sponsorは何を作るかが決まっていないものにお金を払うことは難しいです。Project Managerは、プロダクト開発における不確実性をSponsorに理解してもらい、立ち上げ期、実行期での2段階発注などの相談をしなければいけません。また、予算や納期には限りがあります。Project ManagerとEngineering ManagerはProduct ManagerとUX Desginerが定める要件がそれに見合っているかの検証をします。

この流れを繰り返し、市場優位性のある要件が決まり、またそれの実現可能性の確認もでき、Sponsorとの取り決めが終われば、実行期に移ります。

 

プロジェクトの実行期の組織体制

実行期では主導がProject ManagerとEnginnering Managerに移ります。Enginnering Managerが開発をリードし、なるべく短いサイクルでリリースを繰り返します。そのリリースを(できれば設計段階から)Product ManagerとUX Designerがレビューをし、方向性に間違いがないことを確認しながらプロジェクトを進行していきます。

また、リリースを短いサイクルで行うことで、Project Managerも進捗の把握が容易になり、その状況に応じて、Sponsorと各種調整をしていきます。他プロジェクトとのリソース調整など、実開発の外で起こる課題もProject Managerが解決に動き、Enginnering Managerが開発に専念できる状態が作れると開発スピードも上がっていきます。

 

このように、マネジメントの対象ごとに主担当をアサインし、プロジェクトのフェーズに合わせて柔軟に体制を組み替えるのが、「プロダクト」を作る「プロジェクト」のベスト・プラクティスではないかと思います。

 

終わり

僕はプロジェクトマネジメントが本業なので、もしかしたら視点が偏った書き方になっているかもしれません。「おい、そうじゃないぞ」というような点がもしあれば、ぜひご指摘ください。プロダクトマネジメントについては、下記の書籍やエントリーから勉強させて頂きました。素人でも勉強できる情報が豊富にあり、本当に便利な世の中になったなあと感じます。また、情報化社会によって市場変化の速度が早い現代だからこそ、今後はプロダクトマネジメントがより重要になるのではと感じています。もっと本腰入れて勉強してきたいですね。

 

Inspired: 顧客の心を捉える製品の創り方

Inspired: 顧客の心を捉える製品の創り方

 

 

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

 

 

リーン・スタートアップ

リーン・スタートアップ

 

 

 

プロジェクトにおけるタスク管理の大事な3つのポイント

タスク管理、皆さんやっていますか?仕事でタスク管理のマニュアルを書くことがあったので、良い機会だと思って、プロジェクトにおけるタスク管理に対して自分の考えを整理してみました。PMやディレクターなど、進行管理をする方の参考になれば嬉しいです。

 

asanaのスクリーンショット

お薦めのタスク管理ツール、Asana

 

プロジェクトのタスクは「優先度」「ステータス」「進捗」の3つの観点から管理せよ

プロジェクトの規模によってタスク管理の最適な手法は異なります。このエントリーでは、プロジェクトやチーム単位のタスクを専任の担当者が管理するときの最適な手法について考えてみたいと思います。結論を先に書くと、優先度ステータス進捗の3つの観点からタスクを管理をするのが良いのではないかと思います。

 

タスクの優先度を管理

いきなり逆説的なことを書きますが、タスクを管理する為には、タスクの総数を極力減らしましょう。総数が多くてメンバーがタスクを捌き切れない状況下では、どんな管理方法をとってもまず上手くいきません。「何をタスクにするか?」がプロジェクトのタスク管理において最も重要です。本当に取り組むべきものだけをタスク化するようにしましょう。

いざタスクを作るときには、全てのタスクに優先度をつけます。優先度のつけ方は色々なやり方がありますが、下記のように重要度と緊急度の2舳で考えることがお薦めです。

 

優先度を示すマトリックス

 

タスク化のテンプレート

  • 優先度
  • 期日
  • 終了条件
  • 担当者
  • 必要工数

タスクには最低限、上記の情報を含めるようにしましょう。情報を埋める順序としては、まず「優先度」を決めます。その次に、優先度を考慮して「期日」と「終了条件」を後工程の人と調整してください(ここで適切に優先度が設定できていることが重要になってきます)。

「終了条件」は何をもってこのタスクを終了とするか?を定義することです。例えば、"○○の調査"というタスクがあった場合、調査の対象範囲はどこまでか、どういう形式で調査結果をまとめるか、誰に調査結果を報告するのか、という具合で終了条件を言語化していきます。調査結果は、テキストで箇条書きするだけで良いかもしれませんし、パワーポイントでプレゼン資料用に仕上げないといけないかもしれません。期日と終了条件はトレードオフになるケースも多いので、リソース状況と優先度を考慮した上で、実行可能な着地点を後工程の人とあらかじめ握っておきましょう。

最後に「担当者」をアサインします。その際に終了条件を説明し、「必要工数」をヒアリングして記録してください。タスクのステータスと進捗を管理するのに役立ちます。

 

タスクのステータスを管理

「未着手」「着手」「作業完了」「受領」と区分して、タスクのステータスを管理します。ステータス管理にはカンバン方式でカードを移していくやり方が適していると思います。そして、それぞれのステータスに合わせた対応をしていきます。

 

Asana_カンバン方式

Asana_カンバン方式

 

未着手のタスクへの対応

いつまでに着手する必要があるかを、期日と必要工数から逆算しておきます。そして、その日が近づいても着手されていない場合、担当者にアラートを出しましょう。また、タスク作成時から時間が空いた場合、プロジェクトの状況が変わっている可能性があるので、Slackや議事録などを常に見ておき、関連する情報があれば、タスクにメモを加えてあげておくと親切です。場合によっては、タスクの優先度が変わっていることもあります。こちらも同様にアラートが出せると素晴らしいです。

 

着手のタスクへの対応

※これは進捗管理として別で説明します。

 

作業完了のタスクへの対応

作業完了になっているタスクがきちんと終了条件を満たしているかを確認してください。確認は現地現物が鉄則です。担当者にただヒアリングするのではなく、成果物を見ながら終了条件を満たしているかを指差し確認してください。

また、タスクは作業が終わった後、その結果が後工程の人に渡るのが一般的です。後工程の人に連絡が入っているかも合わせて確認してください。後工程の人が受領してタスクは完了と考えるようにしましょう。

 

受領のタスクへの対応

一定の期間(2週間や1ヶ月)でのタスクの消化量を計測します。必要工数が出ているので、"この2週間では○人日分のタスクが消化できた”というように、定点的に記録をつけていってください。可能消化量がわかれば、プロジェクトの計画の精度が高まりますし、この消化量をいかに伸ばしていくかを工夫することで、プロジェクトの進行がよりスムーズになります。改善の指標の一つにして欲しいところです。 

 

タスクの進捗を管理

着手しているタスクについては進捗を管理します。定量的に進捗がわかるものであればやりやすいのですが、残念ながら全てがそういうタスクではありません。その場合、タスクの終了条件を満たすまでのステップをマイルストーンとして置き、それらがどの程度完了しているかで進捗を測るのが良いです。それも難しい場合は、担当者に後どのくらいの時間で終わるのか定点的にヒアリングしてください。もし期日通りに終わらない可能性が出てきた場合は、すぐに担当者本人や上長にアラートを出しましょう。

また、進捗を確認する際は、何か困っていることがないか合わせてヒアリングをしましょう。もし何かが作業の妨げになっているのであれば、それを除外できるようにサポートしてあげてください。タスク管理者は作業者よりも広い視野や情報を持っていることが多いので、力になれることがきっとあるはずです。

 

期日通りにタスクが処理されていかない場合

もしここまでのやり方でタスク管理をして、それでもタスクが期日通りに処理されていかない場合、次のような可能性があります。これらはマネジメントによって解決すべきものです。しかるべき相手と相談し、課題解決に向けて動いていきましょう。

  • 差し込みのタスクが多い
  • リソースが足りていない
  • メンバーのスキルセットが合っていない

 

 

以上です。僕の思う「こうすれば盤石ではないか」というタスク管理のやり方をまとめてみました。ここまでやるのは専任の担当者がいないと難しいかもしれませんが、大規模のプロジェクトではそうしたPMOを設置する体制を取っても良いのではないかと思います。ぜひ参考にしてみてください。

ヒンディー語の文字(デーヴァナーガリー文字)を学習するアプリを作ってみた

ついに本格的にヒンディー語の勉強を始めたのですが、やはりヒンディー語の文字である"デーヴァナーガリー文字"が最初のハードルです(こういうの → नमस्ते)。「これは繰り返し書いて覚えるしかないなあ」と感じる一方で、紙にペンというアナログ学習は性に合わない...。ということで、手書きでヒンディー語の文字を学習できるアプリを自作してみました。

 

HindiScript (Devanagari)

HindiScript (Devanagari)

  • Takuya Tokiwa
  • Education
  • $3.99

 

HindiScript (Devanagari)  | スマホアプリ

言語学習の初期で重要なのは、その言語の音と文字を一致させながら記憶していくことだと思います。そこで、"手書きで学習できて簡単に模範の文字と比べられる"、"模範の音声が聞ける"、"発音の説明がある"、という3点に絞って、アプリを開発しました。学習の流れを簡単に紹介します。

 

学習の流れ

1. 模範文字を真似て覚える

例を基に学習する様子

「母音」「子音」「母音記号」などのカテゴリーから学習したいものを選びます。すると、模範文字が薄く表示されているので、それを真似しながら、文字を一つずつ記憶していきます。「簡単」「普通」「難しい」と自己評価をするようになっているので、繰り返し学習をしていき、覚えた!というタイミングで「簡単」を押してください。
 

2. 模範文字なしで練習する

例なしで学習する様子

「簡単」が押された文字は次の学習ステージに進み、模範文字の表示がなくなります。アルファベットの読みと音声を頼りに、文字を書いてみてください。その状態で練習を続け、もう大丈夫!というタイミングで「簡単」を押してください。2回の「簡単」でクリアとなって学習対象から外れます。これを繰り返し、全ての文字にクリアしたら完了です。

 

3. 学習Tipを読む

学習Tip

母音や子音はそのまま覚えるだけで大丈夫なのですが、結合文字など複雑なものに取り組むときはTipを読んでください。より理解を深められます。

 

学習後のあなたのレベル

  • ヒンディー語の文字と音が一致するようになる
    • 単語の読みの規則の学習(潜在母音の規則など)は対象外
  • ヒンディー語の文字が書けるようになる
    • 単語の中で不規則に変化する結合文字は一部対象外

このアプリでの学習終了時は上記を想定しています。基本的な文字の学習は全て終了、単語の中での読みや書きに一部未習がある状態です。残りは次のステップになるであろう文法や語彙の学習をする際に慣れていけば良いかなと、敢えて情報量を制限しました。

 

技術的な話を少し

React Native (Expo) + Reduxで開発しました。手書き機能はexpo-pixi、合成音声はAmazon Polly、多言語対応はi18n-js、UIはReact Native Elementsを使っています。カラーをインドの国旗に合わせて、オレンジ、緑、青で構成したのが個人的なこだわりです。取り扱うデータ量が多くなかったので、サーバーを立てず、アプリ側に全ての情報を持たせています。

開発期間は3ヶ月程度ですが、本業の出勤前後の隙間時間と休日の一部を使って作業したので、実質的な工数は20人日ぐらいでしょうか。実際はアプリ開発よりもコンテンツ制作に苦労しました。模範文字は文字データとして持っているのですが、もちろんそれらは自分でタイピングする必要があり、ヒンディー語学習とアプリ開発を並行させるのが大変でした。その大変さもあって、今回は有料アプリにしています。ポチって頂けると飛び跳ねて喜びます。

 

終わりに

ヒンディー語を独学で学習している人はどのぐらいいるのでしょうか。日本語はもちろんですが、英語でググってもあまりヒンディー語に関する情報がないなあと感じています。IT業界にいる自分としては、自身で学習しながら、役に立つアプリや情報を発信していけたらなと考えています。ヒンディー語学習者の皆さん、ぜひ引き続きよろしくお願いします。

 

HindiScript (Devanagari)

HindiScript (Devanagari)

  • Takuya Tokiwa
  • Education
  • $3.99

 

 

2018年を振り返って

あっという間に2018年も終わりですね。仕事納めが12月28日で無事に終わり、自宅に戻って振り返りの記事を書いています。この振り返りエントリーは2012年から続けているので、こうしてPCに向かうといよいよ年末だなあという実感が湧きます。気持ち良く1年を締めくくり、幸先良い新年を迎えたいものですね。

 

f:id:takuya0206:20180523142901j:plain

シアトルのワシントン大学の図書館。ハリー・ポッターの世界観。

 

2018年の振り返り

  • 1月 ... Gantt Chart Generatorをリリース
  • 3月 ... Precedence Diagram Makerをリリース
  • 5月 ... PMだった大型プロジェクトが終了
  • 5月 ... 初めてのアメリカ旅行
  • 6月 ... PMとして超大型プロジェクトが開始
  • 8月 ... 鹿児島旅行
  • 9月 ... サウナと出会う
  • 10月 ... バクシンをリリース
  • 11月 ... ダーツの旅

 

昨年末のエントリーでは「プロジェクトマネジメントのスキルアップ」「PythonSQLを覚える」「中学数学、数学IAをやり直す」「筋力トレーニングを始める」の4つを2018年の目標として掲げていました。これらに関しては、途中で方向転換したものや、達成できていないものもあるのですが、おおむね満足のいく1年間になりました。一つずつ振り返ってみたいと思います。

 

目標 1. プロジェクトマネジメントのスキルアップ

スキルアップには、知識のインプットと、実践のアウトプットの両方が必要です。幸いなことに、2018年は○億円規模の大型プロジェクトを2つもPMとして担当することができて、非常に多くの経験値を積むことができました(その内の一つは今も継続中)。

知識のインプットでは、本を読んでまとめを言語化する、というサイクルを意識して取り組みました。ちなみに、読んだ本の一覧は下記です。プロジェクトマネジメントだけではなく、システムテストや要件定義、エンジニアリングなど、関連する分野の勉強も必要かなと思い、対象範囲を拡げて選択しました。もうちょっと読めたかなあという感じもありますが、実践に活かせる知識もたくさん得られたので及第点としたいと思います。★をつけたのはお薦めの本です。皆さんも是非読んでみてください。

2018年で読んだ本一覧

 

目標 2. PythonSQLを覚える

これは方向転換をして、PythonSQLではなく、JavaScriptに取り組みました。JavaScriptで出来ることも増えていますし、元々JavaScriptは少し書けたので、素人が広く薄くやるよりは、一つを深めていった方が良いだろうという判断です。

アウトプットとしては、Google App Scriptのアドオンを2つ、React NativeでiOSアプリを1つリリースしています。また、仕事のプロジェクトを推進していく為に、AsanaのAPIと連携したSlack Botなど、業務改善ツールにも取り組みました。純粋にモノづくりそのものが楽しかったですし、プログラミングで得られた経験や知見は、本業のプロジェクトマネジメントにも大きなプラスになっていると思います。

プログラミング関連で2018年で一番の経験は、Gantt Chart GeneratorというGoogle App Scriptのアドオンが想像以上にダウンロードされたことです。12月28日時点のユーザー数が 21848人、レビューは57件ついています。1口9.8ドルからという強気な寄付リンクを小さくつけていたら、数十人の方が寄付をしてくれました。2口以上寄付をしてくれる人もいて大変ありがたかったです。その中でも一番嬉しかったのは、コードをGithubに公開しているのですが、ここにスターが50弱ついたことです。自分が作ったものが評価されるということは本当に嬉しいものですね。

また、多くの人が使うからこそ得られる気づきがたくさんありました。例えば、設計の甘さから起こるバグ。世界各国で使われる想定をしていなかったので、時差やサマータイムの対応に苦しみました。他にも、メンテナンス性が考慮できていなくてアップデートするときに特定の手順を踏んでもらわないと動かなくなるとか、本当に様々なトラブルに遭遇しました。設計やテストの重要さを実体験で理解できたのは大きかったです。今後の個人開発、仕事のプロジェクトにこの経験を活かしていきたいと思います。

 

目標 3. 中学数学、数学IAをやり直す

これは途中で挫折しました。中1から始めて中2の図形までいきましたが、これがもう本当に面白くなかった。気分転換に中3の平方根とかやってみましたが、モチベーションがあがらず、あえなく断念しました。 無念。

f:id:takuya0206:20181228230129j:plain

あえなく散った僕の残念な学習履歴

 

目標 4. 筋力トレーニングを始める

これはバッチリ達成できました。NHKの筋肉体操を見ながら毎日やっています。プロテインも飲み始めました。筋肉は裏切らない。筋トレで70kgまでの増量を目指します。

 

 

その他

2018年の大きなトピックの1つはサウナとの出会いです。先輩サウナーに導かれて、錦糸町のニューウイングに行ったのですが、完全にやられました。今では週2でサウナに通っています。僕はもうお酒をやめてしまったので、友人の皆さん、今後は飲みではなくサウナに行きましょう。一緒に整いましょう。

 

2019年の目標

  • ヒンディー語を英検3級レベルで話せるようになる
  • アンガーマネジメントで怒りをコントロールする
  • 筋トレとサウナで心身の健康を保つ

2019年はこの3つを目標にしたいと思います。ヒンディー語はずっとやりたいと思っていていて、インドから帰国して4年近く経ちましたが、ようやく始められるほどの時間的余裕が作れそうです。まずは基本的なヒンディー語を覚えて、インド料理屋で裏メニューを頼むことを目指します。ゆくゆくはインド人をあっと驚かすほどの流暢なヒンディー語が話せるようになりたいです。

怒りの感情のコントロールはずっと自分の課題だと思っていて、仕事で感情的な議論をしてしまう度に反省をしていました。アンガーマネジメントは、anger(怒り)をmanagement(管理)するというもので、精神的ではなくシステム的なアプローチで怒りをコントロールするものです。これが出来たら一つ上のステージに自分が成長できる気がします。

筋トレとサウナはもはや習慣化しているのですが、引き続き継続して、心身の健康を維持したいと思います。2019年で32歳になりますし、これからは健康第一ですね。

 

終わりに

さて、2018年も皆さま大変お世話になりました。年末はどのようにお過ごしでしょうか。僕は明日から家族旅行に出かけ、大晦日に戻って自宅でゆっくりと年越しをする予定です。歳を重ねるに連れて、こういう年越しが理想的になってきました。それでは皆さまも良いお年をお迎えください。 2019年もどうぞよろしくお願いします。

 

 

「人生の100のリスト」作ってみた

もうすぐ32歳。ふと「残りの人生で自分のやりたいことが全部できるのかな?」「そもそも人生でやりたいことって何だったっけ?」と疑問に思うことがありました。そこで、今更ながら作ってみました、人生の100のリスト。作りながら自分が客観視できて、思いのほかやって良かったです。人生、楽しんだもの勝ち。

 

人生の100のリスト

人生の100のリスト

 

 

死ぬまでにやる人生の100のリスト

 

  1. 自分のやりたいことを仕事にする
  2. 海外で働く 達成(2014 - インドで働きました)
  3. スタートアップで働く 達成(2017 - COMPASSで働いています イマココ!)
  4. 外資系企業で働く
  5. 多国籍のチームで働く
  6. 少数精鋭のチームで働く
  7. 旅をしながら働く
  8. プロジェクトベースで働く
  9. チャリンチャリンビジネスを細々と運営する
  10. 教育機会の平等化の為に働く
  11. ソーシャルビジネスをする
  12. ボランティアをする
  13. 外貨を稼ぐ 達成(2015 - 初めてのお客さんはエジプト人でした)
  14. 時間単価1万円で働く
  15. 月に10日間だけ働いて暮らす
  16. 何かの分野のスペシャリストになる
  17. 起業する 達成(2009, 2015 - Omorey, Wasabiで起業しました)
  18. Exitする 達成(2016 - Wasabiを事業売却。志半ば...という感じでしたが)
  19. エンジェル投資をする
  20. 怒りの感情をコントロールする
  21. 承認欲求をコントロールする
  22. 寛容になる
  23. 相手を尊重してコミュニケーションできるようになる
  24. 煩悩を断ち切る
  25. 悟りを開く
  26. 英語を話せるようになる 達成(2016 - 英語学習についてはここ
  27. ヒンディー語を話せるようになる
  28. プログラミングを出来るようになる 達成(2018 -プログラミング学習についてはここ 
  29. 資産運用をする 達成(2018 - 投資信託を始めました
  30. 日本史の勉強をする
  31. 世界史の勉強をする
  32. 哲学の勉強をする
  33. 宗教の勉強をする
  34. 数学の勉強をする
  35. 経済の勉強をする
  36. 社会学の勉強をする
  37. 学士を取得する
  38. 修士を取得する
  39. 自分のブログを通じて人と会う
  40. 英語でブログを書く
  41. 世界中の人とインターネットを通じて交流する
  42. Webアプリをリリースする
  43. スマホアプリをリリースする 達成(2018 - 予防接種の管理アプリ作りました 
  44. ○万人規模のサービス/メディアを運営する 達成(2018 - GASのアドオンのユーザーが2万人超えました 
  45. ○億人規模のサービス/メディアを運営する
  46. Webメディアに載る 達成(2015 - 東洋経済に載りました 
  47. ラジオに出る 達成(2016 - NBC長崎放送に出ました 
  48. 新聞に載る 達成(2016 - 島原新聞に出ました 
  49. テレビに出る
  50. 探偵ナイトスクープに出る
  51. 講演をする
  52. パネルディスカッションに出る
  53. 大学で授業を持つ
  54. 電子書籍を出版する 達成(2017 - 日本語の文法書を書きました)
  55. 紙の本を出版する
  56. 47都道府県を全て訪れる
  57. 世界一周旅行をする
  58. インド一周旅行をする
  59. 宇宙旅行をする
  60. (もう一度)自転車旅行する
  61. (もう一度)ヒッチハイク旅行する
  62. 海外で暮らす 達成(2014, 2017 - インド、中国で暮らしました)
  63. 南国で暮らす
  64. 田舎で暮らす 達成(2016 - 島原半島で暮らしました)
  65. 島で暮らす
  66. インドの文化を体験する(まだまだ足りない)
  67. イスラムの文化を体験する
  68. 共産主義の文化を体験する
  69. アフリカの文化を体験する
  70. 信仰心を持つ
  71. 民族衣装を着て生活をする
  72. ○百万単位で寄付をする
  73. 漫画家に資金援助をする
  74. 政治家を支援する
  75. 行きずりの困っている人を助けて格好良く立ち去る
  76. カウチサーフィンのホストをする
  77. オーケストラを見る
  78. ミュージカルを見る
  79. ジャズバーに行く
  80. 映画の舞台挨拶を見る
  81. Got Talentを見る
  82. TEDを見る
  83. フラッシュモブに出くわす
  84. スタンディングオベーションの一人目で立つ
  85. ブラボー/ブラバー と一人目で言う
  86. ベジタリアンになる
  87. 筋トレで70kgまで増量する(2018/12/22現在は62kg)
  88. 現金を持たない生活をする
  89. 職住近接な生活をする
  90. ホログラム(立体映像)を自宅に導入する
  91. 自宅に書斎を作る
  92. アーロンチェアを買う
  93. ディスプレイを2枚買う
  94. Macbook Proを買う 達成(2018 - 最高!)
  95. ルンバを買う
  96. 食洗機を買う 達成(2018 - 人類が生み出した最高傑作でした)
  97. 乾燥機付き洗濯機を買う 達成(2018 - これまた最高でした)
  98. 一泊20万円以上のホテルに泊まる
  99. 一食5万円以上の食事をする
  100. 「人生の100のリスト」を全て達成して新しい100のリストを作る

 

100個もリストアップできないと思いましたが意外に大丈夫でした。ただ、これらを達成したら人生満足かと言うと、きっとそうではない気がしています。達成する後には新しい価値観を持つ自分がいるだろうし、そのときの自分でまた新しい「人生の100のリスト」を作りたいなと思います。人生はたった一度きり。精一杯楽しみたい。

 

 

【保存版】プログラミングを独学で脱初心者する為のロードマップ

元々IT系ではなかった僕ですが、必要に迫られてホームページを作ったことをキッカケに、コードを書くようになりました。「もっと上手くなりたい」と試行錯誤をしている内に、気がつけば仕事の中でもコードを書いて業務効率化するようになっていました。そして、先日ついに初めてのiOSアプリをリリースしました。ようやく自分の中でも、プログラミング初心者を脱した感覚があり、これまでの勉強法をまとめておきたいと思います。

 

f:id:takuya0206:20180922232919p:plain

*いまや黒い画面も怖くないぞ

 

独学で身につけるプログラミング

プログラミングの上達のコツは「作りたいものを作る」ことにあると思います。僕はホームページがキッカケだったので、HTML, CSS, JavaScriptから学習が始まりました。Web系の学習は成果が見えやすく、モチベーションが保ちやすいのでお薦めです。具体的なインプット(学習リソース)とアウトプット(成果物)を合わせて記述していくので、学習者の皆さんの「このぐらい勉強すれば、こういうことが出来るようになる」という指標になれば嬉しいです。

   

1. WordPressWebsiteを作る

インプット

Codecademy

ドットインストール

書籍

アウトプット 

メモ

まず初めに、WordPressというブログソフトウェアを使ってホームページの作成をしました。WordPressPHPという言語で動いているので、一応PHPの入門コースの動画を見てみたのですが、ほとんど理解できずに意味がありませんでした。しかし、実際にアウトプットのホームページは完成しています。この"わからないけど動く"というのは大事なことだと思っていて、乱暴に言えば初めのうちは理解できてなくても動けば良いぐらいだと思います。 

僕はCodecademyというサービスを使って、HTMLとCSSの勉強をしましたが、英語が得意ではない人はProgateを使うのが良いかもしれません。両サービスとも手を動かしながら学習できるのが特徴で、とても頭に入りやすいです。HTMLとCSSできるようになれば、それだけでとても見栄えの良いWebsiteを作ることが可能です。WordPressの環境設定は手間ではありますが、ググると大量に情報が出てくるので、特に気合を入れて勉強しなくて大丈夫だと思います。

 

2. JavaScriptで動的なWebsiteを作る

インプット

Codecademy

ドットインストール

 書籍

アウトプット

メモ

次にJavaScriptを使って、動きのあるホームページを作りました。アウトプットにあげたのは、友人のBarのホームページを作成したときのものです。Bootstrap を中心に外部のライブラリを使って実装しています。ある程度のプログラミングの基礎を掴めば、公開されているライブラリを活用して、それっぽいものが作られるようになってきます。

このときの学習は、お手本通りに書き写す「写経」が中心でした。写経はあまり楽しい学習法ではありませんが非常に効果的です。Codecademyと書籍で基本的な文法を学び、後はひたすらドットインストールの動画を真似していました。紹介している「JavaScript本格入門 」はとてもお薦めです。初級レベルならこの一冊で良いぐらいだと思います。ホームページを公開するには、独自ドメインをとってレンタルサーバーを借りてと、JavaScript以外の知識も入りますが、Google先生に聞きながら真似するだけで事足りると思います。

 

 

3. Node.jsでWebアプリケーションを作る

インプット

N予備校

  • プログラミング入門 Webアプリコース

書籍 

アウトプット 

メモ

ここでは外部のAPIを使ってアプリケーションを作り始めました。APIが使えるようになると、一気にプログラミングが楽しくなってきます。紹介している振り仮名ジェネレーターは業務の中でも大活躍してくれました。が、独学者にとっては、この辺りが学習の一つのハードルではないでしょうか。内容も難しくなってくるので挫折する人も多いと思います。

そこでお薦めするのがドワンゴが提供するN予備校です。はっきり言って、めちゃめちゃクオリティが高いです。環境構築、コマンドラインの使い方、セキュリティなど、実践的な内容がカリキュラムに組み込まれています。N予備校で勉強しつつ、JavaScript 第6版、通称サイ本で知識を深めるというのが自分に合っていて、かなりレベルアップすることができました。

 

 

4. React NativeでiOSアプリを作る

インプット

Udacity

アウトプット

バクシン

バクシン

  • Takuya Tokiwa
  • Travel
  • Free

メモ

JavaScriptでもReact Nativeという技術を使えばスマホアプリの開発が可能です。JavaScriptの魅力の一つは、この言語だけで様々なことを実現できることだと思います。ES6, ES7と、コードの書き方が多少変わったりするものの、基本的にはこれまで学習した内容を活かしてスマホアプリを作ることができました。

ここではUdacityのNanodegree Prgramを受講しました。安くはないですが(しかも最近値上げをしている)、カリキュラムの充実度を考えると費用対効果は悪くないと思います。Nanodegree Prgramの良いところは、1. コードレビューがあること、2. 学習コミュニティがあること、です。独学をしているとコードレビューを受ける機会があまりないので、凄く勉強になりました。

 

おわり

以上です。最近は、大人こどもを問わず、プログラミングの必要性が社会で論じられています。僕は全員がプログラミングを学ぶべきとは思いませんが、ひとつ確かに言えるのは、プログラミングがわかると仕事が楽になる、ということです。僕は1~2年間はプログラミングを勉強していますが、その時間的投資に対するリターンは充分にあったと感じています。単純作業が自動化できますから。それになにより純粋に、モノづくりは楽しいです。PC1台から始められて、仕事にも活かせる大人の趣味。そんな風に気軽に始めてみるのも良いかもしれません。独学者の皆さん、お互い頑張りましょう!

 

 

「曖昧性とのたたかい」より抜粋したプロジェクトマネジメントのチェックリスト

「曖昧性とのたたかい」という本をご存知でしょうか?日立製作所で、みどりの窓口などの開発に携わった名内氏が、自身のプロジェクトマネジメントの経験をまとめた名著で、プロジェクトマネージャーなら必読の一冊です。アジャイルやリーンというモダンな開発手法が確立されていないなかで、大型のシステム開発をする厳しさは想像に難しくありません。また、その厳しさがタイトルによく現れていると思います。

 

曖昧性とのたたかい

曖昧性とのたたかい

 

 

システム開発に関わるプロマネに必須のチェックリスト

「曖昧性とのたたかい」は疑うことのない名著ですが、SE出身の著者ということもあってか、システム設計への言及などその内容は多岐にわたります。そこで純粋なプロジェクトマネジメントの要素に主眼を置いて、自分に刺さったところを「契約フェーズ」「設計フェーズ」「実装フェーズ」に分けてリストアップしてみました。詳しくは本書の購入をお薦めしますが、概要を斜め読みしたい人は参考にどうぞ。

 

契約フェーズ

提案と交渉

ポイント
  • 提案依頼書に要求仕様などの詳細が書かれていることはまずない
  • 完璧で完全な契約にこだわりすぎると、顧客に嫌がられ失注する恐れがある
  • 曖昧さが残る状態が避けられない以上、この曖昧性をいかにコントロールするかがプロジェクトマネジメントの最大の課題である
チェックリスト
  • 仕様が膨張するものとして、予算増額の必要性があることを事前に伝える
  • 顧客からの仕様変更要求に際しては、必要な対策日程の確保と対策費用を負担していただくことを契約に盛り込む
  • 予算増額の論拠を用意しておく(当初見積もりの前提条件を明確にしておく)
  • 時間の許す限り、顧客の要求を文書化する
  • 仕様の膨張が濃厚であれば、開発段階を区切り、最初の段階だけを見積もらせてもらう
  • 契約納期と絶対納期(顧客側で死守しなければならない期限)を把握しておく
  • 契約納期には「仕様凍結後○ヶ月」のような条件をつけておく
  • 検収条件を「条件Xのとき結果Y」のような明示的なものにするか、検収期間を有限にして検収テストは全て顧客に実施してもらう
  • 見積もりは再見積もりが許される条件設定をしておく
  • 要求仕様が曖昧すぎる場合は、仕様確定までは「要員派遣ベースによる仕様確定契約」としてもらい、仕様確定後に「システム開発請負契約」にしてもらう

 

設計フェーズ

要件定義

ポイント
  • 受注が決定したら、全力を挙げて受注条件の明確化、再確認、システム仕様の早期確定に努めなければならない
  • 基本的に契約金額内で仕様をまとめることが両者にとって大事なことであり、かつ両者の利益につながるのだという共通認識を確認し合って仕様の確定に臨む
チェックリスト
  • 契約書のみならず(提案と交渉の時の)覚書や議事録も確認する
  • 検収条件をよく読み、無理なく検収されるような検収条件になっていることを確認する
  • 見積り条件や検収条件に不備があれば、今後どう正常化してゆくべきかを営業担当者とともに善後策、および顧客といかに交渉するか戦略を立てる
  • 打合せに入る前に、まず見積り / 契約条件に盛り込んだ(受注者側の考えている)システム仕様をより具体的に文書化して提示する
  • 詳細を説明した後、発注者からの「変更要求」を聞くようにするのが仕様の早期確定に有効であるばかりでなく、「仕様変更要求項目」の明確化にも役立つ
  • システム全体の開発費用は仕様確定後に決めるという段階的契約方式をとる場合も、顧客側には予算の腹づもりがあるはずなので 、総予算を聞き出して、この予算枠内で仕様をまとめるように顧客をリードする
  • いつまでにシステム仕様を固めるか全体工程の中で顧客と合意し決める

  • もし発注者側の体制や統制力に問題がある場合には、幹部、営業と協力して、発注者幹部に善処してもらえるよう早めに申し入れる

  • 業務仕様をどういう順序で確定していくかあらかじめ作戦を立てておく
  • プロトタイプ方式を採用するときは、終結時限(仕様凍結時限)を明確に定め、いつまでもやり直しや修正が続かないようにする
  • 何のためにシステムが必要とされ、何が一番重要なことなのかを全員が正しく理解する(真の目的を把握していれば、より合理的、より経済的な代案システムの提案も可能となり、システム機能の膨張の抑制につながる)
  • 業務の正確な理解に努める(正確な理解とは、その業務の目的、やらなければどういう不都合が生じるのかということまで理解すること)
  • 仕様追加がある場合は、要求しても無理だろうなどと考えず、粘り強く予算増額交渉をする
  • 仕様が凍結したら、新たな仕様変更要求が出てくる前に、仕様変更案件管理、変更承認手続き、顧客による変更予算認可手続きなどの管理方式を顧客と共同で用意する
  • 受注したら直ちに第三者を含めてプロジェクト推進作戦会議を開催し、多角的にリスク回避戦略を議論する

工程設計

ポイント
  • 受注後、プロジェクトマネジャーがまずやらねばならないことは、工程の設計と目標原価の設定

  • プロジェクト工程計画とは、そのプロジェクトに挑むプロジェクトマネジャーの作戦計画であるから、まさにマネジャーの、そのプロジェクトに関するすべての知識と認識、今後発生しうる各種の事態に対する予測を含めた見解を表現したものとなる

  • 人件費は、ざっと言えば投入工数のみで決まる。投入工数が予算以上に増えるのは工程(スケジュール)が遅延するか、開発量が膨れ上がるか、予想以上に品質が悪いかが主たる原因である。したがって、 コスト管理はとりも直さず、進捗管理、品質管理、仕様変更管理の問題に帰着する

チェックリスト
  • 稼働日(=納期)に絶対不可欠な機能と、無理をすればあとからでも追加可能な機能に分ける
  • やってみなければわからないことが多くても、最初に全貌を考えぬく積りで極力詳細な工程を設計する
  • PERT図の考えを取り入れ、前後関係、相互依存関係が明確になるようにする
  • 重要な仕事にはその前に必ず準備作業(仕事の前の仕事)が必要であることを忘れないように
  • 工程配分は過去のプロジェクト実績データを参考にすべきであるが、少なくとも3分の1の工程を設計工程に割り当て、手戻りのない設計を目指す
  • あらかじめどういう手段で進捗を計るのか考えておく。特に各工程の終了条件を明確に決めておく必要がある(定量的進捗度の把握が大事であるが、質的な進捗度の把握については中身のレビューで補う)
  • 計画時には悲観的に最悪事態を想定した準備を行い、実行時は楽観的に明るくプロジェクトを推進する
  • 最悪の事態に陥った場合、納期延期を申し入れる日を秘かに決めておく
  • 同時に納期までに完成が困難と予想されるときは逃げ道を考えておく(代替手段、部分稼働、従来システムとの並行運転など)
  • 工程表が作成できたら顧客と打合せを実施する。このときには、特に仕様凍結日、提出書類の承認期限、顧客側で準備してもらう各種ドキュメントなどの準備期限について合意を得る
  • プロジェクトで用意するドキュメント体系、およびその作成基準を定める
  • よく使われる業務用語(ジャーゴン)については、素人の人にもわかるような用語集(グロッサリー)を用意し、プロジェクトのステークホルダー全員が共通の理解を持てるようにする
  • 大規模プロジェクトの場合はプロジェクトマネジャーの補佐組織として、ライン設計部隊とは別のプロジェクト統括部隊を編成する
  • 開発するシステムの目的や基本コンセプト、プロジェクト運営の基本的考え方、プロジェクト共通基準、工程計画に関するプロジェクトマネジャーの考え方などを説明し、全員に理解してもらう(このような全員ミーティングは少なくともプロジェクトのスタート時、主要メンバーが揃って定期的進捗管理が始まったとき、全メンバーが揃ったときの3回は実施したほうがよい)

 

実装フェーズ

進捗管理

ポイント
  • 進捗を定量的、客観的に捉えるとともに、質的な面、つまり設計の充実度、ドキュメントの記述レベル、その内容なども重視して、工程(あるいはスケジュール)の進捗を妨げる問題点の早期把握に努めなければならない
  • 仕様変更はプロジェクトの円滑な遂行にはマイナスの影響を与えるが、仕様変更なしのプロジェクトは稀である。したがって、適切な仕様変更管理が必須になる
  • プロジェクトの成否を決めるのは、プロジェクトメンバーの力であり、そのチームとしての組織力
チェックリスト
  • 計画と実行の差を明確化することに主眼を置かなければならない。すなわち、遅れを遅れとして正しく認識できること
  • 進捗度の事前定義と全員への徹底
  • プログラム開発においては、無理をしてでも進捗度を定量的に把握する(ページ数、画面数、帳票数、コーディング行数、メモリー量、項目数、定義数、チェックリスト消化数など)
  • 責任追及より実態把握を重視。何の助言もなく厳しいだけの管理はかえって実態を隠蔽する危険性がある
  • 仕様確定工程は絶対遅れさせないようする。不幸にして顧客の体制が整備されていなかったり、顧客の決定が遅れてきたときは、幹部や営業の協力を得て、顧客幹部に善処してもらえるよう申し入れる
  • 進捗把握は担当者から報告された内容だけに頼ってはならない。自分の目で、現場現物を確認する
  • 定量的進捗度と同じぐらい重要なのがレビューを活用した質的な進捗度の把握・評価
  • レビューは部厚い仕様書ができ上がってから実施するのでなく、ある程度まとまれば少しずつ実施し、だんだんレビューの質あるいは難易度を高めてゆく
  • レビュアーの誰かが大幅な変更ややり直しの必要性を訴えるような場合、プロジェクトマネジャーは一番悲観的な意見を採択し、設計のやり直しを決断したほうがよい
  • ある担当者の開発部分の品質が時間が経っても一向に改善しないとき、その担当を更迭して一からやり直すのは勇気がいるが、思い切ってやり直しをしたほうが良い結果を生む
  • 要員不足だからといって、能力の劣る要員による応援はかえって混乱を招く
  • 工程表を書き直していると、工程が遅れてきた実態がわからなくなり危機感も薄くなる。工程表の書き直しは極力やめるべき(やむを得ず書き直して納期を先に延ばす場合は、思い切って実態を正直に反映したものにする)
  • 進捗状況がかんばしくないときは早めに営業担当者にその旨漏らしておく
  • 混乱したら思い切って開發を止めて、マネージャーの頭の中に実態が正しく認識されるまで徹底的に実態把握に努めるべき

仕様変更管理

ポイント
  • 顧客と開發側双方が仕様凍結を宣言できたあとでさえ、さらなる仕様変更が出てくることは実際には多い
  • 「仕様変更は不可避」であることを覚悟し、仕様変更による工程の混乱や、収益悪化のリスクを回避するために、変更があってもミニマムな対応ですませる作戦と仕掛けをあらかじめ用意する
チェックリスト
  • 仕様変更が続くということは単にベンダーだけの損失でなく、顧客にとってもリスクであり、損失であることを顧客によく理解してもらう
  • 仕様変更要求が出た場合、窓口は一元化し、案件管理の手順を定め、変更決定時のソフトウェア/ハードウェア/ドキュメントなどの変更手続きもあらかじめきちんと決めておく
  • バグの管理と仕様変更の管理ははっきり分け、別管理にしておく
  • システム稼働開始前後数ヶ月の仕様変更は、稼働に不可欠の機能を除き、絶対禁止

組織管理

ポイント
  • プロジェクトメンバーに意欲を持って仕事を行わせるにはモラル(morale: 士気)管理が欠かせない

  • 数十名、数百名に及ぶプロジェクトにおいては、メンバー間、チーム間、組織幹部や顧客との間の適切なコミュニケーションが大きな課題になる

チェックリスト
  • 担当する仕事が本人や会社にとっても、社会にとっても、どれだけ重要でどんな意義を持っているかを全員にはっきり意識させる

  • チーム編成にあたっては単に技術力中心に考えるのでなく、メンバーのモラルにもできるだけ配慮する

  • プロジェクトメンバーが揃った時点で顧客のリーダーから、開発しようとしているシステムの目的やシステムの全貌、将来構想などを説明してもらう

  • プログラム開発担当の人たちも、積極的に仕様決定プロセスに参加し、設計方式についても積極的に提案を行い、顧客とも直接議論する機会を増やす

  • プロジェクトメンバー全員を集め、各サブシステムの代表者が、自分たちが何をやって何に苦しんでいるのかを説明し合うプロジェクト説明会を開催する

  • 担当させている作業が終わったら次に何をやるのかを早めに示しておく(次の仕事がないと思って、仕事をペースダウンさせてしまうメンバーが出てくるため)

  • あとからプロジェクトに入ってきたメンバーには、単に設計基準を手渡すだけでなく、どうしてそういう基準を作っているのかにまで言及した教育をする

  • 大事な内容については別のルートからも確かめるなどのダブルチェックをする

  • 大事な連絡や決定事項は文書化が必要

  • 仕事の指示をするときは、やるべき仕事と、仕事の期限をはっきり設定することは当然として、何のためにその仕事をやる必要があるのか、仕事の目的を明示する

  • 逆に上位者からおおまかな指示を受けた場合、自分と上位者の間には経験や問題意識の差があるのが普通であるから、自分の理解したイメージを自分の言葉で表現して上位者に質問する

  • 良い報告はサボってもよいが、悪い報告はできるだけ早くする

  • マネジャーは嫌な報告でも喜んで聞いてやらなければならないし、なんらかの見返りも必要だ。適切なアドバイスが一番望ましいが、最低限激励だけでも良い

  • 悪い報告がタイムリーになされないのは部下の躾の悪さより、報告を受けたときのマネジャーの対応に大半の非があると考えて間違い

  • 週報や月報は、プロジェクト終了後の反省会の資料にもなるので、大規模プロジェクトや難プロジェクトでは必ず書くようにする

  • 部下やチームメンバーに週報、月報等の定期的報告を要求するなら、報告に対して、なんらかの返事やコメントを書くようにする

  • 報告に必ず部下を同行する人がいるが、こういうことは極力やめたほうがよい(部下の貴重な時間が無駄であるし、自分一人でゆけば、自分のわかっていないところが明確になって勉強になる)

 

最後に

プロジェクトマネジメント、簡単な仕事ではありませんよね?プロジェクトでは不確実性、曖昧性が不可避であり、どうしてもドタバタっとしてしまう時が出てしまいます。そんな時は、自分ひとりの知識で戦うのではなく、「曖昧性とのたたかい」のような先駆者の残した知見を頼りに、立ち向かっていきたいものです。本書のなかには、テストや外注先との付き合い方などにも触れられていますので、興味のある人はぜひ手に取ってみてください。自分も経験が積み重なっていけば、現代のシステム開発に適した知見をまとめて本にしたいなとも思ったり。今日も一日がんばりましょう。

 

曖昧性とのたたかい

曖昧性とのたたかい