勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

2016年上半期に読んだ本からお勧め図書を選んでみる(文芸、ビジネス、技術書)

book Kindle

昨年に引続き、2016年1月～6月に読んだ本についてふりかえってみるもの。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あと雑誌コミック類もけっこう読んでいるのだけれども、これは除外。全般的には旬な本をぜんぜん読んでいないな・・・

2016年上半期に読んだ本を並べてみた










































オススメ文芸書編

色々と読み散らかしているけれども、ITエンジニア的に以下スライドを見て手に取った「赤めだか」が面白かったし名著だったので一番のオススメ。教育論としても読めるけれども、単純に内容が面白くて楽しく読める。古典落語にも興味を持ってしまった。

赤めだか (扶桑社ＢＯＯＫＳ文庫)

赤めだか (扶桑社ＢＯＯＫＳ文庫)

もうひとつ。今年映画化もされた「火星の人」はジャンルとしてはSF小説だけれど万人向けのエンターテイメント作品となっているので強くオススメしたい。逆境に立ち向かうエンジニア魂に震えるし、その経過を面白おかしく日記形式で書くという構成はソーシャルネット時代向きで楽しい。

火星の人

火星の人

オススメビジネス書編

今年前半は割と人類の進歩を実感することが多かった。重力波の検知が報道されたり、日常的に人工知能の話題が聞こえるようになってきた。というわけでレイ・カーツワイル氏の「シンギュラリティは近い―人類が生命を超越するとき」を取り上げたい(なおこの本は2005年の著作である)。現在読んでも非常に刺激的だが、電波な内容も含んでいるので注意（同氏は自身の肉体で実験を行いながら不老不死を目指していたりする）。

シンギュラリティは近い―人類が生命を超越するとき

シンギュラリティは近い―人類が生命を超越するとき


とりあえず同書を読んで、自分は2045年まで生存することを優先度の高い目標にしている。

オススメ技術書編

残念ながら最近の旬の技術書をタイムリーに読めていない。「マイクロサービスアーキテクチャ」とか「カンバン仕事術」「スクラム現場ガイド」なども読みたいのだけれども辿り着けていない。2015年の積ん読をこなすので精一杯である。
「ソフトウェアシステムアーキテクチャ構築の原理 第2版」は有用度で文句なしの一品。アーキテクト関連の仕事をするのであれば目を通すべき鉄板本。
一方で「ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics」はサービス開発、製品開発に関わるエンジニアにお勧めしたい本。受託開発の人にはあまり響かない気がする。

ソフトウェアシステムアーキテクチャ構築の原理 第2版

ソフトウェアシステムアーキテクチャ構築の原理 第2版

ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics

ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics

オススメしないけど面白かった本

今年前半での大きなニュースの一つが「アルファ碁」であることは間違いないと思う。

で、ミーハーではあるものの改めて碁に興味を持ったので、いろいろ調べた結果以下の本で学習を始めてみている。

東大教養囲碁講座～ゼロからわかりやすく～ (光文社新書)

東大教養囲碁講座～ゼロからわかりやすく～ (光文社新書)

なんとなくルールと指し方はわかった気になっているが、ブラウザでできる碁ゲームでは9路盤で時々勝利できる程度。まったく上手にはならないけれども頭の体操としては楽しめている感じ。

最近の読書環境について

画像からも見て取れるように、読書の大半はKindle端末で読んでいる。読書時間のほとんどが通勤時ということもあり、物理図書だととても持ち歩けない分厚い技術書などが読めるのは大変に便利である。新型の端末が発売されているけれども2013年に購入したKindle PaperWhite(第5世代)を継続して使用中。バッテリーの持続時間は短くなっているのかもしれないけど1週間以上は持つので、まったく不便はない。

故障などで買いなおす事になったとしても、たぶん同じ機種（PaperWhite 広告なしWi-Fiモデル）を買うだろう。物理ボタンはあったら便利かもしれないけれど故障リスクもあるわけで、あまり興味は無い。

Kindle Paperwhite、電子書籍リーダー(第7世代)、Wi-Fi 、4GB、ブラック、広告つき

