プロジェクトにおけるタスク管理の大事な3つのポイント
タスク管理、皆さんやっていますか?仕事でタスク管理のマニュアルを書くことがあったので、良い機会だと思って、プロジェクトにおけるタスク管理に対して自分の考えを整理してみました。PMやディレクターなど、進行管理をする方の参考になれば嬉しいです。
プロジェクトのタスクは「優先度」「ステータス」「進捗」の3つの観点から管理せよ
プロジェクトの規模によってタスク管理の最適な手法は異なります。このエントリーでは、プロジェクトやチーム単位のタスクを専任の担当者が管理するときの最適な手法について考えてみたいと思います。結論を先に書くと、優先度・ステータス・進捗の3つの観点からタスクを管理をするのが良いのではないかと思います。
タスクの優先度を管理
いきなり逆説的なことを書きますが、タスクを管理する為には、タスクの総数を極力減らしましょう。総数が多くてメンバーがタスクを捌き切れない状況下では、どんな管理方法をとってもまず上手くいきません。「何をタスクにするか?」がプロジェクトのタスク管理において最も重要です。本当に取り組むべきものだけをタスク化するようにしましょう。
いざタスクを作るときには、全てのタスクに優先度をつけます。優先度のつけ方は色々なやり方がありますが、下記のように重要度と緊急度の2舳で考えることがお薦めです。
タスク化のテンプレート
- 優先度
- 期日
- 終了条件
- 担当者
- 必要工数
タスクには最低限、上記の情報を含めるようにしましょう。情報を埋める順序としては、まず「優先度」を決めます。その次に、優先度を考慮して「期日」と「終了条件」を後工程の人と調整してください(ここで適切に優先度が設定できていることが重要になってきます)。
「終了条件」は何をもってこのタスクを終了とするか?を定義することです。例えば、"○○の調査"というタスクがあった場合、調査の対象範囲はどこまでか、どういう形式で調査結果をまとめるか、誰に調査結果を報告するのか、という具合で終了条件を言語化していきます。調査結果は、テキストで箇条書きするだけで良いかもしれませんし、パワーポイントでプレゼン資料用に仕上げないといけないかもしれません。期日と終了条件はトレードオフになるケースも多いので、リソース状況と優先度を考慮した上で、実行可能な着地点を後工程の人とあらかじめ握っておきましょう。
最後に「担当者」をアサインします。その際に終了条件を説明し、「必要工数」をヒアリングして記録してください。タスクのステータスと進捗を管理するのに役立ちます。
タスクのステータスを管理
「未着手」「着手」「作業完了」「受領」と区分して、タスクのステータスを管理します。ステータス管理にはカンバン方式でカードを移していくやり方が適していると思います。そして、それぞれのステータスに合わせた対応をしていきます。
未着手のタスクへの対応
いつまでに着手する必要があるかを、期日と必要工数から逆算しておきます。そして、その日が近づいても着手されていない場合、担当者にアラートを出しましょう。また、タスク作成時から時間が空いた場合、プロジェクトの状況が変わっている可能性があるので、Slackや議事録などを常に見ておき、関連する情報があれば、タスクにメモを加えてあげておくと親切です。場合によっては、タスクの優先度が変わっていることもあります。こちらも同様にアラートが出せると素晴らしいです。
着手のタスクへの対応
※これは進捗管理として別で説明します。
作業完了のタスクへの対応
作業完了になっているタスクがきちんと終了条件を満たしているかを確認してください。確認は現地現物が鉄則です。担当者にただヒアリングするのではなく、成果物を見ながら終了条件を満たしているかを指差し確認してください。
また、タスクは作業が終わった後、その結果が後工程の人に渡るのが一般的です。後工程の人に連絡が入っているかも合わせて確認してください。後工程の人が受領してタスクは完了と考えるようにしましょう。
受領のタスクへの対応
一定の期間(2週間や1ヶ月)でのタスクの消化量を計測します。必要工数が出ているので、"この2週間では○人日分のタスクが消化できた”というように、定点的に記録をつけていってください。可能消化量がわかれば、プロジェクトの計画の精度が高まりますし、この消化量をいかに伸ばしていくかを工夫することで、プロジェクトの進行がよりスムーズになります。改善の指標の一つにして欲しいところです。
タスクの進捗を管理
着手しているタスクについては進捗を管理します。定量的に進捗がわかるものであればやりやすいのですが、残念ながら全てがそういうタスクではありません。その場合、タスクの終了条件を満たすまでのステップをマイルストーンとして置き、それらがどの程度完了しているかで進捗を測るのが良いです。それも難しい場合は、担当者に後どのくらいの時間で終わるのか定点的にヒアリングしてください。もし期日通りに終わらない可能性が出てきた場合は、すぐに担当者本人や上長にアラートを出しましょう。
また、進捗を確認する際は、何か困っていることがないか合わせてヒアリングをしましょう。もし何かが作業の妨げになっているのであれば、それを除外できるようにサポートしてあげてください。タスク管理者は作業者よりも広い視野や情報を持っていることが多いので、力になれることがきっとあるはずです。
期日通りにタスクが処理されていかない場合
もしここまでのやり方でタスク管理をして、それでもタスクが期日通りに処理されていかない場合、次のような可能性があります。これらはマネジメントによって解決すべきものです。しかるべき相手と相談し、課題解決に向けて動いていきましょう。
- 差し込みのタスクが多い
- リソースが足りていない
- メンバーのスキルセットが合っていない
以上です。僕の思う「こうすれば盤石ではないか」というタスク管理のやり方をまとめてみました。ここまでやるのは専任の担当者がいないと難しいかもしれませんが、大規模のプロジェクトではそうしたPMOを設置する体制を取っても良いのではないかと思います。ぜひ参考にしてみてください。
ヒンディー語の文字(デーヴァナーガリー文字)を学習するアプリを作ってみた
ついに本格的にヒンディー語の勉強を始めたのですが、やはりヒンディー語の文字である"デーヴァナーガリー文字"が最初のハードルです(こういうの → नमस्ते)。「これは繰り返し書いて覚えるしかないなあ」と感じる一方で、紙にペンというアナログ学習は性に合わない...。ということで、手書きでヒンディー語の文字を学習できるアプリを自作してみました。
HindiScript - Devanagari | スマホアプリ
言語学習の初期で重要なのは、その言語の音と文字を一致させながら記憶していくことだと思います。そこで、"手書きで学習できて簡単に模範の文字と比べられる"、"模範の音声が聞ける"、"発音の説明がある"、という3点に絞って、アプリを開発しました。学習の流れを簡単に紹介します。
学習の流れ
1. 模範文字を真似て覚える
「母音」「子音」「母音記号」などのカテゴリーから学習したいものを選びます。すると、模範文字が薄く表示されているので、それを真似しながら、文字を一つずつ記憶していきます。「簡単」「普通」「難しい」と自己評価をするようになっているので、繰り返し学習をしていき、覚えた!というタイミングで「簡単」を押してください。
2. 模範文字なしで練習する
「簡単」が押された文字は次の学習ステージに進み、模範文字の表示がなくなります。アルファベットの読みと音声を頼りに、文字を書いてみてください。その状態で練習を続け、もう大丈夫!というタイミングで「簡単」を押してください。2回の「簡単」でクリアとなって学習対象から外れます。これを繰り返し、全ての文字にクリアしたら完了です。
3. 学習Tipを読む
母音や子音はそのまま覚えるだけで大丈夫なのですが、結合文字など複雑なものに取り組むときはTipを読んでください。より理解を深められます。
搭載コンテンツ
- 母音
- अ, इ, ई, उ, ऊ, ऋ, ए, ऐ, ओ, औ
- 子音
- क, ख, ग, घ, च, छ, ज, झ, ट, ठ, ड, ड़, ढ, ढ़, ण, त, थ, द, ध, न, प, फ, ब, भ, म, य, र, ल, व, श, ष, स, ह
- 母音記号
- क, का, कि, की, कु, रु, कू, रू, कृ, के, कै, को, कौ
- 単語(母音と子音)
- अगर, आम, इधर, ईख, उमर, ऊब, ऋण, एक, ऐनक, ओर, और
- 単語(母音記号)
- नाम, पिता, पानी, बहुत, रुपया, दूध, शुरू, कृपा, देश, भैया, लोग, सौ, हाँ, नहीं,
- 単語(子音結合)
- स्कुल, अच्छा, अम्मा, अक्सर, फ़्लू, छुट्टी, उद्भव, अक्षर, कुत्ता श्वेत, नष्ट, आह्लाद, सह्य, धर्म, धर्मेतर, प्रेम, ट्रक, मित्र, ज्ञान
学習後のあなたのレベル
このアプリでの学習終了時は上記を想定しています。基本的な文字の学習は全て終了、単語の中での読みや書きに一部未習がある状態です。残りは次のステップになるであろう文法や語彙の学習をする際に慣れていけば良いかなと、敢えて情報量を制限しました。
技術的な話を少し
React Native (Expo) + Reduxで開発しました。手書き機能はexpo-pixi、合成音声はAmazon Polly、多言語対応はi18n-js、UIはReact Native Elementsを使っています。カラーをインドの国旗に合わせて、オレンジ、緑、青で構成したのが個人的なこだわりです。取り扱うデータ量が多くなかったので、サーバーを立てず、アプリ側に全ての情報を持たせています。
開発期間は3ヶ月程度ですが、本業の出勤前後の隙間時間と休日の一部を使って作業したので、実質的な工数は20人日ぐらいでしょうか。実際はアプリ開発よりもコンテンツ制作に苦労しました。模範文字は文字データとして持っているのですが、もちろんそれらは自分でタイピングする必要があり、ヒンディー語学習とアプリ開発を並行させるのが大変でした。その大変さもあって、今回は有料アプリにしています。ポチって頂けると飛び跳ねて喜びます。
終わりに
ヒンディー語を独学で学習している人はどのぐらいいるのでしょうか。日本語はもちろんですが、英語でググってもあまりヒンディー語に関する情報がないなあと感じています。IT業界にいる自分としては、自身で学習しながら、役に立つアプリや情報を発信していけたらなと考えています。ヒンディー語学習者の皆さん、ぜひ引き続きよろしくお願いします。
※新たにスピーキングの練習をするアプリと音読・リピーティング・シャドーイングの練習をするアプリも開発しました。
2018年を振り返って
あっという間に2018年も終わりですね。仕事納めが12月28日で無事に終わり、自宅に戻って振り返りの記事を書いています。この振り返りエントリーは2012年から続けているので、こうしてPCに向かうといよいよ年末だなあという実感が湧きます。気持ち良く1年を締めくくり、幸先良い新年を迎えたいものですね。
2018年の振り返り
- 1月 ... Gantt Chart Generatorをリリース
- 3月 ... Precedence Diagram Makerをリリース
- 5月 ... PMだった大型プロジェクトが終了
- 5月 ... 初めてのアメリカ旅行
- 6月 ... PMとして超大型プロジェクトが開始
- 8月 ... 鹿児島旅行
- 9月 ... サウナと出会う
- 10月 ... バクシンをリリース
- 11月 ... ダーツの旅
昨年末のエントリーでは「プロジェクトマネジメントのスキルアップ」「PythonとSQLを覚える」「中学数学、数学IAをやり直す」「筋力トレーニングを始める」の4つを2018年の目標として掲げていました。これらに関しては、途中で方向転換したものや、達成できていないものもあるのですが、おおむね満足のいく1年間になりました。一つずつ振り返ってみたいと思います。
目標 1. プロジェクトマネジメントのスキルアップ
スキルアップには、知識のインプットと、実践のアウトプットの両方が必要です。幸いなことに、2018年は○億円規模の大型プロジェクトを2つもPMとして担当することができて、非常に多くの経験値を積むことができました(その内の一つは今も継続中)。
知識のインプットでは、本を読んでまとめを言語化する、というサイクルを意識して取り組みました。ちなみに、読んだ本の一覧は下記です。プロジェクトマネジメントだけではなく、システムテストや要件定義、エンジニアリングなど、関連する分野の勉強も必要かなと思い、対象範囲を拡げて選択しました。もうちょっと読めたかなあという感じもありますが、実践に活かせる知識もたくさん得られたので及第点としたいと思います。★をつけたのはお薦めの本です。皆さんも是非読んでみてください。
2018年で読んだ本一覧
- ★ エンジニアリング組織論への招待
- 曖昧性との共存
- ★ 曖昧性とのたたかい
- 失敗しないITマネジャーが語る プロフェッショナルPMの神髄
- エクストリームプログラミング
- ユーザーストーリーマッピング
- カンバン仕事術
- 演習で身につく要件定義の実践テクニック
- はじめよう! プロセス設計 ~要件定義のその前に
- ★ Inspired: 顧客の心を捉える製品の創り方
- ★ 知識ゼロから学ぶソフトウェアテスト 【改訂版】
- ★ アジャイルな見積りと計画づくり
- ★ スクラム 仕事が4倍速くなる“世界標準”のチーム戦術
- ★ トヨタ 仕事の基本大全
- 無印良品は、仕組みが9割
- ★ 世界を動かすプロジェクトマネジメントの教科書
目標 2. PythonとSQLを覚える
これは方向転換をして、Python・SQLではなく、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の平方根とかやってみましたが、モチベーションがあがらず、あえなく断念しました。 無念。
目標 4. 筋力トレーニングを始める
これはバッチリ達成できました。NHKの筋肉体操を見ながら毎日やっています。プロテインも飲み始めました。筋肉は裏切らない。筋トレで70kgまでの増量を目指します。
その他
2018年の大きなトピックの1つはサウナとの出会いです。先輩サウナーに導かれて、錦糸町のニューウイングに行ったのですが、完全にやられました。今では週2でサウナに通っています。僕はもうお酒をやめてしまったので、友人の皆さん、今後は飲みではなくサウナに行きましょう。一緒に整いましょう。
2019年の目標
2019年はこの3つを目標にしたいと思います。ヒンディー語はずっとやりたいと思っていていて、インドから帰国して4年近く経ちましたが、ようやく始められるほどの時間的余裕が作れそうです。まずは基本的なヒンディー語を覚えて、インド料理屋で裏メニューを頼むことを目指します。ゆくゆくはインド人をあっと驚かすほどの流暢なヒンディー語が話せるようになりたいです。
怒りの感情のコントロールはずっと自分の課題だと思っていて、仕事で感情的な議論をしてしまう度に反省をしていました。アンガーマネジメントは、anger(怒り)をmanagement(管理)するというもので、精神的ではなくシステム的なアプローチで怒りをコントロールするものです。これが出来たら一つ上のステージに自分が成長できる気がします。
筋トレとサウナはもはや習慣化しているのですが、引き続き継続して、心身の健康を維持したいと思います。2019年で32歳になりますし、これからは健康第一ですね。
終わりに
さて、2018年も皆さま大変お世話になりました。年末はどのようにお過ごしでしょうか。僕は明日から家族旅行に出かけ、大晦日に戻って自宅でゆっくりと年越しをする予定です。歳を重ねるに連れて、こういう年越しが理想的になってきました。それでは皆さまも良いお年をお迎えください。 2019年もどうぞよろしくお願いします。
「人生の100のリスト」作ってみた
もうすぐ32歳。ふと「残りの人生で自分のやりたいことが全部できるのかな?」「そもそも人生でやりたいことって何だったっけ?」と疑問に思うことがありました。そこで、今更ながら作ってみました、人生の100のリスト。作りながら自分が客観視できて、思いのほかやって良かったです。人生、楽しんだもの勝ち。
死ぬまでにやる人生の100のリスト
- 自分のやりたいことを仕事にする
- 海外で働く 達成(2014 - インドで働きました)
- スタートアップで働く 達成(2017 - COMPASSで働いています イマココ!)
- 外資系企業で働く
- 多国籍のチームで働く
- 少数精鋭のチームで働く
- 旅をしながら働く
- プロジェクトベースで働く
- チャリンチャリンビジネスを細々と運営する 達成(2021 - GASのアドオンを有料化しました)
- 教育機会の平等化の為に働く
- ソーシャルビジネスをする
- ボランティアをする
- 外貨を稼ぐ 達成(2015 - 初めてのお客さんはエジプト人でした)
- 時間単価1万円で働く
- 月に10日間だけ働いて暮らす
- 何かの分野のスペシャリストになる
- 起業する 達成(2009, 2015 - Omorey, Wasabiで起業しました)
- Exitする 達成(2016 - Wasabiを事業売却。志半ば...という感じでしたが)
- エンジェル投資をする
- 怒りの感情をコントロールする
- 承認欲求をコントロールする
- 寛容になる
- 相手を尊重してコミュニケーションできるようになる
- 煩悩を断ち切る
- 悟りを開く
- 英語を話せるようになる 達成(2016 - 英語学習についてはここ)
- ヒンディー語を話せるようになる
- プログラミングを出来るようになる 達成(2018 -プログラミング学習についてはここ )
- 資産運用をする 達成(2018 - 投資信託を始めました)
- 日本史の勉強をする
- 世界史の勉強をする
- 哲学の勉強をする
- 宗教の勉強をする
- 数学の勉強をする
- 経済の勉強をする
- 社会学の勉強をする
- 学士を取得する
- 修士を取得する
- 自分のブログを通じて人と会う
- 英語でブログを書く 達成(2019 - Mediumを始めました)
- 世界中の人とインターネットを通じて交流する
- Webアプリをリリースする
- スマホアプリをリリースする 達成(2018 - 予防接種の管理アプリ作りました )
- ○万人規模のサービス/メディアを運営する 達成(2018 - GASのアドオンのユーザーが2万人超えました )
- ○億人規模のサービス/メディアを運営する
- Webメディアに載る 達成(2015 - 東洋経済に載りました )
- ラジオに出る 達成(2016 - NBC長崎放送に出ました )
- 新聞に載る 達成(2016 - 島原新聞に出ました )
- テレビに出る
- 探偵ナイトスクープに出る
- 講演をする
- パネルディスカッションに出る
- 大学で授業を持つ
- 電子書籍を出版する 達成(2017 - 日本語の文法書を書きました)
- 紙の本を出版する
- 47都道府県を全て訪れる
- 世界一周旅行をする
- インド一周旅行をする
- 宇宙旅行をする
- (もう一度)自転車旅行する
- (もう一度)ヒッチハイク旅行する
- 海外で暮らす 達成(2014, 2017 - インド、中国で暮らしました)
- 南国で暮らす
- 田舎で暮らす 達成(2016 - 島原半島で暮らしました)
- 島で暮らす
- インドの文化を体験する(まだまだ足りない)
- イスラムの文化を体験する
- 共産主義の文化を体験する
- アフリカの文化を体験する
- 信仰心を持つ
- 民族衣装を着て生活をする
- ○百万単位で寄付をする
- 漫画家に資金援助をする 達成(2020 - 00:00 Stadio を通じてやりました)
- 政治家を支援する
- 行きずりの困っている人を助けて格好良く立ち去る
- カウチサーフィンのホストをする
- オーケストラを見る
- ミュージカルを見る 達成(2019 - 劇団四季 パリのアメリカ人見てきました)
- ジャズバーに行く 達成(2019 - BLUE NOTE TOKYO 行ってきました)
- 映画の舞台挨拶を見る 達成(2020 - えんとつ町のプペルの舞台挨拶を見ました)
- Got Talentを見る
- TEDを見る 達成(2019 - TEDxOtemachiを見ました)
- フラッシュモブに出くわす
- スタンディングオベーションの一人目で立つ
- ブラボー/ブラバー と一人目で言う
- ベジタリアンになる
- 筋トレで70kgまで増量する(2018/12/22現在は62kg)
- 現金を持たない生活をする
- 職住近接な生活をする
- ホログラム(立体映像)を自宅に導入する
- 自宅に書斎を作る 達成(2020 - コロナ禍によって広い家に引っ越しました)
- アーロンチェアを買う 達成(2019 - エルゴヒューマン プロにしました)
- ディスプレイを2枚買う 達成(2019 - ASUS ZenScreenとiPadのDuetを導入)
- Macbook Proを買う 達成(2018 - 最高!)
- ルンバを買う 達成(2020 - これも最高!)
- 食洗機を買う 達成(2018 - 人類が生み出した最高傑作でした)
- 乾燥機付き洗濯機を買う 達成(2018 - これまた最高でした)
- 一泊20万円以上のホテルに泊まる
- 一食5万円以上の食事をする
- 「人生の100のリスト」を全て達成して新しい100のリストを作る
100個もリストアップできないと思いましたが意外に大丈夫でした。ただ、これらを達成したら人生満足かと言うと、きっとそうではない気がしています。達成する後には新しい価値観を持つ自分がいるだろうし、そのときの自分でまた新しい「人生の100のリスト」を作りたいなと思います。人生はたった一度きり。精一杯楽しみたい。
プログラミングを独学で脱初心者する為のロードマップ
元々IT系ではなかった僕ですが、必要に迫られてホームページを作ったことをキッカケに、コードを書くようになりました。「もっと上手くなりたい」と試行錯誤をしている内に、気がつけば仕事の中でもコードを書いて業務効率化するようになっていました。そして、先日ついに初めてのiOSアプリをリリースしました。ようやく自分の中でも、プログラミング初心者を脱した感覚があり、これまでの勉強法をまとめておきたいと思います。
*いまや黒い画面も怖くないぞ
独学で身につけるプログラミング
プログラミングの上達のコツは「作りたいものを作る」ことにあると思います。僕はホームページがキッカケだったので、HTML, CSS, JavaScriptから学習が始まりました。Web系の学習は成果が見えやすく、モチベーションが保ちやすいのでお薦めです。具体的なインプット(学習リソース)とアウトプット(成果物)を合わせて記述していくので、学習者の皆さんの「このぐらい勉強すれば、こういうことが出来るようになる」という指標になれば嬉しいです。
1. WordPressでWebsiteを作る
インプット
Codecademy
ドットインストール
書籍
アウトプット
メモ
まず初めに、WordPressというブログソフトウェアを使ってホームページの作成をしました。WordPressはPHPという言語で動いているので、一応PHPの入門コースの動画を見てみたのですが、ほとんど理解できずに意味がありませんでした。しかし、実際にアウトプットのホームページは完成しています。この"わからないけど動く"というのは大事なことだと思っていて、乱暴に言えば初めのうちは理解できてなくても動けば良いぐらいだと思います。
僕はCodecademyというサービスを使って、HTMLとCSSの勉強をしましたが、英語が得意ではない人はProgateを使うのが良いかもしれません。両サービスとも手を動かしながら学習できるのが特徴で、とても頭に入りやすいです。HTMLとCSSできるようになれば、それだけで見栄えの良いWebsiteを作ることが可能です。WordPressの環境設定は手間ではありますが、ググると大量に情報が出てくるので、特に気合を入れて勉強しなくて大丈夫だと思います。
2. JavaScriptで動的なWebsiteを作る
インプット
Codecademy
ドットインストール
- JavaScript入門
- JavaScriptで文字数チェッカーを作ろう
- JavaScriptで割り勘電卓を作ろう
- JavaScriptでパスワードジェネレータを作ろう
- JavaScriptで5秒当てゲームを作ろう
- JavaScriptでストップウォッチを作ろう
- JavaScriptでおみくじを作ろう
- jQueryで作るスライドショー
- jQueryで作るキャラ診断
書籍
アウトプット
メモ
次にJavaScriptを使って、動きのあるホームページを作りました。アウトプットにあげたのは、友人のBarのホームページを作成したときのものです。Bootstrap を中心に外部のライブラリを使って実装しています。ある程度のプログラミングの基礎を掴めば、公開されているライブラリを活用して、それっぽいものが作られるようになってきます。
このときの学習は、お手本通りに書き写す「写経」が中心でした。写経はあまり楽しい学習法ではありませんが非常に効果的です。Codecademyと書籍で基本的な文法を学び、後はひたすらドットインストールの動画を真似していました。紹介している「JavaScript本格入門 」はとてもお薦めです。初級レベルならこの一冊で良いぐらいだと思います。ホームページを公開するには、独自ドメインをとってレンタルサーバーを借りてと、JavaScript以外の知識も入りますが、Google先生に聞きながら真似するだけで事足りると思います。
3. Node.jsでWebアプリケーションを作る
インプット
- プログラミング入門 Webアプリコース
書籍
アウトプット
メモ
ここでは外部のAPIを使ってアプリケーションを作り始めました。APIが使えるようになると、一気にプログラミングが楽しくなってきます。紹介している振り仮名ジェネレーターは業務の中でも大活躍してくれました。が、独学者にとっては、この辺りが学習の一つのハードルではないでしょうか。内容も難しくなってくるので挫折する人も多いと思います。
そこでお薦めするのがドワンゴが提供するN予備校です。はっきり言って、めちゃめちゃクオリティが高いです。環境構築、コマンドラインの使い方、セキュリティなど、実践的な内容がカリキュラムに組み込まれています。N予備校で勉強しつつ、JavaScript 第6版、通称サイ本で知識を深めるというのが自分に合っていて、かなりレベルアップすることができました。
4. React NativeでiOSアプリを作る
インプット
Udacity
アウトプット (※現在はストア掲載は停止)
メモ
JavaScriptでもReact Nativeという技術を使えばスマホアプリの開発が可能です。JavaScriptの魅力の一つは、この言語だけで様々なことを実現できることだと思います。ES6, ES7と、コードの書き方が多少変わったりするものの、基本的にはこれまで学習した内容を活かしてスマホアプリを作ることができました。
ここではUdacityのNanodegree Prgramを受講しました。安くはないですが(しかも最近値上げをしている)、カリキュラムの充実度を考えると費用対効果は悪くないと思います。Nanodegree Prgramの良いところは、1. コードレビューがあること、2. 学習コミュニティがあること、です。独学をしているとコードレビューを受ける機会があまりないので、凄く勉強になりました。
おわり
以上です。最近は、大人こどもを問わず、プログラミングの必要性が社会で論じられています。僕は全員がプログラミングを学ぶべきとは思いませんが、ひとつ確かに言えるのは、プログラミングがわかると仕事が楽になる、ということです。僕は1~2年間はプログラミングを勉強していますが、その時間的投資に対するリターンは充分にあったと感じています。単純作業が自動化できますから。それになにより純粋に、モノづくりは楽しいです。PC1台から始められて、仕事にも活かせる大人の趣味。そんな風に気軽に始めてみるのも良いかもしれません。独学者の皆さん、お互い頑張りましょう!
「曖昧性とのたたかい」より抜粋したプロジェクトマネジメントのチェックリスト
「曖昧性とのたたかい」という本をご存知でしょうか?日立製作所で、みどりの窓口などの開発に携わった名内氏が、自身のプロジェクトマネジメントの経験をまとめた名著で、プロジェクトマネージャーなら必読の一冊です。アジャイルやリーンというモダンな開発手法が確立されていないなかで、大型のシステム開発をする厳しさは想像に難しくありません。また、その厳しさがタイトルによく現れていると思います。
システム開発に関わるプロマネに必須のチェックリスト
「曖昧性とのたたかい」は疑うことのない名著ですが、SE出身の著者ということもあってか、システム設計への言及などその内容は多岐にわたります。そこで純粋なプロジェクトマネジメントの要素に主眼を置いて、自分に刺さったところを「契約フェーズ」「設計フェーズ」「実装フェーズ」に分けてリストアップしてみました。詳しくは本書の購入をお薦めしますが、概要を斜め読みしたい人は参考にどうぞ。
契約フェーズ
提案と交渉
ポイント
- 提案依頼書に要求仕様などの詳細が書かれていることはまずない
- 完璧で完全な契約にこだわりすぎると、顧客に嫌がられ失注する恐れがある
- 曖昧さが残る状態が避けられない以上、この曖昧性をいかにコントロールするかがプロジェクトマネジメントの最大の課題である
チェックリスト
- 仕様が膨張するものとして、予算増額の必要性があることを事前に伝える
- 顧客からの仕様変更要求に際しては、必要な対策日程の確保と対策費用を負担していただくことを契約に盛り込む
- 予算増額の論拠を用意しておく(当初見積もりの前提条件を明確にしておく)
- 時間の許す限り、顧客の要求を文書化する
- 仕様の膨張が濃厚であれば、開発段階を区切り、最初の段階だけを見積もらせてもらう
- 契約納期と絶対納期(顧客側で死守しなければならない期限)を把握しておく
- 契約納期には「仕様凍結後○ヶ月」のような条件をつけておく
- 検収条件を「条件Xのとき結果Y」のような明示的なものにするか、検収期間を有限にして検収テストは全て顧客に実施してもらう
- 見積もりは再見積もりが許される条件設定をしておく
- 要求仕様が曖昧すぎる場合は、仕様確定までは「要員派遣ベースによる仕様確定契約」としてもらい、仕様確定後に「システム開発請負契約」にしてもらう
設計フェーズ
要件定義
ポイント
- 受注が決定したら、全力を挙げて受注条件の明確化、再確認、システム仕様の早期確定に努めなければならない
- 基本的に契約金額内で仕様をまとめることが両者にとって大事なことであり、かつ両者の利益につながるのだという共通認識を確認し合って仕様の確定に臨む
チェックリスト
- 契約書のみならず(提案と交渉の時の)覚書や議事録も確認する
- 検収条件をよく読み、無理なく検収されるような検収条件になっていることを確認する
- 見積り条件や検収条件に不備があれば、今後どう正常化してゆくべきかを営業担当者とともに善後策、および顧客といかに交渉するか戦略を立てる
- 打合せに入る前に、まず見積り / 契約条件に盛り込んだ(受注者側の考えている)システム仕様をより具体的に文書化して提示する
- 詳細を説明した後、発注者からの「変更要求」を聞くようにするのが仕様の早期確定に有効であるばかりでなく、「仕様変更要求項目」の明確化にも役立つ
- システム全体の開発費用は仕様確定後に決めるという段階的契約方式をとる場合も、顧客側には予算の腹づもりがあるはずなので 、総予算を聞き出して、この予算枠内で仕様をまとめるように顧客をリードする
-
いつまでにシステム仕様を固めるか全体工程の中で顧客と合意し決める
-
もし発注者側の体制や統制力に問題がある場合には、幹部、営業と協力して、発注者幹部に善処してもらえるよう早めに申し入れる
- 業務仕様をどういう順序で確定していくかあらかじめ作戦を立てておく
- プロトタイプ方式を採用するときは、終結時限(仕様凍結時限)を明確に定め、いつまでもやり直しや修正が続かないようにする
- 何のためにシステムが必要とされ、何が一番重要なことなのかを全員が正しく理解する(真の目的を把握していれば、より合理的、より経済的な代案システムの提案も可能となり、システム機能の膨張の抑制につながる)
- 業務の正確な理解に努める(正確な理解とは、その業務の目的、やらなければどういう不都合が生じるのかということまで理解すること)
- 仕様追加がある場合は、要求しても無理だろうなどと考えず、粘り強く予算増額交渉をする
- 仕様が凍結したら、新たな仕様変更要求が出てくる前に、仕様変更案件管理、変更承認手続き、顧客による変更予算認可手続きなどの管理方式を顧客と共同で用意する
- 受注したら直ちに第三者を含めてプロジェクト推進作戦会議を開催し、多角的にリスク回避戦略を議論する
工程設計
ポイント
-
受注後、プロジェクトマネジャーがまずやらねばならないことは、工程の設計と目標原価の設定
-
プロジェクト工程計画とは、そのプロジェクトに挑むプロジェクトマネジャーの作戦計画であるから、まさにマネジャーの、そのプロジェクトに関するすべての知識と認識、今後発生しうる各種の事態に対する予測を含めた見解を表現したものとなる
-
人件費は、ざっと言えば投入工数のみで決まる。投入工数が予算以上に増えるのは工程(スケジュール)が遅延するか、開発量が膨れ上がるか、予想以上に品質が悪いかが主たる原因である。したがって、 コスト管理はとりも直さず、進捗管理、品質管理、仕様変更管理の問題に帰着する
チェックリスト
- 稼働日(=納期)に絶対不可欠な機能と、無理をすればあとからでも追加可能な機能に分ける
- やってみなければわからないことが多くても、最初に全貌を考えぬく積りで極力詳細な工程を設計する
- PERT図の考えを取り入れ、前後関係、相互依存関係が明確になるようにする
- 重要な仕事にはその前に必ず準備作業(仕事の前の仕事)が必要であることを忘れないように
- 工程配分は過去のプロジェクト実績データを参考にすべきであるが、少なくとも3分の1の工程を設計工程に割り当て、手戻りのない設計を目指す
- あらかじめどういう手段で進捗を計るのか考えておく。特に各工程の終了条件を明確に決めておく必要がある(定量的進捗度の把握が大事であるが、質的な進捗度の把握については中身のレビューで補う)
- 計画時には悲観的に最悪事態を想定した準備を行い、実行時は楽観的に明るくプロジェクトを推進する
- 最悪の事態に陥った場合、納期延期を申し入れる日を秘かに決めておく
- 同時に納期までに完成が困難と予想されるときは逃げ道を考えておく(代替手段、部分稼働、従来システムとの並行運転など)
- 工程表が作成できたら顧客と打合せを実施する。このときには、特に仕様凍結日、提出書類の承認期限、顧客側で準備してもらう各種ドキュメントなどの準備期限について合意を得る
- プロジェクトで用意するドキュメント体系、およびその作成基準を定める
- よく使われる業務用語(ジャーゴン)については、素人の人にもわかるような用語集(グロッサリー)を用意し、プロジェクトのステークホルダー全員が共通の理解を持てるようにする
- 大規模プロジェクトの場合はプロジェクトマネジャーの補佐組織として、ライン設計部隊とは別のプロジェクト統括部隊を編成する
- 開発するシステムの目的や基本コンセプト、プロジェクト運営の基本的考え方、プロジェクト共通基準、工程計画に関するプロジェクトマネジャーの考え方などを説明し、全員に理解してもらう(このような全員ミーティングは少なくともプロジェクトのスタート時、主要メンバーが揃って定期的進捗管理が始まったとき、全メンバーが揃ったときの3回は実施したほうがよい)
実装フェーズ
進捗管理
ポイント
- 進捗を定量的、客観的に捉えるとともに、質的な面、つまり設計の充実度、ドキュメントの記述レベル、その内容なども重視して、工程(あるいはスケジュール)の進捗を妨げる問題点の早期把握に努めなければならない
- 仕様変更はプロジェクトの円滑な遂行にはマイナスの影響を与えるが、仕様変更なしのプロジェクトは稀である。したがって、適切な仕様変更管理が必須になる
- プロジェクトの成否を決めるのは、プロジェクトメンバーの力であり、そのチームとしての組織力
チェックリスト
- 計画と実行の差を明確化することに主眼を置かなければならない。すなわち、遅れを遅れとして正しく認識できること
- 進捗度の事前定義と全員への徹底
- プログラム開発においては、無理をしてでも進捗度を定量的に把握する(ページ数、画面数、帳票数、コーディング行数、メモリー量、項目数、定義数、チェックリスト消化数など)
- 責任追及より実態把握を重視。何の助言もなく厳しいだけの管理はかえって実態を隠蔽する危険性がある
- 仕様確定工程は絶対遅れさせないようする。不幸にして顧客の体制が整備されていなかったり、顧客の決定が遅れてきたときは、幹部や営業の協力を得て、顧客幹部に善処してもらえるよう申し入れる
- 進捗把握は担当者から報告された内容だけに頼ってはならない。自分の目で、現場現物を確認する
- 定量的進捗度と同じぐらい重要なのがレビューを活用した質的な進捗度の把握・評価
- レビューは部厚い仕様書ができ上がってから実施するのでなく、ある程度まとまれば少しずつ実施し、だんだんレビューの質あるいは難易度を高めてゆく
- レビュアーの誰かが大幅な変更ややり直しの必要性を訴えるような場合、プロジェクトマネジャーは一番悲観的な意見を採択し、設計のやり直しを決断したほうがよい
- ある担当者の開発部分の品質が時間が経っても一向に改善しないとき、その担当を更迭して一からやり直すのは勇気がいるが、思い切ってやり直しをしたほうが良い結果を生む
- 要員不足だからといって、能力の劣る要員による応援はかえって混乱を招く
- 工程表を書き直していると、工程が遅れてきた実態がわからなくなり危機感も薄くなる。工程表の書き直しは極力やめるべき(やむを得ず書き直して納期を先に延ばす場合は、思い切って実態を正直に反映したものにする)
- 進捗状況がかんばしくないときは早めに営業担当者にその旨漏らしておく
- 混乱したら思い切って開發を止めて、マネージャーの頭の中に実態が正しく認識されるまで徹底的に実態把握に努めるべき
仕様変更管理
ポイント
- 顧客と開發側双方が仕様凍結を宣言できたあとでさえ、さらなる仕様変更が出てくることは実際には多い
- 「仕様変更は不可避」であることを覚悟し、仕様変更による工程の混乱や、収益悪化のリスクを回避するために、変更があってもミニマムな対応ですませる作戦と仕掛けをあらかじめ用意する
チェックリスト
- 仕様変更が続くということは単にベンダーだけの損失でなく、顧客にとってもリスクであり、損失であることを顧客によく理解してもらう
- 仕様変更要求が出た場合、窓口は一元化し、案件管理の手順を定め、変更決定時のソフトウェア/ハードウェア/ドキュメントなどの変更手続きもあらかじめきちんと決めておく
- バグの管理と仕様変更の管理ははっきり分け、別管理にしておく
- システム稼働開始前後数ヶ月の仕様変更は、稼働に不可欠の機能を除き、絶対禁止
組織管理
ポイント
-
プロジェクトメンバーに意欲を持って仕事を行わせるにはモラル(morale: 士気)管理が欠かせない
-
数十名、数百名に及ぶプロジェクトにおいては、メンバー間、チーム間、組織幹部や顧客との間の適切なコミュニケーションが大きな課題になる
チェックリスト
-
担当する仕事が本人や会社にとっても、社会にとっても、どれだけ重要でどんな意義を持っているかを全員にはっきり意識させる
-
チーム編成にあたっては単に技術力中心に考えるのでなく、メンバーのモラルにもできるだけ配慮する
-
プロジェクトメンバーが揃った時点で顧客のリーダーから、開発しようとしているシステムの目的やシステムの全貌、将来構想などを説明してもらう
-
プログラム開発担当の人たちも、積極的に仕様決定プロセスに参加し、設計方式についても積極的に提案を行い、顧客とも直接議論する機会を増やす
-
プロジェクトメンバー全員を集め、各サブシステムの代表者が、自分たちが何をやって何に苦しんでいるのかを説明し合うプロジェクト説明会を開催する
-
担当させている作業が終わったら次に何をやるのかを早めに示しておく(次の仕事がないと思って、仕事をペースダウンさせてしまうメンバーが出てくるため)
-
あとからプロジェクトに入ってきたメンバーには、単に設計基準を手渡すだけでなく、どうしてそういう基準を作っているのかにまで言及した教育をする
-
大事な内容については別のルートからも確かめるなどのダブルチェックをする
-
大事な連絡や決定事項は文書化が必要
-
仕事の指示をするときは、やるべき仕事と、仕事の期限をはっきり設定することは当然として、何のためにその仕事をやる必要があるのか、仕事の目的を明示する
-
逆に上位者からおおまかな指示を受けた場合、自分と上位者の間には経験や問題意識の差があるのが普通であるから、自分の理解したイメージを自分の言葉で表現して上位者に質問する
-
良い報告はサボってもよいが、悪い報告はできるだけ早くする
-
マネジャーは嫌な報告でも喜んで聞いてやらなければならないし、なんらかの見返りも必要だ。適切なアドバイスが一番望ましいが、最低限激励だけでも良い
-
悪い報告がタイムリーになされないのは部下の躾の悪さより、報告を受けたときのマネジャーの対応に大半の非があると考えて間違い
-
週報や月報は、プロジェクト終了後の反省会の資料にもなるので、大規模プロジェクトや難プロジェクトでは必ず書くようにする
-
部下やチームメンバーに週報、月報等の定期的報告を要求するなら、報告に対して、なんらかの返事やコメントを書くようにする
-
報告に必ず部下を同行する人がいるが、こういうことは極力やめたほうがよい(部下の貴重な時間が無駄であるし、自分一人でゆけば、自分のわかっていないところが明確になって勉強になる)
最後に
プロジェクトマネジメント、簡単な仕事ではありませんよね?プロジェクトでは不確実性、曖昧性が不可避であり、どうしてもドタバタっとしてしまう時が出てしまいます。そんな時は、自分ひとりの知識で戦うのではなく、「曖昧性とのたたかい」のような先駆者の残した知見を頼りに、立ち向かっていきたいものです。本書のなかには、テストや外注先との付き合い方などにも触れられていますので、興味のある人はぜひ手に取ってみてください。自分も経験が積み重なっていけば、現代のシステム開発に適した知見をまとめて本にしたいなとも思ったり。今日も一日がんばりましょう。
「知識ゼロから学ぶソフトウェアテスト」でテストの基本を学ぶ
ソフトウェア開発において切っても切り離すことのできないのが不具合(バグ)。そして、そのバグと表裏一体な存在がテスト。プロジェクトマネジメントをするうえで、テストを適切に工程へ組み込むことは非常に重要なことですが、PMがテストの中身を全く把握していないのは良くないと思い、「知識ゼロから学ぶソフトウェアテスト」を読んでみました。この本、本当に知識ゼロでも読むことができるのでお薦めです。
ソフトウェアテストの実力診断
この本は「完全無欠なソフトウェアテストは可能か?」という問いかけから始まります。そして、いかに完全なソフトウェアテストが難しいものであるかを示すために下記の演習問題が出題されます。
このプログラムでは、ユ ーザーが三つの整数を入力します。この三つの値は 、それぞれ三角形の3辺の長さを表すものとします 。プログラムは、三角形が不等辺三角形 、二等辺三角形 、正三角形のうちのどれであるかを決めるメッセ ージを印字します 。このプログラムをテストするのに十分と思われる一連のテストケースを書いてください。
いかがでしょうか。テストケースのイメージ、湧きますか?僕もこの問題にチャレンジしてみたので、参考まで三角形の判定プログラムとそのテストコードを貼っておきます。※Node.jsのMochaとChaiで書きました。
どう思いますか?これで適切にテストパターンの洗い出しが出来ていると思いますか?...残念ながら答えは「いいえ」です。例えば、僕が書いたコードだと"0, 0, 0"とユーザーが入力した場合でも、正三角形と判定されてしまいます。これは正しい挙動とは言えません。
こうして実際に自分でやってみるとテスト設計の難しさがよくわかります。やはり専任の経験あるテスト担当者がいなければ、品質を担保して製品をリリースすることは難しいでしょう。
では、次に実際にどのようなテストが行われるべきなのかを見てみたいと思います。
ブラックボックステスト
ブラックボックステストは、プログラムを一種のブラックボックスと見立て、さまざまな入力を行うことによって、ソースコードを利用せず(見ずに)行う、というものです。本によれば、現在のソフトウェアテストの大半はこの手法が使用されているとのこと。さっそく詳細を見てみましょう。
同値分割法と境界値分析法
同値分割法
同値分割法は大きく次のような手順で進んでいきます。
- 同値分割
- 有効同値、無効同値に分類
- テストケースを書く
同値分割とは、入力領域をいくつかのクラスに分けて、そのクラスの中の値は同値とみなす行為です。先ほどの三角形判定プログラムのUIが、ユーザーが任意の値を自由に入力できるフォームであると仮定すると、「数字」「文字」「記号」というようにクラス分けできると思います。
次に、有効同値と無効同値ですが、システム仕様から見て、有効な値か無効な値かという意味です。三角形判定プログラムでは、三つの整数が求められている値ですから、有効同値が「数字」、無効同値が「文字」「記号」ということになります。
最後にテストケースを書いていきます。三角形判定プログラムは、入力値が三つの整数だけで、無効同値も2種類しかありませんので、全ての有効同値と無効同値の組み合わせの強固なテストケースが書けると思います。しかし、実際のプログラムでは、無効同値の数や組み合わせ数が多く、テストケースを作ることが困難なこともあります。その場合は、テストケースを省略せざるを得ませんが、だからと言ってバグが起きても良いわけではありません。ちなみに、僕が書いた三角形判定プログラムでは「あ、あ、あ」と入力しても正三角形と出力されます。苦笑
境界値分析法
境界値分析法は、入力領域の境界に焦点を置いてテストを行う手法です。三角形判定プログラムでは、そもそも仕様が「三つの整数」としてあるのが問題でもあるので、整数の境界に焦点を置くのはあまり良いアイディアではありません。ここは三角形が成り立つ数値か?というところに視点を切り替えるべきでしょう。そうすると、入力領域は整数の中の「正の数(1以上の数値)」となります。
では、正の数の境界はどこか考えてみましょう。下の境界は簡単ですね。0以下は正の数ではなくなります。一方、上の境界はどうでしょうか。正の数に上限はありませんので、数値はどこまでも大きくなります。しかし、システム的に処理できる数値には上限があります(JavaScriptの場合は 2^53 - 1)。なので、仕様ではどこかに上限を設定しておくべきだと思います。
実際のテストでは、異なる処理が行われる一番近い2地点を用います。三角形判定プログラムの下の境界で言うと、「0」と「1」です。この境界値分析法と同値分割法を組み合わせることで、効果的かつ効率的にテストケースを作ることができます。
ディシジョンテーブル
ディシジョンデーブルは、すべての入力の組み合わせとそれに対する出力を表にまとめたものです。三角形判定プログラムでは、数値によって、「正三角形」「二等辺三角形」「不等辺三角形」と出力結果が変わります。組み合わせの複雑になるので、それらを表に可視化することで、漏れを防ぐことができます。基本のアイディアは同値分割法・境界値分析法と同じですが、多数の入出力をチェックするときに有効な手段となります。
自分の書いたコードでやってみました。本プログラムでは、各三角形ごとの組み合わせの入力値を書いてまとめた方がわかりやすいかなと思いました。本では、状態は「TRUE」「FALSE」だけの記載でしたが、実態に合わせて臨機応変にしても良いと思います。しかしまあ散々な結果ですね。ひどい。苦笑
状態遷移テスト
状態遷移テストは、状態によって出力結果が変わる場合に用いられるテストです。どういうイベントのときに、どのように状態が遷移するかを一覧にし、各遷移をチェックしていくというものですが、この三角形判定プログラムの例では説明できそうにありません。詳細は下の記事がよくまとまっているので参考にしてください。
ランダムテスト(モンキーテスト)
これはランダムにソフトウェアを操作し、バグを洗い出すテストです。著者はこの手法に関しては、批判的な意見を持っているようで、推奨していませんでした。テスト設計の必要もないし、一定数のバグは見つかるだろうが、バグはランダムテストでは見つからないところにまだまだ潜んでいると。
以上がブラックボックステストの手法として紹介されているものでした。ソフトウェアの複雑さにもよりますが、「同値分割と境界値分析 → ディシジョンテーブル → 状態遷移テスト」は、どのソフトウェアにおいても最低限実施すべきものだと思います。ランダムテストについては、個人的にはそこにテスターの労力を割くのであれば、別のテストを実施した方が良いと思いますね。
まとめ
本では、ブラックボックステスト以外にも「探索テスト」「非機能テスト」「セキュリティテスト」などの重要なものが説明されています(詳細はぜひ本をお読みください)。月並みな感想ですが、テストの奥深さと難しさに驚きました。プログラムを書くこと以上にテストを作ることの方が難しいのではと思ったぐらいです。品質要求を満たしたプロダクト、不具合のないプロダクトを出すために必要な労力を改めて認識し、今後のプロジェクトマネジメントに活かしていきたいと思います。