/bin/osh

ソフトフェアエンジニアリングしたりデータ分析したりプロジェクトマネジメントの勉強したりする人のブログ

エンジニアが選ぶおすすめのマネジメントに関する本

前の記事を読んでからだとモチベーションがあがるかも。

プロジェクトマネジメントは、ソフトウェア開発に限ったことではないがこの記事ではソフトウェア開発寄りの本を多く紹介する。 この記事は淡々とおすすめ本を紹介していくだけ。 Amazonのリンクも貼っておくので、どんな内容が書いてあるかは目次を見て欲しい。

人月の神話

太古の昔から、タールの沼に落ちた巨大な獣が死にもの狂いで岸に吐い上がろうとしている光景ほど鮮烈なものはない。恐竜やマンモス、それにサーベルタイガーがタールに捕えられまいとしてもがく様が目に浮ぶ。激しくもがけばもがくほどタールは一層絡みつき、どんなに力強い獣でも、また賢く器用な獣でも、ついには沈んでいってしまう。

大規模システムプログラム開発は、過去10年以上もの間そうしたタールの沼のようなものだった。

フレデリックブルックス. 人月の神話 第1章 タールの沼

読まれない名著とも言われる「人月の神話」。 約40年前(1975年)に初版が発刊されているこの本はソフトウェアエンジニアリングのマネジメントのスタート地点とも言える。 本のタイトルにもなっている「人月の神話」を筆頭に40年前の本だとは思えないほど、今のソフトウェア開発にも当てはまる話が多い。 名言の宝庫*1。 有名な言葉を挙げると、

  • 時間が足りなかったせいで失敗したプログラミング・プロジェクトは、その他のすべての原因で失敗したプログラミング・プロジェクトよりも多い。
  • ブルックスの法則: 遅れているソフトウェアプロジェクトへの要因追加は、さらにプロジェクトを遅らせるだけだ
  • 銀の弾などない

などがある。 Wikipediaの人月の神話のページに要約が載っているのでおすすめ。

1章が短くて読みやすい。作者はOS/360の開発者であったフレデリックブルックス*2

個人的に記憶に残っている章は

  • 第1章 タールの沼
  • 第2章 人月の神話
  • 第7章 バベルの塔は、なぜ失敗に終わったのか?
  • 第14章 破局を生み出すこと
  • 第16章 銀の弾などない –– ソフトウェアエンジニアリングの本質と偶有的事項

人月の神話【新装版】

人月の神話【新装版】

ピープルウェア

まだプログラマーの仕事を始めたばかりのころ、私は、シャロンワインバーグ(その後、コッド&デートコンサルティング・グループの会長となった)がマネジメントするプロジェクトで仕事をする幸運に恵まれた。シャロンは、今私がマネジメントの真髄と思うことの生きた事例であった。雪が降りしきるある日、私は病床から足をひきずってオフィスへ行き、顧客デモ用の不安定なシステムを立て直そうとしていた。シャロンは、部屋に入ってきて私を見つけ、コンソールの前で倒れそうになった私を支えてくれた。そしてちょっと姿を消したかと思うとスープを持って戻り、私に飲ませて元気づけてくれた。私はきいた。「マネジメントの仕事が山ほどあるのに、どうしてこんなことまでできるんですか?」シャロンは専売特許のにこやかな笑みを顔一杯に浮かべて答えた。「これがマネジメントというものよ」

トム デマルコ;ティモシー リスター. ピープルウエア 第3版

ピープルウェアでは人に焦点を当てて、どうすればチームメンバが生産性高く働くことができるかを事例を交えて紹介している。 この本も「人月の神話」同様に1章が短く読みやすい。 ソフトウェア開発の"あるある"が多く書かれているのでソフトウェア開発に携わったことのある人なら共感できる部分も多いはず。

ピープルウエア 第3版

ピープルウエア 第3版

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版(日本語)

