「一緒に歩く」ことについて

久しぶりのエントリですが、新会社設立のお知らせとなります。 

新会社設立のご挨拶

平素は格別のお引立てを賜り誠にありがとうございます。

このたび、株式会社フルストリームソリューションズを設立いたしましたので、謹んでお知らせ申し上げます。

みなさまのおかげで培うことのできた知識と経験を生かし、質の高いサービスを提供していきたいと考えております。

今後とも変わらぬご指導ご鞭撻を賜りますようお願い申し上げます。 

株式会社フルストリームソリューションズ

代表取締役社長　和智右桂

コンセプト

近年のITを取り巻く環境の変化により、従来であればITへの依存がそれほど高くなかった事業会社においても、デジタル技術の活用を意識した事業の改革*1が求められるようになっています。しかし、こうした会社が事業改革を成功させ、新しい事業を軌道に乗せることは容易ではありません。それを難しくしている要因は大きく二つあると考えています。

ビジョン策定の難しさ

一つ目がビジョン策定の難しさです。事業会社がDXに取り組む際には、どうしても「デジタル」の方に目が行きがちですが、本質的に重要なのは「トランスフォーメーション」つまり、事業改革の方法です。「事業改革」である以上、まず重要なのは「どこに向かうか」を示すビジョンである、ということになります。

このとき難しいのは、このビジョンを「どこまで地に足をつけて設定できるか」です。たしかに、優秀なコンサルティング会社は数多くありますし、そういった会社の提案をもらうことは一案でしょう。ただ、「VUCA*2」などと言われる現在において、客観的に正しい答えを目指すことはその会社にとっての正解とは必ずしもならず、必要なのは、その会社の文化というか、DNAが染み付いたビジョンを策定することになります。

そうしたビジョンの策定には、当然、その会社の経営陣を含め、会社の文化をよく知るメンバーでの深いコミュニケーションが必要になりますが、事業会社の主力メンバーは当然のように事業を運営するのに忙しいもので、腰を据えてビジョン策定をというわけにはなかなかいきません。

体制構築の難しさ

ビジョンが策定できたとして、そこに向かうための仕組みづくりの一環としてシステム構築が必要になるのはもちろんですが、並行して、その仕組みを運用保守していく組織体制を作っていかなければいけません。しかし、そうやって組織改革をしていく際にも当然、現行業務は続けなければいけません。それはつまり、「現行業務を続ける／新しい仕組みを作る／新しい仕組みに順応した組織を作る」の三つを同時にやらなければならないことを意味します。

これを自分たちだけでやりきるのは容易ではありませんが、だからと言ってどこかの会社に一括で外注して済む話でもありません。

こうしてみると、「ビジョン策定」にしても「体制構築」にしても、事業会社にとって必要なのは「一緒に歩く」相手ということになります。すなわち、自社の文化を尊重しつつ、一緒に考え、一緒に作るパートナーです。

＊＊＊

そんな存在になりたいと思って設立したのが、株式会社フルストリームソリューションズです。まだまだ小さい会社ですが、お引き立てのほど、よろしくお願いします。 

*1:一般的には、デジタルトランスフォーメーション、略してDXと呼ばれるものです

*2:Volatility（変動性）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧性）の頭文字を並べたもので、要は予測不能な状況を表しています

「協調型」リーダーのためのおすすめ３冊

9月に翔泳社より上梓した『スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー』のポイント整理と、「協調型」リーダーの理解を深めるためにあわせて読みたい本の紹介

『スモール・リーダーシップ』における「協調型」リーダー

『スモール・リーダーシップ』では、リーダーシップのあり方として、「協調型」という言葉を使っています。これについては平鍋さんの推薦の言葉を引用したいと思います。

自分で考え、自分で決め、自分が指示する、というやり方では、現代のプロジェクトは簡単に破綻します。それよりも、一緒に考え、一緒に決め、一緒にコミットするチームを作ること。そして、成功の喜びを分かち合う仲間を作ることのほうが、大きなビジネス成果を生み出すことができるのです。

つまり、リーダーに求められることを一言で言えば、「チームで考えながらゴールを目指す」ことになるのですが、それにあたって考えなければいけないことは大きく二つあります。一つは「チームで成果を出すこと」、そしてもう一つが「チームを成長させること」です。こう書くと簡単なようですが、そのために学ぶべき事柄は多岐にわたります。一方ではプロジェクトマネジメントの手法を知る必要があり、それと同時に、「チームで考え、問題を解決していく」ための広義のコミュニケーション能力が必要になるのです。

そこで、『スモール・リーダーシップ』では、チームとしてのゴールに向かうためのマネジメント手法と、コミュニケーションについて考えなければいけないことの二つを軸として整理しています。

本記事では、特に「コミュニケーション」にフォーカスを当てて、「協調型」リーダーにとって役に立つ本を紹介していきます。

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

リーダー／マネージャーの仕事を理解する

一冊目は、『最高のリーダー、マネジャーがいつも考えているたったひとつのこと』です。この本は、「リーダーとして、マネージャーとして何をしなければいけないのか」を実にわかりやすく教えてくれます。邦題が若干誤解を招きますが、「マネージャーとして知っておくべきこと」「リーダーとして知っておくべきこと」がそれぞれ個別に提示されています*1。

要約すれば、マネージャーに求められるのは「『人』と向き合うこと、つまり、メンバーの個性を理解してそれを活かすこと」であり、リーダーに求められるのは「進むべき方向を明確に示すこと」です。

一見、普通の組織論に見えますが、どちらかというと「個人として読者がどうするか」という視点で書かれている印象です。事例も豊富で題材も多岐にわたるため、読み物としても楽しめます。

最高のリーダー、マネジャーがいつも考えているたったひとつのこと

考える力を育てる

「コミュニケーション」というと「伝える」ことに目が行きがちですが、その前提として、いわゆる「論理的思考力」が備わっていなければなりません。さらに、「チームで考える」ことを目指すのであれば、自分が理解しているのは当然としたうえで、そうした「論理的思考力」をどう身につけてもらうかもあわせて考えなければいけないのです。