Kindle Paperwhite、電子書籍リーダー(第7世代)、Wi-Fi 、4GB、ブラック、広告つき

  • 発売日: 2015/06/30
  • メディア: エレクトロニクス

Kindle以外の本はだいたい公立図書館で借りたものを読んでいる。というわけで物理図書を購入するのは現在、または将来子供と共有したい時だけである。

読書の大部分は通勤時間と書いたけれども、最近の本の読み方は具体的にはこんな感じ

  • ビジネス書、技術書、文芸書を並行して読む（気分にあわせて選ぶ）
  • 通勤時間、電車等が混雑していない場合は読書。混雑している場合はPodcastなどを聴いている
  • だいたいKindle端末で本を読んでいるけれども、状況によってはスマートフォンのKindleアプリで読むこともある
  • 就寝前も読書。Kindle端末はバックライトがあるので便利
  • 技術書とビジネス書は読了後、カフェか自宅で読書ノートをまとめる習慣を継続中

年齢的にはそろそろ老眼が怖いのだけれども今のところは大丈夫。まぁそうなったらKindleで文字サイズを大きくして読めばいいのだけれど。

残念なレビュー、あるいはレビュアー心得

Project Management

ソフトウェア開発におけるドキュメントレビューについて最近考えていること。漫然としたレビュー、残念なレビューにより生産性が大きく損なわれていることが多い。とはいえ、自部門組織でもうまく改善できているわけではなく、どうしたらよいか悩んでいるのだけれども。
blackboard

（良い）レビューの想い出

ソフトウェア開発におけるレビューはいろいろと経験しているが、折に触れて思い出す出来事がふたつある。こんなことを書くと老害認定されるかもしれないけど書く。老いててすいません。

ひとつは社会人になったばかりの駆け出し時代（一部脚色しています）。社会インフラ的な基幹系システム（ホスト）の開発に参加したのだけれど、ドキュメントもコードもとても丁寧に厳密にレビューしてもらっていた。もちろん学生時代にレポート類のレビューを受ける経験はあったけれども、段違いの精度でのレビューに衝撃を受け、ソフトウェア開発を仕事にするというのはこういうものなんだと理解していた。具体的にはこのような感じ

  • インプットに対して、アウトプットが完全であることをセルフチェックした上で、有識者が時間をかけてレビューしていた
  • セルフチェックも、有識者レビューも文章、コードともに1行ごとに行い、インプットとクロスチェックをしてブロック単位で余白に印鑑押してた（結果として、印刷物の右側に自分のハンコとレビュアーのハンコがずらっと並んでいた）
  • 指摘事項はしっかりとコメントされ、加えて対面で理由も含めてフィードバック

今思うと、紙とか印鑑が非常に懐かしい感じ。ただ、ここで学んだ「レビューへの姿勢」は今も大切にしている。今でも自分がやるレビューではときどき、句読点やコード行すべてにマーキーで色を塗ってしまうのはこの時の癖である。


もうひとつは割と最近の話。大きな企業さんでの大規模な開発での経験（一部脚色しています）。いわゆるウォーターフォール型開発なのだけれども、上流工程を終了するためには形式的にはお客様の部長承認が必要だった。規模が大きかったので、ドキュメントは分厚いキングジム2冊のボリューム。期限ギリギリ夜遅くに提出物を提出して、翌日のレビューに望んだ時に目を疑った。部長さんが持ってきている文書ほぼ全てのページに付箋や書き込みがされている [ウワーッ、なんてこった！] 。こ、これはもしかして伝説のBillGレビューか・・・

私たちが仕様書を彼に送ったのがほんの24時間前だったことを考えると、彼は昨夜読んだのに違いなかった。彼が質問をし、私がそれに答えた。簡単な質問だったが、それがどんな質問だったかどうしても思い出せない。彼が仕様書をパラパラとめくる手元に目をひきつけられていたからだ。
彼が私の仕様書をパラパラとめくっていて [落ち着けよ！ 小娘みたいじゃないか！] …そして仕様書のすべてのページの欄外に書き込みがあるのを見たのだ。彼はあの分厚い仕様書をすべて読んで、欄外に書き込みをしたのだ。 全部読んだんだ！ [ウワーッ、なんてこった！]
http://local.joelonsoftware.com/wiki/%E3%81%AF%E3%81%98%E3%82%81%E3%81%A6%E3%81%AEBillG%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%AE%E3%81%93%E3%81%A8

レビューは無事に通ったのだけど、後で確認したらこんな感じ

  • 部長レビューはそもそも形式的ではなかった。ガチだった
  • 提出時間が遅かったが、徹夜で読んでいただいていた、というか全部読むポリシーとのこと
  • 判断（承認）を行うためには、内容をきちんと理解して、納得できるかを確認する

もちろんその方のスケジュールは超多忙。であっても、きちんとレビューする姿勢に恐れ入りました。

上記のような事を書くとSIer的だとかWFだという批判も受けそうだけど、今回書きたいのは「ちゃんと真剣にレビューすることは重要だ」ということ。

More Joel on Software

More Joel on Software

  • 作者:Joel Spolsky
  • 発売日: 2009/04/09
  • メディア: 単行本（ソフトカバー）

ソフトウェア開発の文書レビューによくある問題点

多くの現場において散見されるのはだいたい以下のような状況である。

  • レビューそのものが「技術の必要なプロセス」と認知されていない
  • 適当なレビュー方法が雑にOJTなどで、なんとなーく継承されている
  • 簡易な「読み合わせ」をレビューと勘違いしている

結果として、残念なレビューが後を絶たない。

必要なのは、レビューのやり方を見直すことです。ITエンジニアの方はたいてい、上司や先輩のやり方にならってレビューを実施しています。そのレビューのやり方には、改善の余地が多分にあるのです。
間違いだらけの設計レビュー

「レビューのスキルは、ITエンジニアとして知識を得て開発経験を積み、レビューを担当していくうちに身についていく」――。この誤った考え方がはびこっているため、レビューの改善が妨げられているように思います。
間違いだらけの設計レビュー

なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー改訂版（日経BP Next ICT選書）

なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー改訂版（日経BP Next ICT選書）

特に簡単な「読み合わせ」をレビューと称するのは大きな問題で、たとえば以下のようなレビューはただちに運用を見直したほうが良いだろう。

  • なんとなく、関係者が会議室に集まって始まる
  • 成果物（アウトプット）だけを時間内にざっくりと読み合わせる
  • 参加者がその場でたまたま気がついた問題点についてディスカッションする
  • 時間が来たらレビューは終わり
  • 指摘された事項を修正したらレビュー終わり

最低限のレビュアー心得

細かいレベルではいろいろあるけれども、最低限抑えるべき事項は以下の通りである。

  • レビューの目的を確認し、目的を達成するためにレビューを行う。なんとなくレビューしない
  • 原則としては事前にレビュー対象物を通読し、目的に即した重要度に基づき指摘を行う
  • 作業結果レビューであれば、インプットとなる情報とアウトプットを付き合わせ、感覚、勘と経験でレビューしない

もちろん忙しいとか、兼務で複数プロジェクト見ているとか、見切れないなどといった状況もあると思うけれど、BillGだってちゃんとレビューしているのだから、やるべきだろうと自分を戒めている。

ちなみに細々としたレビュー技法についての詳細も書こうかと思っていたのだけれども、以下の記事が良かったのでリンク紹介してお茶を濁す・・・

ウォーターフォール型開発プロセスの有効性

Project Management Waterfall Agile

牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。

pool-jump



こちらも合わせて読んだ

そもそも批判されるようなWF型プロジェクトは実在するのか

本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれに工夫を凝らしているので、実際に批判されるに値する害あるWFというのはあまり存在していないのではないかと考えている。外観をひとことで表現するとWFになるのだけれど、皆が魔改造をしており既にWFではなくなっている気がする。

以下は個人的観測による最近のいわるゆWF的プロジェクトの傾向だが、これが批判されるほどWFなのかは疑問がある。

1.計画駆動・計画重視である

プロジェクトを取り巻く環境や、さらされているリスクに応じて適切に計画駆動・計画重視することは必要に応じてやるべきだし、否定されるものではないと思う。
古くはバリー・ベームが2004に書いた「アジャイルと規律」でもバランスを取ることが重視されているし、

