ペーパードライバー卒業への道
(DALL-E3によって生成しました)
この記事はpyspa アドベントカレンダー 2023の4日目です。
昨日は@tokibitoでした。
ペーパードライバー
私は20年前に免許を取って以来、車を運転したことは片手で数えられるレベルの完璧なペーパードライバーでした。
結婚して子供ができてからも旅行はいつもタクシーや公共交通機関を利用していましたが、今回は軽井沢へ旅行をすることになったので、久々に車を運転してみることにしました。
準備
運転に関してはほぼ初心者だった私は、以下のステップで準備を進めました。
ペーパードライバー講習
実際の車を使用して、基本的な操作や運転のコツを学びました。
ペーパードライバー講習は現地にいかなくてもわざわざ近くまで車で来てくれて、最後は自宅前で終了できるという非常に便利なものでした。
また、子供を連れて乗ってもOKとのことだったので（チャイルドシートも用意してくれる）、夫婦そろってペーパードライバー講習を受けることができました（妻もペーパードライバーだった）
ETCカードの手配
高速の運転練習をしたかったので、この機会にETCカードを発行しました。
ボタン1つで発行できて、1週間ほどで自宅に届きました。
驚くほど簡単でした。
レンタカーの手配
ペーパードライバー講習で使った車がプリウスだったということもあり、トヨタレンタカーを使ってプリウスを選択することにしました。
Web上では特に本人確認等もなく、かなりスムーズに予約することができました。
車の説明書を読む
車の機能が多すぎて一発で覚えるのは不可能ですが、やらないよりマシと思ってプリウスの説明書600ページ超に目を通しました。
YouTubeを使った予習・復習
YouTubeには車の操作についての動画もたくさんあるので、それらを見て予習していました。
Googleストリートビューでの経路の確認
当日どのように移動するかをシミュレーションしながら、その経路にそってGoogleストリートビューを眺めてみて、どのようなものが見えるのかを確認していきました。
それにより、例えば「家の前の道は普段は右折可能だが平日7:30 - 9:30は右折禁止となるのでこのルートは使えない」など、普段の徒歩生活では気づけなかった問題も洗い出すことができました。
車につけるアクセサリーの手配
子供を数時間もチャイルドシートに縛り付けるので、子供の退屈しのぎをどうするかが課題でした。
普段家ではあまり動画等を見せていないのですが、今回はやむなしということで動画閲覧用のアクセサリーを導入することにしました。
当日
往路
首都高が難しいというアドバイスを友人からもらっていましたが、本当にその通りで首都高が一番大変でした。
ただでさえ慣れない運転をしている上に、子供も乗り慣れていなくて車酔いして泣いたりしていて、その状態で平静を保ちながら運転するのが一番きつかったです。
後でFitbitの記録を見たら、首都高を抜けるまでの間は心拍数的に運動をしていたことになっていたようです。
自分と子供の疲労回復のために、こまめな休憩をとって移動していたのですが、それが裏目に出て軽井沢の市街に着いた頃には日が落ちてしまいました。
そこからさらに山の中の目的地に移動しなければならないのですが、さらに悪いことに雨も降ってきていました。
雨で真っ暗の中の山道を運転するのはかなりハードでした。
道路の中心線もかすんで見えない状態だったので、とにかく低速での安全運転を心がけてなんとかたどり着くことができました。
復路
慣れたこともあり、往路よりはだいぶスムーズに帰ることができました。
関越道を走行中にPAで昼食休憩して、その後出発したときに太陽の日差しがポカポカと温かく感じたので、直感的にこれは危険だと感じました。
多少の慣れで緊張感が緩んできたので、眠気がきそうな気配を感じたのです。
これはまずいと思ったので、走行して10分程度ですぐに次のPAで休憩しました。
首都高に入った後は、友人からのアドバイス通り山手トンネルを使いました。ほぼ一直線なので本当に楽でした。
終わりに
普段から運転に慣れている人にとってはバカバカしい内容だったかもしれませんが、慣れていない自分にとっては常識のようなことも全然わからないので大変でした。
ペーパードライバーを卒業したい人は参考にしてみてください。
ChatGPTで個人開発を爆速にする
ChatGPTが登場してから始めての大型連休で、自分も久々にまとまった時間がとれたので個人開発をしていました。
ほこりがつもったソフトウェアプロジェクトを取り出すと、大抵の場合はライブラリのアップデートや連携サービスのアップデート対応などに時間を費やしてしまい、せっかくの貴重な休日を環境構築だけに費やすというのが大変憂鬱でした。
しかし、ChatGPTのおかげでこうした個人開発も全く苦ではなくなりました。
以下、自分が取った方法を説明します。
ここでは、個人のプライベートリポジトリでの開発プロジェクトを想定しています。 OSSの場合はこの方法をそのまま適用すると色々課題があると思うのでご注意ください。
方法
- GitHub（または類似サービス）を開きます。
- 大量のIssueを登録します。登録方法のコツは後述します。
- 各Issueに対してChatGPTに質問し、回答結果をコピーしておきます。
- Issueを一つずつ解決していきます。ポモドーロタイマーを使って、1-2個のIssueを1ポモドーロで解決すると効率が良いです。
- 作業中に新たな問題やアイデアが見つかった場合は、全てIssueに追加します。
Issue登録のコツ
- あまり真面目に書かない: 個人プロジェクトなので、簡潔に書いても大丈夫です。重要なのは、忘れないようにIssueに記録することです。
- タグ付けは真面目に行う: どのIssueに取り組むかを決める際に参考になるため、タグ付けは丁寧に行いましょう。例えば、バグと改善案を分けるだけでも役立ちます。
- 細かく分ける: 複数のエラーが同時に発生していても、それぞれが別のエラーであればIssueを分けましょう。
結果
こんなフローでやるだけで、圧倒的に生産性が変わりました。 自分の場合、数年前に作って放置してたソフトウェアプロジェクトを取り出して作業したら、1日でIssueを35個登録し、18個クローズできました。
それだけでなく、退屈な環境構築問題潰しの時間も減るのでモチベーションも上がり、さらに作業が明確になったIssueリストが残るので休暇が終わってもスキマ時間に作業しやすくなり、継続的な開発のモチベーションが上がります。（多分。まだ休暇明けてないので希望的観測）
もう一つ気づいたのが、ChatGPTによる教育効果です。
ChatGPTの結果をコピペするだけでも、きちんと内容を理解していくことでかなりの勉強の効果を感じました。
今までだと環境構築などで色々回り道をして、へとへとになってようやく正解にたどりつく、みたいにしていましたが（それももちろん勉強になることは知っていますが）、確実に問題の本質をとらえ、それに対する解説をしてくれると勉強効率が桁違いです。
「それでも地道に勉強するほうが身につく」という人もいるでしょうが、どのみちChatGPTでは解決できない問題もまだまだあるので（例えば最新バージョン固有の問題など）、従来どおりの地道な調査がなくなるわけではないです。
そうした苦労を全部の問題に対してやる必要は自分はないと思います。
ChatGPTとこれからの知識人：新しい時代に求められるスキルとは？
あまりに忙しくてブログを更新できていませんが、これだけは今後のために記録を残しておきたいと思い書いておきます。
推敲はほぼしてないので乱文・乱筆をお許しください。
DISCLAIMER
ChatGPT関連の記事やツイートは忙しくてほぼ読んでません。
記載されている内容は間違っている可能性があります。
アカウント作成から課金まで
私が初めてOpenAIのアカウントを作ったのは2023/3/19(日)でした。
世間がChatGPTで盛り上がるようになってからずいぶん遅れての参加となりました。
無料でも少し使えるのですがレスポンスがかなり遅く、このタイミングでは正直おもちゃ程度にしか感じませんでした。
なので月20ドルという有料版の価格は割高に感じました。
しかし、GPT4を試してみたいという気持ちもあり、1ヶ月だけでも課金してみるかと思って課金してみました。
全く世界が変わりました。
GPT4については、利用回数が少ないこと(2023/03/22時点で3時間に25回)、レスポンスが遅いことなどから、正直そこまで実用性は感じられませんでした。GPT3.5を高速なレスポンスで使い放題になることが真の価値だったと課金して気づきました。
あらゆる知的活動をアシスト
ChatGPTは、自分が普段行っている知的活動のほとんどについてアシストしてくれます。
ここまで汎用的とは全く想像していませんでした。
多大な生産性向上の体験を一瞬のうちに提供してくれるサービスとしては、Google検索やDeepL以来の衝撃です。
「Hooked」にあるようなフックモデルを完璧に実践しています。
どのくらいChatGPTがすごいのか
世間では有史以来の衝撃とか大騒ぎしていますが、正直そこまでのものかは私には分かりません。
最初盛り上がってもその後沈んでいく製品やサービスは山ほどありました。
ChatGPTがそうならない保証はどこにもありません。
今のところの自分の評価としては、こんな感じです。
- 2022-2023年の「世界史」に確実に名を残す。21世紀前半の歴史に名前が残るかは今のところ不明（別のサービスが今後デファクトになっていくかもしれないので）。
- インターネット史には確実に名を残す。コンピュータ史に名を残すかは今のところ不明
- 対話型AIという一般化された概念としては21世紀の世界史に名を残すしコンピュータ史にも名を残す
自分なりのChatGPTの使い方
以下のスクリーンショットは、特に断りがない限りGPT3.5を用いています。
人力検索の代替
多くの人が一番価値を感じているのが検索だと思います。特に、キーワード検索が難しく、人に聞かなければいけないような質問には完全に答えてくれます。
長いので前半部分だけ貼ります。
他にも、冠婚葬祭や礼儀作法などで、自分の具体例を挙げて質問することができ、自分に合った答えをもらうことができます。
個人的には、少なくとも今のままのYahoo!知恵袋やStack Overflowにある質問のかなりの部分はChatGPTに代替されていくだろうと思っています。
ただし、回答が合っている保証はないので、このあとさらに追加で自分で調べる作業は必要です。
しかし、完全に一から調べるよりも遥かに手間が省けます。
学習用対話システム
コンテンツを使った学習システムは、大抵の場合読書や視聴によるインプットが主体で、アウトプット可能なものでも選択式など非常に限定的なものばかりでした。
なので、フィードバックを得られる対面指導には大きな価値がありました。
ChatGPTは対話によって自分の回答に対してフィードバックしてくれます。
なにかを学習するのにアウトプットをするというのはとても効率がいいことは知られています。
これができるだけでもChatGPTは他の教育サービスと一線を画しています。
ただし、回答が正しい保証もないので、この回答をさらに自分で調べていき正確性を確認するところまでをセットで行う必要があります。
子供用の簡単な童話創作
子供の寝かしつけ用に簡単なお話を創作してみましたがなかなかいいできのものができます。
注文をつけてリテイクしても柔軟に対応してくれます。
以下の例はGPT4で作成しました。
タイトルを考える
このブログ記事のタイトルもChatGPTに考えてもらいました。
以下はGPT4で作成しています。
一見創造的に見えるこうした作業はChatGPTにほぼ丸投げできます。
プロのコピーライターでもない限り、一般人にはこれで十分です。
ChatGPT時代の知識人
膨大な知識を単に自然言語としてアウトプットするだけ、という知識人はこれからかなり立場を悪くしていくことになるでしょう。
また、独創性のあるアイデアを出すというのもChatGPTはかなりのレベルでできると感じました。アイデアを出すだけではかなり生き残るのが難しいと思います。
一方で、過去のシステムと同様、未知の質問を作る能力はありません。
これからの知識人は、今まで以上に新しい質問を創造する能力が問われてきます。
いい質問を作るには、言語化、抽象化の能力の他、問題の構造化や分割などの能力が必要になります。
今まで人力検索でいい質問を作れた人たちは、今後もChatGPT相手にその価値を最大限に引き出す質問をしていくでしょう。
また、ChatGPTでは人から話を聞き出すことができません。
人との対話を通じて話を引き出していく、LISTENの技術はまだまだ人間の独壇場でしょう。
万人向けのツールではない
質問の切り出しや言語化が苦手な人にとってはChatGPTはあまり使い勝手がいいものではありません。
万人向けのツールではなく、知的労働者の一部の人が多大な恩恵を預かれるツールというのが現状の認識です。
とはいえ、知的労働者という非常に広範なくくりの中の一部なので、それでも想定ユーザーは膨大な規模となるでしょう。
1ヶ月でいいから課金しろ
正直、月20ドルを払い続けるというのが万人にとって価値があるかどうかまだわかりません。
ですが、1ヶ月だけ20ドル払って試すというのは間違いなく全員におすすめできます。
映画1本みるか、アミューズメントパークに1回いくのと同じだけの金額で次の未来を体験できるものなら安いものです。
今まで試したことがなかった人も、無料版でちょこっと試しただけの人も、一度は有料版を触わることをおすすめします。
pyspa-bot開発報告2022
(UnsplashのDesola Lanre-Ologunが撮影した写真)
この記事はpyspa アドベントカレンダー 2022の23日目です。昨日は@shinyorkeでした。
過去のpyspa-bot関連記事は以下のとおりです。
pyspa-botの概要
pyspa-botは、pyspaのSlackチャンネル内で稼働しているbotです。
初期バージョンが開発されてから10年以上の歴史が経っています。
2010年ごろにDjango Appとして動作するSkype Botとして初期バージョンが稼働しました。(当時のpyspaはSkypeでチャットしていました)。これを便宜上バージョン1とします。
2013年ごろにSlackに移行したタイミングでSkype BotがSlackにも対応するようになりましたが、開発者の@moriyoshitが個人でメンテナンスしてたこともあり、落ちたら誰も起動できなくなるといった保守上の問題がありました。
そこで2016年に、Django依存をなくし、rtmbotをベースにしたチャットボットシステムに移行しました。これを便宜上バージョン2とします。
pyspa-bot ver.2 の2021年時点での技術概要
2022年の主な作業
GitLabからGitHubへの移行
GitLabが無料版のプライベートリポジトリのユーザー数を5人までに制限したため、リポジトリをGitHubに移行しました。
node-gitlab-2-githubを使ってIssueなども全てきれいに移行しました。
SQLiteからCloud SQL(PostgreSQL)への移行
昨年の記事ではCDに持っていくことを目標としていましたが、一度に全てを行うのが難しかったため、DB移行のみ実施しました。
インスタンスの移動
過去に無料インスタンスを使っていた関係で北米リージョンでインスタンスを稼働していましたが、既に有料インスタンスを利用しているため北米リージョンを選び続ける理由はありませんでした。
現在は東アジアリージョンで稼働させています。
Python 3.10 への移行
特に問題なくアップグレードを完了しました。
古いslackclientからslack-sdkへの移行
2022年9月にSlack APIのrtm.startが廃止された影響を受けて、pyspa-botが稼働しなくなりました。
pyspa-botはrtmbotに依存している関係でslackclientというライブラリにも依存していましたが、既にどちらもメンテナンスされていません。
rtmbotは既にフォークしてメンテを続けていますが、slackclientはライブラリをそのまま使い続けていました。
この機会に新しいslack-sdkに移行しました。
新機能開発: 新KudosBot
pyspa++とbotに入力すると、`pyspa`のスコアがインクリメントされるというKudosという機能を持つbotを刷新しました。
これにより、以下の機能が追加されました。
(1) a+++のように記号を連続させた場合、連続した記号の数-1の数だけインクリメントあるいはデクリメントする
例えばpyspa++++++++++++++++++と連続してプラスを書くと、書いた分だけインクリメントできるようになりました。
(2) コードブロック(バックスラッシュ3つで囲まれた文字列)やコード(バックスラッシュ1つで囲まれた文字列)は無視する
コードを貼り付けるときのコードブロック内のインクリメントに反応するのが煩わしかったので反応しないようにしました。
(3) C++を無視する
C++のような頻繁に使われる用語を無視するようになりました。従来版ではこのおかげでCがやたらとインクリメントされていました。
課題とTODO
CD
昨年に続きCDが課題です。
残るタスクは下記のとおりです。
- サービスのDocker化
- Cloud Buildでビルドするように変更
- Cloud Runから継続的にデプロイするよう変更
rtmbot依存の脱却
現在のpyspa-botはrtmbotをフォークして独自にメンテナンスを続けている状態ですが、あまり健全な状態ではありません。bolt-python等への移行をしていく予定です。
型アノテーションの導入
pyspa-botはPython 2.x時代に作られたレガシーシステムであるため型アノテーションが導入されていませんでした。
例えば以下のコードを見てください。
class Node(typing.NamedTuple): type: str value: typing.Union[str, float, int, typing.Sequence["Node"], "Node", None] pos: typing.Optional[int] image: str if node[0] == "FUNCTION": if node[1][0][0] == "IDENTIFIER": name = node[1][0][1]
2行目と3行目の第2インデックスはNodeのリスト、それ以外は全てNodeになっています。
こんなコードが至る所にあります。
mypy 0.981から再帰型を検査できるようになったので上記のNodeを検査できるようになりました。
これで型アノテーションの付与を進められるようになります。
今はほぼ毎日型アノテーションをつけるという作業を進めています。
Slack依存の脱却
現在のpyspa-botでは、slackAPIを直接叩いているところがあちこちにあったり、rtmbotのプラグインのコードにロジックがかかれていたりなどして、Slack及びSlackライブラリに強く依存してしまっている状態です。
これらを完全に分離して、任意のサービスにpyspa-botを対応できるようにする予定です。
テストの整備
2016年の移行時はノーテストだったため、そのタイミングでテストは色々書きましたけど私の技術力が低かったこともあり、今見ると品質の悪いテストがたくさん入ってしまっています。
これらのテストを整備して、意味のあるテストを追加していく予定です。
パッケージ構造の改善
rtmbotをフォークしたこともあり、トップレベルパッケージが以下のように複数存在しており、保守が煩雑になっています。
- rtmbot
- rtmbotからフォークしたパッケージ
- plugins
- pyspabot
- pyspabot独自のコマンドなどが管理されている
これを以下のように整理する予定です。
よくある質問
いつ開発してますか？
仕事の息抜きとか寝る前のちょっとしたすきま時間に開発してます。
1日10～30分程度です。
一から作り直した方がよくないですか？
まとまった時間取れないのでアプリを壊さないよう慎重に開発しています。
息抜きの割にはかなり作り方が本格的じゃないですか？
息抜きだから他にしがらみなく自由に開発できます。
どれくらいコード書いてますか？
この3ヶ月で4043行(+2478、-1565)でした。
最後に
pyspa-botの開発には多くのメンバーが関わっています。現在の主なメンバーは以下のとおりです。
特に@aodagは日々のコードレビューをこなし続けてくれていて、大変感謝しています。ありがとう！
明日のアドベントカレンダーは@torufurukawaです。
pyspa-bot移行作業報告
この記事はpyspa アドベントカレンダー 2021の4日目です。昨日は@kumagiでした。
pyspa-botとは？
pyspa-botは、pyspaのSlackチャンネル内で稼働しているbotです。
様々な機能があって全てを説明することは難しいので省略します。一部の機能については以下の記事で触れているのでそちらを読んでください。(当時はvoluntas-botと呼んでいましたが、今はpyspa-botと呼ばれています)
初期バージョンが開発されてから10年以上の歴史が経っています。
2010年頃にDjango Appとして動作するSkype Botとして初期バージョンが稼働しました。(当時のpyspaはSkypeでチャットしていました)。これを便宜上バージョン1とします。
2013年頃にSlackに移行したタイミングでSkype BotがSlackにも対応するようになりましたが、開発者の@moriyoshitが個人でメンテナンスしてたこともあり、落ちたら誰も起動できなくなるなど、保守上の問題がありました。
そこで2016年に、私をはじめとした数名で、Django依存をなくし、rtmbotをベースにしたチャットボットシステムに移行しました。これを便宜上バージョン2とします。
pyspa-bot ver.2 の現在の技術概要
- python-rtmbot ベースのbotサーバ
- Python 3.8 (ver.2 移行時は3.6だったが一度アップグレードを実施)
- DBはSQLiteを使用(これはver.1時代のものをそのまま流用)
- Google Cloudで稼働 (初期の頃は無料マイクロインスタンスを使っていたが今はn1-standard-1を使用)
- 手動デプロイ。サービスはsystemdで管理
現在の課題と移行プロジェクトのスタート
一番大きな課題は、手動デプロイ運用のため、コードを修正してpushしても自動でデプロイされないことです。 これができないので開発や保守をスキマ時間に行うのがとても難しくなっています。
2016年に構築した環境はもはや時代に合わなくなって来ているものも増えています。例えばrtmbotは既に開発が終了していますし、Python 3.8 をはじめ、依存パッケージが最新版に追随できていなくなっています。
また、Pyspa自体もSlackだけでなくDiscord等他のチャットプラットフォームを使い始めているということもあり、長期的にはマルチプラットフォームに対応しなければなりません。
そこで、環境移行をしようというプロジェクトが始まりました。
以下の作業を実施して、自動デプロイできる環境を作ることをゴールとします。
- DBのSQLiteからCloud SQL (PostgreSQL) への移行
- サービスのDocker化
- Cloud Buildでビルドするように変更
- Cloud Runから継続的にデプロイするよう変更
作業の詳細に興味があれば、下記ドキュメントを読んでみてください。
この中で私が主に担当しているのがDBマイグレーションの部分なので、この記事ではここの作業を中心に紹介します。
事前調査
最初に行うことは、現在のDBがどうなっているかの調査です。
最初に作られた10年前の構成がベースになっていますが、かなりいい加減に移行した上にその後テーブルやフィールドを追加していってたので、色々と問題がありました。
- 間違ったユニークキー制約がORM(SQLAlchemy)上でついているのにSQLite上では存在しない
- 外部キー制約が入っているべきところに入っていない
- orphan recordがいたるところにある
制約を正しく設定し直す必要がありますが、その際にアプリが正しく動作するかどうかも確認する必要があります。
そして調べてみると、テストもかなりいい加減に作っていたため(書いたのは全部過去の自分ですが……)、これらのテストも正しく直す必要があることがわかりました。
SQLiteとPostgreSQLの仕様の違いについても調査する必要がありました。
例えばSQLiteではBOOLはINTEGERでしかないので、移行するにあたっては適切に値を変換する必要があります。
PostgreSQLではシーケンス管理をしているため、移行の最後に正しいシーケンス値を与える必要もあります。
開発環境の作成
開発用のDocker環境もなかったので、まずDockerfileとdocker-compose.ymlを書いて移行テストをローカルで簡単に行えるようにしました。
マイグレーションツールの作成
先の調査結果を元に、マイグレーションツールを作成しました。Click + SQLAlchemyを使った、DBを読み込んで適切な変換処理して書き出すだけのシンプルなツールですが、先述の問題にたびたびぶつかったために結構手間取りました。
スキマ時間で開発してたので、1ヶ月はかかったと思います。
次のステップ
DBマイグレーションの準備が完了したので、あとは自動デプロイの準備が完了すれば移行はできるはずです。
移行完了したら、最初に着手するのはパッケージ等のバージョンの更新の予定です。
最新版に対応して、それからようやく新規の開発に着手できるようになるでしょう。
明日のアドベントカレンダーは@rokujyouhitomaです。
営業から開発まで全部やる
この1年くらいずっと自社サービスの開発に関わっています。(リリースしたのは半年前)
前職でも製品のプロトタイプ開発に関わったりしていましたが、営業もマーケティングも自分が行っているわけではなく、開発も単なるプロトタイピングなので業務コードではないし、プロダクト開発という意味ではかなり限定的な仕事でした。
今回は、営業、マーケティング、開発など、サービス運営に必要なタスク全てに関わっています。(一応念のため言っておくと一人で100%全部やってるわけではないです。あくまでチームの一員として全てのパートに関わっているというだけ)
サポート、プリセールス、ポストセールスとキャリアを歩んできましたが、そのキャリアを通してずっと悩み続けていたのが「なぜお客様の課題を解決する製品やソリューションを提供できないのか」というものでした。
サポート時代はプリセールスやポストセールスと違い製品軸の技術的課題解決しかできないことに苦労していて、もっと幅広いアプローチの仕方で課題解決したいと考えていました。
プリセールスやポストセールスのときは、お客様だけでなく、営業、プロダクトマネージャー、開発など、ステークホルダー全体での課題の共有や解決策の共有などに苦心していました。
結局お客様の課題の解決がうまくできないことも多く、本当に正しく価値を出せているのか分からなくなることもありました。
結果、たどりついた結論が「じゃあ営業から開発まで全部自分でやればいいじゃないか」というものでした。
自分でお客様の声を聞き自分で開発するのなら、そこにミスコミュニケーションは発生しないはずです。
そこでネックになるのが開発力です。
今までの自分のキャリアでは、業務サービスとして提供するコードを書くには力が不足していました。
なので、とにかく開発力を短期間で上げられるように以下のようなことに特に気をつけて努力していました。
- コードを読む。どの行を読んでもきちんと意味が説明できるようにする。サードパーティライブラリのコードも必要に応じて追いかける。
- 公式ドキュメントを読む。サードパーティライブラリが使われているコードが出てきたらその挙動を正しく理解する。
- 速く書く。速く書くというと「コピペとかしていい加減に書く」ように聞こえるが、そういう適当な書き方すると大抵の場合もっと時間がかる。頭をフル回転させて素早く実装を設計して書き出していくと、結果としてコードがきれいになる。
- PRにはきちんと説明を書く。どういうPRなのか、何をしようとしているのか、なぜこういう実装になっているのか、なぜこのPRを出そうとしたのかなどを書く。必要に応じて別途設計書を書く。
- テストをきちんと書く。きちんと書くとは、上記PRに書いた内容をテストしてることがわかるテストを書くということ。
- テストデータは時間をかけて作る。テストデータが正しくないと全部の結果がおかしくなる。
- コメントをきちんと書く。きちんと書くとは、コードから読み取れないコンテキストをコメントとして残しておくということ。
- レビューの指摘は、なぜその指摘なのかを一言一句ちゃんと理解してから指摘を直す。
- レビューするときは、レビュー対象のコードが何をするものなのかを自分が説明できるレベルまで読み込む。
- テストだけでなく、自分の手できちんと動作確認をして、期待した挙動に本当になっているのかを確認する。
その結果1年でそこそこコードを書けるようにはなった気がします。
営業から開発まで全部できるようになると以下のような流れで仕事ができるようになります。
- お客様と話をして、解決したい課題を確認する
- 手元でPoCのコードを書いて、課題を解決できるかを確認する
- 新規開発で解決できることがわかったら、設計を書く
- 設計のレビューを受けたら開発する
- 開発したらお客様に見せて、課題解決ができているか確認する
- できていない場合は再設計、再修正する
- 完成したらリリースする
「お客様の課題を本当に解決できているのかわからないけど開発しなければならない」といった開発サイドの悩みや、「開発側がお客様のペインをきちんと理解してくれない」といった営業サイドの悩みが一切ないというのが大きいです。
デメリットというか懸念点としては、こういう何でも屋的スキルセットは世の中の需要がないので今後のキャリアにはあまりプラスになりそうにないということですね。
どれか一つの専門性を高めていった方が転職市場での需要はあると思います。
サービスとしては始まったばかりなのでまだまだ課題はたくさんありますし、自分個人としても営業、マーケティング、開発など全ての方面で能力をもっと高めていかないといけないので、まだまだどちらも発展途上の身ではありますが、近況報告を兼ねて書き出してみました。
デッドライン: 「なれる！プロジェクトマネージャー」
voluntasさんのおすすめ本にあったのですが、読んだことなかったので読んでみました。
TL;DR
デッドライン、「七人の侍的な感じで集まったドリームチームのプロジェクトに突如クソ上司が登場してめちゃくちゃに引っ掻き回すけど最後はデウスエクスマキナがいい感じにクソ上司を退場させてプロジェクトが成功する」って内容のITプロジェクト管理ラノベだった
— Sho Shimauchi (@shiumachi) 2021年1月25日
デッドライン読んで一番印象に残ってるのが「やっぱデスマの根本原因となるクソ上司にクスリを盛って始末できる優秀なパートナーって最高だなあ」ってことなので、多分本の重要なパートを少しも習得できてない
— Sho Shimauchi (@shiumachi) 2021年1月25日
概要
デッドラインは、トム・デマルコの書いた、プロジェクト管理についての小説です。小説の体を借りたプロジェクト管理についての専門書、と書くべきなのかもしれませんが、正直、専門書と呼ぶには内容が体系だっておらず、概念的・思想的な話が多いので、「専門的な話を多く含む小説」と認識した方がいい気はします。
あらすじ
米国大企業のITプロジェクトマネージャー、ウェブスター・トムキンスは、謎の美女ラークサー・フーリハンに誘拐され、東欧の小国モロビアでソフトウェア開発プロジェクトの責任者として働くことになります。この国はソフトウェア産業で世界トップになることを目標としていて、そのために6つのソフトウェアを開発しようとしています。トムキンスには、1500名の優秀なソフトウェアエンジニアが与えられ、それらの開発プロジェクトを2年弱で成功させるというミッションが与えられます。この膨大なプロジェクトを達成するにあたり、様々な仲間が次々に加わり、それぞれの専門分野に応じた助言を与えていくという形式で話は進んでいきます。例えば、風変わりな女性だけどプロジェクトマネジメントのスペシャリストのベリンダ・バインダは、プロジェクトマネージャの面接におけるアドバイスをトムキンスに与えていきます。
「わたしたちが求めているのは、世界を知ったらそれを変えていく、自分や部下が目指しているものに合わせて変えていくという意識を持っている管理者よ」 (p.67)
ラークサーによって誘拐された人はトムキンスだけではありません。ヘクター・リッツォーリ博士はプロジェクト管理の権威ですが、ラークサーによって強制的に旅程を変更させられて、トムキンスと議論するよう仕向けられます。博士もまた、トムキンスに助言していきます。
ソフトウェア開発はリスクの多い仕事だ。その仕事を管理することは、リスク管理を実践することだと言っていい(p.82)
その他にも、モロビアの大総統NNL、モロビアの将軍ガブリエル・マルコフ、プロジェクト分析モデルについての若き研究者アブドゥール・ジャミッド博士など、トムキンスのもとに優秀な人物たちが集まってきて、プロジェクトは順調に進むかのように見えます。
ところが、総統NNL不在のときに、内務大臣アレア・ベロックがプロジェクトを危機に陥れます。ITに限らず、なんらかのプロジェクトに携わった経験がある人なら、「現場のことは一切わかろうとせず、金の話など自分の都合だけでプロジェクトを引っ掻き回す、厄介なボス」という存在を目にしたことがあるでしょう。ベロックは、そうしたプロジェクトを破綻させるトップの権化のような存在です。彼が行っていく悪行には以下のようなものがあります。
- プロジェクトの締め切りを「リリースが1日遅れるたびに自分が損をするから」という理由だけで一方的に半年短縮する
- その代わりに、わざと小規模にしていたチームに大量に人員を投下してやる、といって実際に人員を大幅に増やしてしまう(人月の神話を読んだことがあれば、これがどれほど愚かしい行為かわかるでしょう)
- プロジェクトの真っ最中に、CMMI (本文中ではCMMだがこれは1997年に廃止)の等級を上げるなどして標準化を無理やり進めようとする
- 当初の契約になかった第7のプロジェクト(それも、航空管制システムを2年でスクラッチから開発するという恐ろしい案件)に無理やりアサインする
- エンジニア達に残業をさせないようしていたところ、残業時間が平均2時間以下ということに憤慨し、「週80時間でも働かせろ」と言い始める
- トムキンスがなんとか半年短縮された締切に間に合うよう調整を進めているのを見て、さらに1ヶ月締切を短縮させる
- その締切に間に合わせるため、週7日労働を命令する
どれ一つ取っても、想像するだけで身の毛がよだつような恐ろしい行為です。この悪役ベロックによってプロジェクトを引っ掻き回されつつも、トムキンスはさらなる仲間を獲得しながらプロジェクトを進めていきます。
最終的には、長期の出張から戻ったラークサーがベロックをあっさりと排除することによって、プロジェクトは順調に進み始め、ついにはリリースにこぎつけることに成功します。
所感
プロジェクト管理について幅広いトピックをカバーしていて、プロジェクト管理をしたことがなくても、メンバーの一員として何らかのプロジェクトに関わったことがある人であれば、「あーこういうのあるよね」と楽しめる内容がもりだくさんです。文章は読みやすいしストーリーは単純で、1日でサクッと読めます。ITの専門知識がなくても読めると思います。知っていた方が楽しいのは事実ですが、なにせ原著の出版が1997年ということもあり、ITの描写についてはかなり古臭いです。ソフトウェアをCD-ROMを焼いて販売するとか、今の20代より若い世代だと理解できないかもしれません。
冒頭に書いた通り、プロジェクト管理の専門書とみなすにはかなり難があります。どのトピックも触りしか説明しておらず、アドバイスの根拠や参考文献などが示されていないので、インデックスとしても使いづらいです。純粋にこういう小説だと割り切って楽しんで読むのがいい気がします。個人的には、プロジェクト管理に役立つというよりは、悪役アレア・ベロックの所業を読んで過去のトラウマを蘇らせて楽しむための本という印象でした。
間違ってることとかデタラメを書いてるわけではないので、トンデモ本というわけでは全くありません。あくまで、他の専門書を既に読了していたり、過去の経験から十分学んでいる人が読むと、復習にはなっても新たな知見を得るには至らず、また入門者が読んでもさらなる勉強の足がかりとするには心もとない、という感想です。
既にプロジェクト経験が豊富であるか、プロジェクト管理経験をしたことがある人が気軽に読むか、あるいはまだ業界に入って間もない人で、プロジェクト管理について雰囲気をさらっと学びたいという人にはいいかもしれません。
ストーリーは単純ではありますが、登場人物や展開が割とご都合主義な部分もあり、自分の感覚としてはラノベを読んでる感覚に近かったです。登場人物などをローカライズして、ITの描写を現代風にアレンジしたラノベとかが出版されたら読みたいかもしれないです。
