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

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

導入

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

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

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

納得して向き合う

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


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


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


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


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


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


***


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

その後

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

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

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


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

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

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