残念ながら、ソフトウェア開発に対するこれら二つのアプローチは、お互いにサポートしあう道を採るのではなく、相手をゼロサムゲームにおける対戦相手のようにみなしている。アジャイル主義者は、伝統主義者を罵倒し、プロセスを崇拝する「テーラー式」還元主義者によってソフトウェア開発の人間性が奪われていると嘆く。すると、主流派はそれに応戦して、ハッキング（ずさんなシステムを適当に作っている）とか、品質が悪いとか、真剣なビジネスの中にお楽しみを持ち込みすぎだと非難する。さらに、それぞれの陣営の真剣な信者がやってきては、ほとんど救世主のように甲高い声で自分の信念を言い立てるので、成功のための真の戦略を見つけ出そうとしているソフトウェア開発者やマネジャーはますます混乱するばかりである。
アジャイルと規律

アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバランス～

アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバランス～

近年だとエンタープライズアジャイルのガイドの一つであるDADについても、必要に応じた一定の計画重視を論じていたように記憶している。
ディシプリンド・アジャイル・デリバリー　エンタープライズ・アジャイル実践ガイド

ディシプリンド・アジャイル・デリバリー　エンタープライズ・アジャイル実践ガイド

2.フェーズゲートがある

段階的に計画や見通し、状況をチェックしながら進める（たとえば要件定義→設計などのフェーズ移行時）手法はWF的な特徴ではある。しかし実際には利害関係者が多岐に渡る大規模プロジェクトにおける合意形成や、有識者レビューによるリスク軽減を目的にしているものが多く、純WF的なゲートチェックを行うことは最近は少ない。どういうことかというと

  • ○○フェーズ（例えば要件定義）が完了したか

のチェックをするというよりは、

  • 現段階での分析結果について関係者は合意できるのか（みんなサインできる？）
  • 現時点の未確定事項や、リスクを棚卸して、計画を続行してよいか（コントロールはできてる？）

という実践的な確認が中心であり、忌避すべきようなものでは無くなっている印象。

3.プログラミングの工程で要員数が膨らむ

WFのお家芸として

  • プログラミング能力のないエスイーが大量に設計書を書いて
  • 大量に調達されたプログラマーがエスイーを呪いながらコードを大量生産
  • 効率悪ぃ〜

というものが以前にあったことは確かだけれども、これも現代ではかなり少なくなってきている。
短納期、大量開発が求められる場合もコードの自動生成とかフレームワークをうまく活用して、どこも効率良く開発するようになった。
要求されるスケジュールと規模を勘案して途中の要員数が大きく増えることはあるけれども、ゼロ年代のような人海戦術の精神論はイマドキあまり見かけない。

4.長期間の統合テストやシステムテスト期間が終盤に存在する

これもWFあるあるだけれども、あまり意味なく長大なテスト期間を設ける例は少なくなってきたと思っている。それなりの期間をテストに費やすケースは、

  • 関連システムとのスケジュール同期化を目的としたもの
  • 高い信頼性と品質を求められるために実施する

などの理由がきちんとある事が多い。
また、前述のDADでも統合テストの必要性は論じられていたし、アジャイル開発でも必要に応じて統合テストとかシステムテストは必要であろう。

また、世の中にはこんな事例もあるわけで、これらも含めてWFのタグがついているからと言って石を投げるのはあまりに乱暴な気もする。
www.publickey1.jp

亀だ愚鈍だと批判されることも多いSIerと大手企業システム部門ではあるが、経済成長も鈍化した昨今、それぞれが様々な工夫をこらしており、非効率を放置しているようなことはほとんどない。というか進歩しないと死ぬ。もちろん悪手も多いが、向いている方向性は正しいのではないかと思っている。

WFの課題

牛尾さんの記事では主にWikipediaの記事をベースにウォーターフォールの課題をいくつか挙げているのだけれど、同じ論点については過去に以下の記事でも深堀りをしたことがあるので参考に。

改めて「ソフトウェア工学で大切な10の考え方」からウォーターフォールの論点を抜き出すと、

  • ウォーターフォールというコンセプト、そのものについては誤解がある（構想者は1回限りの段階プロセスを想定していなかった）
  • コンセプトの適用は「All of Nothing」ではない。プロジェクトにあわせて最適化せよ
  • 「すべてを先に決定しなければならない」ということはない
  • しかし、慎重に検証しても大規模プロジェクトでは「納品後のソフトウェアの変更は要求フェーズでの変更より100倍も高くつく」
  • この事実を踏まえて、適切なプロジェクトの設計が必要である

ということになるというのが私の見解である。そういう意味では、WFもアジャイルも相互補完的に活用するものであり、要は適材適所であろう。というわけでWFもメリットあると思うよ。

エンタープライズ開発とアジャイル

実は最近の実感としてはエンタープライズ開発の領域におけるアジャイル開発プロセスの相性は割と微妙だと考えている。
というのも、企業システムはシステムと人間系が相互に密に連携したワークフローであることが多いため、システム側の適応性をいかに俊敏にしても、人間系が変更に追いついて来ないのだ。準リアルタイムに業務改善のアイデアをシステムに反映していっても、使うユーザー側が追いつかない。もしくは「慣れた頃に変更しやがって」と石を投げられる。

以前に大きな業務改革のプロジェクトに参画したことがある。そのプロジェクトでは、ある店舗業務を無くして新設する専門部門で一括処理を行うというものだったが、新組織を立ち上げるという性格から構想計画分析には多大な時間を要した(マスタースケジュールはとてもWF風だった)。新組織の役割や、そこでの評価の仕組みもかかわってくるわけで、人事や経営も巻き込んだ意思決定について時間をかけた。また当然組織やファシリティはシステムの完成にあわせて立ち上がるので、テストはビッグバン方式にならざるを得ない。この手のプロジェクトに対して、やれアジャイルだ、DevOpsだと言ってもあまり意味はないだろう。（なお、実はソフトウェアの開発部分はScrum採用してた。当時RUPを強く意識していたのだけれども、これはまた別の話)。

だから、人間系と密に結びついた業務ソフトウェア開発プロジェクトにおけるアジャイル開発プロセスの適用は、最近割と慎重に考えるようにしている。アジャイルでやりたいと言われても、ちょっと待て、と実際に言っている。

逆に言えば「人間系」の制約に縛られないソフトウェア、例えばコンシューマ向けのWebサービス事業開発や、自動取引の領域においてはアジャイル開発プロセスの親和性が非常に高いのだろう。ソフトウェアの改修や機能追加を人間系の制約なしに反映させることができるかどうか、人間系のボトルネック無くダイレクトに価値を生み出す事ができる領域なのか、というのが重要なポイントだ。ただ、悲しいかな企業システムの領域でこういった取り組みができる範囲は、割と限られているのではないだろうか。

まとめ / 今後に向けて

まとまらないのだけれども、言いたい事は次の通りである。

  • 現代的に工夫、改良されたウォーターフォール的プロジェクトには課題も多いがメリットも相応にあり、ステレオタイプとして否定非難すべきものではない
  • ビジネス適応領域に応じて、計画駆動とアジャイル型プロセスを使い分け、最適なプロジェクト設計をすべき

プロジェクト環境と開発プロセスが不適切な組み合わせとなってしまう事が、発注者と受注者（もしくは使用者と開発者）にとって最も不幸な事態である。これを避けるために、個人的には何れの方法論宗教にも組せず、学びを継続し、所属組織の能力向上を図り、顧客に積極的に提言できるポジションに踏み込んでいくことが重要なのではないかと思っている。

2016/6/23追記

わかる範囲で、本記事に反応いただいたブログ記事をご紹介（順次追記）。

2016/6/24以降追記

必ずしも本記事に反応いただいたものに限定していませんが、関連記事ということでピックアップしたものを随時追記。

Kindleで50%オフ以上セールが始まったけど目新しい技術書が無い

book Kindle

どうやらKindleで50%以上オフのセールが始まっているようなのだけれども、目新しいものがあまり無い印象。とりあえず読んだ事のある中でオススメのものをピックアップしてみた。

高額技術書カテゴリー

【電子合本版】Code Complete 第2版　完全なプログラミングを目指して

【電子合本版】Code Complete 第2版　完全なプログラミングを目指して

技術書としては鉄板本。全員読むべき。今回合本版が新たにリリースされて、こちらはセールになっているがバラ売りは定価のままなので注意が必要。