プロジェクトマネジメント知識体系ガイド PMBOKガイド 第6版(日本語)

*1:人月の神話の名言をランダムで出力するSlackのSlash Commandを作ったこともある

*2:「人月の神話」の中にもOS/360の話がいくつかでてくる

*3:自分が読んだのは第5版英語版なので現在の第6版とは異なる可能性があります

エンジニアがプロジェクトマネジメントを学ぶ意義

プロジェクトマネジメントとはプロジェクトが円滑に進むようにすること

まずプロジェクトとは「2人以上で特定の目的に向かって特定の期間行う取り組み」と定義する。 その上でプロジェクトマネジメントとは、要件を定義したり、リソース*1やスコープ、品質や予算やリスクを調整したり、ステイクホルダ*2とコミュニケーションを取ってより生産性を上げたり...とプロジェクトが円滑に進むようにすることである。

プロジェクトマネジメントで重要なのはコミュニケーション

プロジェクトマネジメントについて細かい知識や手法などいろいろあるが、コアとなるものはコミュニケーションであることは確かである。

PMBOK*3から引用すると

Communication has been identified as one of the single biggest reasons for project success or failure.

一応日本語に直すと「コミュニケーションこそはプロジェクトが成功するか失敗するかを決定するさまざまな要因のうちで、唯一にして最大の要因と呼び得るものである。」というところだろうか。

もしコミュニケーションが円滑でないと、チームメンバが必要な情報にアクセスできず個人の生産性が落ちたり、信頼関係を築けずにチームとしての生産性も落ちてしまう。そうならないようにコミュニケーションをマネージするのがプロジェクトマネージャの一番の仕事であると言ってもいいだろう。

エンジニアがプロジェクトマネジメントを学ぶ意義

上手くマネージされ、メンバが何も考えなくても円滑なコミュニケーションが取れればよいが、そう上手くいかないこともある。 コミュニケーションの当事者がある程度プロジェクトマネジメントやコミュニケーションについて知っておけばマネージャの労力も少なくなるかもしれない。

このようにコミュニケーションについて知る(考える)ことでマネージャを助けることがプロジェクトマネジメントを学ぶ意義の1つなのではないかと思う。

また、プロジェクトマネージャでなくても自分がオーナーシップを持って小さいプロジェクトを進めることもある場合があるだろう。 その時に、何もプロジェクトマネジメントについて知らないと上手くチームの生産性を上げることができないかもしれない。 そういう場合を見越して勉強するのも学ぶ意義の1つだろう。

副次的な効果として、自分の組織のマネジメントの状態を知ることができる。 自分の能力を高めるのに環境を整えるのは最重要要素とも言えるだろう。 もし状態が悪いなら組織の改善案も出せるし、どうしようもなければ別の環境に移ることもできる。

おわりに

組織はドメイン固有の事柄が多い上に変化し続ける。 プロジェクトマネジメントの勉強をしたからといってどんな状況にも対応できる訳ではない。 「人月の神話」で有名なフレデリックブルックスの言葉を借りると銀の弾丸はない』のである。

プロジェクトマネジメントを学びたくなってきた(であって欲しい)皆さんのために次回はおすすめマネジメント本を紹介しようと思う。

追記: 書いた。

ushiumi.hatenablog.com

あと自分がなぜこう思うに至ったかもいつか書きたい。

*1:人的リソースを含む

*2:プロジェクトに関わる全ての人を指す

*3:A Guide to the Project Management Body of Knowledge 5th Edition

技術書典6に初サークル参加した話

4/14に行われた技術書典6に初サークル参加した。

lambda-sunという名前で、λ計算入門について書きました。 気になる人は以下から100円で買えるのでよろしくお願いします。

lambda-sun.booth.pm

この記事では初サークル参加した振り返りを書いていきたいと思います。

振り返り

KPTで振り返る。