そこで二冊目は、『世界で800万人が実践! 考える力の育て方――ものごとを論理的にとらえ、目標達成できる子になる』です。タイトルにもあるように「子どもの考える力の育て方」の体裁をとってはいますが、ここで紹介されていることには子どもも大人も関係ありません。「答えを教えるのではなく、傾聴しながら相手が答えを出すのを支える」という姿勢は、協調型リーダーにとって欠かせないものです。

論理的思考のためのフレームワークとしては、TOCfEが採用されています。この本はTOCfEの教科書として見ても、きわめてわかりやすく解説されています。

世界で800万人が実践! 考える力の育て方――ものごとを論理的にとらえ、目標達成できる子になる

共感力を高める

「『仕事』なのだから感情は持ち込むべきではない」という考え方はもちろん正しいのですが、人間そこまで割り切れるようにできてはいません。そして、押し殺された感情は必ず別の形で噴出することになります。したがって、リーダーは「論理」だけでなく、「感情」に寄り添うことが求められるのです。

そんな苦労の絶えないリーダーのための三冊目は、『NVC 人と人との関係にいのちを吹き込む法』です。NVCとは、Nonviolent Communication（非暴力コミュニケーション）の略で、「人を思いやる気持ちを引き出し、人と理解しあう」ためのコミュニケーションの方法論です。方向性としては、『スモールリーダーシップ』でも紹介した『話す技術・聞く技術―交渉で最高の成果を引き出す「3つの会話」』に近い部分もありますが、こちらの方がより深く感情に寄り添っています。

NVCの大きな特徴は、まずは自分の感情を見極めるところから始まる点にあります。感情に触れれば、当然自分の感情も揺れます。「そうした感情に対してどう向き合うのか」から丁寧に解説されています。

NVC 人と人との関係にいのちを吹き込む法

まとめ

知識領域がどんどん幅広く、また深くなっている今、「知識労働においては、仕事の成果は「知的能力」×「コミュニケーション能力」で決まる」とも言われます*2。「知的能力」あるいは専門分野における能力を高めなければいけないのはもちろんですが、チームとして成果を出すためのコミュニケーション能力を高めるうえでフレームワークとなる本のご紹介でした。

*1:付け加えると、「個人として継続的に成功を収めるために知っておくべきこと」を含む三本の柱で構成されています。

*2:仕事で必要な「本当のコミュニケーション能力」はどう身につければいいのか? -p.156

組織と向き合うこと ~『スモール・リーダーシップ』出版のお知らせ~

9/11に翔泳社様より上梓した『スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー』について、簡単なまとめとふりかえり。

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

出版に至る道のり

ソフトハウスでプログラマを始めて以来、システム開発のベンダー側に10年ほど勤めていましたが、2015年10月からユーザー企業の情報システム部に勤務しています。早いもので、もうすぐ二年が経つことになります。「発注者の側に回っても、システム開発に変わりはなかろう」と思っていた部分はあったのですが、いざ移ってみるとその見込みの甘さに気づくことになります。SIer側にいた頃と比べると、文化や基礎知識、さらには責任範囲もまったく違う環境に移った結果、今までの「最前線で手を動かしながら、全体としてのバランスを取る（もしくは、周りのメンバーに取ってもらう）」というやり方が通用しなくなったことを強く感じました。これは、今にして思えば、できあがるモノやそれを作るプロセスの前に、以前にも増して「組織」と向き合わなければならなくなったことを意味しているのですが、転職してすぐの頃はそこまではっきりとは理解できませんでした。

「システム開発のような汎用性の高い知識は自分の中にある一方、業務知識はまったくない」という状況を受けて、最初のうちはチーム内の議論をファシリテートすることに徹していました。以前はそれほど多くなかった「ホワイトボードを使った認識合わせ」を数多くこなすうちに、そういう時のちょっとしたテクニックを言語化することは、「やろうとしてもなかなかうまくいかない」と困っている人の役に立つかもしれないと思い、最初はブログのネタとして書きためていました。そんな折に翔泳社の岩切さんから本を書かないかと勧めていただき、「実はホワイトボードの本を書きたいと思っているんです」とお願いしたのが、この本を書いたそもそものきっかけです*1。

その後、書き進めるうちに、「そうやって認識合わせをしていることの目的は、実は会議をうまく進めることに留まらないのではないか？」と、自分の立ち位置に気づくことになります。そして、「書くべきなのはホワイトボードの話ではなく、リーダーとしての仕事のやり方の話だ」ということになりました。

日々の仕事に追い回されていると「組織に対して自分は何をするべきなのか／したいのか」という根本的な問いかけをする機会は意外とありません。著者である自分自身にとっても、考えていることを言葉にできたことは大きな価値があったと思っており、お声がけくださった岩切さんに深く感謝しています。そして何より、読者の方にとって、日々のチーム運営の奥にある「人と向き合うこと」を改めて考えることが意味あることになれば幸いです。

本書で伝えたかったこと

「特定の問題を解決して成果を出すこと」と「組織と向き合うこと」は本来切り離せないはずですが、両者の必要な知識セットはだいぶ異なります。メンバー（プレーヤー）として仕事をしているときには自分で考えて答えを出せばよかったことも、リーダーになって「考えるプロセス」自体を共有しようと思えば、そのプロセスを改めて言葉にする必要が出てきます。ガラッと変わった環境に適応するため、私自身ここ二年ほどは、「組織」や「チーム」といったテーマについて、意識して本を多く読むように努めていました。

そういった活動を通じて感じたことが大きくは二つあります。

• どこまで行っても定跡は大切
• 定跡の奥には常に「人」がいる

どちらも基本的なことではあるのですが、一通り理解することはなかなか容易ではありません。

どこまで行っても定跡は大切

あるジャンルを扱った本を何冊か読んでいると、「根底に流れている考え方」もっと言えば「定跡」のようなものがぼんやりと見えてきます。システム開発で言うなら、例えば、「V字をきちんと設計しましょう」（つまり、「仕様は検証しましょう（横のつながり）」／「成果物間の連携は正確にとりましょう（縦のつながり）」）というような話です。

チームの文脈に置き換えるなら、「目標を設定し、そこに向けてメンバーの意識を揃え、そこに至る道筋を作り、日々発生する問題を解決し、定期的にふりかえって改善する」ということになるでしょう。これ自体は普通のことなのですが、目の前のタスクでいっぱいになってしまうと、こうした定跡が崩壊しつつあることに気づけないこともあります。そんな時に、拠り所になる場所があるだけで随分と違うものです。「計画づくりや線表術、問題解決、PDCAといったチーム運営の話について、ある程度わかりやすく整理することには価値があるだろう」という思いがまずはありました。

ただし、ここまでであれば通常の「プロジェクトマネジメント」の教科書のカバー範囲です。あえて書きたいと思ったことにはもう一つの理由があります。

定跡の奥には常に「人」がいる

こうした定跡は、確かに形を真似するだけでも一定の効果はある（というより表面的にでもなぞっておかないとひどい目にあう）のですが、本来的には、チームとして納得感を持って進めなければ、真価は発揮できません。チームで定跡を適用しようとした場合に、そうした定跡の奥で「人」と向き合うことが結局欠かせないのです。

しかし、そのために学ばなければいけないことは少なくありません。ロジカルシンキング、ファシリテーション、図解力、交渉術、セルフコントロールなど、少し考えただけで多岐にわたります。もちろん、一つ一つを取り上げれば名著は少なくありません*2。その一方で、チーム運営に必要なこれらの知識について、「チーム」あるいは「リーダー」という観点から、プロジェクトマネジメント自体の知識と合わせて包括的に説明してくれている本は存在しないように思いました*3。

結局自分としては、これまでの経験に加え、新しい環境での日々の体験と様々な本を読むことで得られた学びを実践に取り込み、試行錯誤しながらリーダーとしての仕事を進めることになりました。本書はこうして得た学びを気づきをまとめたものとなります。本書の内容について、私自身がすべてを100点満点で実践できているとも思いませんが、少なくとも心がけていることであり、また自分にとって一定の基準となっていることでもあります。そうである以上は、「リーダー」という役職で私と同じように悩み、手探りで進んでいる人にとって、手がかりになれるはずだと考えています。やや自画自賛ですが、仕事を抱え込んでメンバーを振り回していた5年ほど前の自分がこの本を読んでいたら、随分と仕事のやり方を変えられたのではないかと思っています。

チームがうまく機能していれば、リーダーの仕事はむしろそうしたチームの機能を促進し、周りの横槍から守ることになります。しかし、チームがうまく回っていない時には、成果だけでなく、チームとして向かう方向について指針を示さなければいけません。端的にいえば、「チームの仕事についてどう考えるか」という価値観を共有しなければいけないのです。「どう仕事をするか」「それについてどう考えるべきか」といった価値観について、なるべく地に足をつけながら記述したつもりです。

出版後のあれこれ

本書は予約時点から、Amazonのカテゴリ「経営理論」部門で第1位を獲得（9/2時点）、また、東洋経済の「売れているビジネス･経済書200冊ランキング」(9/12)で36位を獲得と望外のご好評をいただきました。予約してくださった方々のお手元には届いているかと思いますが、ご満足いただけていることを願ってやみません。

9/8のデブサミ関西では、「チームで議論すること」をテーマに読書会ワークショップを開催いたしましたが、こちらも参加者の方々の間で熱い議論が展開されました。積極的に参加してくださったことに感謝するばかりですが、書籍の内容が、多くの方々の抱える悩みに何かしら刺さる部分があったのであれば幸いです。

おまけ

今回本を書くうえで、いくつか軸となった価値観があります。裏話的ではありますが、この機会にそれらをご紹介したいと思います。

ポップであること

すごく当たり前のことなのですが、文章としてのタッチが柔らかいことは、内容のレベルが低いことを意味しません。重要なのは、根本にあるメッセージとそれを伝えるための論理構成であって、文体ではないのです。ともすれば耳慣れない概念を引っ張り出して、難しく説明したがる私の拙い文章を、適切に噛み砕いて平易な表現に直しつつ、全体の論理構成に目を配ってくださった編集の秦さんには何とお礼を言っていいのかわかりません*4。秦さんとの会話を通じて、文章を書くときの「間合い」が少しずつわかっていったことを覚えています。

特に最初にドヤ顔で提出した草稿の出来は凄まじく、今となっては自分でも正視に耐えないところもあるのですが、そんな草稿からスマートな目次案を示してくださった時には、匠の業を見た思いでした*5。そんなこともあって、草稿まで含めると、実際に書籍になった分量の1.5倍強は文字を書いたような気がしています。

学びを書くこと

前述した通り、「学ぶこと」と「実践すること」と「書くこと」がほぼ同時に起きている本ではありました*6。その時に勇気を与えてくれたのが、結城浩さんのこちらのツイートです。「自分が今回の執筆中に発見した喜びと驚きと感動を書く。そこにこそ本物の道がある」と（ぜひ全文を呼んでください）。正直、原稿の段階では受け売りっぽい内容が混入していたケースもありましたが、そういったものは推敲の時に細心の注意を払って排除し、自分が自分の言葉で語れることだけを書くように心がけました。これは、自分の言葉を刻む作業であると同時に、自分に言葉を刻みこむ作業でもあったように思います。必ずしも「斬新なこと」が書いてある本ではありませんが、地に足をつけることについては成功していると自分では思っています。

全体を貫く信念を持つこと

もう一つ大切にしていたのが、これもやはり結城さんのこちらの言葉。「本を書くときには全体を綴じる「糸」が必要で、それは著者の「意図」である」と。性質上、ノウハウ集的に散らかりそうになっていたところを、この言葉を見て軸を取り戻すことができました*7。本書で一貫して大切にしているのは「言葉」です。「言葉にする」ということは自分なりのものごとのとらえ方を宣言する、ということでもあります。だからこそ、リーダーとして自分の思想を言葉にすること、そしてメンバーの言葉を引き出すことは何よりも大切なのです。そういった信念を「糸」として全体の記述を見直して初めて、本としてのまとまりが得られたように思っています。

本書が読者の方とチームにとって、価値ある一冊となれば幸いです。

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

*1:この「ホワイトボード」の発想はAmazonの予約特典でひっそりと復活しました。

*2:特に、交渉術の『話す技術・聞く技術―交渉で最高の成果を引き出す「3つの会話」』、セルフコントロールの『サーチ・インサイド・ユアセルフ――仕事と人生を飛躍させるグーグルのマインドフルネス実践法』は読んで損のない２冊です。

*3:もちろん、これは私の狭い観測範囲に限ったことですので、私の知らない名著はあるのかもしれません。そうであればぜひ教えていただきたいと思います。

*4:もちろん、今の書籍の内容や構成に何か問題があれば、それは著者である私の責任です。

*5:岩切さんからも、「あなた、とりあえず本をたくさん読みなさい」と何冊もお借りしたことを覚えています。

*6:その意味で会社で一緒に仕事をしてくださっている方々全員に深く感謝しています。

*7:連ツイの日付を見ると5/24とありますが、期日的にはギリギリまで手を入れていました。恐ろしい量の赤に対応してくださった組版のBUCH+さんと何度も絵を描き直してくださったデザイナーの荒川さん（ことのはデザイン）には深く感謝いたします。

今年読んだ本と仕事に役立つおすすめ５冊（2016年版）

意識的に行っている多読の結果報告と、その中でのおすすめを５冊紹介。（紹介している本は今年出版されたものに限っていません。）

ふりかえり

今年の１月末から、意識的に多読をするように心がけています。目標は年間50冊としていて、概ね一週間に一冊です。一応、「エンタテインメントやコミックは除く」という制約を課していますが、哲学系、社会系は含めていて、必ずしもビジネス書だけというわけではありません。結果、今年は55冊ということで、月によって凸凹はありますが、目標としては達成できたことになります。ただし、9月以降は失速しているので、来年は、あらためて計画的に進めないといけなさそうですね。結果的に読んだ本の一覧はこちらです。

読書の管理にはブクログを使っています。web本棚サービスを使って読みたい本を管理するのは初めてでしたが、数値目標を立てたときには、結果を記録するのは必須ですね。非公開の読書メモも書けるので、「あの本にこんなことが書いてあったな」と後から見直すにも便利です。

一覧をざっと見返すと、私自身がSIerから「エンタティンメント系総合商社」という位置づけのユーザー企業に転職したこともあり、分野としてはドメイン知識や組織論が中心で、IT関連も上流寄りになっています。分野の選択をある程度戦略的に行うことで、自分の頭の中にある「目次」が広げられたような気がしています。一方で、ドラッカーの『マネジメント』や、コッターの『リーダーシップ論』、グリーンリーフの『サーバントリーダーシップ』など、「その道の古典」と言える本は積んでるだけでまだ手が出ておらず、来年はこの辺りもきっちりと仕留めたいと思います。古典は一通り読んだうえで、新しく出版された本を読み重ねるような形を早く作りたいものです。

さて、これらの中から、「仕事」という観点で読んで頂きたいおすすめを５冊ピックアップしました。

失敗の本質―日本軍の組織論的研究 (中公文庫)

失敗の本質―日本軍の組織論的研究 (中公文庫)

この本をきちんと読みたくて読書記録をはじめたと言っても過言ではないくらい昔から気になっていた一冊です。太平洋戦争について、敗戦の原因を日本軍の組織論に求めたうえで緻密に分析しているのですが、本書を貫く感情は「怒り」であり、それが本書をいわゆる組織論や軍事評論とはまったく別のものにしています。失敗から学び、それを繰り返さないことこそが祖先に対する敬意であるという強い意志が根底にあり、正直、仕事に「役立つ」と表現することがはばかられます。さらっと読める本ではありませんが、組織運営にすこしでも関わる人ならば読んでほしい一冊です。私も定期的に読み返したいと思います。

サーチ・インサイド・ユアセルフ――仕事と人生を飛躍させるグーグルのマインドフルネス実践法

サーチ・インサイド・ユアセルフ――仕事と人生を飛躍させるグーグルのマインドフルネス実践法

2016年5月出版。アンガーコントロールの本を探していて出会いました。瞑想術の本と言えなくはないのですが、「瞑想」という言葉から通常想起されるような脱現世的な価値観ではなく、ビジネスパーソンあるいは人と関わりながら生きる一人の人間として、心を平静に保ちながら人間関係を構築していくためのプラクティスです。大好きな一文を引用するなら、「相手の気持ちに同意することなく、それを理解し受け入れられるのは、発達した心のあかしだ」（p.243）です。それをできるようにするためのマインドフルネスなんですね。

あなたのチームは、機能してますか？

あなたのチームは、機能してますか？

全体としては、小説仕立ての前半と、フレームワークを説明している後半の二部仕立てです。ポップなタイトルと表紙とは裏腹に、「なぜ組織がうまくいかなくなるのか」が実にロジカルにわかりやすく構造化されています。組織を立て直そう、と思う人にとって、「何を前提としてまずどこに取りかかるのか」は重要課題であり、そういう悩みに対して間違いなく一定の答えを与えてくれる本です。

イシューからはじめよ―知的生産の「シンプルな本質」

イシューからはじめよ――知的生産の「シンプルな本質」

"知的生産の「シンプルな本質」"という副題がまさに本書の内容を的確に表現しています。適切に「課題」を設定し、それに「解」を与えていくという活動をどのように行うべきかが緻密に書かれています。あるイシュー（課題）に対して、一心不乱に解の質を上げようとするのは労が多くして益の少ない活動であり、まずはイシューの質を高めるべきである、という考え方が基本になります。もうすこし一般化すれば、いわゆる「仮説」思考であり、とにかく目の前の作業に没頭するのではなく、まずは適切な仮説を持って物事に当たるべき、ということを前提とし、それを発展した形であるとも言えるでしょう。いずれにしても、筆者の結果へのコミットメントの強さが、本書を単なるハウツー本ではないものに押し上げています。

27歳からのMBA グロービス流ビジネス基礎力10

27歳からのMBA グロービス流ビジネス基礎力10

「27歳からのMBA」というタイトルが果たして的確だったのかと疑いたくなるほど、ビジネスパーソンであれば絶対に抑えておかなければいけない内容です。「論理的思考力とコミュニケーション力」という基礎力をベースに、企画提案力と実行力という二本柱について語られています。単なるノウハウに留まらず、マインドセットにまで言及しているのが素晴らしいですね。きわめて幅広い内容をコンパクトにまとめているため、一つ一つに関する記述は少なめですが、重要事項の網羅性は高く、その後勉強をするうえでの有益なインデックスとなってくれます。

終わりに

他にもご紹介したい本はあるのですが、「50冊読んで５冊拾い上げる」ということに価値があるように思いますので、これに留めます。上記の中にまだお読みでない本があれば、ぜひ一度お手にとってください。

なお、今年読んで強く印象に残った本を最後にもう二冊挙げておきます。こちらは「仕事」とはまったく別の軸で読んで頂きたい本となります。

殺人犯はそこにいる (新潮文庫)

小説ではありません。まだ記憶に新しい「足利事件」の背後で、執念を持って犯人に迫るジャーナリストの方の記録です。

さびしすぎてレズ風俗に行きましたレポ

2016年6月出版。出版当時は話題になりましたね。タイトルで敬遠されている方もいるかもしれませんが、人と接することにある種の難しさを感じているひとであれば、誰でも心に刺さる内容だと思います（上記、55冊のカウントからは外れています）。

GxPで学んだ、ただ一つのこと

パラダイムを学ぶことと、実際にデリバリーすることとのバランスについて。あるいは転職報告。

導入

9月末を以て、グロースエクスパートナーズ株式会社を退職しました。４年と２ヶ月の間この会社にお世話になっていたことになりますが、その中できわめて多くの貴重な経験をさせていただいたと思っています。退職を決めてから、４年前に自分が書いたエントリ（SIを仕事にするということ）は何度か読み返しました。その中でGxPを表現した次の言葉は、今読んでも正しかったと思います。

ソフトウェアをデリバリーすることには、多くの「泥臭い作業」が伴います。そしてその「泥臭い作業」は本に書かれたり、語られたりすることがあまりない。それはたぶん、語るまでもなく当たり前のことであったり、語れるほどには言語化されていなかったり、語るほど面白くなかったりするせいでしょう。だからといって、「そういうこと」をしなくていいわけではない。このあたり、パラダイムと泥臭い作業をひっくるめた「デリバリー」の全体像が見えずに苦しんでいたわけですが、他にもそういう方はいるのではないかと思います。「バリューストリームの中で自分の手を動かしつつ」「企業をお客様として業務に使うアプリケーションを作る」ことができる場所があるんだということは、多くの方に伝えたいメッセージです。

この４年間のふりかえりとして、この文章にある「泥臭い作業」を言葉にしてみようとしてみたのですが、相変わらず「語るまでもなく当たり前のことであったり、語れるほどには言語化されていなかったり、語るほど面白くなかったり」したので、そのかわり、GxPで学んだマインドセットのようなものについて言葉にしていくことにします。おそらくそれは、自分が求めていた「パラダイムを学ぶことと実際にデリバリーすることとのバランス」にとって、欠かせない要素だったのだと思います。

納得して向き合う

その要素とは何か...と溜めるまでもなく見出しに書いてしまいましたが、「納得感」の一言に尽きます。「そうすることになっているから」「誰がそう言ったから」そういう理由で仕事を進めることは許されませんでしたし、納得できなければ誰に対してでも何かを言える文化だったと思います。では、納得とは何か。分解するなら、一つは「理解」もう一つは「説明」でしょう。どちらも同じコインの表と裏です。プロジェクトに対してなんらかコミットしようと思えば、この納得感を一定のレベルで確保しなければなりませんし、ましてや、プロジェクトのハンドルを握ろうと思えば、それを隅々にまで行き渡らせる必要があります。少し具体的に書いてみます。

「何を」「どのように」「いつまでに」「いくらで」「誰が」作るのか、それら複合した要素をプロジェクトとして組み立てるときにはツールが必要なのですが、この点に関する「これさえやれば大丈夫」という包括的なツールは、僕が知る限りありません。というより、「これさえやれば大丈夫」という感覚がそれ自体すでに危険です。

たとえば....「何を」に関して言うならば、ユースケースなりシナリオなりで対象システムが備えるべき「機能」を何らかのかたちで表現することは誰でもやっていることでしょう。しかし、作るものの性質に応じて、適した記述方法は変わります。画面とER図があればおおよそ大丈夫なこともあれば、なんらかのルールを表形式にまとめなければいけないこともあるでしょう。「設計書とは、あるいは要件定義書とはこのフォーマットで記載するものである」という固定化した発想からは確かに安心感は得られますが、確実に何かを取りこぼします。

さらに、その「何か」を具体的に「どのように」実現すべきかは、ハードウェア構成／ソフトウェアのモジュール構成等いくつかのビュー、いわゆるアーキテクチャで表現されることになりますが、分解された構成要素は「いつまでに」「いくらで」「誰が」というスケジュール／コスト／チームの根拠になります。アーキテクチャの方針によって複雑さは凝集することも点在することもあり、そういった実態を無視して引かれたスケジュールには現実性がありません。

他にもどういうドキュメントを書くのか、そのドキュメント同士はどうつながっているのか、テストとはどう関連するのか、テストの考え方は十分か、など考えなければいけないことを挙げていけばキリがありません。ただ、大切なのは、そういった個別の構成要素およびその関連性について、まずは自分が理解する必要がある、ということです。その理解は、計画時であればプロジェクト計画という作業結果ではなく、その作業を通じて、自分あるいはチームの中で醸成されるものです。そういった「理解」があって初めて、顧客に会社にあるいはチームに「説明」できるようになります。一会社員がプロジェクトに対して果たせる責任といえば、せいぜいがそういった説明責任だけなのです。逆に言えば、誰かのせいにせずに「こういった理由により自分はこれが正しいと考えている」と説明できる立場に立つことこそが、プロジェクトのハンドルを握るということなのだと思います。