ソフトウェア要求　第3版

ソフトウェア要求　第3版

要求定義関連のトピックをおさえるのであればオススメ。

レガシーコード改善ガイド

レガシーコード改善ガイド

今年に入って電書化された名著の類。いま読んでいるのだけれども、レガシーコードに悩まされている人は読んだ方が良い印象。

C#実践開発手法　デザインパターンとSOLID原則によるアジャイルなコーディング

C#実践開発手法　デザインパターンとSOLID原則によるアジャイルなコーディング

本書だけは未読。良書だという評判だけれども。

高額じゃないけどオススメ

ソフトウェア見積り　人月の暗黙知を解き明かす

ソフトウェア見積り　人月の暗黙知を解き明かす

ソフトウェア開発にかかわる人（技術者だけでなく営業さんも）にオススメ。

デッドライン

デッドライン

小説形式で読みやすいので、技術書が苦手な人にもオススメ。

闘うプログラマー［新装版］　ビル・ゲイツの野望を担った男達

闘うプログラマー［新装版］　ビル・ゲイツの野望を担った男達

こちらもドキュメンタリーで読みやすい。Windows NT開発秘話なのだけれども、ソフトウェア開発の難しさの本質について学べると思う。

テストから見えてくるグーグルのソフトウェア開発

テストから見えてくるグーグルのソフトウェア開発

グーグルのテスト戦略および品質改善の取り組みに関する本。テストという文脈だけでなく、プロセス改善という観点からも興味深い。

技術書じゃないけれど

HARD THINGS　答えがない難問と困難にきみはどう立ち向かうか

HARD THINGS　答えがない難問と困難にきみはどう立ち向かうか

技術マネジメントの観点でいろいろと学びがある。ベストセラーでもあるので、未読であれば

後進育成ついて考えたこと

Project Management Professional Engineer

「プロフェッショナルエンジニアは後進の育成よりも、自己の能力向上を優先すべきではないか」という意見を複数方面で見かけて考えたこと。管理者としての教育と、技術者としての後進教育は混ぜないほうがよいという意見。そしてエンジニアとして成長を望むのであれば「技術者としての後進教育」は意識すべきだと思っている。

というのはちょっと乱暴だと思うけどなー、という話

管理者による部下教育

会社組織における教育には2種類あって、その1つが「管理者による部下教育」である。もう1つは「プロフェッショナルとしての後進教育」なのだけれどもこれは後で書くことにして、管理者による教育についてまず整理したい。

管理者による教育についてはいろいろな論があると思うけれども、アンドリュー・S・グローヴの経営論などを参考にするとだいたいこんな感じである。

  • 教育の目的は部下・チームから最高の業績を引き出すことである
  • メンバーのスキル習熟度に応じて、マイクロマネジメント方式から、関与を最小限にして任せる方法まで、マネジメントスタイルを調整しながら教育する
  • 目標設定に関与することにより、必要とする能力の学習を促進する
  • 査定に関与することにより、不足する技能があれば矯正する方法を考える。また良い成長を促進する
  • 人員配置に関与することにより、アサインに関する期待や不満をコントロールする

インテル経営の秘密―世界最強企業を創ったマネジメント哲学

インテル経営の秘密―世界最強企業を創ったマネジメント哲学

実際に、うまくやれているかどうかは別にして自分は上記を強く意識している。管理をしているメンバーを面談するときには、「管理職としてのアドバイス」なのか「技術者としてのアドバイス」なのか極力明確にフィードバックしようとしている。

ただ、この「管理者による教育」を一定年次以上のシニアなエンジニアが必ずやらなきゃいけないかというと、それは違うと思う。そもそもこれを実行するためには必要な職責や権限もあるだろうし、スキルとしても追加で学ばなければいけないことはあるだろう。そういう意味で冒頭の倉貫氏のツイートに戻ると、これは「余分な仕事」として関与しないような組織体制作りはアリなのかなぁと。

技術者としての後進教育