Keep

  • なんとか出せた!
  • 執筆環境が \TeXだったが、Dockerに環境を閉じ込めたことで \TeX環境に苦しめられることがなかった
  • 40冊売れた
  • 技術書典公式のQR決済(後払い)が強かった
  • Kyash決済も用意していて使ってくれる人が何人かいた

Problem

  • 書き始めるのが遅かった
  • iPadで見本誌を置いていたが躊躇する人が多かった
  • 直前まで書いていたせいでブースの準備をしていなかった
  • お釣り用の小銭を用意してなかった
  • 意外と物理本を求める声があった
  • 1人で売っていたのでブースから離れられなかった

Try

  • 中締め切りを設けて余裕を持って書く
  • 物理本を数冊用意する
  • 売るときは複数人で売る
  • ブースの準備をする

おわりに

ちゃんと計画的に書こう!!!!

BigQueryでArrayの各要素をそれぞれ別の行にしたいとき

タイトルが難しい。 よく忘れるのでメモ。

要するに

これを

f:id:ushiumi:20190405140932p:plain

こうしたい

f:id:ushiumi:20190405140951p:plain

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つが出力されます。

例えば このツイートのテキストを入れると

Score: 0.6000000238418579
Magnitude: 0.6000000238418579

という値が返ってきます。 これはスコアが0.6もあるので非常にポジティブな内容であるということが分かります。 ねおりんがニッコリ笑顔になってるのでポジティブと出てるのはあってそうですね。

こんどはこのツイートのテキストを入れると

Score: -0.8999999761581421
Magnitude: 0.8999999761581421

今度は非常にネガティブなスコアになりました。

2つのツイートから得られるマグニチュードは非常に低いものですが、これは文章自体が 短いことに起因すると考えられます。

ねおりんのツイートを分析

ツイートの期間は2018/09/06~2018/12/18 (UTC)

今回はマグニチュードは考慮せず、スコアだけを取りました。

f:id:ushiumi:20181219205501p:plain

   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
-0.4500  0.0500  0.1211  0.1097  0.1985  0.4133

第1四分位数が正なのを見るとねおりんはポジティブな発言が75%以上ということが分かります。

最小値の日は

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を見ると分かりやすく月曜日がスコアが高い。 月曜は憂鬱になる人が多いのにねおりんはポジティブになるという発見。

まとめ

  • Cloud Natural Language 簡単!
  • ねおりんはAppleAmazonに厳しい
  • ねおりんは月曜にポジティブになる

Google Cloud Pub/Sub のat-least-onceってどれくらい重複するの?

Google Cloud Platform その2 Advent Calendar 2018の15日目の記事です。


Google Cloud Pub/Sub とは

Google Cloud Pub/SubGCPの非同期メッセージングサービスです。 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する。

使用する言語はRubyで、すべて同期pullで行った。

10万件Publishするスクリプト gist.github.com

すべてSubscribeするスクリプト gist.github.com

結果

10万件だと重複はなかったRubyの処理速度だと重複があまり起きない? 100万件でやろうとしたけど時間がかかるのでまた別の機会に...

ただ気になったのは1回のpullで取ってくる件数。 maxで1000件まで取ってくる設定にしていたが、以下のように件数が上下していた。

f:id:ushiumi:20181215234043p:plain

10回の単純移動平均をとると

f:id:ushiumi:20181215234304p:plain

途中で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なデータセットにデータをコピーしてから、 元の場所にコピーしましょう。

例:

  1. dataset_name.table_nameのスナップショットをtmp_dataset.table_nameにコピー
    • bq cp dataset_name.table_name@1540869645 tmp_dataset.table_name
  2. tmp_dataset.table_namedataset_name.table_nameにコピー
    • bq cp tmp_dataset.table_name dataset_name.table_name

データセットごとやってしまった場合はこれをデータセット内の全テーブルに行うことでデータセットを復旧できます。
これでいつテーブルを消しても大丈夫!

参考: