エンジニアが選ぶおすすめのマネジメントに関する本
前の記事を読んでからだとモチベーションがあがるかも。
プロジェクトマネジメントは、ソフトウェア開発に限ったことではないがこの記事ではソフトウェア開発寄りの本を多く紹介する。 この記事は淡々とおすすめ本を紹介していくだけ。 Amazonのリンクも貼っておくので、どんな内容が書いてあるかは目次を見て欲しい。
人月の神話
太古の昔から、タールの沼に落ちた巨大な獣が死にもの狂いで岸に吐い上がろうとしている光景ほど鮮烈なものはない。恐竜やマンモス、それにサーベルタイガーがタールに捕えられまいとしてもがく様が目に浮ぶ。激しくもがけばもがくほどタールは一層絡みつき、どんなに力強い獣でも、また賢く器用な獣でも、ついには沈んでいってしまう。
大規模システムプログラム開発は、過去10年以上もの間そうしたタールの沼のようなものだった。
読まれない名著とも言われる「人月の神話」。 約40年前(1975年)に初版が発刊されているこの本はソフトウェアエンジニアリングのマネジメントのスタート地点とも言える。 本のタイトルにもなっている「人月の神話」を筆頭に40年前の本だとは思えないほど、今のソフトウェア開発にも当てはまる話が多い。 名言の宝庫*1。 有名な言葉を挙げると、
- 時間が足りなかったせいで失敗したプログラミング・プロジェクトは、その他のすべての原因で失敗したプログラミング・プロジェクトよりも多い。
- ブルックスの法則: 遅れているソフトウェアプロジェクトへの要因追加は、さらにプロジェクトを遅らせるだけだ
- 銀の弾などない
などがある。 Wikipediaの人月の神話のページに要約が載っているのでおすすめ。
1章が短くて読みやすい。作者はOS/360の開発者であったフレデリック・ブルックス*2。
個人的に記憶に残っている章は
- 作者: Jr FrederickP.Brooks,Jr.,Frederick P. Brooks,滝沢徹,牧野祐子,富澤昇
- 出版社/メーカー: 丸善出版
- 発売日: 2014/04/22
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (19件) を見る
ピープルウェア
まだプログラマーの仕事を始めたばかりのころ、私は、シャロン・ワインバーグ(その後、コッド&デートコンサルティング・グループの会長となった)がマネジメントするプロジェクトで仕事をする幸運に恵まれた。シャロンは、今私がマネジメントの真髄と思うことの生きた事例であった。雪が降りしきるある日、私は病床から足をひきずってオフィスへ行き、顧客デモ用の不安定なシステムを立て直そうとしていた。シャロンは、部屋に入ってきて私を見つけ、コンソールの前で倒れそうになった私を支えてくれた。そしてちょっと姿を消したかと思うとスープを持って戻り、私に飲ませて元気づけてくれた。私はきいた。「マネジメントの仕事が山ほどあるのに、どうしてこんなことまでできるんですか?」シャロンは専売特許のにこやかな笑みを顔一杯に浮かべて答えた。「これがマネジメントというものよ」
トム デマルコ;ティモシー リスター. ピープルウエア 第3版
ピープルウェアでは人に焦点を当てて、どうすればチームメンバが生産性高く働くことができるかを事例を交えて紹介している。 この本も「人月の神話」同様に1章が短く読みやすい。 ソフトウェア開発の"あるある"が多く書かれているのでソフトウェア開発に携わったことのある人なら共感できる部分も多いはず。
- 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2013/12/18
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (10件) を見る
PMBOK
Communication has been identified as one of the single biggest reasons for project success or failure. Project Management Institute. A Guide to the Project Management Body of Knowledge 5th Edition
正式な名前は"A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE"。 現在第6版まで出ているプロジェクトマネジメントのフレームワークを記したスタンダードな教科書。 最初の方に概要の章があって、そこにプロジェクトマネジメントとはどういうもので、どういうプロセスがあって、組織とどう関係するかが書いてあって、ここを読むだけでも価値がある*3。 ただし、個人で買うには高いのと、重い。
プロジェクトマネジメント知識体系ガイド PMBOKガイド 第6版(日本語)
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2018/01/01
- メディア: ペーパーバック
- この商品を含むブログを見る
*1:人月の神話の名言をランダムで出力するSlackのSlash Commandを作ったこともある
*2:「人月の神話」の中にもOS/360の話がいくつかでてくる
*3:自分が読んだのは第5版英語版なので現在の第6版とは異なる可能性があります
エンジニアがプロジェクトマネジメントを学ぶ意義
プロジェクトマネジメントとはプロジェクトが円滑に進むようにすること
まずプロジェクトとは「2人以上で特定の目的に向かって特定の期間行う取り組み」と定義する。 その上でプロジェクトマネジメントとは、要件を定義したり、リソース*1やスコープ、品質や予算やリスクを調整したり、ステイクホルダ*2とコミュニケーションを取ってより生産性を上げたり...とプロジェクトが円滑に進むようにすることである。
プロジェクトマネジメントで重要なのはコミュニケーション
プロジェクトマネジメントについて細かい知識や手法などいろいろあるが、コアとなるものはコミュニケーションであることは確かである。
Communication has been identified as one of the single biggest reasons for project success or failure.
一応日本語に直すと「コミュニケーションこそはプロジェクトが成功するか失敗するかを決定するさまざまな要因のうちで、唯一にして最大の要因と呼び得るものである。」というところだろうか。
もしコミュニケーションが円滑でないと、チームメンバが必要な情報にアクセスできず個人の生産性が落ちたり、信頼関係を築けずにチームとしての生産性も落ちてしまう。そうならないようにコミュニケーションをマネージするのがプロジェクトマネージャの一番の仕事であると言ってもいいだろう。
エンジニアがプロジェクトマネジメントを学ぶ意義
上手くマネージされ、メンバが何も考えなくても円滑なコミュニケーションが取れればよいが、そう上手くいかないこともある。 コミュニケーションの当事者がある程度プロジェクトマネジメントやコミュニケーションについて知っておけばマネージャの労力も少なくなるかもしれない。
このようにコミュニケーションについて知る(考える)ことでマネージャを助けることがプロジェクトマネジメントを学ぶ意義の1つなのではないかと思う。
また、プロジェクトマネージャでなくても自分がオーナーシップを持って小さいプロジェクトを進めることもある場合があるだろう。 その時に、何もプロジェクトマネジメントについて知らないと上手くチームの生産性を上げることができないかもしれない。 そういう場合を見越して勉強するのも学ぶ意義の1つだろう。
副次的な効果として、自分の組織のマネジメントの状態を知ることができる。 自分の能力を高めるのに環境を整えるのは最重要要素とも言えるだろう。 もし状態が悪いなら組織の改善案も出せるし、どうしようもなければ別の環境に移ることもできる。
おわりに
組織はドメイン固有の事柄が多い上に変化し続ける。 プロジェクトマネジメントの勉強をしたからといってどんな状況にも対応できる訳ではない。 「人月の神話」で有名なフレデリック・ブルックスの言葉を借りると『銀の弾丸はない』のである。
プロジェクトマネジメントを学びたくなってきた(であって欲しい)皆さんのために次回はおすすめマネジメント本を紹介しようと思う。
追記: 書いた。
あと自分がなぜこう思うに至ったかもいつか書きたい。
技術書典6に初サークル参加した話
4/14に行われた技術書典6に初サークル参加した。
lambda-sunという名前で、λ計算入門について書きました。 気になる人は以下から100円で買えるのでよろしくお願いします。
この記事では初サークル参加した振り返りを書いていきたいと思います。
振り返り
KPTで振り返る。
Keep
- なんとか出せた!
- 執筆環境がだったが、Dockerに環境を閉じ込めたことで環境に苦しめられることがなかった
- 40冊売れた
- 技術書典公式のQR決済(後払い)が強かった
- Kyash決済も用意していて使ってくれる人が何人かいた
Problem
- 書き始めるのが遅かった
- iPadで見本誌を置いていたが躊躇する人が多かった
- 直前まで書いていたせいでブースの準備をしていなかった
- お釣り用の小銭を用意してなかった
- 意外と物理本を求める声があった
- 1人で売っていたのでブースから離れられなかった
Try
- 中締め切りを設けて余裕を持って書く
- 物理本を数冊用意する
- 売るときは複数人で売る
- ブースの準備をする
おわりに
ちゃんと計画的に書こう!!!!
BigQueryでArrayの各要素をそれぞれ別の行にしたいとき
タイトルが難しい。 よく忘れるのでメモ。
要するに
これを
こうしたい
UNNEST
を使ってクロスジョインみたいにすればできる。
WITH dataset AS ( SELECT 1 AS id, ARRAY['foo', 'bar'] AS arr UNION ALL SELECT 2, ARRAY['foo', 'bar', 'baz']) SELECT id, item FROM dataset, UNNEST(arr) AS item
参考:
https://cloud.google.com/bigquery/docs/reference/standard-sql/arrays?hl=ja#querying-nested-arrays
Google Cloud Natural Language で簡単感情分析
この記事はねおりんアドベントカレンダー19日目の記事です。
ざっくり言うとねおりんのツイートを分析してみたよというお話しです。
Google Cloud Natural Languageは、 APIを投げるだけでGoogleが事前に学習させたモデルを使って自然言語処理ができてしまう優れものです。 最近はGoogle Cloud AutoMLという データを与えるだけでそのデータから学習したモデルを作ってくれるサービスも出ています。
今回はねおりんアドベントカレンダーということでCloud Natural Languageを使って @noir_neoのツイートの感情分析をしてみました。
Cloud Natural Language を使った感情分析
Cloud Natural Language での感情分析では、文章を与えると
- -1.0(ネガティブ)~1.0(ポジティブ)の範囲で表わされるスコア
- 0.0~+infで表わされる感情の強度であるマグニチュード
の2つが出力されます。
例えば このツイートのテキストを入れると
起床したらゆいかおり素材が投下されててニッコリ笑顔になった😊😊😊
— ねおりん (@noir_neo) 2018年11月25日
Score: 0.6000000238418579
Magnitude: 0.6000000238418579
という値が返ってきます。 これはスコアが0.6もあるので非常にポジティブな内容であるということが分かります。 ねおりんがニッコリ笑顔になってるのでポジティブと出てるのはあってそうですね。
こんどはこのツイートのテキストを入れると
Apple の審査まじで何やってんの
— ねおりん (@noir_neo) 2018年11月15日
Score: -0.8999999761581421
Magnitude: 0.8999999761581421
今度は非常にネガティブなスコアになりました。
2つのツイートから得られるマグニチュードは非常に低いものですが、これは文章自体が 短いことに起因すると考えられます。
ねおりんのツイートを分析
ツイートの期間は2018/09/06
~2018/12/18 (UTC)
今回はマグニチュードは考慮せず、スコアだけを取りました。
Min. 1st Qu. Median Mean 3rd Qu. Max. -0.4500 0.0500 0.1211 0.1097 0.1985 0.4133
第1四分位数が正なのを見るとねおりんはポジティブな発言が75%以上ということが分かります。
最小値の日は
amazon のアカウント https://t.co/TMqf4c0vVb で分かれてるのもゴミだし、 iOS アプリで言語設定英語にしてると .com でログインされるのも本当にゴミ
— ねおりん (@noir_neo) 2018年10月16日
Amazonにキレてました。
11月は
曜日ごと(UTC)の最小値、第1四分位点、中央値、平均、第3四分位点、最大値を見てみると
day of the week | Min. | 1st Qu. | Median | Mean | 3rd Qu. | Max. |
---|---|---|---|---|---|---|
月 | -0.06667 | 0.12680 | 0.18570 | 0.18280 | 0.23530 | 0.41330 |
火 | -0.16670 | 0.05777 | 0.12960 | 0.11840 | 0.21810 | 0.35000 |
水 | -0.45000 | 0.04062 | 0.09583 | 0.08636 | 0.17900 | 0.31820 |
木 | -0.30000 | -0.02593 | 0.05926 | 0.04662 | 0.12660 | 0.27040 |
金 | -0.38330 | 0.02316 | 0.10690 | 0.09655 | 0.20210 | 0.30450 |
土 | -0.03788 | 0.08788 | 0.12780 | 0.13010 | 0.15700 | 0.32000 |
日 | -0.22310 | 0.07211 | 0.12110 | 0.10610 | 0.18030 | 0.29170 |
1Qを見ると分かりやすく月曜日がスコアが高い。 月曜は憂鬱になる人が多いのにねおりんはポジティブになるという発見。
まとめ
Google Cloud Pub/Sub のat-least-onceってどれくらい重複するの?
Google Cloud Platform その2 Advent Calendar 2018の15日目の記事です。
Google Cloud Pub/Sub とは
Google Cloud Pub/SubはGCPの非同期メッセージングサービスです。 Pub/Subの概念の詳細やユースケースついてはGoogle Cloud Pub/Subのドキュメントに書いてあるのでそちらをご覧ください。
at-least-once配信
Cloud Pub/Subの特徴としてat-least-once配信があります。 at-least-once配信とはメッセージが1 回以上配信することを指します。
ドキュメントの中のサブスクライバーガイドには以下のように書かれています。
通常、Pub/Sub は各メッセージを公開された順序で 1 回配信します。ただし、メッセージが順不同で配信される場合や複数回配信される場合があります。通常、複数回の配信に対応するには、メッセージの処理時にサブスクライバーがべき等である必要があります。Google Cloud Pub/Sub メッセージ ストリームを 1 回だけ処理するには、Cloud Dataflow の PubsubIO を使用します。
これがなかなか厄介です。
そもそもat-least-once配信って言うけど実際どのくらい重複が起きるの? という疑問がある。
そこで以下のような検証をしてみた。
検証
順序が分かる10万件のデータをPublishし、その後すべてSubscribeする。
10万件Publishするスクリプト gist.github.com
すべてSubscribeするスクリプト gist.github.com
結果
10万件だと重複はなかった。 Rubyの処理速度だと重複があまり起きない? 100万件でやろうとしたけど時間がかかるのでまた別の機会に...
ただ気になったのは1回のpullで取ってくる件数。 maxで1000件まで取ってくる設定にしていたが、以下のように件数が上下していた。
10回の単純移動平均をとると
途中で200件が続いてるのが気になる... 過去にCloud Pub/Subを使っていてデータがあるのに0件で返ってくるケースもあったので、pullするときの件数はばらつきがあるみたいだ。
順序性を保証しようとするとどれくらいパフォーマンスが落ちるのかなど調べたいことはまだあるのでまた調査したい。
BigQueryのテーブルの復元方法
疲れてたりするとうっかりBigQueryのテーブルやデータセットを消してしまうことありますよね?? でも大丈夫!BigQueryは最新2日間であれば1秒ごとに全データのスナップショットを取っているのです!
ただし削除された後に同名のテーブルが作成されるとスナップショットを参照できなくなります!
テーブルの復元方法
スナップショットには以下の構文でアクセスできます。
PROJECT_ID:DATASET.TABLE@<time>
<time>
はエポックタイム(Unix Timestamp)で表わされます。
詳しい情報は以下のURLから。
https://cloud.google.com/bigquery/table-decorators?hl=ja
スナップショットをコピーするにはbq
コマンドを使用します。
(インストール方法や使い方は以下のURLから
https://cloud.google.com/bigquery/bq-command-line-tool?hl=ja)
安全に復旧するためには一度temporaryなデータセットにデータをコピーしてから、 元の場所にコピーしましょう。
例:
dataset_name.table_name
のスナップショットをtmp_dataset.table_name
にコピーbq cp dataset_name.table_name@1540869645 tmp_dataset.table_name
tmp_dataset.table_name
をdataset_name.table_name
にコピーbq cp tmp_dataset.table_name dataset_name.table_name
データセットごとやってしまった場合はこれをデータセット内の全テーブルに行うことでデータセットを復旧できます。
これでいつテーブルを消しても大丈夫!
参考: