2021-10-31 仕事でプロジェクトを任せられたときの私の計画方法
仕事でプロジェクトを任せられたときに私が実施している計画方法です。
プロジェクトというと規模が曖昧ですが、システムを開発して納品する案件ひとつとかを想定しています。大体 1, 2ヶ月で終わるようなボリューム感です。
流れ
- ゴールを確認する
- 期日を確認する
- 成果物を確認する
- 成果物の作成に必要なプロセスを洗い出す
- テスト仕様書を作成する
- プロセスをタスクに分割する
- 時間にタスクを割り当てる
- 計画に沿って実施する
ゴールを確認する
ゴールを確認します。
納品案件であれば、「〇〇システムを納品する」などと書きます。
製品の開発であれば、「バージョン〇〇をリリースする」「〇〇機能を実装する」などと記載します。
期日を確認する
いつまでに実施しないといけないのかを確認します。
成果物を確認する
何を満たさなければいけないのかを網羅的に書きます。
納品案件であれば、
- テスト仕様書を実施し、全て OK となったシステム
- 操作マニュアル
- アプリケーション仕様書
などと網羅的に書き出します。
これを行うのは、後から「マニュアル必要なの忘れてた！」となってスケジュールに大きな遅れが出ることを防ぐためです。
成果物の作成に必要なプロセスを洗い出す
成果物の作成に必要なプロセスを洗い出します。
- テスト済みアプリケーション
- テスト仕様書の作成
- 実装
- テストの実施
- レビューを受ける
- パッケージング
- 本番環境
- 〇〇に依頼する
- 操作マニュアル
- 作成
- レビューを受ける
などです。
テスト仕様書を作成する
スケジューリングを行う前に、テスト仕様書を作成します。
スケジューリングより先にこれを行うのは、アプリケーションの仕様を網羅的に洗い出すためです。特にエラー処理を洗い出すのに役立ちます。
また、テスト実施にかかる時間も見積もりやすくなります。
プロセスをタスクに分割する
「成果物を作成するためのプロセスを洗い出す」過程で洗い出したプロセスを、見積もることのできる単位に分割していきます。タスクと呼んでいます。
時間にタスクを割り当てる
時間にタスクを割り当てていきます。
Google カレンダーに時間を割り当てていきます。
プライベートでもやっているんですが、今日であればこんな感じです。
実際にはこんなに細かくスケジュールすることは少なく、半日単位でタスクを割り当てることが多いです。
計画に沿って実施する
計画が済んだら、計画に沿って実施していきます。
振り返りを行う
定期的に振り返りを行います。見積もりと実際にずれが生じている場合、見積もり時の想定と異なる状況になっているということなので、そのズレを認識して次に活かします。
遅れについては、以下のブログの考え方を取り入れています。
終わりに
以上、現状の計画方法でした。
まだまだ洗練させる余地はあると思います。繰り返し適用して、振り返りを行うことによってこの方法もより洗練させていければいいなと考えています。
2021-10-17 変形 GTD
GTD というタスク管理方法をプライベート、そして仕事に採用して一年が立ちました。
使う中で揉まれて、色々と変わった部分があるので、それについて一度まとめてみます。
ステータス
私が最初に GTD を導入した際は、 INBOX, NEXT ACTION, STAND FOR, SOME DAY の 4ステータスでした。
使う中で、ステータスの数はかなり増えました。
こんな感じ。 GTD の管理には ClickUp を利用しています。
SCHEDULED
NEXT ACTION に移動したタスクのうち、実施する時間を割り当てたものがここに移動されます。
時間の割り当ては Google Calendar で行っています。例としては以下のような形です。
経緯
「タスクに時間を割り当てて計画する」という手法を取り入れたタイミングで、 スケジューリング済みのタスクと未スケジューリングのタスクを区別する必要が生じました。
NEXT ACTION だけでは賄いきれなかったため、「SCHEDULED」のステータスを新設しました
Keep
「生活リズムに影響するから、朝起きたらすぐ太陽光を浴びるようにしよう」などの習慣化したいタスクなどは、こちらに移動されます。
他、例えば「人にやさしくしよう」みたいな心がけたいこと、「作業するときは細かく作業工程を洗い出そう」みたいな特定の作業を行うときに気をつけたいことなども、ここに移動します。
毎朝、 discord でここの内容が通知されます。
週に一度、全体的に振り返って意識できているかを確認します。習慣化できたと感じたり、状況が変わって必要ではなくなったと感じたものはクローズします。
経緯
「生活リズムに影響するから、朝起きたらすぐ太陽光を浴びるようにしよう」とかの習慣化したいがためのタスクは、一度実施したら終わりというわけでもないためタスクとするのに適しませんでした。
「習慣化したらクローズ」という形でタスクを作成することもできますが、そうすると NEXT ACTION のステータスがそれらで埋まってしまいます。かつ、それらのタスクは時間を割り当てて実施するようなものでもありません。
ということで、このステータスを新設しました。
増えすぎ
割とこのステータスは曲者で、たくさん問題が起きて、色々と試行錯誤しました。
まずひとつは、Keep が増えすぎたことです。
自分が生活で意識できることなんて、せいぜい多くても4, 5程度が限度でした。1,2,3程度が適切です。
対策の１つ目としては、積極的にここのタスクを「不要」としてクローズすることです。
優先度をつけ、優先度が低いものは積極的にクローズしていきました。もし本当に大事なものであれば、一度消してもまた再度いずれ作成されるだろうというロジックです。
加えて、年間の Keep という記事を esa に作り、「ある程度意識できた気はするけれど、これは一生大事にしていきたい」みたいなことはその記事に移動することにしました。年末か、どこか年に一度のタイミングで別途振り返る予定です。
意識できない
これは半年ほど経ってからですが、慣れのためか、あまり立てた KEEP を意識できていないという状況が続きました。KEEP の内容が、意識の難しい内容になってきたということもあります。
週に一度振り返った際、「これは今週全然意識できてなかったな」と思うことが増えました。
対策として、 API 経由で Keep のタスクを引っ張ってきて、一覧にして、discord に一日一回通知するようにしました。会社では gmail 宛にメールを飛ばしています。
割とこれは効果的でした。劇的な効果はありませんでしたが、週に一度振り返った際の感触がやや良くなったように思います。
まだ少しあるのですが、今日のところはこのへんで。以上です。
2021-10-17 ボールペンのインクが切れました。
2021-10-17
昨日、ボールペンがかすれて使えなくなりました。
少し前から、ボールペンのインクが切れたら写真を撮っています。前回は 8月31日でした。
ボールペンのインク切れというのは自分にとって割と感慨深いものでして。
くだらない内容ですが、記録の意味でここにちょいちょい記事として上げていこうと思います。
2022-01-23
会社で使っていたボールペンのインクがかすれてきました。
まだ残ってはいるんですが、書きにくいので早めの交換です。記録。
2021-10-03 OSS-DB Silver に合格しました。
先日、 OSS-DB Silver (v2.0) に合格しました。弊社では、開発課社員は
- PHP5 中・上級試験
- OCUP (FOUNDATION) もしくは UMTP (level2)
- OSS-DB Silver
の 3種の資格取得が強く推奨されており、私は残り OSS-DB silver のみでした。
この半期の目標は OSS-DB Silver 取得でした。とりあえず昨日で取得できたので、12月までの残り 4半期は可処分時間を増やすことができそうです。
振り返りを実施したので、可能な範囲で公開しておきます。フレームワークは YWT を利用してみました。
タイムライン
| 日時 | 作業内容 | 所要時間 |
|---|---|---|
| 2021-10-02 | 受験 | 1時間弱 |
| from 2021-09-11 to 2021-09-25 (3週) | 学習 | 週に平均30分 |
| from 2021-07-10 to 2021-09-05 (9週) | 計画・学習 | 週に平均1時間半 |
所要時間
9 * 90m + 3 * 30m = 900m = 15h
YWT
合格することを目標に逆算し、予定を立てた
わかったこと
このやり方はよかった。やはり、目標を立てることは大事だと思った。
一方で、「合格すること」を目標に据えることの妥当性については疑問点が残った。「合格すること」と、「知識を定着させること」を両立する必要があるように思った。
次やること
「合格する」という目標に加え、「対象の技術知識についての脳内インデックスを作成する」という目標を併せて設定する。
ある程度記事を先に読み、よさそうな教科書を選定した
わかったこと
徹底攻略の問題集をベースに勉強していたら、落ちていたかもしれないなと思う。先に記事を検索して「教科書の章末問題がよさげ」という情報を収集していたのは正解だった。
次やること
次回も、計画段階で情報を収集し、適切な資料を持って当たる。
ただ、前述した目標調整から逆算した結果、「公式マニュアルを頭から読む」という選択肢が出てくるとなおよい。
ある程度勉強したら一度目の受験、落ちたら二度目の受験という計画を立てた
わかったこと
一発で合格できたので結果論ではあるが、無駄に過剰な努力をせずに済んだ。実際に問題を受けて難しさを認識することで、あとどの程度勉強すればいいのかがわかる。
そう考えると、もう少し小刻みに、3回ほど受験するのも妥当なのかもしれない。
ただ、費用がかさむのでそこは要相談なところ。
次やること
次回も、一か八かの受験を一度、必ず受かるまで準備しての受験を一度行うのは確定。更に失敗を受けての一か八かの受験をもう一度挟むかどうかについては、その時の状況判断に委ねる。
最初に章末問題を解き、弱そうな箇所だけ教科書を読んだ
わかったこと
正直歯抜けになるのであまり効率は良くなかったように思う。頭から順に読んでいくのがやはり一番良いかと思った。
次やること
「この部分の教科書を読まない」という判断はより慎重に行う。すでに知っているような領域については、「流し読む」という形で労力をかけないようにする。
PostgreSQL のドキュメントを読んだ
空き時間に行ったものでありメインの時間を使ったわけではないが、公式ドキュメントを読んだ。
わかったこと
やはり公式ドキュメントは強い。そして面白い。そしてわかりやすい。
今回は頭から読む形でのみ利用したが、索引を利用してわからない単語、理解のあやふやな用語を検索するのも非常に有用だった。教科書の索引を利用するよりも圧倒的に理解しやすかった。
次やること
公式ドキュメントを読むという選択肢を積極的に選択する。また、わからない用語や理解のあやふやな用語については公式ドキュメントの記載を索引で検索し、読んで学ぶ
見直しをしなかった
わかったこと
早く帰りたかったし、余裕があると思ったので、受験中に見直しをしなかった。しかし結果を確認すると合格点 +4点での合格だった。
おそらく、あと数問間違えていれば死んでいた。そして、数点差で不合格となったとき、自分は見直しをしなかったことを深く後悔していただろう。今回は運が良かったが、そちらの結果に転ぶ可能性もあった。
見直しはサボらないようにしよう。
次やること
- 見直しを必ず行う
- そのために、テスト本番の手順についても事前に計画し、一度書き出しておく。
2021-10-03 「理想を掲げて現状を批判する」に +2アルファする
職場において理想を掲げて現状を批判すると、大抵嫌なやつになる。昔の私は間違いなくそうだったし、今もそうかもしれない。
ただ、それに加えて、
- 理想と現状の間にあるギャップは何なのかを認識する
- その理想とギャップを埋めるのに必要なものを認識して、計画する
さらに
- 実際にリソースを割り当てて実行する
まで行えば、!(嫌な奴) になれるのではないかと思った。嫌な奴でなくなるのであって、いい奴になれるわけではないと思うという意味で否定演算子を選定した。
2021-09-23 毎日15分、情報を整理するための時間を確保することにした
紙のノート、 Google Drive、esa.io、このブログ。
いつの間にか自分にとってあまり重要でない情報が増え、参照しづらい状態になっていた。
毎日15分時間を確保して、情報を整理する時間とすることにした。いつもは 21時から 22時の間に実施している。
対象は
- 紙のノート
- Github のリポジトリ
- Google Drive
- ブログ
とりあえず、紙のノートについてはある程度整理し、必要なものは再度ノートにまとめなおしたり、 esa.io にまとめたりした。
GitHub のリポジトリについても整理。何でもかんでもアップロードしていたので、サンプルコードをコピーしただけのプロジェクトやちょっとした書捨てスクリプトは削除した。昔は使っていたが、今は使っておらずメンテできていないプロジェクトはアーカイブ化した。
毎日たった15分だが割と進むもので、管理できていない感じのあった情報たちが割とハンドリングできる範疇に収まってきた実感がある。
このブログも玉石混合という感じになっているので、一度整理して、書き直すべきは書き直し、アーカイブするものはアーカイブしようと思う。