余談ですが「自分がこう考えた」ということを基点に置くことは、プロジェクトに限らず、様々な面において後悔しないための一つの方法であるように思います。もちろん、ある種の後悔はするのですが、少なくとも自分のこととして引き受けて、誰かを恨まずに先に進むことはできますからね。そういうことをひっくるめての「納得感」ですね。

＊＊＊

社員がそういう姿勢で仕事に臨むことについては、どんな企業であっても少なくとも経営陣は望んでいるような気がします。それが様々な事情や経緯で現場レベルで実践できなくなっているケースも多々あるのだと思います。そういうことを求めつつ大きな裁量と共に仕事を任せていただいたこと、また、チームのメンバーが皆、主体的に考え動いてくれたこと、そして、色々なものを放りだして去って行く僕を温かく送り出してくださったこと、そういったことすべてについて、深く感謝します。ありがとうございました。

その後

10月からは、中間流通を軸としたエンタテイメント系総合商社の情報システム本部に勤務しています。立場が変わり、見えるものもだいぶ変わってきました。ユーザー側に移ったことにより、これまでできなかったことでできるようになったこともあると思います。ただ、根底にある「ものづくり」という本質はそう変わるものでもなく、これまでの経験を活かして引き続きがんばります。また、言葉を紡ぐ作業はこれからも続けていきたいと思いますので、どうかよろしくお願い致します。

ソフトウェアアーキテクチャの先に

最後に、少し宣伝めいたことを。10/1付で新しい翻訳書が出版されました。ちょうど転職のタイミングとなってしまいましたが、僕がGxP名義で出版する最後の翻訳書ということになります。編集の上野様、パートナーの岡澤さんにはいつものように多大なるご迷惑をおかけしました。また、10年前に書かれた本を訳させてほしいという私の勝手なお願いを引き受けてくださった翔泳社様に深くお礼申し上げます。

内容については、ゆうすけさん、今野さんのインタビューがこちらに掲載されていますので、興味のある方はどうかご覧ください。「結局のところ、アーキテクトは考えるという行為から逃れられない」という、ある種このエントリで書いてきた内容とつながるところがあるのですが、そういう、考えながら前に進もうとする人に対して、多くの気づきを与えてくれる名著だと思います。

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

パラダイムを学ぶことと、現実の中で活かすこと

本に書かれた内容を実際に使うことの難しさについて

導入

ここ一年ぐらい将棋にハマっているのですが、最近は棋力が上がらなくて悩んでいます。序盤で失敗して一方的に敗けるのが嫌なので、序盤から中盤の入り口について解説してある戦型の本をよく読んでいるのですが、いまいち「強くなった」という気がしません。原因は明らかで、「知らない形に出会った時に安定して力が発揮できない」のです。初めて見る局面でも自信を持って指せるようになりたい。多分私が触れたいのは、定跡とか手筋を超えたところにある「棋理」みたいなものなんでしょう。そんな話をあるプロ棋士の先生にしたときに言われたのが「お勉強しても強くなれませんよ」という言葉で、それが妙に耳に残っています。

似たようなことはシステム開発にも言えるのではないか、ということを最近よく思います。そのことについて、「ドメイン駆動設計（DDD）」や「スクラム」を例に言葉にしていきます。

DDDにせよ、スクラムにせよ、パラダイムとして優秀であることに疑う余地はありません。ただ一方で、「DDD/スクラムで開発をしようとしているが、いまいちうまく行っていない」という話も時折耳にします。こういう「うまく行かなさ」は何に起因するのでしょうか。

書き留められたパラダイムと現実のコンテキスト

特定のパラダイムを教える立場にある人なら、そのパラダイムを正確に理解することは欠かせません。ただ、プロジェクトやビジネスを推進している側からすれば、「優れた手法を取り入れることがプロジェクト（ひいてはビジネス）の成功につながるとは限らない」といえます。理由の一つとして、プロジェクトやビジネスが、置かれている環境や構成要因、対象とするドメインの性質、文化といったさまざまなコンテキストに束縛されていることを挙げられます。あるパラダイムが一つの体系として書き留められる場合、そうしたコンテキストは語られないため、そもそも適用段階で具体的にどのようにしたらよいかわからないことになります。適用の方法についての議論は、こうした「どのように」が多いような印象を受けています。ただ、こうしたことについてはそれほど深刻とは思えません。適用事例が増え、ノウハウが蓄積されるにしたがって自然と解消していくものでしょう。

より深刻なのが、「何をするべきか」という問題です。「DDD/スクラムを実践する」と、パラダイムが目的化してしまった場合、「何をすればDDD/スクラムをしていることになるのか」というメタな議論が生じます。こうした関心の横滑りはきわめて危険で、DDD/スクラムを正しく実践することに意識が向くと、プロジェクトの本来の目的から逸れてしまいます。DDDで言えば、モデルの正しさを追求するあまり、複雑化しすぎて誰にも理解できなくなったとしたらどうでしょう。あるいは、スクラムの実践に取り組み、「タイムボックスによる定期リリース」ができていたとして、バックログに積んであるものがバグフィックスだけだったとしたら、それはうれしいことなのでしょうか。それがうれしいとしたら、誰にとってなのでしょうか。

実践から得られるもの

