Qiitaで気になる、あのエンジニアに会ってみた！＜vol.1 広木大地さん＞
Qiitaのユーザーさんを取材する連載企画「Qiitaで気になる、あのエンジニアに会ってみた！」をはじめます！ 今回はユーザーランキングでトップクラスの常連である広木大地さんにお会いしました。広木さんは『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング』を2018年2月に上梓。Qiitaとの関わりについて、エンジニアを取り巻く状況や課題、その打開策といった幅広いテーマでお話を伺いました。
・社内で実践しているノウハウは、地味な内容でも発信すると価値になる
・Qiitaはリクエストの積み重ねで、価値ある情報が蓄積されるプラットフォーム
・エンジニアの生産性を下げる、あらゆる不安を取り除くことが記事のテーマ
プロフィール
@hirokidaichi
目次
社内で実践しているノウハウは、地味な内容でも発信すると価値になる
海野：広木さんの Qiitaの記事は、特長がありますよね。技術的なノウハウが多いとは思うんですが、それにとどまらず広い範囲をカバーしています。要素技術の活用方法というより、活用するための意思決定に関する記事、といえば良いでしょうか。
広木：確かにそういった内容の記事が重要だと考えているところはありますね。
海野：読んでみるととてもためになるのでインパクトが大きいなと思います。早速なのですが、そもそもなぜ Qiitaを使ってみようと思われたのかを教えてもらえますか？
広木：きっかけは、僕がミクシィにいた2010年ごろにエンジニアブログでエンジニアが発信する流れというのがあって、その状況で「エンジニアブログを書きづらいエンジニアでも発信していく文化」を醸成していきたいと思ったからです。
というのは、ノウハウはもちろん、エンジニアの考え方なんかも合わせて発信して、フィードバックを貰うオープンな文化を体験しないと、エンジニアとしての成長の機会を得られないと思っていたからです。
そういった文化をどうやって作っていくかを考えていた時に、「会社の名前を背負ってブログで書くとハードルが高いな…」、「ちゃんとしたこと書かなきゃ」、「これって会社を背負って書くことなの？」みたいなものが壁になって、エンジニアの人たちはオープンに発信することに取っつきづらさを感じているんじゃないかと。
そんな思いを持っていた時、Qiitaを知りました。Qiitaは取っつきやすくする設計がされていたし、マークダウンは便利だなと思って利用しはじめたんです。
気軽に投稿できるQiitaで利用をはじめた
海野：使い始めのころはどういった内容の記事を投稿されていたんでしょうか？
広木：最初は教科書的な、社内で教育している内容、例えば障害報告の書き方みたいな記事を書いていました。
これには理由があって、社内で実践しているノウハウって、こんなポリシーで対応していますといったような一見すると泥臭いものなんですけど、意外に大切なノウハウなんです。
軽視されがちな地味な内容でも、記事にして発信すると価値になるというのを若い人たちに知ってもらいたかったし、バズって多くの人に見てもらえたら…という気持ちもありました。結果的に多くの人の目に止まったので、Qiitaで発信して広げていこうと思いました。
社内でもQiitaを使った発信を盛り上げていました。いざ記事にするとなると、みんな難しかったり、しっかりした内容の記事を書かなきゃという意識が働いてしまうんですよね。僕としては、当たり前に自分たちがやっていることの記事を積み重ねて、オープンに発信していくという習慣が大切だと思ったので、社内でギフト券プレゼントみたいなキャンペーンをして、発信する体験が根付くような施策に取り組んでいました。
人に見られる前提で文章を書く経験を積むことで、エンジニアとしてうまく伝えることができるようになったり、発信することで良質なフィードバックが得られる。そういう体験が気軽にできるのがQiitaの良い点だと思います。
Qiitaを利用していくにあたっては、他社と比較したランキング１位を一旦の目標にしていろいろ試していました。また、僕自身としてはプログラミングの細かなtipsという枠にとどまらず、エンジニアリングのノウハウや考え方をしっかりまとめて記事すべきという気持ちがありました。
社内では技術教育も担当していたので、その内容をオープンな場所で記事にして注目が集まれば、社内でも価値があるものなんだと感じる人が増えるだろうし、社外に対してはこの会社で働いてみたい、この記事を書いた人と働いてみたいといった採用広報としての効果も狙っていました。実際、このような効果は大きかったですね。
Qiitaはリクエストの積み重ねで、価値ある情報が蓄積されるプラットフォーム
海野：いまのお話で出ていた「エンジニアとしてうまく伝えることができるようになったり、発信することで良質なフィードバックが得られる」という点で、Qiitaはうまくサポートできていますか？
広木：編集リクエストの機能が便利ですね。誰かの書いた記事を読んだ別の人がより良いノウハウを知っていたり、間違いに気づいたら、書いた人に追加のリクエストをしたり、古い情報なら新しいアップデート情報などのリクエストを送ることができます。
リクエストの積み重ねで、価値ある情報が蓄積されるプラットフォームになっていると思うので、編集リクエストがもっと使われていったり、コントリビューションを充実させていくとQiitaはより面白くなるんじゃないでしょうか。
海野：広木さんが書かれた記事で、修正や追加の編集リクエストが来ることはありますか？
広木：ちょくちょくあります。誤字脱字レベルはもちろん、例えばオブジェクト指向について書いた記事ですと、いろいろな言語のコードがあったりするので、ソースコードをチェックして、編集リクエストしてもらえるというのがありました。そういうのは本当にありがたいですよね。
ブログだとそうはいかなくて、だからそれこそぶっこんじゃいますけど（笑）
Incrementsが買収されて…という話になった時に、自分の書いているものがどうなっていくか不安になっている人って結構いると思っていました。なくなってもらっちゃ困るから商売して、儲かってもらいたいです（笑）。
何にせよエンジニア文化の中で生まれてきたサービスだから、文化的なところは大事にして欲しいです。「そこは変わらないぞ」という何かしらのアクションみたいなものが運営から見えるといいな、というのは最近思っていることですね。
海野：会社はエイチームグループ入りとなりましたが、QiitaやIncrementsのスタンスは基本的に変わっていません。「エンジニアを最高に幸せにする」というミッションのために何でもやっていくつもりです。当時の話や今後のスタンスはIncrements Advent Calendar 2017の記事として投稿しているのでご覧いただければと思います。
エンジニアカルチャーでQiitaの編集リクエストが生まれた
海野：編集リクエストは、コミュニティとしてコンテンツをよくしていくという、まさにエンジニア的カルチャーの影響があります。先ほどのオブジェクト指向の言語の話については、バージョンが変わっても記事を投稿した人が管理し続けるのは辛いですよね。そうった内容をコミュニティでよくしていってもらいたいなという思いがあります。
冒頭でQiitaを使い始めた理由というところで、社内に閉じている情報をオープンにして価値を出していくいった話が出ていました。広木さんは、現在、いろいろな会社の技術組織の顧問やサポート支援、構築などを行っていますが、そのような立場からみて、どの会社でもオープンにしていくべきとお考えですか？
広木：そうですね。どの会社も他社にとって参考になるノウハウや考え方を持っているんですけど、発信しない、できない雰囲気があるんです。「情報を出すことでうちが損をするんじゃないか」、「質が低すぎて価値がないから誰も読まない」といった点で、発信に二の足を踏んているように思います。エンジニアにとっては「会社を背負ってまで書くことじゃない」、「発信することはエンジニアの仕事じゃない」みたいなことも多分あるでしょう。
でも、そもそもインターネットやウェブって、オープンにしてフィードバックを得て、それで成長していく文化の中で成り立っていて、それはエンジニアの文化も一緒でしょう。ノウハウをオープンに共有して、フィードバックを貰っていいものにしていくといったサイクルは大切だと思います。
エンジニアの生産性を下げる、あらゆる不安を取り除くことが記事のテーマ
海野：要素技術の活用方法にとどまらず、意思決定に関する記事について書かれているのはなぜなのでしょうか。
広木：僕のQiitaのエンジニア組織の記事や『エンジニアリング組織論への招待』では、心理学・カウンセリングに関係するようなことも取り上げています。それは会社がエンジニアにストレスをかけてしまって、自分の居場所が確保できない不安を醸成する装置になっているように思うことがあるからです。
組織は一丸となって問題を解決していくべきだし、会社は社会にインパクトをもたらすべき存在なのに、不安が醸成されてしまうと、エンジニアの生産性がどんどん下がってしまう。それをなんとかしたいというのが、僕の記事や著作におけるテーマのひとつです。不安を取り除くための取り組みをしていかないとチームや組織は成長しませんし、不安な環境のままでは最適なシステムアーキテクチャは組めないでしょう。
組織の不安を取り除き、エンジニアの生産性を上げたい
海野：使えるソースコードの書かれている記事だけが、必ずしも有用ではないということでしょうか。
広木：僕としてはエンジニア組織に関するQiitaの記事や『エンジニアリング組織論への招待』も、ソフトウェアエンジニアや彼らと共に働くすべての人々にとって有用な”ノウハウ”として書いているつもりです。
Qiitaポエム問題ってあったじゃないですか。ソースコードの記述がないとポエム、感情論が入るとポエムといった。
でもエンジニアが必要としている”ノウハウ”の中には、そのままコピペができるソースコードやライブラリの使い方といったものだけではなく、組織や会社としてどう課題を解くべきか、といったことも多くあると思います。
もうちょっと分かりやすく言えば、インターネット上でよく言語やフレームワークの論争ってあるじゃないですか。
良い悪いとか、流行ってる流行ってないの話じゃなくて、結局どのぐらいのニーズ、規模で、どんなスキルセットの人たちで何を展開するかという組織設計とか、そういう技術的な課題やトライアンドエラーの方向性によって、どんな技術選定をするかが決まるはずです。
それなのにこの言語やフレームワークが良く、他のものはよくない、みたいな二元論になりがちです。そうではなく、今の会社のこのサービスの課題だったら何がマッチするのだろうかというものを考えていくべきです。
流行りものに飛びついたり、周囲の意見右往左往して、もうこの言語やフレームワークはよくないんじゃないかといった戸惑いが生まれるのも心情としてはわかります。しかし、それは正直、本質的な問題ではないと思っています。
海野：おっしゃる通りですね。今流行りであるかどうかというよりも、メンテナンスされていくかどうかや、チームに合うかどうかの方が大事だと思います。
広木：例えばメンテナンスされなくなるとか、コントリビューターがいなくなるぐらい規模が小さくなるケースは別として、組織の課題においてフィットするかしないかとか、技術的だけじゃなくてビジネス的な課題においてフィットするかしないかが重要です。
Vue.js使えばいい、React使えばいいとかってたいした問題じゃないというか、単純にどっちか流行っているから使おうみたいな話じゃないのかなと考えています。
じゃあそのメタなところにある、なぜ今回はVue.jsを使うのか、あるいはReactを使うのかみたいな文脈の方が大事で、そっちが公開されにくい方だと思うんです。
流行りの技術などではなく、エンジニアの意思決定や心理面にも踏み込む投稿をしているという広木さん
システムや技術はエンジニアの話、組織は経営層の話みたいに、扱いの異なる問題として受け取られている傾向がありますが、今後、言語が簡単になってより多くの人がプログラミングできるようになっていけば、プログラミングそのものより、何が問題なのか、どのように解決するのか、そのためにシステムをどのように設計するのか、さらにはシステムを利用する組織がどのようにあるのが最適なのか、といった高いレイヤーの視点を持って、さまざまな事柄に対して、エンジニアとして取り組む必要があります。
技術の発展にともなって、仮説検証能力を持ったエンジニア、仮説検証するためのエンジニアリングが上流から下流までにわたって求められていくはずです。開発費が抑えられるから、すぐにシステムが調達できるから評価が高い、といった判断をしている経営層も考え方をあらためて、エンジニアやエンジニアリングに理解を示して必要なだけ投資するように変化していくタイミングが来ているように思います。
経営層に理解がなければ、優れたエンジニアやプログラマーは会社を選べる立場にいるので、積極的に人材やエンジニアリングに投資している会社に転職すればいいと思うんです。ですが、なぜそれができないかというと、自分にはそれほどの価値はない…、自分の持っているノウハウなんて利用されるほどのものではない…みたいな後ろ向きな考え方を持っているのも理由のひとつだと思います。
そういった考え方は思い込みかもしれないので、Qiitaを利用してオープンに発信してフィードバックを受けてみてもいいんじゃないでしょうか。
海野：閉じたノウハウをオープンにしてみると、意外に貴重なものとして受け入れられるかもしれませんよね。
広木：閉じている・隠すという状態は、情報がないので判断できない不幸な状況を作り出しかねません。オープンにする文化を根付かせないと、エンジニアリングがハッピーな方向にいかないと思うんです。「エンジニアリング＝コードをコピペするだけ」になってしまわないようQiitaにも頑張って欲しいですし、各社のエンジニア組織も頑張っていきましょうとエールを贈りたいです。
海野：ありがとうございました。組織に関する話は広木さんならではの視点でとてもためになりました。これからもいろいろな方が発信しやすい、フィードバックをやり取りしやすいサービスをめざして開発に取り組んでいきます。
編集部より
「Qiitaで気になる、あのエンジニアに会ってみた」という企画で、Qiitaにとどまらず多方面でご活躍の広木大地さんとIncrements海野との対談を取材いたしました。
広木さんによるQiitaへの投稿ポリシーや技術選択の方針などに触れていただき、大変興味深いお話となりました。広木さんどうもありがとうございました。
編集部から今回のテーマに沿った広木さんのQiita記事をご紹介いたします。こちらいずれも大変興味深い内容となっております。ぜひご覧いただければと思います。
・著書「エンジニアリング組織論への招待」の概要について
https://qiita.com/hirokidaichi/items/195d42ee056ea85a3150
・不安とストレスから解放される見積りとスケジュール方法
https://qiita.com/hirokidaichi/items/5a204a57a200569f755d
・心理的安全性ガイドライン（あるいは権威勾配に関する一考察）
https://qiita.com/hirokidaichi/items/5d8c4294083d85654a04
また、記事内でも触れられた編集リクエストに対するIncrementsの想いについてはこちらからご覧いただけます。
https://qiita.com/official-columns/event-report/challenge-increments-and-qiita-2017-2/2/#downvote
最後に、広木さんの書籍「エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング」をご紹介します。
当記事をここまでご覧いただけた皆さまにおススメです。冬休みの一冊にぜひどうぞ😁
