勘と経験と読経

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

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

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

高額技術書カテゴリー

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

ソフトウェア要求 第3版

ソフトウェア要求 第3版

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

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

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

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

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

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

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

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

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

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

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

デッドライン

デッドライン

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

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

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

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

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

技術書じゃないけれど

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

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

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

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

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

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

管理者による部下教育

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

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

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

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

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

技術者としての後進教育

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最近のSIer論に想うこと

ここ数年、定期的にソフトウェア業界で盛り上がるのがシステムインテグレーター(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冊。前者は若手向け。

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

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

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

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

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

おまけ

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

まだまだ踊りたい

IPA/SEC情報処理システム高信頼化教訓の2016/1~3の更新点を読む

IT業界(?)のトラブル情報を収集して、そこから教訓を抽出して公開するという取り組みをIPA/SECが行っている。わりと惰性でやっている感はあるのだけれど、2016年1月から3月までにいくつか教訓が追加されていたので目を通して感想を書いてみた。

前回記事はこちら

2016/1~3に追加された教訓

今回読んだのは以下のもの。

ID タイトル 教訓
T20 パッケージ製品の機能カスタマイズに関する教訓 パッケージ製品の機能カスタマイズはリスクを認識し、特に必要十分なチェック体制やチェック手順を整備して進めること
T21 運用保守で起きる作業ミスに関する教訓 作業ミスを減らすためには、作業指示者と作業者の連携で漏れのない対策を!
T22 バッファプールの管理に関する教訓 隠れたバッファの存在を把握し、目的別の閾値設定と超過アラート監視でオーバフローを未然に防止すること
G10 システム動作の疑義問合せがあった場合の対応に関する教訓 関係者からの疑義問合せは自社システムに問題が発生していることを前提に対処すべし!
G11 システムの運用・保守に関する教訓 システムの重要度に応じて運用・保守の体制・作業に濃淡をつけるべし
G12 キャパシティ管理のマネジメントに関する教訓(その1) キャパシティ管理は、業務部門とIT 部門のパートナーシップを強化するとともに、管理項目と閾値を設定してPDCA サイクルをまわすべし
G13 キャパシティ管理のマネジメントに関する教訓(その2) キャパシティ管理は関連システムとの整合性の確保が大切
G14 キャパシティ管理のマネジメントに関する教訓(その3) 設計時に定めたキャパシティ管理項目は、環境の変化にあわせて見直すべし

[教訓T20]パッケージ製品の機能カスタマイズはリスクを認識し、特に必要十分なチェック体制やチェック手順を整備して進めること

微妙な事例。新規構築したコールセンタ受付システムにて、顧客向けにカスタマイズした箇所に不具合あり業務影響が出てしまったというもの。該当の不具合は事前のテストで検出することが難しいものだったということだが、そもそも顧客に「カスタマイズしている」ということを十分に説明していなかったという点が問題だったと言いたいようだ。

おそらく「このシステムは他社でも多数利用実績のある品質の高いパッケージです」という売り文句で導入したものの、いきなり不具合が出て「品質高いんと違うのか?」「そこだけは御社専用のカスタマイズ部分でした。本体品質は問題ありません」「そんなこと事前に聞いてないし、わかるかい!」という揉め方をしたのだろうと思う。

ちなみにIPA/SECでは「ソフトウェア品質説明」というキーワードで品質説明力(?)を高める検討をしているようで、以下の資料も興味深い。

[教訓T21]作業ミスを減らすためには、作業指示者と作業者の連携で漏れのない対策を!

わざわざ教訓にする必要があるのか、ちょっと悩ましい印象をもつ事例。あいまいな作業指示+結果を作業指示者がちゃんとチェック検証していないでやらかしてしまったトラブルである。TPSにおけるポカヨケを考える必要がある印象。

[教訓T22] 隠れたバッファの存在を把握し、目的別の閾値設定と超過アラート監視でオーバフローを未然に防止すること

こいつも微妙な事案。後方にあるキューが溢れて、業務全体を管理するキューまで溢れて全業務停止、といった内容。これは単純に運用設計の漏れな気がするのだけれども・・・。

[教訓G10]関係者からの疑義問合せは自社システムに問題が発生していることを前提に対処すべし!

一部の接続先通信業者から接続異常の問い合わせがあったにもかかわらず、自システムの障害の可能性に気づかず相手先の問題として切り捨ててしまったために、問題発覚が遅れたという事案。ある意味、インシデントの切り分けに課題があると思うのだけれども、保守体制にある程度の余裕がないと実運用で改善するのは難しいのではないだろうか。ただ、この事案は頭に入れておいたほうが良い気がする。

[教訓G11]システムの重要度に応じて運用・保守の体制・作業に濃淡をつけるべし

複雑で難しい事案。複合的な要因(製品不具合、リカバリー作業時の保守作業ミス)で重要なシステムが停止となったとのこと。教訓に書かれている通りでもあるのだけれど、システムの重要性を鑑みてレベル分けを行い、最重要システムはそれなりにコストをかけて障害対応訓練を行うべきだろう。防災訓練と同じで、スムーズな初動は訓練によって生み出されるものである。また教訓には書かれていないけれどシステムコンティンジェンシープラン的なものをきちんと策定し、毎年ちゃんと見直すような活動も重要だと思う。

[教訓G12]キャパシティ管理は、業務部門とIT 部門のパートナーシップを強化するとともに、管理項目と閾値を設定してPDCA サイクルをまわすべし

想定取引データ量の急変によりシステムが停止したもの。その後、IT部門と業務部門が連携してキャパシティ管理するようになったらうまくいったというベストプラクティスの共有となっている。

この教訓では「キャパシティ」というKPIについて議論がされているが、近年脚光を浴びているDevOpsに通じるものもある。システムという重要なビジネスリソースを最大限活用するという意味では、開発、運用、業務の三位一体での合意形成が必要という話があるが、まさにその一例であったという印象。2013年の夏のデブサミの基調講演でもそういった話があったことを思い出した。

[教訓G13]キャパシティ管理は関連システムとの整合性の確保が大切

次に紹介する教訓G14も含めて、単一の事例(どこかの会社からの報告)からいろいろと読み取って掲載しているようだ。この事例では、システム群全体のキャパシティを見極めるために、システム間の連携を台帳管理しながら関係者で頭を付き合わせて管理をするというプラクティスを紹介している。
このアプローチに似たものは何回か見聞きしたことがあって、確かに有用なのだけれども、台帳を維持する労力がバカにならないので、強い統制を効かせないと実行は難しいと思う。また、システム間連携管理台帳を「データディクショナリに登録して管理する」というのは考え方として違和感を感じる。マスタデータ管理と、トランザクション管理は別のスキームだと思うのだけれども、どうだろうか。

[教訓G14]設計時に定めたキャパシティ管理項目は、環境の変化にあわせて見直すべし

これも教訓G12,G13と同じ事例から抽出された教訓の模様。キャパシティをPDCAサイクルで維持管理しつつ、見直した内容を適切に次期システム検討のインプットに継承しましょう、ということが書いてある。その通りだし、異論は無いのだけれども現行システムの運用保守に、次期システムの考慮も同時に実施させるというのが現実的なのかどうか疑問を感じた。次期システム検討時に、きちんと非機能要件を検討分析すれば漏れないような気もするのだけれど。

Kindleで大規模セールで安くなった目ぼしい技術書リストアップ

Kindle技術書の定点観測結果より。30%~70%くらいの範囲で割引セール中の模様(ポイント還元を含む)。対象はこれからも変動あるような気がしている。割と高額な「エンタープライズアプリケーションアーキテクチャパターン」「ソフトウェアシステムアーキテクチャ構築の原理 第2版」「Code Complete」「エリック・エヴァンスドメイン駆動設計」「実践ドメイン駆動設計」「アジャイルソフトウェア要求」「ディシプリンド・アジャイル・デリバリー」あたりが狙い目な印象(未購入なら)。
あと、わりと新しい本であれば「The DevOps 逆転だ!究極の継続的デリバリー」あたりが安い。

アーキテクチャ構築の原理 第2版を読んだ

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」を読了した読書メモ。なお書籍版だと898g、616頁の大著をKindle版で手軽に持ち運べるのは有難い(もちろん、必要に応じてPCでも閲覧できる)。今後、何度も読み返すような本である。

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

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

最後には監訳者である榊原さんのあとがきが。

本書の真骨頂は、ビューポイントとパースペクティブのカタログ化にある。十二分なボリュームの書籍でもあり、生真面目に最初から600頁を読み進める必要はない。まずは第30章から読み始めてみるのもいいかもしれない。どこでどのテクニックを使うのか、インデックス的な使い方をするのも本書を有効に活用する1つの手だ。
ソフトウェアシステムアーキテクチャ構築の原理 第2版

すいません、生真面目に読み進めてしまいましたorz。というわけで、これから読む方は監訳者あとがきから読むことをまずオススメする。上記だけでなく、本書の読み解き方についてアドバイスがしっかりと書かれている......

なお、30章は「ソフトウェアアーキテクトとして仕事をする」である。この章では規模(小規模/アジャイル/計画駆動/大規模)や形態(社内システム/製品開発/エンプラシステム/既存エンハンス/パッケージ/ネット対応/廃止)ごとにアーキテクトとして検討する事項と、どの章を読むべきかがとりまとめて記載されている。第1部、第2部と読んだあと、自分の置かれている状況に応じて第30章を読み解き、ガイダンスに従って残りの章を読むのが良いかと思う。

ますます重要になるアーキテクチャ

現代では、いろいろな要因からソフトウェアの仕様はますます変化し易くなり、固定化や文書化が難しくなってきている。

  • ビジネス側の要請により、要求されるデリバリーサイクルが非常に短くなった
  • 慎重に計画・検討して構築するのではなく、迅速に構築して試行し、結果評価をすぐに再反映するような開発プロセスや基盤技術が実用的になった
  • 取り扱うニーズが高度化、複雑化したことにより、「作らずに仕様を決定する」ことそのものが困難になった。「作りながら考える」ことが必然となった

このような状況で「要件」や「仕様」をきちんと文書化するのは難しいだけではなく、無駄にもなりがちだ。最近見聞きするプロジェクト事例だと、専用の要求管理ツールやチケットシステムで管理することも多くなっているようである。アジャイル開発プロセスの文脈だと「ストーリー」とか「フィーチャー」と呼ばれるものが管理する対象である。

では、随時登録/更新される「ストーリー」のリストをインプットにソフトウェアは開発できるのかというと、そうではない。土台として必要となるのが開発の軸としての「アーキテクチャ」である。

最近、グローバルでアジャイル開発を啓蒙している組織の事例を見聞きする機会があったのだけど、やはり「アーキテクチャ」はきちんと文書化して共有し、その上で随時変化する要求を管理ツールで共有しながら順次開発していると聞いた。

思うに古き良き滝の時代に時間をかけて作成していた「要件定義書など」はある程度アーキテクチャの記述や表現を含んでいたんじゃないだろうか。しかし、時代の要請で「要件定義書」は失われ、別の形に変化してしまった。そこで、これまで以上にアーキテクチャを分析し、明確化する重要性は高まってきているのではないかと考えている。

アーキテクチャ構築の原理

さて、本書に何が書かれているかだけれども、詳細な目次は以前に新旧版の比較をした際の記事を見ていただきたい。概観としては以下の通りである。

  • 第1部 アーキテクチャの基本
    • アーキテクチャの概念についての整理。本書を読む上でも重要な「ビュー」「ビューポイント」「パースペクティブ」の関係について論じられている。
    • 第5章に「核となる概念間の相互関係」がモデルとして提示されているので、それを中心に読んでいくと良いと思う。
  • 第2部 ソフトウェアアーキテクチャのプロセス
    • どのようにアーキテクチャを検討し、最終的にアーキテクチャ記述(AD)に落とし込んでいくか、について記述されている。
    • 第13章で、サンプルとしての具体的なアーキテクチャ記述(AD)の章立てが提示されており、これと5章の「核となる概念間の相互関係」の関係を意識すると分かりやすい印象。

手書きの整理をしてみた。
https://www.instagram.com/p/BCLABITnEKC/

  • 第3 部 ビューポイントカタログ
    • ここからはアーキテクチャ検討において具体的に活用する観点のカタログである。
    • 「ビューポイントカタログ」はアーキテクチャ検討上の重要点が書かれているので、目を通して損は無いような気がする。

ビューポイントと、それぞれで作成する主要なモデルの関係を手書きで整理してみた。
https://www.instagram.com/p/BCVP6I9nEPF/

  • 第4部 パースペクティブカタログ
    • ここは、必要に応じて閲覧すればよい印象
  • 第5部 すべてを1つにまとめる
    • ソフトウェアアーキテクトとしてどのように取り組むべきか、についての論考。
    • 冒頭で紹介した監訳者あとがきにある、第30章はここに含まれている。

体力が許すならば第1部~第2部までは通して読んで、その後第5部を読んでから、必要に応じて第3部と第4部を読むのが良いような気がする。とはいえ、通読するのも非常に勉強になる、今後も何度も立ち返っていく教科書のような本であった。