Hideaki KANO (hkano)

ゆるふわアジャイラーです。noteらしくエモいポエムを書いていきます。 https:/…

Hideaki KANO (hkano)

ゆるふわアジャイラーです。noteらしくエモいポエムを書いていきます。 https://hkano.com https://twitter.com/hkano

最近の記事

PHPカンファレンス2019に登壇してきました(スポンサー枠で)

この記事は、「弁護士ドットコム Advent Calendar 2019 - Qiita」の7日目の記事です。ラッキー7ですね。PHPの最新メジャーバージョンも7ですね。よろしくお願いします。 ということで、12月1日に開催された「PHPカンファレンス2019」にスポンサー枠で登壇してきました。 この記事はその顛末と感想をまとめたものです。思ったことをざっくばらんに書こうかと思います。登壇時の発表内容と違って個人の感想が多く含まれていますので、個人のnoteに書かせていた

    • コミュニケーションの「成功」について

      みなさんはコミュニケーションをする時、何を意識しているでしょうか。 この時、自分の伝えたいことを一方的に話していないでしょうか。それで相手は理解できているのでしょうか。それどころか、そもそもまともに聞いてすらいない可能性もあります。当然、その後の行動も変化しません。(悪化することすらあります。) これはコミュニケーションが「失敗」しています。 コミュニケーションにおいて、「成功」しているか「失敗」しているか、これはとても重要です。 コミュニケーションは「相手に何かをして

      • 「曖昧耐性」について

        「曖昧(あいまい)」という言葉は、あまり良い意味で使われていないと思います。 しかし、果たして本当にそうでしょうか。曖昧さは完全に無くした方が良いのでしょうか。 確かに、慎重さや確実性が必要な仕事では曖昧さは無くすべきでしょう。しかし、多くの仕事は不確実性を持っていて、対応するには柔軟さの方が必要になります。 そのような時に、「ちゃんと決まってないと動けません!」などと言ってはいけません。明確に決め過ぎると、決まった範囲で既得権益が生まれ、狭い範囲の仕事を好むようになりま

        • 実践的モデラーについて

          このエントリーは「ドメイン駆動設計 \#2 Advent Calendar 2018」の20日目です。(1日遅れですが、空いていたので登録させていただきました。) はじめにドメイン駆動設計(Domain-Driven Design)にはドメインを反映したモデルを作り上げるためのいくつかの要素があり、それらは戦略的設計と戦術的設計に分類できます。(戦略的設計をマインド、戦術的設計をパターンと呼ぶ人もいます。) 戦略と戦術、どちらも等しく大事です。(戦術だけ実践した

        PHPカンファレンス2019に登壇してきました(スポンサー枠で)

          「人に期待しない」という考え方について

          「人に期待しない」という考え方を聞くことがあります。 「過度に期待するよりも期待しない方が楽」だし「そもそも人はそんなに思い通りに動いてくれない」ということのようです。 これだけだと「ただ諦めている」だけのようにも読み取れます。しかし本当にそうなのでしょうか。一方、「人に期待する」ことが正しいのでしょうか。「人への期待」とは何なのでしょうか。 「人に期待する」とはどういうことでしょうか。 何かを伝え、伝えた意図通り(か、それ以上)の行動をしてくれれば「期待通り(か、それ以

          「人に期待しない」という考え方について

          「信頼」について

          チームにおける「信頼」についてです。 チームは、メンバーがお互いに補完し合うことで力が増します。補完し合わないのであればチームにする必要はありません。よくある例えで「足し算ではなく掛け算」などと言ったりします。2人なら「2」ではなく「3や4、それ以上」の力を発揮するとこを目指します。 補完し合うと言ってもお互いの補う点がきれいに分かれることは稀で、基本的には職能や与えられている責務などで作業をざっくり分けて割り振ります。その結果、自分の方が知識や能力があると思う領域であっ

          「信頼」について

          「優先度」について

          システム開発において、「優先度」決めは非常に大事になります。 ターゲット(市場・ユーザー)を決め、企画・要件を決め、ストーリーを決め、タスクを決め、結果「あれもこれも大事」という状況は往々にして存在します。 そのような状況で「人を増やして解決する」も一案ですが、「人月の神話」に陥ることが多いと考えられます。最終的には優先度を決めて、高いものから一つずつ対応することになります。 ですが、それでも「全て大事で、優先度は決められない」と言ってしまう場合があります。何故でしょう

          「優先度」について

          「泥」の許容について

          システム開発における「泥」というメタファーについてです。 「現実は泥臭い」と許容すると「泥臭いシステム」ができてしまいます。やがて「巨大な泥団子」になります。「泥臭さ」を取り去らずに分割られて「複数の泥団子」ができます。「分割された泥団子」は分割されたチームで運用されます。文字通り「泥を被る」ことになってしまいます。 なので「泥臭くやりたいなら勝手にやってくれ」と言う訳にはいかないのです。泥臭さを排除するのがエンジニアのマインドセットです。直ぐに排除できなくても影響範囲を

          「泥」の許容について