こまぶろ

技術のこととか仕事のこととか。

2018年8月23日「第133回白熱塾 きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質」に参加した

8月23日の夕方から、「きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質」(@デンソー東京支社)に参加してきた。

connpass.com

錚々たる登壇者の方々であることに加え、Connpassで参加者として登録している方の中にも単独でメイン登壇者が務まる方が複数いらっしゃる豪華イベント。テーマとしても、「本質を理解しないままのアジャイル開発に挑む危うさ」というもので、どんな話がされるのだろうと期待を膨らませながら当日を待っていた。

各登壇者の発表資料&参加者の方によるグラレコ

各登壇者ごとに簡単な紹介と発表資料(きょんさんは未公開)をまとめておく。内容については、共同主催のクリエーションライン社からレポートが出ているので、そちらをご参照ねがいたい。

また、参加されていたgaoryu*1@DiscoveryCoach)さんと渡部そば(@sobarecord)さんがグラレコ(Graphic Record)をされていたので、ご紹介させていただく。

やっとむさん

やっとむ(@yattom)さん。お恥ずかしいことに、お名前に印象がなかったのだが、「安井力」という文字列は僕の自室の中にある何冊もの書籍に見出すことができる。翻訳書を多数出しておられて、ちょうど来週『テスト駆動Python』も出版されるところとのこと。

テスト駆動Python

テスト駆動Python

きょんさん

きょん(@kyon_mm)さん。Regional Scrum Gathering Tokyoなど、スクラムのイベントでの登壇が多数あり、エクストリームなスクラム実践者として有名だ。僕は、「しがないラジオ」のsp.22にゲスト出演されていたのを聴いてショックを受けたのが初めて彼の名前を知った時だった。

shiganai.org

(2018.08.27追記

資料の公開はなされないそうです。

ryuzeeさん

ryuzee(@ryuzee)さん。吉羽龍太郎さんというと、『SCRUM BOOT CAMP THE BOOK』の共著者の一人であり、よく出回っているスクラムの図の作者であり、アトラクタに所属するアジャイルコーチだ。Ryuzee.comにはしばしばお世話になっている。

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

変則フィッシュボウル

お三方の発表後、登壇者の3人+3席にフィッシュボウル形式で入れ替わりながら座った方々によるセッションが行われた。こちらについては、発表資料もなく、イベントレポートでも記述が薄いので、手元のメモから一部を記載する。自分なりに理解しながら紙に落としたので間違っているところもあると思われることをご了承願いたい。

守破離」というが、スクラムを「まず守らせる」については?

  • 「ちょっと忙しくなるとやめてしまおうとする誘惑にかられるから、何度でも同じことをいう」(ryuzee)
  • 「やりたいようにやらせてみて、うまくいかないのを笑う」(きょん)
  • 「外野がガーガー言ってくるときは黙らせる」(やっとむ)
  • (きょんさんの発言に対して)「プロジェクト、プロダクトの成功に対して金を貰っているかどうかによって言い方が変わる。貰っている場合は重大な失敗をしそうになっているのを見ているわけにはいかない。」(ryuzee)

アジャイル初心者はどうやって始めればいいか?

  • 「絶対に成功しないといけないプロジェクトで始めない。練習する。」(ryuzee)
  • 「XPの方が始めやすいのではないか。技術的な部分への言及がスクラムにはない。」(やっとむ)
  • 「信用してくれる経営陣を持つこと、それに報いる気概を持つチームになること。」(きょん)

形のある「アジャイル」の先に何があるのか?

  • アジャイルは終わらないジャーニー」(ryuzee)
  • 「Unlearnの仕方がまとまることが次のプラクティスではないか」(きょん)
    • ある仕事にしか対応できないチームになってしまった(早すぎた最適化)
    • 早すぎた最適化をUnlearnする必要がある
    • そのうえで今に最適なものをどう素早く構築するか
  • 「世の中の多くのチームは最適化にまで達していないのできょんさんの話は多くの人には関係ない」(ryuzee)
  • 大事なのはチームではなくビジネスではないのか?(司会の成迫さん)

5分でできるチームの賞味期限は30秒では?変化し続けることが大事?

  • 「構造を決定するのではなく過程であり続けることが大事」(きょん)
  • 「お金を稼げなければ意味がなく、そのためにはたくさん球を投げなければならないが、中の人は今のプロダクトで勝てるはずだと信じられないといけないのが難しい」(ryuzee)
    • チームビルディングを叫んでいる人は、当事者意識があるか?圧倒的当事者意識は?
    • SIerの場合は、アジャイルでやって何にコミットすればいいのかがよくわからないので難しいのではないか。
    • 当たり前のことができていない、規律の部分をかなり指導した。
  • 「なぜビジネスは大事か?」(やっとむ)
    • 赤福は変化ができている。ビジネスを意識するだけではできなかったことなのでは?
    • エコシステムを存続させることを意識した結果が変化できる会社のあり方なのでは

ちゃんとやれていない組織には鞭を入れる必要があるのか?

  • 「変えられない会社で頑張るより移ったり独立した方が幸せになれる」(やっとむ)
  • 「大きい会社でも味方がいれば可能性がある、ミドルレンジ以上の人のサポートが得られるか」(ryuzee)
  • 「案件単位で、偉い人が興味を持たないようなものでやればいい」(ryuzee)
  • 「間違ったスイングの方法で試み続けるよりは見学に行く、コーチを呼ぶ」(ryuzee)
  • 「現場がやらされ感をもっていてはダメ、チームを連れてカンファレンスに行ったりすればいい」(きょん)
  • 「教育を徹底的にやる、トップダウンの場合はそれができる」(やっとむ)

自動車産業でのアジャイル。高品質、大規模なプロダクションにどうやって結びつければいいのか?

  • 「機能以外のソースコードが多くなるはず、それをプロダクトバックログに入れるのかどうか。」(ryuzee)
  • 「デモやPoCのコードは捨てた方がいい」(ryuzee)
    • どの段階で使うためのものなのかによって品質のレベルが違うはず
    • 品質を後から上げるのは難しい、だから捨てた方がいい
  • 「コードを2回捨てて3回目を使う」(きょん)
    • Royceのモデル、ソフトウェアは三回作る
    • 捨てるレベルはどこか?実装、アーキテクチャ設計、基本設計?
    • 捨てるレベルをどこまでに留めるかがチームの力ではないか
  • 「プロトタイプをTDDで作っていって、プロダクトコードだけを捨てる」(やっとむ)
  • 「車も1週間スプリントで作ればいい」(やっとむ)
  • 「どっかの原野に人工の街を作って、『人を殺せる』環境を作って試験をしまくるのがいいのではないか」(ryuzee)

自動車の開発におけるテストはどうするか?

  • 「ソフトウェアの場合も、自動テスト(xUnit、Selenium)の技術が育つのには時間がかかった。車の場合でも、似たようなことが起きない限りは難しいのではないか?」(やっとむ)
  • 「網羅性を求める前に、プロダクションラインを絞った方がいいはず。部品化、標準化が必要?派生開発が多すぎるのではないか」(ryuzee)
    • CI/CDの場合は、リリースするのは一本で、顧客ごとの違いはフラグで管理
  • 「10年かかることが今できていないのは10年前に始めなかった自分が悪い」(やっとむさんに急に振られた川口さん)

なんでアジャイルコーチと偉い人しか前にいないんですか?

下記のようなツイートをしていた及部(@TAKAKING22)さんが最後の質問者として問いかけた。

  • 「僕は現場代表です」(きょん)
  • (聴衆の方を見て)「みなさん、アジャイルを現場に取り戻しましょう!」(及部)

感想

先に公開しているこちらの記事を読んでいただきたい。

ky-yk-d.hatenablog.com

*1:ファシリテーションセミナーなどを主催されている方で、先日僕もワークショップに参加させていただいた。【2018年8月】ガオ流ファシリテーション基礎講座 - connpass

なぜ僕は「アジャイルを!」と叫ぶのか〜「きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質」に参加して

8月23日の夕方から、「きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質」(@デンソー東京支社)に参加してきた。

connpass.com

イベントレポート的なものは、別にまとめている。本記事は、イベントに参加した感想として書き始めたが、感想の域を大幅に越えて、現時点での僕のアジャイルへの認識をまとめるものとなったため、イベントレポートからは独立させることとした。そちらに関心のある方は、下記に貼り付けた記事を参照していただければよいが、アジャイルに造詣の深い方々にはぜひ、本記事で書いた私見に対してのご指摘・ご批判をいただきたいと思っている。なにせ、僕はアジャイル非実践者であり、誤解や表面的な理解をしていると思うからだ。

ky-yk-d.hatenablog.com

(2018.08.27追記

良質なイベントレポートを公開してくださった方がいらっしゃったので、ご紹介します。

bayaaki.github.io

ビジネスとアジャイル

「ビジネスの成功が大事」なのか?

今回のイベントで、何度か発せられた発言に、「大事なのはビジネスの成功じゃないのか」「金を稼げなければ」というものがあった。それぞれ、成迫さんとryuzeeさんの発言だったと記憶している。お二人の発言の趣旨は、「アジャイル開発と言ってチームを良くすることばかり考えていてはいけない」ということだと理解している。文脈としても、きょんさんの「アジャイルの目的化」というインパクトの強い話があり、「チームビルディング大事!」一辺倒の流れになってしまいかねない*1ところにバランスを取りにいった印象を持った。

僕もこの指摘は、至極真っ当だと思う。この指摘は、「アジャイル開発者も霞を食らって生きるものではない」という意味で正しいだけではなく、「アジャイル宣言の背後にある原則」から読み取れるように、アジャイルという考え方自体にビジネスへの志向が(敢えて言えば、ウォーターフォールよりも)色濃く含まれているという意味でも説得力のあるものだ。

一方で、上に掲げたような発言を耳にしたときに、僕は少なからず違和感を覚えた。あるいは、「もにょる」という表現が伝わりやすいかもしれない。僕も、アジャイルが開発者だけに都合のいいものだったら、今日に至るまでのアジャイルの普及はなかっただろうし、アジャイルはビジネスの成功にも大きく貢献しうるものだと確信している。しかし、「大事なのはビジネスの成功」と言ってしまうことには危うさを感じている。この言葉がryuzeeさんなどのアジャイルを実践してきた方々の口から出てくる分にはよいのだが、「ビジネスの成功がアジャイルの目的だ」というような語りが蔓延することは危険だと思う。

なぜ「ビジネスの成功がアジャイルの目的だ」は危険なのか

ビジネスの成功の曖昧さ

なぜ僕は「ビジネスの成功がアジャイルの目的だ」という言説を危険視するのか。それは、「ビジネスの成功」という表現が曖昧すぎるからだ。ソフトウェア開発における「ビジネスの成功」とは何か。ある人は、「開発したプロダクトが売れること」と考えるだろうし、「いや、売れるだけじゃなくて利益が大事だ」という人もいるだろう。ではその売上や利益はどのような範囲で考えられているのか。単発のプロジェクトの収支か?ひとつのプロダクト/サービスの収支?それとも企業がその存続期間中に生み出す全てを含んでいるのか?

一定期間の数字に責任を持つ人間は、当然、その期間にフォーカスして物を考えることに傾斜しがちになる。皆が近視眼になっているというわけではなく、仕組み上そういう風になりがちだということだ。中長期的な視野をもって経営陣やマネージャーが現場を導くということもある(本来はそういうものだと思う)が、近視眼的になった上層部が現場に無理を強い、社会に対して無責任な行動に出た結果、長期的には企業の価値が大きく損じられたという事案も世間に多く見られる。

先に述べたような、近視眼的な行動による弊害に対する歯止めとして、CSR(Corporate Social Responsibility、企業の社会的責任)という考え方が登場し、マイケル・ポーターらはCSV(Creating Shared Value、共通価値の創造)を唱えるに至った。やっとむさんが赤福の例を挙げて指摘したのは*2、このようなことだったのではないかと理解している。

アジャイル人間性CSVから考える〜

やっとむさんが明示的に指摘していたのは変化することだったが、CSVという考え方を導入することでアジャイルには別の側面も見えてくる。これは僕がそういうものをアジャイルに付け加えようというのではない。この側面は、アジャイル宣言の起草者の一人であるケント・ベックも(CSVとは言わないが)意識しているものだ。それを見出すことができるのが、『エクストリームプログラミング』の第5章で第一の原則に掲げられている「人間性(Humanity)」の項目においてである。

人間がソフトウェアを開発する。このシンプルで逃れようのない事実によって、利用可能な方法論の多くがその効果を失っている。ほとんどの場合、ソフトウェア開発は人間の欲求を満たしていない。人間の弱さを認めていない。人間の強さを活用していない。ソフトウェアを人間が開発していないかのように振る舞えば、関係者にかかるコストが高くなり、人間の欲求を認めない非人道的な行為によって、人間性が失われてしまう。こうしたことは、高い離職率に伴うコストや組織の崩壊、クリエイティブな行動の機会損失など、ビジネスにとっても好ましいことではない。(『エクストリームプログラミング』22頁)

アジャイルは、人間性を帯びた考え方・やり方だ。「アジャイルソフトウェア開発宣言」・「アジャイル宣言の背後にある原則」には「対話」・「協調」・「意欲」・「信頼」、「スクラムガイド」には「スクラムの価値基準」として「勇気(courage)」や「敬意(respect)」などの人間にフォーカスした概念が登場している。その他にも、アジャイルを実践する現場ではメンバーのモチベーションに光をあてるプラクティスなどが採り入れられている場合も多いと思う。

開発プロセスとしてウォーターフォールを採用している現場でも人間的な実践が行われていることもあるが、「ウォーターフォール」には人間性への配慮はない。これは欠陥ではなく、そういった部分に関心を持つ考え方ではないというだけだ*3。しかしアジャイルはそこに関心を持つ。だからこそ僕は「アジャイルを!」と叫ぶのだ*4

アジャイルをそれ自体として擁護する

チームのアジャイルがビジネスのためにもなる

繰り返しにはなるが、「アジャイルができればビジネスなんてどうでもいい」と言うのではない。アジャイルを実践する現場の開発者は、「ビジネス大事だ」と100回唱えるくらいでいい。僕も唱えよう。しかし、「ビジネス大事だ」という圧力には警戒しなければならない。それは現場の開発者もそうだし、経営サイドもそうであるべきだと考えている。

アジャイルは、ビジネスに貢献しようとするものだ。フィードバックループを回すことによってプロダクトとプロセスを改善すれば、それはビジネスの成功可能性を高めてくれる。その基本方針は、「アジャイル宣言の背後にある原則」で高らかに謳われている。

顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。

ここで述べられていることを常に意識し、様々なプラクティスも活用しながらソフトウェア開発に臨めば、良いものができる方向に向かうはずだ。より良いやり方が一切存在し得ないと断定することはできないが、少なくとも、20年前に超一流のプログラマたちが実践の中から生み出したこの知恵を上回る有効性をもつものを、僕は知らない*5。 したがって、現場が「うまくアジャイルできていれば*6」、基本的にそれがビジネスの成功にも資するはずなのだ。

アジャイルを育むということ

そうはいっても、状況が芳しくないとき、外側から手を突っ込みたくなるのが管理者の情というものだ。しかしそれは我慢してもらわなければならない。そうでなければアジャイルなチームは死んでしまう。うまくいっていないならば、アジャイルの内部で、つまりチームによる改善に携わることによって対応していけばいいのであって、上意下達式の介入は避けなければならない。「環境と支援を与え仕事が無事終わるまで彼らを信頼」するのだ。与えるべきなのは支援であって指示ではない

「ビジネスの成功」という言葉に導かれたマネージャーが短期的な利益を志向した場合に、顧客/エンドユーザーにとって長期的には好ましくないプロダクトを世に送り出してしまったり、あるいは開発者を疲弊させてしまったりする危険性があるのではないか。そこで起きるのはアジャイル開発の崩壊だ。だからこそ、アジャイルは擁護されなければならない。

今回、きょんさんは、「目的論からのアジャイル〜手段を目的化すること〜」と題して、アジャイルが目的に対する手段として実践される場合であっても、それ自体を目的化してしまうくらいの方がよいというお話をされていた*7。きょんさんのポイントは、アジャイルの目的とされているもの*8の実現の困難さを考えると、仏教の修行のように本来は手段であるはずのものに「自らを一体化させる」ことが必要ではないかというところにある。

今回の記事は、このきょんさんの話に触発されて書かれた面がある。きょんさんの議論と僕の議論は、「アジャイルを、何かの目的のための手段として従属させること」に反対するという意味では共通する部分がある。しかし、その内容は異なる。非常に雑にまとめれば、きょんさんの論旨はアジャイル自体を目的にしたつもりで全力でやれ」であり、僕の論旨はアジャイルを特定の目的の手段としてのみ扱うと壊れてしまいかねないから、それ自体として擁護せよ」だ。

よいソフトウェア開発とは何か?

長々と論じてきた。僕は、アジャイルを実践できていない現場、会社にあって、これを(ほぼ一人で)推進しようとしている立場の人間だ。これまで自分なりに勉強をし、同僚や上司に伝えようとしてきたが、どうにも前に話を進めることができないでいる。だから、一度自分なりにアジャイルについての考えをまとめておきたいと思って、この記事を書いた。また、アジャイルというものについて、Twitter以外で文章をネット上に公開するのはもちろん、ここまでの文章を書いたことすら初めてだ。初めてだからこそ、一定の立場を据えて書こうと思った。それゆえ穏当でない部分もあると思う。

ここまで読んでくださった人の中には、社内での説得に失敗している理由が僕の考え方にあると感じる人もいるかもしれない。もし、「そういう考えだから人を納得させられないんだよ」という指摘があれば、ぜひ聴かせていただきたい。僕の考えていることに少しでも理があるなら、そういったフィードバックも欲しい。間違っていたら教えていただきたい。

この文章を書くにあたって、色々と考えたし、この記事に載せなかった文章もいくらか書いた。そうしているうちに、かえって「アジャイルどうでもいいかもしれない」という思いも自分の中に生まれてきた。会社ではアジャイルを推進する立場だし、現在の自分の会社にはアジャイルという考え方を導入することが意味のあることだと思っている。しかし、これからソフトウェアエンジニアとして仕事をしていく中で僕が向き合っていくべきは、「よいソフトウェア開発とは何か?」という問いであり、アジャイルはその問いに答えようとするためのヒントを与えてくれるものに過ぎないのだろうと思うようになった。これはまさに目的に関する問いであり、価値に関わる問いである。

エクストリームプログラミング

エクストリームプログラミング

よい教育とはなにか: 倫理・政治・民主主義

よい教育とはなにか: 倫理・政治・民主主義

*1:きょんさんが「ビジネスはどうでもいい」という立場を示したわけでも、そういう人だと僕が理解したわけでもない。

*2:赤福について、やっとむさんは肯定的に論じていたように記憶しているが、不祥事からカムバックできているのかは僕は評価する材料を持っていない。とはいえ、赤福が良い企業であるかどうかはここでの問題ではない。

*3:したがって、ウォーターフォールを採用する現場において人間性が重んじられるかどうかは、開発プロセス以外のところがどのように運営されるか次第であり、マネージャーの資質に大きく依存することになる。

*4:最近、「DX(Developer eXperience)」という言葉も目にする。参考、 DX: Developer Experience (開発体験)は重要だ - Islands in the byte stream

*5:どうやらウォーターフォールは限られた状況でしか機能しないらしいということを知識として知っているに過ぎない。

*6:"Don't do agile, Be agile"という言葉が飛んできそうだが、手法だけを取り入れる"doing agile"を意図したものではないとご理解いただきたい。

*7:「20年前の現実解をありがたがって理想を追求しないアジャイル老害だ!」というもう一つの軸は今回は措くとしたい。

*8:もっとも、これが何であるかをきょんさんは語っていなかったように思う。

Scalaに入門してみることにした

先日、下記のようなツイートに接した。

Scalaについては、以前参加したイベントで、コアメンバー(?)らしき方から強く推薦されて、面白そうだなと感じていた。

tddyyx.connpass.com

Scalaというと、JavaやHaskelなどから影響を受けており、JVM上で動く言語だ。冒頭のツイートがそうであるように、Java経験者であれば手を出しやすい(連携できるからという側面もあろうが)というような話を目にすることがある。

僕にとってJavaは、最近は仕事でもプライベートでも書く機会はないが、新人研修でじっくり勉強することのできた言語であり、実際のプロジェクトで書いた唯一の言語でもある。

というわけで、Scalaの勉強を始めてみることにした。関数型のプログラミングを勉強したことがないので、そのあたりも学ぶことができればと思っている。

入門〜環境構築〜Hello World

Scalaに入門しようと思って調べ始めると、下記の記事にまず行き当たった。この手の、情報を集約してくる種類の記事は、自分はおそらく書かないと思うが、存在していると助かることが多いので、それぞれの分野の有識者の方々にはぜひ書いていただきたい。

qiita.com

その中から、評判の良さそうなものということで、ドワンゴさんの新人研修向け資料をまずは読み進めてみることにした。

「新人エンジニア向けの研修資料」という位置付けではあるが、僕が受けた新人研修のように「プログラミング全く未経験」向けのものではないらしい。

読者層としては、

  • 大学の情報学部卒である
  • Java言語の基本知識がある
  • 何か意味のあるアプリケーションを作ったことがある
  • 趣味でTwitter APIなどを触ったり、プログラミングを行っている

人(相当)を仮定しています。なお、上記の指標はこの資料を読むにあたってのあくまで目安であり、特に大学の情報学部卒でなければ理解できないといったことはありません。ただし、本資料は1つ以上のプログラミング言語でアプリケーションを作れることを最低限の前提にしていますので、その点留意ください。

環境構築〜Hello World

環境の構築は、もともとJDKが入っていたので、sbtとIntellij IDEAのみインストールした。この辺りは、研修資料がスクショ付きで非常に丁寧に書かれているので、悩むことなく進めることができた。

テキストに従い、REPLで簡単な出力と計算を行ってみる。まずはお決まりのHello World。

println("Hello World")

なるほどJavaを思い出す。ここのところはずっとconsole.log()だったので、少し懐かしい。四則演算も、特に違和感は持たない。

f:id:ky_yk_d:20180819221711p:plain

ここまではよくあるプログラミング入門という感じ。JavaScriptをかじったので、var命令だって怖くない(意味は違うが)。

制御構文の多くが「式」である?

しかし、制御構文の章に入って、雲行きが怪しくなる。

まず、「構文」と「式」と「文」についての説明が入るのだ。プログラミング経験者向けの資料なので、「条件分岐が必要だから〜〜」とif文の説明に入るわけではないのは自然だが、式と文の違いを意識させることに意外の念を持った。制御構文の章の冒頭に置かれたこの説明の末尾には、以下のような記述がある。

ScalaはCやJavaなどの手続き型の言語に比べて、文よりも式になる構文が多いです。 Scalaでは文よりも式を多く利用する構文が採用されています。これにより変数などの状態を出来るだけ排除した分かりやすいコードが書きやすくなっています。

式になる構文が多いと言いながら、この章で出てくるのはどいつもこいつも式である。下記すべて、Javaにも存在するものだが、Javaでは文(つまり、値を持たない)であるのに対し、Scalaでは式(つまり、値を持つ)であるという。

  • {}
  • if
  • while
  • for

特に、forについては、Javaのfor文におけるのとは異質な使い方をすることができるようである。

実は、for構文はyieldキーワードを使うことで、コレクションの要素を加工して返すという全く異なる用途に使うことができます。特にyieldキーワードを使ったfor式を特別に for-comprehensionと呼ぶことがあります。

これらが式であるということは、おそらく、関数型プログラミングにとって重要な特徴なのではないだろうか。これから勉強を進めていく中で、明らかになるだろう。

match式、パターンマッチ

制御構文の章の後半は、match式の導入である。Javaのswitchが引き合いに出されているが、かなり申し訳程度であると感じた。Javaのswitchは、(OOPの立場からは)隙あらばポリモフィズムによる書き換えの対象となるような代物だ。それに対して、Scalaにおけるmatchは、極めて強力な機能を持っているようだ。

match式の説明の部分は、下記のような項目に分けられている。

  • パターンをまとめる
  • パターンマッチによる値の取り出し
  • 中置パターンを使った値の取り出し
  • 型によるパターンマッチ
  • JVMの制約による型のパターンマッチの落とし穴

説明に一通り目は通したが、どうにも頭に入ってこない。正直に言って、この段階で既にJavaとだいぶ違うというので少々面食らっている。先達(この方も元々Javaプログラマで、Scalaを後から勉強された方だったと思う)も、下記のようにツイートしていて、どうも関門のようだ(このツイートで言われているのはもっと高度な話だと思うが)。

思ったこと

上にも既に書いたが、ここまでJavaと違うとは思わなかった。いや、違うというのはわかっていたが、違いが出てくるのが思ったより早かった。JavaScriptはよく、「Javaと名前は似ているけど全然違う」と言われるが、JavaScriptを勉強し始めたときとは全くレベルの異なる戸惑いを感じている。

とはいえ、言語として違いがあるということは、それだけに学ぶことの意義も大きいということだ。自分がオブジェクト指向をマスターしているとは口が裂けても言えないが、それとは違うパラダイムを学ぶことは意味のあることだと確信できるし、何より面白い。

ボブおじさんも、下記のように言っている。オブジェクト指向と関数型プログラミングの両方を身に付けることは、単にプログラマとしての幅を広げたり、書き方の参考にすることができるようになったりというだけでなく、両方を駆使したプログラミングを可能にするということなのかもしれない。

「充実とは価値観が満たされた状態である」?

Twitterで関わりのある方々が複数参加しているコミュニティがある。

note.mu

「成長と充実」を研究するコミュニティということで、僕は参加していないけれど、アンケートに協力させてもらったり、参加者の方々のTwitterを通じて活動の経過を垣間見たりしている。

そうした中で、先日目に入ってきたのが、参加者の一人である、ゆのんさんの下記の投稿である。

note.mu

上の投稿で紹介されているワークが何かしら僕にとってきっかけになるのではないかと考え、取り組んでみることにした。

「充実とは価値観が満たされた状態である」

ワークの内容は単純で、

  • 33+1個の価値*1から大切だと思う10個の価値を選ぶ
  • 10個のなかの価値を2個ずつ取り出して比較する(45通り)

というものである。そして、2番目の比較において「より大事だ」と評価された回数で、上から3個がベスト3ということとなる。僕がやってみた結果、ベスト10は、以下のような顔ぶれとなった。

  1. 高潔さ・誠実さ(正直さ、誠心誠意、真実一路)
  2. 知恵・賢さ(成熟した人生の理解)
  3. 内なる調和(心の中が苛まれていない、平安でいる)
  4. 自己への尊敬(自尊心、自分を信じる)
  5. セキュリティ(安全・安心、収入の確保)
  6. 知的な(知性、省察する)
  7. 開かれた(心の広い、良い意思伝達)
  8. 責任感(信頼・信用できる、説明責任を果たす)
  9. 自制心(継続、効果性、専門性)
  10. 論理的(首尾一貫した、合理/理性的)

ちなみに、比較をすべて終えた後で、どの価値がどの価値に対して優位だったかを調べてみると、このランキングでの位置づけと完全に整合したので、ある程度首尾一貫した比較を行うことができたのだと思う。

ワークをやってみて考えたこと

ワークの結果について、少し考えてみる。コミュニティの参加者の皆さんの回答も(把握している範囲で)下記に列挙しておく。

さて、こうして自分のワークの結果を眺め、また他の人のものと見比べてみたときに、目立つのはこれだ。

  1. 高潔さ・誠実さ(正直さ、誠心誠意、真実一路)

トップにこれが来るのは、我ながら何とも嫌な奴だと思ってしまう。もちろん、現実の自分が高潔で誠実な人間であると主張するものではないのだが、それにしてもこれを重視するということに嫌らしさを感じてしまう。嫌らしさを感じるというのは、「心の底から、本当に、そう思っているのか?」という疑念を自らが捨てきれていないということなのだろう。

「欲求に関する欲求」

と、ここまで書いてきて、思い出したことがある。それは、大学院生時代に関心を持っていた、チャールズ・テイラーの議論、更に言えば、彼が依拠しているハリー・フランクファート*2の議論である。すっかり忘れてしまっていたが、自分の考え方の一つのベースになっている議論であったので、紹介したい。

フランクファートは、人間と他の動物の違いを、「第二階の欲求(second-order desire)」を持ちうるかどうか、という点に求めている。第二階の欲求とは、「欲求についての欲求」である。「ラーメン二郎が食べたい」は第一階の欲求であり、「ラーメン二郎が食べたいという欲求は持ちたくない」は第二階の欲求である。この、第二階の欲求を持つことが、人間の自由意志を支えているのだという議論をフランクファートは展開しているらしい*3

自由と行為の哲学 (現代哲学への招待Anthology)

自由と行為の哲学 (現代哲学への招待Anthology)

  • 作者: P.F.ストローソン,ピーター・ヴァンインワーゲン,ドナルドデイヴィドソン,マイケルブラットマン,G.E.M.アンスコム,ハリー・G.フランクファート,門脇俊介,野矢茂樹,P.F. Strawson,G.E.M. Anscombe,Harry G. Frankfurt,Donald Davidson,Peter van Inwagen,Michael Bratman,法野谷俊哉,早川正祐,河島一郎,竹内聖一,三ツ野陽介,星川道人,近藤智彦,小池翔一
  • 出版社/メーカー: 春秋社
  • 発売日: 2010/08/01
  • メディア: 単行本
  • クリック: 30回
  • この商品を含むブログ (15件) を見る

この「欲求に関する欲求」というのは、僕にとっては大きな主題であるようだ。これまた、専門外ではあるのだが、マルクス・アウレリウスの『自省録』のなかに、大好きな一節がある。

自省録 (岩波文庫)

自省録 (岩波文庫)

欲望が満たされることを望むのではなく、欲望自体がなくなることを望む。そういった思想への共感・傾倒を、自らのなかに見出すことができる。

ワークの結果について改めて考える

以上のことを踏まえると、今回のワークの結果に対する見方は少し変わってくる。僕の作ったランキングには、「現に自分が従っている欲求」と、「従いたいと思っている欲求」とが混ざっているように思われる。前者の例は、「セキュリティ」や「内なる調和」であり、後者の例は、「高潔さ・誠実さ」や「責任感」である。前者ついては、それらの満たされた状態を現に求めてはいるが、求めなくてもいいと思っている。後者については、そういったものを求めるような人間でありたいという想いがある。

それでは、後者を僕は「現に求めている」のだろうか?暫定的な答えはYesだ。高潔な、誠実な人間になりたいと思うし、責任感を持って事に当たれる人間でありたい。一方で、日頃の自分自身がこれらの欲求に従えているか、言い換えれば、これらの価値を満たすような行動をとれているかというと、これはNoであり、だからこそ自らを苛むものがあるし、ランキングを見た自分は違和感を覚える。

ゆのんさんの投稿の末尾には、下記のような文章がある。

 やってみた結果はどうだろうか?自分の思っていた通りになった方もいれば、全く思ってもいなかった結果になった方もいるかもしれない。特に、後者の全く思っていなかった場合は、こんな結果は本意ではない、と思うかもしれない。ただ、もしかしたらそういう方は、自分の本当の気持ちを抑えてしまっていて、対外的な目を気にしていたり、理想の自分を強く願いすぎてしまっているのかもしれない。何が引っかかっているのか、逃げずに深く考え、自分に向き合うということが必要である。

 逆に、納得感のある結果になった場合は、じゃあその価値観を大切に出来る行動とはなんだろうか、を考えてみよう。例えば、健康が一番の価値観であれば、健康を最大化させる行動をある種無理やり取ってみる。毎日ヤクルトを飲むでもいいし、ランニングするでも良いし、30分早く寝るでも良い。そうやって、自分の価値観に沿った行動をすることで、ものごとの見方・人生の意義付けが変わる可能性がある。

充実とは価値観が満たされた状態である|ゆのん|note

当初、僕はゆのんさんの投稿と自分のワークの結果を眺めていて、「健康が大事だから運動するとかそういうんじゃなくて、もっと内面を変化させるようなことが必要なんだよなー」と考えた。「高潔さ・誠実さ」は、僕にとっては既に従っている欲求ではなく、従いたいと思っている欲求(つまり、「欲求している欲求」)だからであり、何か他の欲求があって、それに従ってしまうと当の欲求の充足が妨げられる(価値が失われてしまう)という状況に陥っている。

しかし、ゆのんさんの文章を読み直してみると、「ある種無理やり」というフレーズが挿入されていることに気付く。健康を価値として奉じている人が、健康のための行動をとれていない*4とすれば、それは自分が「高潔さ・誠実さ」について陥っている状況と同じではないか?

アジャイルな価値観の探し方

では、ゆのんさんの提案している、「ある種無理やり」ということは、どのような意味があるのだろうか。おそらくそれは、自分の価値観について行う仮説検証なのではないか。さきほど僕は、以下のように書いた。

後者を僕は「現に求めている」のだろうか?暫定的な答えはYesだ。

暫定的な答え、と書いた意図がある。ワークの結果、「高潔さ・誠実さ」がトップにきた。これは事実である。しかし、それだけだ。自分が本当に求めているものなのかはわからないし、そもそも「高潔さ・誠実さ」などというものは抽象的に過ぎる。

「本当に求めているものかわからない」、「抽象的に過ぎる」。僕らは日々このようなものに接している。そして、それに対応するためにできることの一つとして、経験主義に立脚して、小さなフィードバックサイクルを回すことが大切だと学んでいる。

暫定的な答えに従って、行動をしてみる。フィードバックを得て、自分の本当に大切にしているものを、より精緻に明らかにしようとし、またそれを満たすことのできる行動を考え直す。この過程に、充実というもののヒントがあるような気がしている。

ニコマコス倫理学(下) (古典新訳文庫)

ニコマコス倫理学(下) (古典新訳文庫)

プロタゴラス―あるソフィストとの対話 (光文社古典新訳文庫)

プロタゴラス―あるソフィストとの対話 (光文社古典新訳文庫)

*1:てぃーびーさんの記事によると、ロキーチの価値観に由来するもののようだ。

*2:今回、改めて調べてみて、邦訳が文庫で出ている『ウンコな議論(On Bullshit)』の著者であることを知った。

*3:この分野を専攻としていたわけではなく、フランクファートの原典を参照したこともないことを断っておく。

*4:なぜ、人は「大事だ」と思っていることのための行動をとることができず、別の欲求に負けてしまうのか?このテーマを扱っている書籍として、プラトンの『プロタゴラス』があったと思う。

GitHubに草を生やして100日の節目にアウトプットをふりかえる〜ブログ・登壇・GitHub〜

はじめに

目次

GitHubに草を生やして100日目の節目に

昨日、GitHubのコントリビューショングラフへの着色*1(いわゆる「草を生やす」)が5月3日から連続100日目を迎えました*2

上記のツイートへの反響が大きくて驚いています。#100daysofcodeというのもありますし、100という数字にインパクトがあったのでしょうか。いずれにせよ、ひとつの節目になるこのタイミングでブログを書き残しておくことは、自分のために有意義であるだけでなく、少なからず誰かのためにもなるのだろうと感じさせられました。

アウトプット全体をふりかえる

草を生やし続けたことについての「ふりかえり」をしようと考えましたが、僕の場合はGitHubへのコミットは独立して存在するものではなく、当ブログを中心としたアウトプットの一環としての位置付けです。そこでこの記事では、ブログ、登壇、GitHubという3つのアウトプットを総体的にふりかえってみようと思います。

この100日間+αでのアウトプットは以下の通りです。これらについて、順にふりかえっていきます。

  • ブログ
    • 頻度:週1回更新
    • 記事数:21本
      • 技術記事:14本
      • 登壇報告:2本
      • イベントレポート:2本
      • その他:3本
  • 登壇
    • 回数:2回
    • 内容:
      • 2018/6/26「行動を無駄にしないために必要なこと」
      • 2018/7/27「httpモジュールから始めるNode.js入門」
  • GitHub
    • 草を生やした日数:100日
    • コミット数*3:227コミット

ブログ(記事21本)をふりかえる

意図:技術の勉強を駆動する&長い文章を書くために

「エンジニアにとってアウトプットをすることが重要である」という趣旨の言説は、しばしば説かれ、少なからざるエンジニアにとって受け容れられているものと思います。あえて権威に訴えようとすれば、Matzの若手エンジニア向けの講演や、『SOFT SKILLS』を挙げることができます。

アウトプットの媒体として、やはり人気があるのはブログでしょう。ブログは簡単に始められますし、内容もタイミングも分量も自由、また顔も声も本名も出ない媒体ということもあって心理的なハードルが相対的に低いのも魅力です。

このような魅力に加えて、僕の場合は長い文章を書くことへの苦手意識があり、それを払拭するためにもブログというアウトプットを選択しました。このあたりについては、ブログの最初の投稿でも書いています。

ky-yk-d.hatenablog.com

週に1回、技術系の記事を書くことをノルマとしていました。イベントレポートなどは、あくまでオプションという位置付けに留めていました。その理由は、僕が「プログラミング大好き!」というタイプの人間ではなく、放っておくと開発手法や組織論といった方向に偏ることがわかっていたからです*4

実績:投稿した記事を一覧にしてふりかえる

投稿記事一覧

No 投稿日 タイトル 分類
1 4/22(日) ブログを始めます。目標:週1更新 その他
2 4/22(日) Tech系ポッドキャストについて(1):t_wadaさんとajitofm その他
3 4/26(木) 4/26「エンジニアリング組織論への招待 ☓ カイゼン・ジャーニー」 に参加しました イベントレポート
4 4/30(月・祝) Tech系ポッドキャストについて(2):しがないラジオについて その他
5 5/4(金・祝) フロントエンドの勉強としてGitHub PagesでダメWebサイトを公開してみました 技術
6 5/14(月) フロントエンド初心者が学ぶ「リンクが展開されるあれ」とVue.js 技術
7 5/17(木) JS初心者がAWS Lambdaで実装するLINE Bot〜「オウム返し」の一歩先〜 技術
8 5/21(月) WebページからDynamoDBにアクセスしてみる〜はじめてのAjax通信とDOM操作〜 技術
9 5/27(日) Vue.js+axiosでDynamo DBにAjax通信する 技術
10 6/3(日) 目指せ!脱Vue.js初心者〜Udemyの"The Ultimate Vue JS 2 Developers Course"を始めた〜 技術
11 6/9(土) フロントエンド弱者が腹を括ってWebpackに触ってみた 技術
12 6/16(土) Vue.jsで作る初めてのSPA〜Udemyの"The Ultimate Vue JS 2 Developers Course"のProject 2を受講した 技術
13 6/20(水) F.O.X Meetup #3 ~スタートアップのチームビルド~ に参加した イベントレポート
14 6/23(土) 環境構築弱者でも簡単に始められるテスト駆動開発〜mocha + power-assert でJavaScriptのテストを書く〜 技術
15 6/27(水) 6/26 「カイゼン・ジャーニー・ライトニングトークス」で初LT登壇した 登壇報告
16 7/1(日) Vue Routerで「ネストされたルート」を試した 技術
17 7/7(土) Vue Routerのナビゲーションガードによるアクセス制限を試した&コードを読み解いた 技術
18 7/16(月) Node.jsのhttpsモジュールを用いた通信処理をPromiseで書き直して解読してみた 技術
19 7/22(日) Node.jsからConnpassのAPIを叩こうとしてつまずいたこと 技術
20 7/28(土) 7/27 WEBエンジニア勉強会 #08 でNode.jsについてLTした 登壇報告
21 8/5(日) Connpass APIをLambdaから扱う〜Lambdaの非同期呼び出しによる分散処理〜 技術

更新頻度については、週1回のペースを守って合計21本の記事を書くことができました。「週1回」というのを「月〜日の間に1回」として、土日のどちらかに書くというのを原則にしていました。月曜日に投稿していることが何回かありますが、これらは全て「日曜日に書こうとして日付が回ってしまった」パターンです(翌日の月曜日、その後の1週間が辛かったことは言うまでもありません)*5

内容についても、「技術系記事を」というのを概ね達成できました(記事の内容についての縛りを目標に追加したのは5月に入ってから)。7月最後の週に投稿した記事は登壇報告ではありますが、スライドの内容にソースコードが含まれているので技術系の投稿ということにしました。こうして並べてみると、Web系の技術、それにAWSについて中心に勉強していたことがわかります。Vue.jsの勉強は最近止まってしまっているので再開したいですね。

感想:ノルマは守れている。しかし、ただそれだけだ。

当初立てたノルマを守ることで、習慣になりつつあることはよいです。当初はまったく更新できる気がしなかったのですが、今では「あー書くかー」くらいの気分で書くことはできています。もっとも、辛いことにはまだまだ辛く、毎週苦しみながら書いているというのが正直なところです*6

技術面の勉強を駆動するという意味でも、平日のうちに勉強しておかないと土日でネタを探すのは辛い*7ので、勉強のネタを探すようになりました。また、日頃のプログラミングの中でエラーに直面したときなどは、「しめしめ、これでブログが書けるぞ」と逆にポジティブに捉えられるようになりました。また、よく言われる「外部記憶装置」としての意義も大きく、一度やったはずのことを忘れてしまった時に自分のブログを見るという機会がすでに何度かありました。


課題は、「技術系の記事を週1」というノルマを達成することで満足してしまっていることです。何度かノルマを引き上げようか検討したこともあったのですが、結局このノルマに安住したままになっています。あくまでノルマなので、当人の心がけ次第ではあるのですが、実情として達成に資する技術系の記事の執筆だけにフォーカスしてしまっているのは確かです。

目標としたいのは、技術系の記事を定期的に投稿しながらも、それ以外の記事もバシバシ投稿するような状態です。記事の質については、上げようとするとペースの方が犠牲になる、あるいは嫌になってしまってブログ自体やめてしまう危険性があるので、当面は過度に意識することはしませんが、もう少しあげられたらとは常々思っています。

登壇(5分間LT×2回)をふりかえる

意図:コンフォートゾーンに留まらない

ブログは自分のペースで書けますし、読みたい人だけ読んでくれればというスタンスで、質をそこまで意識しないでいられます。当初は、ブログを書くだけでも精一杯だと思ったので、これでもよかったのですが、ブログを続けていくなかで、(ノルマを変更しなかったこともあり)自分に満足してしまいそうになっていました。

一方で、アウトプットの別の形として、登壇というのはかなり初期から意識していました。5月半ばに参加した「WEBエンジニア勉強会 #07」の最後に、OSCA(@engineer_osca)さんが勉強会の趣旨を説明されているなかで、登壇歓迎と仰ったのを聴いて以下のようなTweetを残しています。

三点リーダ×2が示しているように、このときは登壇に対してはあまり前向きではなかったと思います。しかしその後、「コンフォートゾーン」という言葉を目にするたびに、自分がアウトプットについてコンフォートゾーンに陥り、そこに留まってしまうことへの危惧を覚えました。そこで、ブログの次は登壇だろうということで登壇することを考えました。

実績:ブログの記事でふりかえる

6月末と7月末に1回ずつ、合計2回のLT(5分間)を経験しました。それぞれ、ブログ記事を書いています。

ky-yk-d.hatenablog.com

ky-yk-d.hatenablog.com

感想:登壇に必要な安心感、学生症候群

エンジニアにはブログを書く人は結構いる印象ですが、登壇する人はその中でもごく一部なのではないかと思います。登壇というのは聴衆の前に身を晒すことですから、(本名を明かす必要こそありませんが)ブログのような気楽さはありません。この心理的ハードルを乗り越える経験ができたのは収穫です。

「勇気を振り絞ってやってやった!」というような書き方をしましたが、登壇については安心して自らを晒すことのできる場の存在があって初めて実現したものだと思います。これまで登壇させていただいたのは、どちらも自分にとってそういう場でした。すなわち、過去のイベントに参加したことがあったり、中心メンバーの方*8と懇親会の場やTwitterなどで交流する機会があったりしたコミュニティです。いきなり見知らぬ人ばかりのイベントで登壇するのは難しくても、このような場で訓練を積んでからであれば心理的にも随分と楽になるのではと思います。

登壇をすることによって気付くことができたこともあります。1週間で1本のブログと異なり、登壇は1ヶ月くらい前から予定が決まるので、準備に使うことのできる時間が長くなります。したがって、ブログでは意識せずに済んだ自分の悪癖を嫌でも思い出させられることになります。それは、学生症候群です。夏休みの宿題に8月下旬まで着手しなかったり、試験前日に慌てて勉強を始めてしまうあれです。学生症候群については、7/27の登壇の報告記事でも書きましたが、これはブログだけやっていたら気付かなかったものだと思います。


感想ということからは少しずれますが、プレゼンという面で、とても印象に残っているのが、ajitofmの和田卓人(@t_wada)さんゲスト回です。テスト駆動開発の伝道師であり、プレゼンテーションの名手として知られる和田さんが、どのようにプレゼンの準備をしているのかを語っています。準備の重要性というのはよく知ってはいますが、登壇をすることでより実感しますし、準備をすることが簡単ではない(単に時間をかければいいというものではない)こともよくわかりました。

ajito.fm

GitHubでの「草生やし」(100日間)をふりかえる

意図:技術から逃げないこと。Write Code Every Day

ブログで技術系の記事を書くのと同じで、技術から逃げないために続けていました。開始当初の下記の記事でもその旨が表明されていました。

技術で解決されるべき問題をエモい話で解決しようとしてしまったり、業務で与えられた技術的課題を自分の技術力の不足によって解決できなかったりするという怖れがある以上、技術の勉強をすることは不可欠だなと考えています。

フロントエンドの勉強としてGitHub PagesでダメWebサイトを公開してみました - こまどブログ

また、Write Code Every Dayというキーワードにも強く背中を押されました。このキーワード自体は、以前から知ってはいましたが、GitHubに草を生やしはじめてから「やってみよう」と思いました。

おじさんになるのも怖かったみたいです。

実績:コントリビューショングラフとTweetでふりかえる

f:id:ky_yk_d:20180811104438p:plain

github.com


書いたコードの内容は以下の通りです。


開始直前〜継続期間中のTweetも載せておきます。

  • 【2018/4/28】 Git/GitHubの使い方を学び始める

  • 【2018/5/3】GitHub Pagesに草を生やす(翌日にブログ投稿)

  • 【2018/5/21】自戒する

  • 【2018/6/22】8週間を達成(継続のために毎日の時間を短縮している)

  • 【2018/8/10】100日間を達成

感想:「草」を目的にすることの功罪

「草が生える」というのは、モチベーションとしてはかなり大きく作用したと思います。途中で何度もコントリビューショングラフのスクショをとって嬉々としてTwitterに貼っていました。他人に見てもらいたいという気持ちが強かったと思います。動機としてはあまり褒められたものではありませんし、そのための弊害も後述するようにありましたが、「草を生やしている自分に酔う」というのはそれなりに使い道のあるものです。

GitHubでの「草を生やす活動」については、良かったことと悪かったことがはっきりあります。まず、良かったこととしては、以下の2点が挙げられます。

  • ブログで技術系の記事を書く準備になった
  • 朝の時間を有効活用できるようになった

「草を生やし続ける」ということは、毎日コードを書くということです。毎日コードを書くことで、ブログに書く材料を継続的に供給することができました。土日だけでネタを探すのは辛いというのは先述の通りですが、平日にも毎日コードを書いていると何かしらネタにはなるわけです。言い方を変えれば、ブログ執筆における学生症候群を防いでいたとも言えるかもしれません。

また、夜は飲み会などがあって時間を確保できない、場合によっては日付が変わってから帰宅することもあるということで、コードはほぼ朝、会社に行く前に書いていました。始める前は、朝は寝坊したり、ネットサーフィンしたりと無駄に使っていたことも多かったのですが、コードを書くようになって有意義に使うことができるようになりました。


一方、悪かったことは以下の2点です。

  • ネタが断片的になった
  • 「草の生えないこと」をしなくなってしまった

毎日書くというのはハードルが高く、続けるために1日あたりの時間は少なくせざるを得ませんでした。じっくり設計について考えたり、方針を考えたりする機会を設けることもしませんでしたから、必然的に書くコードは場当たり的になります。100日間続けた割に、技術を身につけたという感覚に乏しいのは、このあたりの事情もあるでしょう。

また、「草を生やす」を目標にしてしまったことの弊害もありました。最も大きいのは、「コードを書くことではあるのに、草は生えないこと」をしなくなってしまったことです。ブログでも書いたように、UdemyのVue.jsのコースを受講していました。このコースは、講師のGitHubリポジトリからプロジェクトの土台のソースコードをクローンし、そこを編集することで進めて行くものです。しかし、GitHubの仕様上、他人のリポジトリからクローンしたものへのコミットはコントリビューション扱いにならず、草が生えません(当然といえば当然)。

6月半ばごろまでは、Udemyのコースの勉強も進められていました。しかし、少し忙しくなってきてから、これは一番最初に生活から抜け落ちました。理由は当然、それが「草の生えない活動」だからです。講師の方の説明もわかりやすく、実践的な内容でもあったUdemyのコースは、自分としてもモチベーション高く取り組めていたはずのものでした。そうであるにもかかわらず、「草」を優先したのは、もちろん「草を途絶えさせたらコードを書くのをやめてしまう」という危惧があってのことでしたが、このような選択をすることになったノルマの設定の仕方が悪かったことは疑いようがありません。

おわりに

以上、ブログ・登壇・GitHubの3つに分けてふりかえってみました。最後に、全体的な感想と、今後のアクションについてまとめておこうと思います。

全体的な感想

ノルマとして設定したものについては、守ることができている印象を持ちます。もちろん、今回「ノルマ設定した」と書いたこと以外に、Twitterやら何やらで「こうしていく」と宣言したことで、実際にできていないこともあります。しかし、毎日コードを書き、週に1回ブログを書くという明白で基本的なノルマを守ることができたのは、自信になりました。これからもノルマをうまく設定して取り組んでいこうと思います。

一方で、質については修正が必要です。これまでは頻度を維持するため、質を問うことはしてきませんでしたが、習慣化ができつつあるので、既に習慣になっている部分を中心に質も向上させたいです。そのためにも、場当たり的な記事・コードではなく、ある程度の計画をもってアウトプットを組み立てていきたいです。

今後の方針

下記をアクションプランとします。

  • ブログは週に2本で、1本は技術系の記事(2本目は、イベントレポート、書評、雑記など、何でも可)を書く。
  • ブログはすぐに公開せず、必ず推敲する(上から下まで読み通して修正し、修正点がなくなるまでこれを繰り返す)。
  • 2ヶ月に1回は登壇する(ジャンルは問わない)。
  • 1週間に4日はプライベートで1ポモドーロ以上コードを書く(草には拘らず、Trelloで管理)。

ふりかえってみて感じたこと

最後に、今回の記事を書こうとしてみて思ったことを。アウトプットのふりかえりというのが今回の趣旨ですが、ふりかえろうとして思ったのは次のことです。

ブログとGitHubでのアウトプットについては、習慣化というのを強く意識したものでしたが、ふりかえりを同時に習慣に組み込めていなかったのは失敗でした。今回の記事が書きづらかったこともそうですが、ここまでに書いてきた反省点の中には、もっと早く自覚し、修正するアクションを起こすことのできたものも含まれています。

ふりかえりを習慣にするというのは、何度も何度も決心し、その決意を周囲の人に伝えることまでしていたにもかかわらず、結局できずにいることです。もちろん、日々行動しながら「今のはよくなかったな」とか「うまくいっていないな」とかは感じていますが、それは一過性のもので、すぐに忘れてしまいますし、アクションに繋がっていきません。

今回書き出してみて、一度感じていたはずなのに忘れていたことをいくつも思い出しました。おそらく、思い出せていないものもあるはずです。やはり、ブログの記事という形をとるかはともかくとして、「定期的に」「アクションプランを伴って」ふりかえりを行うことが必要だと思いました。

というわけで、アクションプランを追加します。

  • ブログは週に2本で、1本は技術系の記事(2本目は、イベントレポート、書評、雑記など、何でも可)を書く。
  • ブログはすぐに公開せず、必ず推敲する(上から下まで読み通して修正し、修正点がなくなるまでこれを繰り返す)。
  • 2ヶ月に1回は登壇する(ジャンルは問わない)。
  • 1週間に4日はプライベートで1ポモドーロ以上コードを書く(草には拘らず、Trelloで管理)。
  • 1ヶ月に1回ふりかえりの記事を書く(その週の2本のうちの1本としてよい)。
  • 月次のふりかえりでは方針の見直しを必ずする(これ自体も見直す)。

この記事を書いていたら、土曜日が終わってしまいました(扱う対象も記事自体も大きすぎる)。コードを書いていないので、GitHubの草も途切れました。変なものに執着しても仕方がないので、来週から上記の方針でまた気分を入れ替えて頑張って行こうと思います。乞うご期待。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル


Special Thanks to @kakakakakku

僕がアウトプットについてふりかえるとき、欠くことのできない人がいます。それは、カカカカック(@kakakakakku)さんです。ここまでの記事では、彼への言及は全て脚注に落としておきましたが、それは本文に出すと「アウトプットのふりかえり」という記事の趣旨がブレるからです。とはいえ、最後に言及しておかなければなりません。

ブログを書こうと思ったきっかけをくれたのも、マネジメント方面に傾く僕に敢えて技術系の記事を書くように勧めてくれたのも、ブログの書き方を教えてくれたのも、困ったときにネタを提案してくれたのも、登壇に向けて背中を押してくれたのも、カカカカックさんです。僕がアウトプットを曲がりなりにも続けられているのは、カカカカックさんのおかげです。感謝します。思い切ってお願いして良かったです*9

*1:本来は他人のリポジトリへのプルリクエスト等で「貢献」した実績がこのグラフに表れるべきなのでしょうが、僕の場合はすべて自分のリポジトリへのコミットだけです。OSSコントリビュートもできるようになれるとエンジニアとしては一段階上がる感じがしますが……

*2:アクセスしてみると、6/1については草が生えて見えるときとそうでない時があります。この日は、他のユーザからリポジトリをフォークして、そこに対して修正を加えていた日で、厳密には草を生やしたことになるのか怪しいのですが、実態としてコードを書いてはいたのでアリとしています。

*3:自分のリポジトリに対してなのでこの数字に意味はありませんが。

*4:この傾向は自覚はしていましたが、それを踏まえて「技術系を週1」というノルマを提案してくれたのはカカカカックさんでした。

*5:日付が変わってしまって月曜日から寝不足で会社に行くのはサラリーマン的には褒められた行為ではありませんから、合理的な判断としてブログを翌日に先送りする選択をすることもできたと思いますが、ブログを書かないと眠れないのです。

*6:三大欲求の一角を「ブログ欲」が突き崩してしまった方も世の中にはいるようですが……。

*7:カカカカックさんからも指摘を受けました。

*8:カイゼン・ジャーニー』の著者の市谷(@papanda)さんと新井(@araratakeshi)さん、WEBエンジニア勉強会のOSCAさん。

*9:5月から2ヶ月間、「ブログメンティ」として上記のようなサポートを受けました。その内容については、他のメンティのみなさんが卒業エントリとして書いているものをご参照ください。