もうひとつが「プロフェッショナルとしての後進教育」である。人によって意見は違うと思うけれども、職業プロフェッショナルを名乗るのであれば「自己研鑽」と「他の技術者の育成支援」は必ず意識すべきであるし、やって当然というのが個人的な見解。
ITエンジニアについては、

  • 米国では一般的と思われる、ACM/IEEE-CSのエンジニア倫理規定でも「他のソフトウェア・エンジニアの専門的能力の開発を援助」することが規定されている
  • 国内では、たとえば情報処理学会 認定情報技術者 倫理要綱・行動規範というものがあるが、ここにも「自己研鑽」「他の育成の支援」は入っている

「自己研鑽」は別として「他の技術者の育成支援」まで本当に必要なのか、という反論はあるかと思うが、

  • 一定レベル以上に自己の能力を高めるためには、教育に関わることは必要だと思う
  • その方法は、部下の教育に限るものではないだろう。論文を書いたり、セミナーで発表したりするということも含まれる。とはいえ一般的には周りのエンジニアの能力向上に寄与するということが、自己能力を高めるひとつの方法だというのが個人的な意見

というわけで、後進教育にも一定関与して初めて一人前であると言えるのではないかと考えている。

以前に書いた以下記事も参考まで。

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

KindleでPoEAA(エンタープライズアプリケーションアーキテクチャパターン)が28%オフのセール中他

book Kindle

GW後半からKindleで広範囲な20%ポイント還元セール中になっているのだけど、PoEAAについては値引きもあわせて28%ほどの割引になっている模様（10%値引きに対して20%ポイント還元なので）。技術書としては古典だけれど、未読で興味のある人はチャンスかも。

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

古い本だけれど、固定レイアウトではなくて普通の電子書籍として読める（今読んでいるところ）。

あとこれも値引き＋ポイント還元で27%くらいオフかな。こちらは未読。

C#実践開発手法　デザインパターンとSOLID原則によるアジャイルなコーディング

C#実践開発手法　デザインパターンとSOLID原則によるアジャイルなコーディング

他の本は20%ポイント還元のみだけれど、購入予定の高額技術書はチャンスかも。個人的なオススメは以下。

セールは突然終わることもあるので、値引き状況はリンク先でご確認ください。

最近のSIer論に想うこと

Project Management

ここ数年、定期的にソフトウェア業界で盛り上がるのがシステムインテグレーター(SIer)のビジネスモデルに対する批判の話題である。いろいろと議論されるのは良いことだと思うのだけれども、自分の周りで不必要に不安を感じている人が多いのでいったん現時点での私見をまとめておく。最近よく面談で聞かれる「SIerってどうなんですか」「SIerに所属することについて不安を感じんですけど」という質問に対する2016年前半時点での答え。

Towel dna.jpg
By Ammit - selber Fotografiert, パブリック・ドメイン, https://commons.wikimedia.org/w/index.php?curid=247724

気をつけるべきこと

本論のSIer論とは全然関係ないのだけれど、先の震災の時に糸井重里氏が書いたこのコメントを紹介しておきたい。

このコメントは震災の後、デマを含む様々な情報がネットで飛び交っていたときに発せられたもの。文脈は異なるけれど、昨今話題となるSIer論についても様々な立場の人やメディアが、いろいろな立場で、いろいろな形で情報を発信しているので注意したほうがよいと思うのだ。そしていたずらに不安を感じるのはやめたほうがいいと思う。

ギーク向けには以下の書籍もおすすめしておきたい。

銀河ヒッチハイク・ガイド (河出文庫)

銀河ヒッチハイク・ガイド (河出文庫)

作中に登場する（本当の）銀河ヒッチハイクガイドにも、表紙には親しみやすい大きな文字で『あわてるな』（Don't Panic、パニクるな）と書いてあるぞ。

自分のキャリアとビジネスについて再考する