わかりやすくするために極端な例を挙げましたが、現実に特定のパラダイムを理解し、そのパラダイムの価値を自分なりに解釈し、実際の文脈の中で必要なことを行って成果に結びつけるのは、決して簡単なことではありません。私自身は大筋、DDDであれば、適切なドメインの分析とドメインの特性に応じたモデリング／アーキテクチャ設計が、スクラムであれば、ゲームのルールに従うよりも組織全体のバリューストリーム／フィードバックループの構築が骨子だと考えていますが、具体的なコンテキストに置かれれば、また違った解釈が必要になることもあるでしょう。後から振り返れば教科書通りで最適だと言える判断も、その場に置かれたときに行えるというのは、まさに「お勉強」ではたどり着けない場所で、実際どうすればそういうことができるようになるのか、正直私もよくわかっていません。差し当たりは、視野を広げ、「全体」という言葉で自分に見えるものを広げつつ、一歩ずつ考えながら進んで、「何かがおかしい」という違和感や、あるべき姿に対する感覚を磨いていくしかないのではないかと思っています。

GxPでは人材を募集しています

今の会社に入って一番よかったと思うのは、会社の規模的に正しく手を伸ばせばどこまでも届く反面、プライムという立場でお客様と直接やりとりができることです。すべてがうまくいくわけではなく、苦労がないわけではありませんが、「全体」を見渡しつつシステムを通じて世の中と関わるという実感は、間違いなく得られる場所だと思っています。入社してからの取り組みについては、以前ご報告させていただきましたので、よろしければ、こちらもご覧ください（動画はこちらで公開されています）。なお、弊社はいつでも人材を募集しています。

弊社に興味を持ってくださった方で、いきなりサイト登録するのがためらわれるという場合には、お気軽にお問い合わせください。メール（digitalsoul0124 at gmail.com）やfacebookなどでのご連絡もお待ちしております。

「アジャイル」と「ウォーターフォール」

アジャイルがダメだと思う7つの理由へのだいぶ遅い反応

導入

もうだいぶ前の話になってしまいましたが、アジャイルに関するブログエントリ「アジャイルがダメだと思う7つの理由」は予想以上に波紋を呼び、それに呼応していくつものエントリが公開されました。発端となったエントリに関していうと、通常であれば必要となる数々の留保事項や前提事項を書かずに切り込んでいるという点において、間違いなく「煽り」であると言えます。ただ、「アジャイル」という言葉をとりまく数々の事象をかなり的確に指摘することによって、「アジャイル」という言葉をパブリックな場所で語っている少なからぬ人たちに対して、（意識的か無意識的かは問わず）ある種のポジショニングを強いたという意味で、実にいい釣り針なのではないでしょうか。

個別の論点に関する「アジャイルでは全体スケジュールにコミットできない」「いや、アジャイルだって全体スケジュールにコミットできる」という議論は一通り終わった感がありますので、だいぶ出遅れた立場としては、少し違う視点から整理したいと思います。

ところで、「アジャイル」と「ウォーターフォール」は何が違うんでしょうね

反射的に出されるであろう主張とそれに対する反論をいくつか挙げてみます。「ウォーターフォールは出来上がるまでの時間が長い」―本当ですか？ウォーターフォールは一年かけなければならないなどという定義はどこにもありません。「ウォーターフォールではフィードバックを受けられない」―どうでしょう？重要な機能なら必要に応じてプロトタイピングをするなどということは常識です。「ウォーターフォールでは変化に適応できない」―そうでしょうか？顧客がソフトウェアを触るようになって上がってきた諸々の仕様変更を、テストの進捗を考慮しつつ、別の線を引きながら取り込んでリリースに間に合わせる、みたいなことは普通だと思います。また、アーキテクチャ策定段階で、比較的安定している機能と後々変化が予想される機能とで設計／実装方針を区別し、変化に対応しやすい（その代償としてコストのかかる）設計にしておくといったことも当然やるべきことです。

また、ウォーターフォールの基本的な性格とされる「要件定義」→「設計」→「実装」→「テスト」という工程は、フィードバックサイクルの長短に関わらず必要なことであり、これを以てアジャイルとウォーターフォールの違いを語ることは難しいでしょう。「基本設計書がすべて出そろってレビューが完了するまでは実装に着手してはならない」といった教条も時折は耳にしますが、それがウォーターフォールのあるべき姿かどうかという疑問と共に、現実としてそこまで厳格な運用が行われているケースはごく稀ではないかと思います。実際には、サブシステム（あるいは大機能など、呼び方は色々あると思いますが）といった、一定の粒度でシステムを分割し、各工程を並行させると共に、実装も着手できるところから着手しているでしょう（そのリスクを発注側と受注側のどちらが持つかは別として）。

つまり、現実の開発においては、「変化の方向性を先読みしつつ、フィードバックを適切に受け取ること」が重要なのは間違いなく、そのための施策は色々とあるわけです。ただ、そういった諸々の施策を「アジャイル」と呼び、そうではないものを「ウォーターフォール」と呼んで思考停止するのは、色々と不幸なことを引き起こすと思うのです。一方で、アジャイルの主張する「変化への適応」に気を取られすぎて、「事前に考えること」を否定することも逆方向の思考停止です。「それは後で考えれば良い」という台詞は、後で発生するであろう揺らぎを吸収できるスケジュールとアーキテクチャに支えられてはじめて説得力を持ちます。事前に計画を立てること、全体像を描くこと、全体の中で個別に戦略を考えること...総じて先のことを予め考え、読んでおくことは常に必要です。そういった「考えること」の放棄に「アジャイル」という名前を冠することに対しては、同様に強い危機感を覚えます。

結局のところ、「考えてわかることは、考える。考えてもわからないことは、どうすればわかるかを考えたうえで、そこまで手を進めてみる」という基本がすべてで、それ以上でもそれ以下でもないということです。

とはいうものの、世の中に目を向けてみると、ここまで「アジャイル」という言葉が盛り上がる背景には、"これまでの"開発がうまくいっていないという感覚あるいはある種の閉塞感が存在するのだろうとは思います。つまり、批判されるべき「何か」は現実に存在し、それへの批判として別の「何か」が存在するのは事実で、それぞれがウォーターフォールとアジャイルという名前をまとっているだけではないか、と感じるのです。それが一体何であるのか、普段受託開発を行っている自分の経験をふりかえりながら言葉にしていきたいと思います。

チームと文化

