勘と経験と読経

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

アジャイルじゃなくていいのに

アジャイル開発プロセス(批判)の話ではなく、汚れちまった「アジャイル」という単語に関して考えたこと。まあ、流行るということは、こういうことなんですかね。

大衆化/ファッション化する「アジャイル」とは

 最近読んでいる「FRICTION(フリクション) 職場の問題を解決する摩擦の力*1が良い言語化をしているので、まずは引用させていただく。ちなみにカーネマンが引き合いにでているがそれは「NOISE 組織はなぜ判断を誤るのか?」の話*2である。

 長年、アジャイル・ソフトウェアにまつわる運動には大いに魅力を感じてきたが、『フリクション・プロジェクト』では「アジャイル」という言葉を使わないようにしている。種々雑多なアイデアの売り手たちが混乱を招く専門用語を並べ立て、「アジャイル」の旗のもとであまりに多くのツールや本、講演を売り込み、あちこちの職場にまん延するありとあらゆる病の治療法として、それらをすべてしつこく宣伝しているせいで、そんなもつれ合った情報の洪水を理解したり、解消したりすることはもはや不可能となっているからだ。
 カーネマンなら、各人が「アジャイル」と見なす言葉や方法があまりに多様化したために、ノイズの多い「アイデアのランダムなばらつき」に陥ってしまったということだろう。

 アジャイルソフトウェア開発のコアとなる考え方の有益さに疑うべき点はない。現代のソフトウェア開発の主流はアジャイルソフトウェア開発であるともいえる。しかし、ソフトウェア開発の枠組みを超えてなんでもアジャイルと言うようになってしまったのだ。結果のしてアジャイルという単語の無意味化が進んでいると思うのは、わたしだけだろうか。むしろいまさらアジャイルと言われると怪しげな話ではないかと疑うようにもなっている。

 なおソフトウェア業界の内部でも手法のファッション化について警鐘を鳴らすような動きはあったのだが、結局はビジネスという名の大きな流れに飲み込まれてしまい立ち消えてしまったのは残念だ。

 さまざまなアプローチが、ソフトウェアプロダクトの提供に構造と規律を与えている。だが、こうした手法やプラクティスの数は爆発的に増えている。なかには成功しているものもあるが、失敗したものや非常にコストのかかるものもある。多くの手法において、熱狂的なクリエイターとフォロワーの関係は「宗教」のようになっている。手法の人気はまるでファッション業界のようである。それぞれの違いがきちんと理解されておらず、人為的に拡大されているからだ。

似非アジャイルにだまされないためのチェックリスト

 というわけで、最近「アジャイル」という単語を聞くとだいぶ懐疑的になっているのだけれども、だまされないためにはどうしたらいいのだろう。例えばこんなチェックリストはどうだろうか

別に原理主義になりたいわけではないのだけれども、モヤモヤしている今日この頃である。皆さんはどうですか

*1:この本はとても良いので別途記事を書きたいと思っている。仕事に関する摩擦=フリクションをどのようにコントロールするかについて書かれた本である。

*2:正しく判断するためにはバイアスとノイズの両方を理解する必要があるということについて書かれていた本。有名な「ファスト&スロー」はバイアスについて扱っていたので、続編の本書はノイズについて扱っている。行動経済学には再現性などについての批判もあったが示している観点には有効なものも多いので興味があれば読んでみるとよいだろう

プロダクトマネジメントの方法論の逆輸入か?「両利きのプロジェクトマネジメント」を読んだ

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第82回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら

さて、今回読む本は「両利きのプロジェクトマネジメント 結果を出しながらメンバーが主体性を取り戻す技術」だ。少し前に流行ったキーワードに「両利きの経営」というものがあったけれども、「両利きのプロジェクトマネジメント」とは何だろうか。

www.shoeisha.co.jp

全体的な感想:発展し続けるプロダクトマネジメント系の知見をうまく統合したプロジェクトマネジメント方法論

本書のテーマである「両利きのプロジェクトマネジメント」は雑にまとめると

  • 計画駆動、従来のプロジェクトマネジメント方法論によるマネジメント、と
  • 対話や変化を重視する適応型のプロジェクト推進方法

の両方をバランス良く、時には切り替えながら実行するというハイブリッドなプロジェクトマネジメント方法論と理解している。
そしてその統合がバランスよく実現されているという点で、適応型のプロジェクト推進方法をうまく取り込んでみたいPMにとっては、参考になる点が多いだろう。
なお、本書はITプロジェクト向けに特化されたものではない点には注意が必要である。著者が想定しているのは、DXや新規事業、組織変革などゴールや要件を明確にすることが難しいプロジェクトとされている。

管理者のジレンマ:予測型か適応型か

そもそも現代のマネジメント方法論の花形は適応型だ。リーンスタートアップが源流のプロダクトマネジメントについて様々な議論が行われ、方法論が定義され、さまざまな講演や書籍が発表されている。現代ではPMと書いても「プロダクトマネージャーと、プロジェクトマネージャーのどっちの意味ですか?」と言われてしまうくらいである(個人的にはPdM、PjMと書き分けているけど、これもメジャーではない)。

そして活発に議論されている適応型・プロダクトマネジメントの最新知見はいろいろと参考になる。だが一方で「水と油」「ウォーターフォールvs.アジャイル」ほどではないとしても、「音楽性の違い」くらいの壁があって予測型・プロジェクトマネジメントとの統合融合はなかなか難しいように思うのだ。