現在も進行中だし、今後もSIerを中心とするIT業界は大きな変化が起こっていくだろう。
ただ、いたずらに不安を感じて安易に船を乗り換える行動をするのは乱暴すぎるし、リスクも大きい。
というわけで、個人的にはPanicになっている人には以下のアドバイスを行っている。

  • SIerというと将来は明るくなかったり不安を感じたりするかもしれないけれど、もう一歩踏み込んでソフトウェア開発業務に従事しているという立場に立ち返って、ものごとを考えた方が良い
  • SIerはあくまでビジネスモデルの一形態である。課題は多いが、ビジネスモデルの良し悪しは本来は技術者のキャリアパスとは直接関係ないはずだ。ビジネスモデルとキャリアパスを一緒に考えるのは筋が悪い
  • ソフトウェア開発のプロフェッショナルとして仕事をすることに立ち返って、自分自身のキャリアパスを考えるべき。そして、そのキャリアパスを実現するためにどう行動するか、が重要
  • 5年後くらいまでのキャリアの見通しを考える。見通しが立たないのであれば情報不足か検討不足だ。まず見通しを立てるべき
  • 10年後くらいに業界それを取り巻くビジネスモデルがどうなっているかなんて、誰にもわからない。ソフトウェア開発技術者としてのキャリアをしっかりと構築しよう
  • 現在のアサインメントに不満があるのであれば、それを改善するために何ができるのかを考えよう。プロジェクトなんて千差万別だし、移ろい変わるものなのだから（特にSIerにいれば）
  • ソフトウェア開発を行う場所としては、SIerは選択肢（プロジェクト）を固定せず、うまく渡り歩く事でいろいろなキャリアを構築しやすい。その特性を有効活用できないか考えてみるといい
  • 職場文化は自らが創るものであると考える
  • 仕手士になるな。中抜きの仕事で満足するな

キャリアデザインについて考えている人におすすめの本は以下の2冊。前者は若手向け。

仕事のための12の基礎力　「キャリア」と「能力」の育て方

仕事のための12の基礎力　「キャリア」と「能力」の育て方

ワーク・シフト　─孤独と貧困から自由になる働き方の未来図<2025>

ワーク・シフト　─孤独と貧困から自由になる働き方の未来図<2025>

現時点でのSIerに所属する自分の考え

  • 勝負はこれからだ
  • キャリア構築は長期戦だ。いま何の仕事をやってるか、短期的な役割は割とどうでもいい
  • 自分の市場価値が低下しないように、自己学習投資は怠らない
  • 20年後も、現場の中堅・若手と競争できるようにするにはどうすればよいかを考える
    • 国内の労働者数は今後減少していく。健康で、競争力があれば老いても仕事はある（ということを最近先輩諸氏が示してくれている）
    • 働きつづけることは普通になる

未来の職業生活に向けて準備するのは、刺激に満ちた経験だ。今後数十年の間に、仕事の世界で多くの変化が起き、キャリアや働き方に関する古い常識が次々と葬りさられる。
ワーク・シフト　─孤独と貧困から自由になる働き方の未来図<2025>

みなさんのお父さんやおじいさんは――お母さんやおばあさんは仕事をもっていない場合が多かったでしょう――生涯を通じて一種類の仕事を続けるのが普通でした。でも、みなさんは六〇年以上、働き続けることになります。生涯の間に、いろいろなタイプの仕事を経験するケースが増えるはずです。最初の仕事に就いてから二〇年たって、別の道に移る人もいるでしょう。あるいは、四〇年たってから進路を変える人もいるかもしれません。まず学校に通い、その後で仕事に就き、それから引退生活に入るというシンプルな道のりを歩んで人生を送るケースは珍しくなります。複雑なモザイクのように、人生のさまざまな段階に教育や能力開発の要素を織り込むようになるでしょう。
ワーク・シフト　─孤独と貧困から自由になる働き方の未来図<2025>『子どもたちへの手紙』

  • 2045年まで生き延びて、シンギュラリティを突破を目指すのが目標
    • ここまで生存できれば技術的特異点の出現(超AI、不老不死技術など)によって、様々な問題が解決するはず

シンギュラリティは近い―人類が生命を超越するとき

シンギュラリティは近い―人類が生命を超越するとき

おまけ

ただし、古代ではあまり広くは使われなかった。当時、「メメント・モリ」の趣旨は carpe diem（今を楽しめ）ということで、「食べ、飲め、そして陽気になろう。我々は明日死ぬから」というアドバイスであった。ホラティウスの詩には「Nunc est bibendum, nunc pede libero pulsanda tellus.」（今は飲むときだ、今は気ままに踊るときだ）とある。

まだまだ踊りたい