批判されるべき「何か」は、プロセスや成果物ではなかろう、ということが出発点です。プロセスにしても成果物にしても、コンテキストに応じて適切なものを選んでいけばよいものだからです。むしろ「コンテキストに応じて適切なものを選ぶ」ことができない環境にこそ問題視すべきだと考えます。

単能工とコマンドコントロール

基本設計書を書くだけの"ＳＥ"。設計書の内容を実装するだけの"ＰＧ"。よく話題にあがりますね。「それではダメだ」という批判と、「実際にそういう人たちが集まってシステム開発をしているんだ」という現実路線の両方が存在すると思います。僕自身の経験に照らせば、一定以上の規模であれば、実装がある程度わかる人が設計書を書き、設計の矛盾に気づける人が実装し、双方のコミュニケーションが円滑に進んでいる状態が現実的で健全な開発であるという気がします。それでも工程ごとに担当者が分かれれば、そのコミュニケーションを繋ぐための中間成果物が必要になるのであり、そういう中間成果物が「お客さんと要件を詰め、過不足のないドキュメントを描き、柔軟かつ統一のとれたアーキテクチャでそれを実装して、鉄壁のテストをやってくれるエンジニア」から見て無駄なオーバーヘッドに見えてしまうのは仕方が無いことだと思います。そういうエンジニア２，３人で開発できる規模なら、また違ったやり方もできるでしょう。

工程ごとに担当者が分かれていても、工程間がスキル的にもコミュニケーションパス的にもゆるやかにつながってフィードバックが回っていれば、それほど問題にはならないと僕は考えています。問題なのは「あらゆる指示が上から降ってきて、ただ決められた期日までにその指示をこなす」ことが求められる環境です。これを生み出すのは、同一工程内の階層化、具体的に言えば、少数の「タスクを分解し指示する人」と多数の「指示に従ってタスクを遂行する人」との分断です。工程ごとに作業者が分かれていて、かつその作業が上から降ってくるという構造であれば、メンタリティとして成果物の提出先が「仕事を割り当てる人」になってしまい、それを受け取る次工程の人が忘れ去られてしまうのもわからなくはないですが、当然いい結果は生まないでしょう。

個人的には、この「分解されたタスクの指示書」がWBSの姿をしていることこそが、この構造が「ウォーターフォール」と呼ばれてしまう原因ではないかと思っています。ただ、もはや開発モデルとしてのウォーターフォールは関係ないですよね。ここにあるのは、「多重階層によるコマンドコントロール」と「成果物を壁の向こうに投げつけるサイロ構造」です。フィードバックが届かない多重階層構造によって人が病み、サイロ構造によって成果物の品質も下がるのはよくわかります。

多能工と自己組織化

「お客さんと要件を詰め、過不足のないドキュメントを描き、柔軟かつ統一のとれたアーキテクチャでそれを実装して、鉄壁のテストをやってくれるエンジニア」に話を戻します。そんなスーパーマンがいたとして、その人も始めからそうだったわけではないでしょう。要件定義、設計、アーキテクチャ策定、実装、テストといった各工程を個別に経験する中で知識と技術を蓄積した結果にすぎません。つまり、多能工になるためには、工程を横断して様々な経験をする必要があるわけですが、前述の文化ではその経験を積むことができません。

「多重階層によるコマンドコントロール」では多能工が育たず、多能工が育たないから「多重階層によるコマンドコントロール」が必要になるのです。この負の連鎖を断ち切るために、単能工とコマンドコントロール、多重階層の関係をもう少し整理しておきます。作業をする人が見ることのできる範囲が狭い場合、その狭い範囲に応じたチャンクにまで仕事を細分する必要があります。そして、その負荷は、指示をする人に集中することになります。一人で見ることのできるノードの数には限りがありますので、作業者が食べられるサイズになるまでに階層ができあがるのはよくわかります。

つまり、「指示を出す人／従う人」という構造に無理があるのです。では、違う道はどこにあるのでしょうか。「正解」ということではないのですが、受託開発のリーダーという立場で自分のやっていることは、「指示出し」ではありませんので、少しふりかえってみたいと思います。

...さて、僕は何をやってるんでしょうね。感覚を言葉にすると、対チームとしては「大きな方向づけと情報の流れのコントロール」、対顧客としては「窓口」ですかね。考えてみると、作業の細分化はほとんどメンバーに任せてます。得意分野を中心に緩やかに周辺をカバーできるメンバーに囲まれているので、渡せる仕事のチャンクが大きく、作業分割と統合にコストがかからないんですね。コストがかからない、というよりそこに自分が入ると、自分がボトルネックになって効率が落ちてしまう、という表現が正しいです。また、大きな方向づけと書きましたが、進め方も自分だけで決めているわけではなく、あまり時間を気にせずに、よく議論している気がします。とはいえ、和智「どうしたらいいと思います？」○○「こうですかね？」和智「じゃあそれで」○○「」というパターンが頻出している気もして、エントリを書いていて、改めてメンバーに恵まれていると思いました。要は自分がボトルネックにならなければ順調に開発が進むわけで、ボトルネックにならないコツは、情報の流れをプッシュ型からプル型に変換することだと思っています。「大きく渡して、必要に応じて聞いてもらう」というやり方ですね。

終わりに

ソフトウェア開発を生業としていれば、さまざまな業務に関わることになります。やることが大きく、作るべきものが最初から分かっている業務であれば、コストを抑える代償に変化を想定しないアーキテクチャで進めることができるでしょうし、そもそも何をするかもわからないうちから実験的にモノづくりを始める状況であれば、変化に柔軟に対応できるアーキテクチャをインクリメンタルに膨らませていくべきでしょう。

重要なのは常に、「何のために何を作るのか」という目的であって「どう作るか」は手段でしかあり得ません。それに対してエンジニアとしてできるのは、専門性を高めることと守備範囲を広げることを通じて、どういう要求にも対応できるようになっていくことかありません。顧客が満足するものを提供しつつ、プロジェクトを通じてメンバーが成長できるのであれば、開発手法は別に何でもいいと思うのです。