本書ではこの難しかった統合を「プロジェクトストーリー」という骨組みと「ミーティング」でコントロールしようとしている点は、かなり興味深いものとなっている。

でもそれって「両利き」っていうの?

「両利きのプロジェクトマネジメント」という呼称にはモヤモヤする。「両利きの経営(増補改訂版)―「二兎を追う」戦略が未来を切り拓く」「両利きの組織をつくる――大企業病を打破する「攻めと守りの経営」」あたりは読んでいるが、これらは組織経営戦略の議論なので、複数の戦略を同時に実行するという話を両利きと言っている認識である。同時に実行するということは組織論の文脈では、組織を分けるという意味でもある。

本書の「両利き」は状況に応じて観点や考え方を入れ替えるという意味になっているので、これはビジネスワードとしての「両利き」とはちょっと違うんじゃないだろうか……

どんなプロジェクトにも適用できるわけではない

本書の中では言及されていないが、おそらく以下のようなプロジェクトに「両利きのプロジェクトマネジメント」を適用するのは難しいだろう。この点には注意が必要だ

  • 顧客から受託したプロジェクト(確定的なゴールと納期がある場合)。共同開発といった形態ならセーフ
  • 再委託するプロジェクト(請負・準委任どちらでも)。任せきることができないのでアウト

ITプロジェクトであれば内製開発といったジャンルであればうまくいきそうだが、そうでない場合に本書で紹介されている進め方を全面的に取り入れるのは慎重な判断が必要になるだろう。一方で参考になる点は多いので、つまみ食いはどんどんすべきだ思う。

その他のメモ:本書で気に入ったこと、気になったこと

  • 全般的に、近年の最新の組織理論が積極的に取り込まれているので本書を通じてそういった知識を得られるというメリットもあるように感じた
  • 本書はプロジェクトマネジメントが主眼だが、同じような視点で組織マネジメントを論じている「冒険する組織のつくりかた──「軍事的世界観」を抜け出す5つの思考法」と響きあうものも感じる。この本はおすすめ
  • 本書では触れられていないが、プロジェクトが炎上した場合も曲線モードになる。とすれば炎上した場合に限らず平時も「両利き」でやるというのは、合理的なんじゃないかと読みながら考えた
  • 「自分たちのプロジェクトに合った道具を自ら作る」「持論を見つける」(第2章 前提とする世界観 ほか)といったプラグマティズム的アプローチは極めて現代的でよいし、好印象
  • 第5章 マネジメントすべき4つの領域 で語られている『プロジェクトの計画は「物語」である』という考え方が好き。この詳細が語られている第6章もよい

プロジェクトを立ち上げる際に立てる計画が、単なる作業項目・タスクが羅列された機械的なスケジュールではなく、プロジェクトが歩んでいくであろう道筋が豊かにイメ ー ジできるような物語(プロジェクトストーリー)であるべきです。

というわけで本書は読了。次はちょっと古い本ですが「超予測力 不確実な時代の先を読む10カ条 (早川書房)」を読む予定。このブログ記事で紹介されていて興味を持った次第。

おっさんITエンジニアの後輩に勧める10冊の本 2025年版

いわゆるエンタープライズ向けソフトウェア開発技術者向けにお勧めする本をまとめてみた、というか10年くらい前に書いた記事を見直したもの。後輩から「後輩に勧めたい本を教えてください」という相談を受けることがあって(白目)記事が古くなっていたことに気づいたのだった。10年前の記事と同様にSIer勤務でお固めのドメインの受託開発に従事しているエンジニア向けになっていると思う。なお学生、新人、初心者向けにはなっていないのであしからず。

10年以上前に書いた記事はこちら
agnozingdays.hatenablog.com

ソフトウェア開発ライフサイクル全般

IPA 応用情報処理技術者試験

いきなり資格試験のテキストを紹介するのは心苦しいのだけれども、以下の理由で応用情報処理技術者試験をまずは推しておく。

  • ネットでは珍妙な設問などでバカにされることも多いが、それだけ利用している人も多いということでもある。まだある、ということに意味はあるだろう
  • 事実として、「情報処理の促進に関する法律」に基づき経済産業省が、情報処理技術者としての「知識・技能」が一定以上の水準であることを認定している国家試験であり、要は税金によって投資されているカリキュラムである。アップデートされており、トータルバランスにも優れている
  • 「資格を取っても仕事ができるようになるわけじゃない」という指摘がよくあるしその通りではあるのだが、一方である分野の知識がモロ抜けしている(または誤った理解である)ということもあるので、ベースの知識習得として学んでおいてほしいところである
  • ちなみに資格を取れる程度の知識が習得されていれば、資格を取るかどうかは別にどうでもいい(とはいえ合格しておくのが良いとは思うけど)

△上記は記事執筆時点の書籍を紹介している。最新のものを調べて手に取ってほしい

プロジェクト管理

デッドライン

プロジェクト管理の基礎的なことを学習するなら、情報処理技術者試験のPMや、PMIのPMPをやれば良いと思っている(私の評価はPM>>PMP)。ここで紹介するのは、もう少し深くプロジェクト管理について考えるための本である。

この本はまず小説形式になっているので大変に読みやすく、あまり仕事で読書をする経験が無い人にもお勧め。物語のなかで、様々なプロジェクトマネジメントの鉄則が出てくる。例えば有名なのはこれ。

正しい管理の四つの本質

  • 適切な人材を雇用する
  • その人材を適所にあてはめる
  • 人びとの士気を保つ
  • チームの結束を強め、維持する

(それ以外のことは全部管理ごっこ

人月の神話

こちらは古典中の古典なのだけれども、ソフトウェア開発に従事するなら一度は読んでおきたい。ソフトウェア開発について書かれた本、本ブログでもたびたび登場する有名な「銀の弾丸」の概念の原典でもある。どんな本なのかはWikipediaにとても詳しく書かれているので参考までにチェックしてみると良いと思う。

アート・オブ・プロジェクトマネジメント

プロジェクト管理の最後は鉄板の名著としてこれを上げておく。本書にはプロジェクト管理の技芸に関する本だ。プロジェクトマネージャが考えるべきことについて書かれている。けっこう厚いけれど、文章もかなり面白いので楽しめると思う。

このあたりも参考に

巨大で危険な物体を操縦するときには、操縦桿をしっかりと握っているだけでは不十分です。あなたが操縦しようとしているものが巨大であり、多くの人が関与しているのであれば、より大きな慣性が働くのです。プロジェクトマネジメントにおいても同様ですが、巨大な機械(自動車、飛行機、航空母艦等)を操縦する場合、初心者は進路変更操作をしてから、実際に変更し始めるまでの時間を過小評価しがちです。

見積もり

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

ソフトウェア開発見積もりの古典的名著であるが、古びてはいない。タイトルに「人月」という文字が入っているのでアレルギーの出る人もいるかもしれないが、極めて合理的にソフトウェア開発作業を見積る方法について論じられており、今でも参考になることは多い。経験と雰囲気で見積もっている人は必ず読んでほしい本。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイル開発だから見積もりはいらない、という言説をときどき耳にするがそうではないという点ではこの本もチェックしておきたい。アジャイルプロジェクトにおけるプランニングに関する名著である。計画そのものもアジャイルに変更されるが、価値あるソフトウェアを構築するために計画は必要だということが説明されている。

設計

システム設計の謎を解く

業務システムの設計に関するバランスのとれた本。というか割とこの分野のチョイスが難しい。コードを中心とした本や、オブジェクト指向設計のパターン本ならいろいろあるけれども、割と汎用的な設計に関して書かれた本というのは思い当たらない。

筆者は「設計とは"考えること"であり、アウトプットはその一側面である」と考えているからです。設計は単純に右から左に書き写せばよいものでもありませんし、機械的にできるものでもありません。設計には他にも重要な要素がありますうが、最も重要なのは「考えること」です。
(はじめに、より)

アーキテクトの教科書 ~価値を生むソフトウェアのアーキテクチャ構築~

設計のパートでこの本を紹介するのは意外かもしれないが、現代のソフトウェア設計については以前にもましてアーキテクチャへの目配せが重要になっている。本書ではアーキテクト的な視点でソフトウェアの設計からテストまでをカバーしており、かつ初学者向けであるという点でおすすめしたい本となっている。

テスト

ソフトウェアテストの教科書

比較的コンパクトに、現代的なソフトウェアテストの概論、手法、分析手法までをカバーしている本である。より高度な本は沢山あるが、平易であるという価値もある。

コミニュケーション

Team Geek

最後にコミュニケーションに関する本について取り上げてみる。ソフトウェア開発におけるコミュニケーションに関する本である。本書のかわりに「人を動かす」を読んでもいいのかもしれないけど、この本ではソフトウェア開発独特のコミュニケーションの仕方についていろいろと示唆を与えてくれる。

本書は、ソフトウェア開発の社会的危機について扱ったものだ。したがって、君が確実にコントロールできる変数を取り上げたい。君自身だ。

本書の基本的な考えは単純である。ソフトウェア開発はチームスポーツであり、技術的要因と同じだけ人的要因が影響するというものだ。何十年もかけてプログラミングの技術面を学んだとしても、人間的要因を学んでいない人がほとんどだ。成功するにはコラボレーションについて学ぶことも必要である。ソフトウェアエンジニアリングの「ソフトスキル」に投資すれば、同じだけの努力でより大きな効果が得られるだろう。

以前に書いた感想はこちら

むすび

というわけで、以上で10冊である。絶版本や、名著であっても現代ではお勧めしにくい本などは除去して新しい本に差し替えてみた。心構えや思考法に関する本も世の中ではたくさんお勧めされているようだが、これも含めていない(流行っているものを読めば良いと思う。これだけ読んでおけばいいというものはないと思う)。もう少し技術に振った本(アーキテクチャや、コードや、設計方法論や、モデリングや、DB関連や、低レイヤ技術など)もお勧めしたいが、これも結局は必要になりそうなものを自分で探して読めば良いと思うのだ。アジャイルに関しては書籍よりは体験できる研修で学ぶことをおすすめする。

なお、いくつかのジャンルについては別の切り口でおすすめをまとめたページがあるので、興味があればご参照いただきたい。
agnozingdays.hatenablog.com
agnozingdays.hatenablog.com

就任予定はないけど「エンジニアリング統括責任者の手引き」を読む Part.2

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第81回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら

さて、今回読む本は「エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ」だ。ちょっと長いので前回は12章まで、後半である今回で残り全部を読む方針だった。というわけで後半も読み終わったので感想をまとめよう。

エンジニアリング統括責任者に就任する予定はまったくないし興味もないんだけれど、エンジニアリング組織を統括するようなテーマは割と身近で、興味深く読んだ。

「エンジニアリング統括責任者の手引き」とは

エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか」「スタッフエンジニア マネジメントを超えるリーダーシップ」の著者であるWill Larsonさんが書いた三冊目の本「The Engineering Executive’s Primer」の翻訳である。詳しい話は前回の記事に書いているので興味があればどうぞ。

最後まで読んだ感想

前半の感想でわたしはこう書いていた。

全般的には非常に面白く読んでいるが、「自分には関係なさそうな章」「日本企業向きではない章」なども存在するのでなかなか難しい本というのが第一印象である。ただ、あまり興が乗らないテーマの章であってもエンジニアリングに関する事例や著者の気づきなどにハッとさせられることが多いので、良い読書体験ではある。

結局、最後までこの印象は変わることがなかった。というか「大変よく練られ整理された上質のCTOブログを読んだ」という感じである。参考になることも多いし、「うーん、これは興味深いけどいらないや」という情報も多い。ただ、著者が突き当たった問題に自分が幸運にも突き当たっていないだけかもしれないので、いつかこの本を思い出して読み返すことになるかもしれないとは思う。そういう点では、けっこうメモは取った。

さて今回読んだ13章以降の簡単なメモをここにまた書いておこう

  • 13章 CEO、統括責任者陣、エンジニアリング組織との協働:マネジャーとして周囲とどのように信頼関係を構築するか。ここは学びが深い
  • 14章 エンジニアリング組織の幹部層を団結させる:組織運営という点でこの項目も興味深い
    • あなたのチームは、機能してますか?」が紹介されているが未読だった。この本で紹介されている『直属の部下ではなく、同格の同僚こそが「第一のチーム」であるという考え方』が本章のテーマである。うげぇ、その通りだよ
  • 15章 ネットワークの構築:業界内の頼りになる人脈作りについて。自分はあまり悩みはないのだけれども、この章は皆に強くお勧めしたい
  • 16章 同格の統括責任者のオンボーディング:新任の統括責任者をサポートする話。あまりこの発想がなく、よい刺激をうける章である
  • 17章 検証を伴う信頼:CTOはコードを書くなという話の再解釈。マネジメントに注力し「チームを信頼せよ」とよく言われるが、著者は「検証を伴う信頼」という考え方を提唱している。これは良い話
  • 18章 基準の調整:求めるレベルと、燃え尽きるような働きかたの話
  • 19章 エンジニアリングプロセスの進め方:ある意味ではこの章こそが「エンジニアリング統括」のメイントピックのような気もする。いくつかのパターンが提示されており、ちょっと時間をかけて考えたい内容
  • 20章 採用:効果的なプロセス構築について
  • 21章 エンジニアリング組織でのオンボーディング:けっこう注目している領域なので興味深く拝読。オンボーディングへの投資は費用対効果が高いはずなのに、二の次にされがちというのはマジでその通りだと思う
  • 22章 パフォーマンスと報酬:まあ、ここはお国柄の違いがあるという印象
  • 23章 企業文化診断データの活用:使い方に悩んでいたので助かる。まじで人事の人もこの章を読んでくれ!
  • 24章 エンジニアリング統括責任者のポジションを離れる:そもそもポジションにないので何とも
  • 25章 結び:『ソフトウェア業界はまだ黎明期だ。これまでにわかるようになったことよりも、学ぶべきことの方がはるかに多く残されている』残念ながらその通りなんだよなぁ・・・

本書の参考文献について読んでみる

著者の前著である「エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか」の参考文献リストはとても良かった印象がある。感動したのでインスパイアしたブログ記事を書いてしまったくらいだ

というわけで本書の付録にある「追加のリソース」も興味深く読んでいる。

訳者やレビュアーの皆様のブログ

snoozer05.hatenablog.jp
△訳者の島田さんのブログ。おおむね、訳者あとがきと一緒だった。

tech.andpad.co.jp
△こちらはレビューされた柴田さんという方のブログ。レビューで盛り上がった話なども紹介されていて興味深い。私も非常に興味深いと思った14章が推されている。

実践要件定義レビュー入門

AI時代になって、要件定義の重要性が増しているらしい。自分で要件定義をやる人向けの注意点もあるけれど、要件定義書をレビューする立場の人にも知っておいてほしいことがある。というわけで実践的な要件定義レビュー入門を書いてみたという記事。

要件定義をやる人はこちらの記事をどうぞ

目次

この記事の前提

システムやソフトウェア開発プロジェクトの要件定義フェーズにおいて、自分以外の誰か(情報システム部門であったり、コンサルやベンダーであることもある)が作成した「要件定義書」と言われるようなドキュメントをレビューするときのことを想定している。想定するあなたの立場は発注者、ユーザー、要求の出し手である。なお現代では様々な開発手法があって、要件定義をしない場合もあるがその場合は対象ではない(が、ある種のシステムやソフトウェア開発では要件定義を実施したほうが良いと思うがそれはまた別の話)。

要件定義レビュー全般で注意すべきこと

レビューといっても、作業途中で実施する中間レビューと最終レビューで異なる注意点がある。が、まずそのどちらでも留意すべき事項をあげておこう。

文章の校正をするな

レビューの目的はそもそも何か。この点についてあいまいなままレビューをしてしまうと悲しい事故が起こる。レビューの目的は、これから作るシステムまたはソフトウェアの開発作業で手戻り作業を減らすことだ。だから、レビューでは手戻り作業の原因になりそうな間違いを探す必要がある

だけどこの目的がきちんと共有されない結果、レビュアーは、目についた文章のミスを指摘してしまう。なぜなら、自分が学校や職場で経験したことのあるレビューはだいたいそういうものであるからだ。日本語のいいまわし、誤字脱字、フォントサイズやインデントなどを指摘してしまう。これはほとんど無駄である。

よく考えればわかることだが、要点定義書はこれから作るシステムやソフトウェアの青写真である。瑣末な表現上の誤りは、最終的に出来上がるシステムやソフトウェアの品質にほとんど影響しない。指摘をするあなたの労力も、その指摘を確認して修正する(もしくはしない交渉をする)作業者の時間もおおむね無駄になる。

それでも「この文章の言い回しは誤解を招く可能性がゼロではないので修正するべきでは」と考える人もいる。これは「善意をもって読み取れば、おおむね正しく読み取れるのであればセーフ」と判断することをおすすめしたい。自然言語で表現している時点で、多義性はゼロにならない。そういったあいまいさをゼロにしたいのであれば形式手法など高度な記述方式を検討すべきだろう(ただしコストがかかる)。

というわけで、要件定義書のレビューにおいては文章の校正のような作業を行うべきではない。見つけるべきなのは、もっと大きな誤りである。

ユーザーの責任を果たす

さて、要件定義に関する(技術者向けの)テキストである「ソフトウェア要求 第3版」に書かれている「ソフトウェア顧客の要求に関する責任宣言」を紹介しておこう。

あなたは次のことを行う責任がある。

  1. あなたのビジネスについてビジネスアナリストと開発者を教育する。
  2. 要求を提供し、明確にするために必要な時間を割く。
  3. 要求に関する情報を提供する際には、明確かつ正確な情報を提供する。
  4. 求められた場合は、要求についてタイムリーに決断を下す。
  5. 要求のコストと実現可能性に関する開発者の評価を尊重する。
  6. 開発者と協力して、要求に現実的な優先願位を付ける。
  7. 要求をレビューし、プロトタイプを評価する。
  8. 受け人れ基準を確立する。
  9. 要求に対する変更が発生した場合は、即時にそれを伝える。
  10. 要求開発プロセスを尊重する。

細かい説明は同書を参照していただきたいが、いくつか補足しておく。

  • 1. あなたのビジネスについてビジネスアナリストと開発者を教育する。
    • 要求を理解するために必要なビジネス知識を説明するのはあなたの義務だ
  • 2. 要求を提供し、明確にするために必要な時間を割く。
    • 忙しくとも、時間を割いて、忍耐強く要求を説明しなければならない
  • 3. 要求に関する情報を提供する際には、明確かつ正確な情報を提供する。
    • 自分が決めたことの責任を取りたくない、詳しく把握していないなどの理由で要求をあいまいにしておきたい誘惑にとらわれてはいけない
    • 要求をビジネスアナリストや開発者に推測させないようにしよう

ユーザーの権利は主張して良い

一方で「ソフトウェア要求 第3版」には「ソフトウェア顧客の要求に関する権利宣言」というものも書かれている。

あなたは次のことを期待する権利がある。

  1. ビジネスアナリストが、あなたが使用することばを話す。
  2. ビジネスアナリストが、あなたのビジネスと目標について学ぶ。
  3. ビジネスアナリストが、適切な形式で要求を記録する。
  4. 要求プラクティスと成果物に関する説明を受ける。
  5. 要求を変更する。
  6. 互いを尊重する環境を期待する
  7. 要求とソリュ ー ションに関するアイデアと代替案について話してもらう。
  8. プロダクトを使いやすくする特性について説明する。
  9. 再利用により開発速度を上げるために要求を調整する方法について話してもらう。
  10. 機能に対するニーズと品質に対する期待に応えるシステムを受け取る。

同様に、いくつか補足しておこう。

  • 3. ビジネスアナリストが、適切な形式で要求を記録する。
    • 要求を、あなたが理解するように記述され整理されることは要求してもよい
  • 4. 要求プラクティスと成果物に関する説明を受ける。
    • 表記法について(それが一般的なものであっても、あなたになじみが薄いものであれば)説明を求めて良い
  • 6. 互いを尊重する環境を期待する
    • プロジェクトの参加者が味方同士で、尊敬しあって協力することを要求してよい
    • ただしこれは、発注者・受注者といった関係性を主張できないということでもある

具体化しすぎない

システムやソフトウェア開発では、段階的に要求を詳細化してモノをつくっていく。そして、つくる過程でさまざまな気づきや学習を経て、問題を解決することになる。これを理解せずに、要件定義の段階でむやみに要求を具体化してしまうと、後々の失敗につながるので注意が必要だ。

  • 要件定義でかなり細かい画面イメージを作り込んでしまうと……
    • 画面のディティールの検討ばかりを要件定義で実施して、時間が足りなくなる
    • 参加者それぞれの要望希望を全部盛り込むことになり、結果として過剰に豪華な要件を定義してしまう
    • 設計してみると使いやすさなどの問題が発覚。でも要件定義に書かれているので変更できず、使いにくい画面をそのまま作ってしまう
    • 実際に作ってみると技術的な制約で、まったく同一の画面の実現が困難であることが発覚する
  • 要件定義でデータ定義を細かく決めすぎてしまうと……
    • 実際のモノづくりの段階で検討不足が発覚して詰む

もちろん、問題があれば後で変更すればいいのだけれども、発注方法や契約形態などによっては余計な手間も増えることになる。というわけで要件定義では適切な抽象度を保つように心がける必要がある。

ソフトウェア開発における抽象度の話は「「具体⇔抽象」トレーニング 思考力が飛躍的にアップする29問 (PHPビジネス新書)」などで触れられているので興味があれば読んでみることもおすすめする。

要件定義の最終レビューで注意すべきこと

まず全体を俯瞰して要件が十分に表現されているかを確認する

間違い探しをする前に、全体として要求がすべて表現されているかを確認すべきである。書かれていないことは実現されない。この点は少し古い文書だがIPAの「経営者が参画する要求品質の確保」がうまく表現している。

システム開発の受託側から見た原則は「受託した要件として、書いてあるものは実現させる。書かれていないものは作らない。」ことです。システムは決めたとおりに作られ、決めたことに理解の誤りがない限り、正しい結果を生み出します。もちろん、プロジェクトのスタート地点で、すべてを誤りなく責任をもって確定することはできません。決め事も、それに基づいてのシステム構築も、人間である限り、見込み違い、思い込み、決め付け、聞き違い、聞き漏れはなくなりません。システム構築は、そういったことにより発生した「誤り、漏れ」を解消していく過程ともいえます。「要件の行間を読め」ということを要求してはいけません。基本的には当たりまえの前提や例外処理であっても漏れなく伝達する必要があります。
また、同じ言葉を聞いても頭に浮かぶものが異なるのが人間です。発注者、受注者双方が説明責任を果たすことが、多様化した要求と、複雑化したシステム開発において品質を確保する重要なポイントとなることは間違いありません。

といっても抽象度の高い要件定義書を見て十分かどうかを判断するかは、なかなかに難しい。以下のような方法でまずチェックしてみると良いだろう

  • 要件定義書を見ながら、標準的な業務のはじめから最後までを実現できるイメージが持てるか、確認する
  • 業務で発生したら嫌なトラブルをいくつかあげて、新しいシステム・ソフトウェアではどのような取り扱いになるのかを、確認する

要件定義書の出来が悪かったら立ち止まる勇気をもつ

全体としての定義内容に違和感があったり、意思決定を先送りした未決の課題が多数あるような状態であったら、システムやソフトウェアの開発に進む前に立ち止まることを検討すべきである。不十分な要件定義から生まれるのは、ハウルの動く城であったり不気味なサイボーグであることが多いからだ(もしくは、完成しないという場合もある)。

IPAの「ユーザーのための要件定義ガイド 第2版」でも

内容に自信が持てないならそこには何らかの問題がある、思い切ってやめることも時には必要

と記載されており、この判断を選択肢に入れておくというのは重要なポイントだ。

  • 要件定義の出来が悪いことを、誰か(例えばベンダー)のせいにするのはやめよう
    • ときどきベンダーやIT部門に対して「システム開発のプロはそっちなんだから責任がある」的な言説を聞くけど、それをいったら業務のプロはユーザーだろうという水掛け論になるので、おすすめしない
    • IPAなどの整理だと「要件定義は発注者の責任」という論もあるけれども、実際のところは協働作業だ。責任は全員にある
  • システム開発を中止するとしても、要件定義がうまくいかなかった原因をきちんと振り返ることには意味がある
    • 単純に検討時間が不足しているとか、巻き込む参加部門が不足していたとか、業務の整理が不十分だったとか、原因にはいろいろある。原因がわかれば、次回に向けた対策ができる
    • そもそもシステムやソフトウェアの要件定義は難しい活動ということも認識すべきだろう。物理的な構造物(ビルとかオフィスとか橋とか)に比べるとソフトウェアは抽象度が高いので、要件を定義するのは簡単ではない。いろいろ検討を重ねた結果、初期の要件と結論がまったく正反対になることだってあるのである。ただ、その困難性はやってみないとわからない
  • 後工程でリカバリーという判断は、できるという強い確信がある場合をのぞいて、やめておいたほうがいいだろう
  • 検討が不十分で未解決の課題が多い場合は、要件定義の期間を延長すればよい
  • 方向性が間違った方向に進んでしまっている場合は、方針を見直してからやりなおすのがよい


いろいろ書いたが、こんなところだろうか。本記事が参考になれば幸いだ。フィードバックやツッコミはX(旧Twitter)かはてなブックマークあたりでどうぞ。

就任予定はないけど「エンジニアリング統括責任者の手引き」を読む Part.1

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第80回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら

さて、今回読む本は「エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ」だ。ちょっと長いので前半では12章まで、後半で残り全部を読む方針にしている。というわけで前半を読み終わったので途中までの感想をアウトプットしておく。

エンジニアリング統括責任者に就任する予定はまったくないし興味もないんだけれど、エンジニアリング組織を統括するようなテーマは割と身近で、興味深く読んでいる。

「エンジニアリング統括責任者の手引き」とは

エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか」「スタッフエンジニア マネジメントを超えるリーダーシップ」の著者であるWill Larsonさんが書いた三冊目の本「The Engineering Executive’s Primer」の翻訳である。この方はキャリアポジションごとに深い考察を行うようで、キャリアップに従って書籍のテーマが変遷している点は興味深い。「エレガントパズル」ではマネージャーになったときの、「スタッフエンジニア」は上級エンジニアになったときのことが書かれており、本書はタイトル通り、エンジニアリング統括責任者すなわちCTOになったときに著者が考えたことを中心に書かれているようだ。そういう意味では「手引き」と書かれているが理論に基づいたマニュアルというよりは、実践知で組み立てられた引継ぎ資料のような手触り感がある。

一方で注意が必要だと思ったのは、結果として著者がキャリアップするにしたがって過去の考えを見直しているという点である。

本書の中で私が最も好きなのは、エンジニアリング戦略の策定について解説した3章だ。前著『スタッフエンジニア』(日経BP)でも、私はエンジニアリング戦略について解説した。それからわずか3年の開きしかないにもかかわらず、内容は大きく異なっている。

もちろんその内容の変化は視点が変わったことによるものなので、古いものが誤りであったというわけではないが、こういった実践知に基づいた本であることは意識しておいたほうが良いだろう。

前半(12章まで)を読んだ感想

全般的には非常に面白く読んでいるが、「自分には関係なさそうな章」「日本企業向きではない章」なども存在するのでなかなか難しい本というのが第一印象である。ただ、あまり興が乗らないテーマの章であってもエンジニアリングに関する事例や著者の気づきなどにハッとさせられることが多いので、良い読書体験ではある。

  • 1章 エンジニアリング統括責任者のポジションに就く:どうやって米国でCTOになるのかという話。ちょっとこれは縁がないわ
  • 2章 最初の90日間:ポジションに就任して最初の90日間をどう過ごすか。これはCTOじゃなくてもありうる話であり、非常にためになる
  • 3章 エンジニアリング戦略を立てる:「はじめに」で著者も推している章であり、とても参考になった
  • 4章 計画の仕方:経営層クラスの計画立案の方法であって興味深いけど、ちょっと縁遠い内容
  • 5章 効果的なバリューを作る:組織のビジョンやバリューの話。これもなかなかうまく実行できていないので、たいへんにヒントをもらった
  • 6章 エンジニアリング組織の測定:いろいろなところにある測定論だが「まず自分のために測定する」という点にはハッと気付くものがあった
  • 7章 M&Aへの参加:これも縁遠い内容。いつか役に立つかもしれないが
  • 8章 リーダーシップスタイルの開発:状況に応じてスタイル変えようぜという話で、参考になる
  • 9章 優先順位とエネルギーの管理:これは燃え尽き対策に重要
  • 10章 効果的なエンジニアリング組織のためのミーティング:良い話。コミュニケーション計画はいつも悩んでいるので、とても参考になった
  • 11章 社内コミュニケーション:これも立場は違えど参考になる。従業員に対してどうコミュニケーションしていくかについて
  • 12章 個人と組織のプレゼンスを高める:個人ブランディングの話を含む。著者のブログ論が面白かった

というわけで大変おもしろく、残り後半もしっかりと読んでいきたい。デッドラインは2週間後だ。

エンジニアリング戦略の策定について、前著と本書は何がどう変化したのか

以下は蛇足である。先ほど紹介したとおり エンジニア戦略について著者の考え方が変化しているとあったが、実際のところどう変化したのだろうか。この記事を書くにあたって両方の本を開いたので、ちょっと確認してみた。

「スタッフエンジニア」におけるエンジニアリング戦略の策定

ひとことでいうと、「スタッフエンジニア」におけるエンジニアリング戦略の策定はボトムアップなアプローチである。

「エンジニアリング戦略」を作成するには、5つの「デザイン文書」を書けばいい。その5つに共通する類似点を書き出せば、それがエンジニアリング戦略だ。「エンジニアリングビジョン」を作成するなら、5つの「エンジニアリング戦略」を書いて、それらが2年後にもたらすであろう影響を予測する。それがエンジニアリングビジョンだ。

なお、興味深いのはこの時点でもルメルトの「良い戦略、悪い戦略」が引き合いに出されている点だ。この本を読んで考え方が変わったというわけではなく、ポジションの変化で変わったという事がわかる。

「エンジニアリング統括責任者の手引き」におけるエンジニアリング戦略の策定

「スタッフエンジニア」ではエンジニアリング戦略の策定はボトムアップに行われていた。しかし本書では一転してトップダウンなアプローチを推奨している。

これらの(引用註:戦略はボトムアップで立てるべきという)主張は戦略の仕組みを誤解しているように思う。戦略はトップダウンでしか採用できないのだから、トップダウンボトムアップかという問題ではないのだ。問題なのは、戦略を持つか否かだ。戦略の施行に社会的圧力を利用できる小規模でゆっくりと成長する組織を除いて、トップダウンのリーダーシップ(またはその権限を委譲されたグループ)だけが、効果的な戦略に必要な慣行を施行できる。

まあCTOのポジションに立つならば、それはそうだと思う。なお前著で書かれた持論については、上級エンジニアが効果的に仕事を推進するという点においては最適であるというコメントがされている。つまり上位から適切なエンジニアリング戦略が示されなければ、ボトムアップで戦略を立てざるを得ないということなのだろう。

さて、いったんこの記事は終わりにして、続きを読むことにしよう。邪魔が入らなければ、2週間後に後編の記事をポストする予定だ

前略、戦略

あまり「戦略」という言葉は好きではないのだけれど、事情によりいろいろ調べてるという話。個人的には「作戦」くらいでいいんじゃないの。

戦略とは何か

戦略とはなんだろう。最近のエンジニアリングマネージャー向けの本を読んでいると、よく紹介される本がルメルトの「良い戦略、悪い戦略」だ。

Richard Rumeltによる『良い戦略、悪い戦略』(日本経済新聞出版)は、戦略を扱った代表的な書籍です。できれば時間をかけて読むことをお勧めします

スタッフエンジニアの道 ―優れた技術専門職になるためのガイド

や、

リチャード・ルメルトの古典的名著『良い戦略、悪い戦略』(日本経済新聞出版、原書“Good Strategy/Bad Strategy” Profile Books)の冒頭にある説明は、戦略に関する記述では私がいちばん気に入っているものかもしれません

プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド

とか、

Richard Rumeltの『良い戦略、悪い戦略』(日本経済新聞出版)は、これまで読んだ中で最もわかりやすい戦略に関する書籍で、私はそこから多くのことを学んだ」

エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ

ここまで推されたら読まざるをえないだろう。というわけで読んだ。極めて良い本だ。そしてなによりエンジニアにとって、わかりやすい。

良い戦略、悪い戦略

先に言っておくと、要点は「エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ」に完璧にまとめられているので、同書を持っている または オライリーのサブスク が使えるなら同書を先に読んだ方がいい。持っていない場合、もしくはより深掘りしたい場合に手に取ろう。

  • 2011年の本、という点では10年以上前の本ではある。最新の事例としてNVIDIAなどが紹介されているが古いのはご愛敬だろう。ただ有益性は損なわれていない
  • 表題どおりだが、本書の目的は多くの組織に存在するエセ戦略を倒すことにある。というわけで、役に立つだけでなく面白い本だ
  • 著者のルメルトはシステムエンジニアとしてNASAで働いた経験も持っている(エピソードも紹介されている)。というわけでエンジニアとしての親近感も感じる
  • 多数の悪い戦略がなぜダメなのかについて解説される。ダメな戦略にふりまわされている人にとっては特に楽しいかもしれない。適格に批評できるようになる

さて本書に書かれていることを雑にまとめると、良い戦略とは「漠然とした期待の表現ではなく」「具体的な課題を前にして行動を指し示す」ものだということである。精神論であったり、単なる数値目標だけであること、MVVは戦略ではないとバッサリと切り捨てられている。うーん耳が痛い。おっと、誰か来たようだ……

なお、本書では紋切り型の、テンプレートに穴埋めをしたような戦略を徹底的に批判しているため「考え方」は豊富にあっても「道具」の話がほとんどない点には注意が必要だろう。まあ、自分で考えるべきといわれればそれまでではあるが、道具も欲しくなってしまうのが人情というものだ。

経営理論からのアプローチ

というわけで理論や既存のフレームワークを押さえておきたい。というわけで以前に読んだ「世界標準の経営理論」も再読してみた(この本は辞書的によく紐解いている)。本書においては第33章がズバリ「戦略」テーマである。

第5部の最初に取り上げるのは、「戦略」(strategy)と「イノベーション」(innovation)とのマトリックスだ。とはいえイノベーションについては、第2部「マクロ心理学」編で様々なイノベーションに関する視点をすでに論じている。そこで本章では「戦略」に多くの紙幅を割きたい。

世界標準の経営理論

本章では戦略領域の(経営理論における)構造や、論点がまとめられており参考になる。技術というよりビジネス戦略(競争戦略)などについて考えてみるなら手に取ってみるのも良いだろう。

歴史からのアプローチ

経営理論は難しいし、ロジックではなくてナラティブで考えたいというのなら、この本はけっこう面白いし参考になるかもしれない。ただし大著なのでビジネス活用に限定するなら下巻から読むので十分だ(上巻は、戦争と政治の戦略の話である)。下巻の最後に経営理論、社会理論に関する現状の総括や分析も含まれており、カバー範囲は広い(ただし長い)。

  • 結論(?)は「良い戦略、悪い戦略」と等しい。対立があり、行動が必要な場合にのみ戦略は有効である。対立が表面化していない状況で戦略は必要ない。
  • (行動を導くという意味では)戦略はアート(技芸)であり、科学ではない

このあたりは、経営理論としての戦略とバランスを見ながら活用したいものである。

そもそも戦略って必要なんだっけ

一方で、そもそも戦略を中心とした軍事的世界観の組織運営に問題がある、という議論も最近は存在する。最近読んだこの本もたいへんに良かった。

  • 最近若手が会社を辞めてしまうという問題がある。その原因は、個人のキャリア観が会社中心から人生中心にシフトしたのに対して、組織の世界観がアップデートされていないから……という入り口の本
  • 戦略という点においては、ビジネスの世界が競争から価値創造にシフトしている状況のなかで企業が「戦略中心」であるべきではないのではないか、などと書かれていて興味深い

もちろん本書では既存の戦略をないがしろにしているわけではなく、デメリットも考慮しながらうまく活用していこうというスタンスではあるが、いろいろと参考にはなる。

雑なまとめ:戦略とは何か

そろそろこの雑な記事も終わりにしようと思うが、いろいろ読んでわかったことは以下の通りだ

  • 戦略は状況に対する意図である。なんとなく数年ごとにトップマネジメントが発表するポエムは戦略ではない
  • 戦略は状況を制御する手段ではなく、不透明な状況下で対処する方法である

なおいろいろな本を紹介してきたが、読みやすさという点ではルメルトの「良い戦略、悪い戦略」がおすすめ。カバー範囲という点では「戦略の世界史」の下巻(経営学も、ルメルトの理論についても含まれてはいる)という感想だ。でも、戦略なんてものを考える必要がないのが一番かな……