読者です 読者をやめる 読者になる 読者になる

KATOエンジニヤリング開発日誌

「アウトプット無きエンジニアにインプットもチャンスも無い」の精神で書いています

「ピープルウェア」を読んでIT業界の不変性を感じた

f:id:masayuki_kato:20170220235132j:plain

今年の目標として掲げた「[改訂新版 コンピュータの名著・古典100冊]に載っている本を読む」の1冊目として「ピープルウェア 第3版」を読み終わりましたので、内容と私の思うところを振り返ってみました*1

改訂新版 コンピュータの名著・古典 100冊

改訂新版 コンピュータの名著・古典 100冊

  • 作者: 石田晴久,青山幹雄,安達淳,塩田紳二,山田伸一郎
  • 出版社/メーカー: インプレス
  • 発売日: 2012/08/23
  • メディア: Kindle版
  • 購入: 1人 クリック: 1回
  • この商品を含むブログを見る

ピープルウエア 第3版

ピープルウエア 第3版

心当たりがあること

チーム内の「触媒」の役割

マネージャーがあるスタッフの能力に疑いを持っており、そのスタッフを評価してほしいという依頼があった。 そのスタッフは開発、テスト、その他の仕事をやらせても優秀とはいえない。 ただし、そのスタッフが関わったプロジェクトは全て成功を収めている。 そのスタッフがいると担当者間の意思疎通が良くなりプロジェクトが楽しくなるようだ。 チーム内で「触媒」の役割を果たしていると結論に達した。

書籍では結局、「触媒」の役割のスタッフは評価されることなく終わっており、マネージャー以外のスタッフがプロジェクトメンバーを結束させる能力は認められずらいという。

私見では「触媒」のような人間はマネージャーやチームメンバーからも信頼されており、評価されていないということは無かった。

これは「触媒」の技術だけが評価されているわけではなく、その人の人柄も含めて評価されているように見受けられた。

ただ、書籍が指す「マネージャー」がチームリーダーのような役割なのか、それとも複数プロジェクトを掛け持ちしているようなマネージャーなのかが読めなかった。

もし後者であれば「触媒」であっても評価はされづらいかもしれない。

ただ、複数プロジェクトを掛け持ちしているような人が一つのプロジェクトの1スタッフの評価に関わるのかが疑問に感じた。

ハイテクビジネスに身をおいているという驕り

最新技術に関係しているエンジニアは自分がハイテクビジネスの旗手だと錯角している。 自分の職業を話す時になんとなく得意げに思ってしまう。 だが、本当にハイテクビジネスに身を置いているのは発明・発見を成し遂げた研究者だけで、 それ以外の人は他人の研究結果を応用しているに過ぎない。

自分がIT業界で働いていると話すときには顔には出さないようにしているがなんとなく得意げな気分になっている。

そして、他人の研究結果を応用しているだけというのも自覚していた。

我々は誰かが発明した技術を、誰かが考案した開発手法でシステムを作っているに過ぎない。

品質優先...でもコストとスコープはそのままで

顧客は品質第一と言っているが、それはコストが予算内で収まり、且つ機能が削られることなく期限までに完成させることが当たり前と思っている。

最初の要件通りのスコープでスケジュールが進めば難しいことでは無いが、大抵は追加要件がでてくる。

しかもタチが悪いのは「追加要件」ではなく、「以前から伝えている」とシラを切ってくる顧客もいる。

そうなると「言った」「言わない」の水掛け論になり、最終的には開発せざるを得ない。

その場合、私の経験上では予算(コスト)は貰えることはあっても期限が伸びることはあまりない。

顧客側としては追加要件としてのコストは容認するが、リリース日を伸ばすことによる機会損失は認められないようだ。

コストを増やしてもらっても、スケジュールの後半になってくるとコストを費やして人を増やしても役に立つまで時間が掛かるので、「コストを増やす」ということは「既存メンバーに残業させる」同義だ。

スケジュールが伸びない以上、品質が多少おざなりになるのは仕方ない。

エンジニアだって本心は品質がよくないシステムをリリースすることには気を揉む。

エンジニアの作業環境

フロー状態

単独で作業をする場合、プログラマーはフロー(Flow)状態になっていることが理想だ。 これは一つのことに没頭し、ほとんど瞑想状態になることである。

一度フロー状態に入ると、設計やプログラミング・ドキュメント作成といった作業が捗るということがある。

このフロー状態に入るには、15分以上の精神集中過程が必要とある。

周りの少々の雑音程度ではフロー状態を解かれることはないが、電話や騒音でフロー状態を解かれることがある。

そして一度解かれると、再度15分以上の精神集中過程が必要になる。

私が携わったプロジェクトでは幸い、電話が頻繁に掛かってくることは無かった。

近年では電話による中断が作業効率に影響を与えることが考慮されるようになったのだと感じた。

ただ、このフロー状態だが新人がベテランに質問しづらい原因にもなっていると思う。

質問される側も何度もフロー状態を解かれるとイライラが溜まってくるし、それが原因で新人も質問をせずに抱え込んでしまうのではないかと思った。

その情報は要らない

プロジェクトに入るとメールアドレスが付与される。

そしてプロジェクトのメーリングリストに追加されるのだが、1つのプロジェクトでも複数のチームが関わってくるので複数のメーリングリストに登録される。

アプリケーションの開発としてプロジェクトにアサインされたとしても、インフラチームのメーリングリストに登録されるとアプリケーション開発チームに関係ないメールまで受信してしまう。

不要なメールを大量に受信すると、要不要の判断のためにメールの内容を確認する必要があるし、受信の頻度が高いと必要なメールが不要メールに紛れ込まないように頻繁にメールボックスを確認する必要が出てくる。

そうなると前述のフロー状態が解かれる回数が増えてしまい、作業効率が落ちてしまう。

まとめ

この書籍は良いマネージャー、悪いマネージャーの例が大半を占めています。

今も昔もチームが一丸となってプロジェクトに取り組めるマネージャーもいれば、チームのやる気を削ぐようなマネージャーもいるということです。

私自身はマネージャーの経験が無く、今後もマネージャーとしてプロジェクトに携わる可能性は低いので「ピープルウェア」を読んで、何らかの知識を得られたという実感はないです。

ただ、小説のような読み物としてみると、IT業界の「社会」が30年間変わることなく続いていることに歴史と不変性を感じました。

最後に、この本を読んで一番強く残っているのが、携わった仕事のなかで楽しい経験は「挑戦」というものがあります。

プロジェクトが挑戦的なものであれば、多少の残業や困難も喜んで引き受ける人が多いのもIT業界の特徴だと思っています。

今後も新しいことに積極的に挑戦する気持ちを忘れないようにしたいです。

*1:「コンピュータの名著・古典100冊」に載っているのはピープルウェアの第2版ですが、最新の情報を得るために第3版を読みました。